K8s生产环境最佳实践：从集群规划到安全运维的进阶指南

1. 从“能用”到“好用”：为什么2022年的K8s最佳实践依然值得深挖

最近在整理团队的技术资产，翻到了去年做的一次关于K8s和Rancher 2.x的内部培训材料。当时正值容器化浪潮从“尝鲜”转向“深耕”的阶段，很多团队已经完成了从零到一的搭建，但随之而来的是一系列“幸福的烦恼”：集群规模上来了，管理却越来越乱；应用部署是快了，可线上故障排查却慢了；YAML文件堆成了山，没人敢轻易改动。我们那套课程，核心就是解决这些问题——不是教你如何安装一个K8s集群（这太基础了），而是聚焦于如何让一个已经运行起来的K8s生产环境，变得更稳定、更高效、更易于运维。

时间到了现在，虽然K8s的版本已经迭代了很多，但你会发现，当时梳理的那些核心原则和“坑点”，不仅没有过时，反而因为大家踩的坑更多，显得愈发重要。比如，如何设计命名空间和资源配额来避免“一颗老鼠屎坏了一锅粥”，如何利用Rancher的多集群管理功能实现真正的“云原生”运维视图，以及如何将CI/CD流水线与K8s的声明式API深度结合，而不是简单地在容器里跑个Jenkins。这些都不是版本更新就能自动解决的，它们关乎架构理念和运维习惯。

所以，我想把这些沉淀下来的东西重新梳理一遍，结合这两年看到的新问题和新工具，形成一份更聚焦于“最佳实践”的分享。这份内容适合已经对K8s和Docker有基本了解，正在或计划将K8s用于生产环境的开发者、运维和架构师。我们会跳过“kubectl get pods”这种入门命令，直接深入到集群规划、应用部署、安全加固和日常运维的“深水区”。

2. 生产级集群规划与资源治理：超越简单的kubeadm init

很多教程止步于用kubeadm或RKE（Rancher Kubernetes Engine）把集群跑起来，但这离生产就绪还差得远。一个健康的集群，首先源于良好的顶层设计。

2.1 节点规划与隔离策略：计算、存储与网络的考量

在物理机或云主机层面，我们强烈建议将控制平面节点（Master）与工作节点（Worker）彻底分离。对于中小规模集群（比如20个节点以内），三个控制平面节点组成高可用（HA）模式是性价比最高的选择。这里有个细节：控制平面节点的配置（特别是内存和磁盘IOPS）往往被低估。Etcd是集群的大脑，对磁盘延迟极其敏感。如果你把Etcd和数据盘放在同一块机械硬盘或普通云盘上，集群响应慢、甚至莫名故障的几率会大增。最佳实践是，为Etcd单独配备高性能的SSD盘，并确保网络延迟在毫秒级。

工作节点的规划则要结合业务特点。我们通常采用“混合部署+污点容忍”策略。例如：

• 通用计算节点池：无特殊标签，运行大多数无状态应用。
• 高IO节点池：打上标签node-type: high-io，并加上污点disk=ssd:NoSchedule。只有明确声明了对应容忍（Toleration）和节点选择器（NodeSelector）的Pod（比如MySQL、Redis）才能调度上去。
• GPU节点池：打上标签accelerator: nvidia-tesla-v100，用于AI训练或图形处理任务。

在Rancher 2.x中创建集群时，你可以直接在“节点模板”里预设这些标签和污点，后续通过“节点池”功能批量管理，这比手动到每台机器上打标签要规范高效得多。

2.2 命名空间（Namespace）设计：逻辑隔离与资源配额

命名空间不是简单的文件夹，它是资源配额、网络策略和权限控制的天然边界。一个常见的反模式是把所有应用都扔在default命名空间里。我们的实践是：

• 按团队/项目划分：如namespace: team-a，namespace: project-eagle。这是最直观的划分方式。
• 按环境划分：dev,staging,prod。特别注意：不建议在命名空间名中直接使用prod（生产）。因为任何有list namespace权限的人都能一眼看到哪些是生产环境，增加了安全风险。可以用一些内部项目代号，如namespace: blue（生产），namespace: green（预发布），再通过RBAC控制访问权限。
• 按应用类型划分：infra（用于运行Prometheus、EFK等基础设施组件），middleware（用于MySQL、Kafka等中间件）。

每个命名空间都必须配套资源配额（ResourceQuota）。这是防止某个应用失控、耗尽集群资源的关键阀门。一个基础的Quota配置如下：

apiVersion: v1 kind: ResourceQuota metadata: name: compute-resources namespace: project-eagle spec: hard: requests.cpu: "20" # 最多申请20个CPU核 requests.memory: 40Gi # 最多申请40Gi内存 limits.cpu: "40" # 所有Pod的CPU限制总和不能超过40核 limits.memory: 80Gi pods: "100" # 该命名空间最多100个Pod services.loadbalancers: "5" # 最多5个负载均衡器（云厂商收费）

