爱主机如果你已经在生产环境中部署过Kubernetes，你一定会认同：K8s的入门曲线并不陡峭，但把集群跑稳、跑久、跑得安全，则是另一回事。很多团队在初期尝到容器化带来的快速迭代甜头后，很快会遇到资源争抢、配置混乱、权限失控、故障恢复慢等一系列问题。这些问题的根源往往不是Kubernetes本身不够好，而是缺少一套系统性的最佳实践。下面我从命名空间设计、Pod声明规范、配置管理、网络安全、存储可靠性、资源控制、自动化运维以及监控告警八个维度，分享经过生产验证的Kubernetes最佳实践。
首先，命名空间与租户隔离是集群治理的起点。不要把所有资源都丢进default命名空间。建议按照环境层级划分：prod、staging、dev，或者按照业务团队划分：team-a、team-b，再配合ResourceQuota和LimitRange控制每个命名空间的资源上限。细节上，ResourceQuota硬性限制CPU和内存总量，LimitRange则给每个Pod设定默认请求与限制，防止单个Pod无限占用集群资源。同时，通过NetworkPolicy实现命名空间间的隔离，默认拒绝所有跨命名空间流量，再按需允许特定端口和标签的通信。这套组合拳下来，不同业务单元既互相独立，又共享同一集群，运维压力大幅下降。
其次，Pod的设计是Kubernetes应用的最小粒度，也是最佳实践最容易忽略的地方。一个Pod内，主容器只做一件事，Sidecar容器负责辅助功能，比如日志转发、配置重载、监控指标暴露。Init容器用于初始化数据或等待依赖服务就绪。健康检查必须配置两种探针：livenessProbe用于检测进程是否存活，readinessProbe用于判断Pod是否可接收流量。探针的路径、端口、初始延迟和超时时间要根据应用启动耗时来调整，避免因启动慢而被反复杀死重启。另外，Pod的优雅终止需要结合preStop钩子以及terminationGracePeriodSeconds参数，让应用在收到SIGTERM后有时间完成正在处理的请求。
配置管理方面，不要将敏感信息写入镜像或硬编码进YAML。Secret用于存放密码、Token、证书，但默认Secret只是Base64编码，并不安全。生产环境建议配合外部密钥管理系统，比如HashiCorp Vault、AWS Secrets Manager，通过CSI驱动程序或者Sidecar注入动态获取真实凭证。ConfigMap适用于非敏感的配置文件，但要注意ConfigMap更新后Pod不会自动重载，需要借助Reloader这类工具来滚动重启。对于更复杂的配置变更，建议采用Kustomize或Helm管理参数化部署，避免手动修改YAML导致的漂移。
网络安全是Kubernetes集群最容易出漏洞的环节。在RBAC层面，遵循最小权限原则：为每个ServiceAccount只分配其需要的操作，不要随意绑定cluster-admin角色。Pod安全策略目前已被Pod Security Standards取代，通过标签强制执行privileged、baseline或restricted三种安全策略，禁止特权容器、禁止挂载主机路径、只允许只读文件系统等工作负载。网络策略方面，除了命名空间间的隔离，还应在关键服务上配置Ingress和Egress的精确规则，比如只允许前端Pod访问后端Pod的特定端口，防止横向扩散攻击。
存储与有状态应用是Kubernetes最复杂的领域之一。无状态应用可以随意漂移，但数据库、消息队列等有状态服务需要持久化存储。StorageClass要指定回收策略为Retain或Delete，根据业务数据的重要性选择。StatefulSet配合VolumeClaimTemplate可以为每个Pod自动创建独立的PV，保证Pod重新调度后能绑定原先的数据卷。但在生产环境，建议不要在Kubernetes内直接运行核心数据库，而是使用云厂商托管的数据库服务，让Kubernetes只管理应用层。如果确实需要自建，记得配置PodDisruptionBudget来限制节点维护时同时宕机的Pod数量，避免数据写入丢失。
资源限制与自动伸缩是实现成本控制和弹性保障的关键。每个Pod的requests和limits必须配置，否则一旦某个容器内存泄漏就会拖垮节点。HPA根据CPU、内存或自定义指标自动调整副本数，VPA则自动调整Pod的资源请求，两者可以配合使用：先用VPA分析出合理的资源基线，再基于HPA做水平伸缩。对于突发流量，Cluster Autoscaler会在节点资源不足时自动扩容节点，但要注意节点池的实例类型要匹配工作负载的CPU和内存需求，避免产生大量碎片资源。
自动化运维方面，GitOps已经成为主流模式。将集群的期望状态提交到Git仓库，通过ArgoCD或Flux自动将变更同步到集群，不仅实现了版本控制、审批流水线，还能在集群故障后快速重建。CI/CD流水线中，镜像构建完成后要用trivy或clair扫描漏洞，并在Kubernetes中通过Kyverno或OPA Gatekeeper进行准入控制，禁止部署携带高危漏洞的镜像。对于Helm Chart的升级，推荐使用helm diff插件先预览变更，再执行升级，必要时启用helm rollback。
监控与告警是运维的最后一道防线。Prometheus搭配Grafana是标准组合，但要注意指标采集的稳定性：尽量使用ServiceMonitor和PodMonitor通过Operator自动发现目标，避免手动配置。告警规则不要过于敏感，最好基于持续时间来滤除瞬时的抖动。日志收集方面，fluentd或fluentbit采集Pod日志发送到Loki或Elasticsearch，注意控制日志采集的元数据量，避免索引膨胀。另外，集群资源使用率的趋势预测也很重要，通过kube-state-metrics和node-exporter的指标可以提前发现磁盘空间不足、CPU平均负载过高的问题。
以上八个维度并不是孤立的，它们相互制约也相互促进。比如良好的命名空间隔离能降低网络策略的复杂度，资源限制又为自动伸缩打下基础，GitOps则让配置管理变得可审计。真正实践Kubernetes最佳预算的过程，就是不断把人工判断转化为自动规则，把经验沉淀为代码的过程。
不要期望一次改造就能达到最佳状态。每半年复盘一次资源使用率、安全策略覆盖率、Pod健康检查失败率等数据，根据业务增长调整ResourceQuota和HPA阈值，并关注Kubernetes社区的新特性，比如Gateway API、Service Mesh的演进。最终，Kubernetes最佳实践会变成团队的一种习惯，而不是一份需要死记硬背的文档。当你的集群能够自主应对节点故障、流量波峰和安全扫描，你的团队就能把更多精力留给业务创新，这才是运维Kubernetes的真正价值。