通过Rancher UI，你可以非常直观地为每个命名空间创建和调整Quota，并且能实时看到资源的使用率，这对于成本控制和容量规划至关重要。

2.3 网络策略（NetworkPolicy）入门：默认拒绝一切

K8s集群内，Pod之间默认是网络全通的。这意味着一旦某个Pod被攻破，攻击者可以扫描并攻击集群内任何其他服务。生产环境必须实施“零信任”网络模型。

第一步，也是最重要的一步，是在每个命名空间下创建一个默认拒绝所有入站和出站流量的策略：

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: your-namespace spec: podSelector: {} # 选择所有Pod policyTypes: - Ingress - Egress

创建这个策略后，该命名空间内所有Pod将失去网络连接。然后，你再像砌墙一样，通过白名单方式，逐个添加允许访问的规则。例如，允许前端Pod访问后端API：

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend-to-backend namespace: your-namespace spec: podSelector: matchLabels: app: backend-api policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: frontend-web ports: - protocol: TCP port: 8080

这个过程虽然繁琐，但能极大提升集群内部的安全性。Rancher的UI提供了可视化的网络策略编辑器，降低了配置复杂度，但理解其背后的原理仍然必要。

3. 应用部署与配置管理的进阶之道

部署一个Deployment只是开始，如何让它健壮、可观测、易于回滚，才是体现功力的地方。

3.1 工作负载（Workload）配置的黄金法则

1. 永远定义资源请求（requests）和限制（limits）这是稳定性的基石。不设置requests，调度器就不知道你的Pod需要多少资源，可能导致节点超卖；不设置limits，单个Pod可能吃光节点资源。一个经验值是：limits通常是requests的1.5到2倍，给应用留出一定的突发缓冲，但又不至于失控。

resources: requests: memory: "256Mi" cpu: "250m" limits: memory: "512Mi" cpu: "500m"

2. 配置就绪和存活探针（Readiness/Liveness Probe）这是实现“自愈”能力的关键。很多应用启动慢，或者运行中会卡死。

• 存活探针（Liveness）：检测应用是否“活着”。失败则重启Pod。适用于死锁场景。
• 就绪探针（Readiness）：检测应用是否“准备好”接收流量。失败则将其从Service的负载均衡端点中移除。适用于启动依赖（如连接数据库）或临时过载场景。 一个常见的坑是探针配置不当导致频繁重启。例如，一个Java应用启动可能需要60秒，但你把initialDelaySeconds设成了5秒，结果应用还没启动完就被探针杀死了。务必根据应用实际启动时间设置合理的延迟。

3. 使用多副本（Replicas）和Pod反亲和性（PodAntiAffinity）对于关键应用，至少运行2个副本。并且，通过podAntiAffinity确保这些副本被调度到不同的物理节点上，避免单点故障。

affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - my-critical-app topologyKey: kubernetes.io/hostname # 确保Pod不在同一主机

3.2 ConfigMap与Secret：告别环境变量硬编码

把配置写在Deployment的YAML里是初级做法。最佳实践是使用ConfigMap和Secret来管理配置。

• ConfigMap：存储非敏感的配置，如配置文件内容、环境变量。
• Secret：存储敏感数据，如密码、令牌、密钥。虽然Secret默认以Base64编码存储（并非加密），但K8s会对其提供更多保护（例如，在内存中不以明文存储）。

更高级的用法是以卷（Volume）的形式挂载ConfigMap，这样应用配置文件可以动态更新。在Rancher中，你可以在UI里轻松创建、编辑这些配置对象，并绑定到工作负载，比手写YAML更直观，且减少了出错几率。

关于那个常见错误k8s configmap执行脚本 permission denied：这通常发生在你将一个Shell脚本作为ConfigMap挂载到容器中，并尝试执行它时。ConfigMap挂载的文件默认权限是644（即-rw-r--r--），而执行脚本需要x（执行）权限。解决方法有两种：

1. 在容器启动的初始化容器（initContainer）里，用chmod +x命令修改脚本权限。
2. 更优雅的做法是，不要通过ConfigMap挂载可执行脚本，而是将脚本内容作为配置参数，在容器的主进程（如通过sh -c）中动态生成并执行。

3.3 有状态应用（StatefulSet）部署实战：以PostgreSQL为例

部署无状态应用（Deployment）和部署有状态应用（StatefulSet）是两回事。后者涉及稳定的网络标识、有序的部署/扩缩容和持久化存储。

以在K8s中部署高可用的PostgreSQL（使用Crunchy Data的PostgreSQL Operator是一种更佳选择，但这里演示原生方式）为例，你需要关注：

1. Headless Service：为每个Pod提供唯一的、稳定的DNS名称，格式为<pod-name>.<svc-name>.<namespace>.svc.cluster.local。
2. 持久化存储卷（PVC）：使用volumeClaimTemplates，每个Pod会自动绑定一个独立的PVC，即使Pod被重新调度，数据也会跟随。
3. 初始化容器（Init Containers）：用于在主容器启动前，进行数据目录初始化、权限设置等操作。

在Rancher的“应用商店”中，其实已经有很多经过验证的有状态应用模板（如Redis、PostgreSQL集群），它们已经帮你处理了这些复杂逻辑，我强烈建议优先使用这些成熟方案，而不是自己从头造轮子，尤其是在生产环境。

4. 运维、监控与故障排查体系化建设

系统上线后，运维才刚刚开始。如何快速发现问题、定位根因、恢复服务，是更大的挑战。

4.1 构建中心化日志与监控体系

日志：所有容器的标准输出（stdout/stderr）都应该被采集。使用Fluentd或Filebeat作为日志收集代理（DaemonSet部署），将日志发送到Elasticsearch或Loki，并通过Grafana进行可视化查询。关键点是给日志加上丰富的标签（如namespace,pod_name,app），方便过滤。

监控：分为四个层次：

1. 基础设施监控：节点CPU、内存、磁盘、网络。通过Node Exporter采集。
2. K8s组件监控：API Server、Scheduler、Controller Manager、Etcd等的状态和性能。这些组件的Metrics端口通常已暴露。
3. 应用业务监控：通过应用自身暴露的Prometheus格式的Metrics。
4. 中间件监控：数据库、消息队列等组件的状态。

你提到的“prometheus监控k8s集群状态的详细操作，注意prometheus在k8集群外”，这是一个非常典型的场景。核心步骤如下：

1. 在集群外部署Prometheus Server：避免监控系统本身故障影响集群。
2. 在K8s集群内部署Prometheus的抓取代理：通常是prometheus-node-exporter（DaemonSet，抓节点指标）和kube-state-metrics（Deployment，抓K8s对象状态）。它们将Metrics暴露在HTTP端口上。
3. 让集群外的Prometheus能够发现并抓取这些目标：这是关键。不能直接用Pod IP，因为IP会变。你需要创建对应的Service，然后有两种主流方式：
   • 通过Service的NodePort：为每个Metrics Service创建NodePort，集群外的Prometheus通过<NodeIP>:<NodePort>来抓取。简单但不安全，且需要管理一堆端口。
   • 通过API Server代理或Ingress：更安全的方式。让Prometheus配置抓取目标为K8s API Server的地址，并指定路径为/api/v1/namespaces/<namespace>/services/<service-name>:<port>/proxy。这需要Prometheus具有访问API Server的权限（配置RBAC和Bearer Token）。或者，通过一个对外的Ingress统一暴露这些Metrics端点，并配置安全认证。
4. 配置Prometheus的scrape_configs：使用kubernetes_sd_configs自动发现集群内的Service或Pod，并利用relabel_configs进行过滤和重写标签，最终生成正确的抓取地址。

4.2 通用故障排查思路：从现象到根因

当收到报警“k8s虚拟机cpu占用率太高”或“服务不可用”时，一个清晰的排查路径能节省大量时间。

第一步：确定问题边界

• 是个别Pod的问题，还是整个Service或Deployment的问题？
• 是单个节点的问题，还是整个集群的问题？
• 问题发生的时间点，是否和最近的部署、配置变更有关？

第二步：逐层排查

1. 查看事件（Events）：kubectl describe pod <pod-name> -n <namespace>。Events信息是黄金线索，会告诉你Pod为什么卡在Pending（资源不足、节点选择器不匹配），为什么CrashLoopBackOff（启动失败），为什么被驱逐（节点资源压力）。
2. 查看Pod状态和日志：kubectl logs <pod-name> -n <namespace> --previous（查看前一个容器的日志，对于崩溃的Pod尤其有用）。
3. 检查资源使用：kubectl top pod/node查看实时的CPU/内存使用情况。结合监控图表，看是持续高位还是瞬间尖峰。
4. 检查网络连通性：进入Pod内部（kubectl exec -it），用curl或nslookup测试到其他服务或外部的网络连接。检查NetworkPolicy是否配置过严。
5. 检查存储：如果是有状态应用，检查PVC/PV的状态是否为Bound，挂载是否成功。

第三步：深入组件如果怀疑是K8s系统组件问题：

• kubectl get cs检查组件健康状态。
• 查看对应组件的日志。例如，调度器问题看kube-scheduler日志，网络问题看CNI插件（如Calico的calico-node）日志。

在Rancher中，这些排查工作得到了极大简化。其“集群管理”视图直接集成了Pod日志查看、事件流、容器Shell终端，以及资源监控图表，你可以在一个统一的界面里完成上述大部分操作，无需在多个命令行窗口间切换。

4.3 关于“若依（RuoYi）”等系统部署的特别提醒

你提到了“ruoyi-cloud k8s 完整部署教程”和“若依k8s部署”。对于这类复杂的、多服务的Java微服务系统，直接将其所有组件打包成镜像扔进K8s，会遇到很多挑战：

• 服务发现：系统可能依赖Eureka或Nacos。在K8s内，可以继续使用它们，但更云原生的做法是逐步迁移到K8s Service + Ingress的组合，或者使用Service Mesh（如Istio）。
• 配置管理：若依有自己的配置中心。需要处理好其与K8s ConfigMap/Secret的边界。通常，应用启动的引导配置（如连接配置中心的地址）用ConfigMap，业务动态配置走原有的配置中心。
• 数据库迁移：生产环境数据库强烈不建议部署在K8s内，除非你使用经过严格测试的Operator并具备专业的运维能力。建议将MySQL、Redis等中间件部署在集群外的高可用托管服务上，或独立的物理机/虚拟机中。
• 文件存储：这类系统常有文件上传功能。需要配置持久化存储卷（如NFS、Ceph RBD或云存储），并注意多个Pod实例间的文件共享与同步问题。

部署这类系统的关键，是先画出一张清晰的架构图，标明每个服务、中间件、配置源和存储的部署位置（集群内/外），以及它们之间的依赖关系和网络访问路径。然后，分批次、分服务地进行容器化和部署，而不是搞“大爆炸”式迁移。

5. 安全、备份与持续交付闭环

安全不是功能，而是基础；备份不是选项，而是必须。

5.1 最小权限原则与RBAC实践

Rancher 2.x自带了强大的、基于项目的RBAC（角色基于访问控制）体系。你应该：

1. 为每个用户或组创建独立的账号，而不是共享管理员账号。
2. 利用“项目（Project）”进行逻辑分组：在Rancher中，项目是命名空间的集合。你可以将dev、staging命名空间放入一个“开发项目”，将生产环境的命名空间放入“生产项目”。
3. 分配“项目成员”角色：例如，给开发人员“项目只读”或“项目成员”角色，他们只能在自己所属的项目内操作资源，无法看到或影响其他项目（如生产环境）。
4. 定期审计：利用Rancher的审计日志或集成外部SIEM系统，监控所有关键操作（如删除Pod、修改Service）。

对于需要kubectl命令行访问的情况，可以通过Rancher生成并下载针对特定集群、具有特定权限的Kubeconfig文件，实现精细化的权限控制。

5.2 不可或缺的备份与灾难恢复

即使用了高可用架构，没有备份也是裸奔。你需要备份：

1. 集群资源定义：使用velero（原名Heptio Ark）这类工具，定期备份整个命名空间或特定标签的资源YAML文件。
2. 持久化数据：这是最关键的。Velero可以通过插件备份PVC数据到对象存储（如S3）。务必定期进行恢复演练，确保备份是有效的。
3. Etcd数据：这是K8s集群状态的核心。虽然Velero也能备份，但更底层的做法是定期对Etcd的数据目录进行快照（etcdctl snapshot save）。在通过RKE部署的集群中，Rancher提供了便捷的Etcd备份与恢复功能，建议配置定时自动备份到远程位置。

5.3 打造GitOps风格的持续交付流水线

最终的理想状态是实现GitOps：将应用的所有声明式配置（K8s YAML、Helm Charts）存储在Git仓库中。Git仓库中的main分支状态，就是你期望的生产环境状态。

具体流程可以是：

1. 开发人员提交应用代码到Git。
2. CI流水线（如Jenkins、GitLab CI）触发，构建Docker镜像并推送到镜像仓库，同时生成或更新对应的K8s部署清单（如kustomize overlay、helm chart values.yaml），提交到另一个“配置仓库”。
3. GitOps工具（如Argo CD、Flux CD）持续监视“配置仓库”。一旦发现配置变更，它自动将变更同步到目标K8s集群，使集群状态与Git仓库声明的一致。

Rancher 2.x可以与Argo CD等工具很好地集成，你可以在Rancher UI中直接看到来自Argo CD的部署状态和同步历史，实现可视化的持续交付管理。这比单纯的在Jenkins里执行kubectl apply要可靠和清晰得多，因为所有变更都有版本记录，且可以一键回滚到Git中的任何一个提交。

走到这一步，你的K8s之旅才算真正从“技术实验”迈入了“生产实践”的成熟阶段。整个过程充满了细节和权衡，没有一劳永逸的银弹，但遵循这些从大量实践中总结出的最佳实践，至少能让你避开80%的常见深坑，构建出一个既强大又易于驾驭的容器化平台。