贝壳主机网
注意：部分文章发布时间较长，可能存在未知因素，购买时建议在本站搜索商家名称，先充分了解商家动态。
交流：唯一投稿邮箱：hostvps@88.com。
引言
如果你的团队已经迈过了Kubernetes的入门门槛，Pod能调度、Service能访问、Deployment能滚动更新，那么恭喜你，你已经解决了“能不能用”的问题。但真正的挑战才刚刚开始：当集群规模从几个节点扩展到几十个节点，当应用从单体拆分成几十个微服务，当故障从偶发变成常态，你很快会发现，仅仅“能跑”远远不够。Kubernetes提供了一整套强大的原语，但它的灵活性也意味着，错误的使用方式会带来同样强大的反噬。这篇文章不打算重复官方文档里的基础概念，而是聚焦于那些决定生产环境稳定性、效率和成本的关键实践，帮助你从“能跑”走向“跑得稳”。
资源请求与限制：别再凭感觉写数字
最容易被忽视却又最容易引发事故的，就是资源配置。很多开发者习惯在Deployment里随意填上requests和limits，或者干脆不填。这会导致两个极端：要么Pod因为资源不足被频繁驱逐或OOMKilled，要么节点资源大量闲置却无法调度新的Pod。最佳实践是，先用垂直Pod自动扩缩容（VPA）在测试环境观察应用的真实资源画像，运行一周左右，取P99或P95分位值作为requests，再乘以1.2到1.5的安全系数作为limits。对于有明确峰值的业务，可以考虑使用HorizontalPodAutoscaler（HPA）结合自定义指标，而不是盲目放大资源。另外，务必为关键工作负载设置PriorityClass，确保资源紧张时低优先级的批处理任务先被驱逐，而不是核心服务被牺牲。
命名空间与标签：你的集群不是垃圾场
随着微服务数量增加，集群里的资源对象会呈指数级增长。如果没有清晰的命名空间规划和标签体系，你将很快陷入“这个Pod是哪个服务的？这个Service归属于哪个环境？”的混乱中。强烈建议按照“环境-团队-应用”三层结构划分命名空间，例如prod-frontend、staging-backend。同时，强制推行标签规范，至少包含app、version、tier、environment四个标签。这些标签不仅是查询和筛选的基础，更是网络策略、资源配额和监控告警的核心依据。使用Kyverno或OPA Gatekeeper这类策略引擎，在CI/CD流水线中强制校验标签和命名空间是否符合规范，从源头杜绝脏数据。
探针配置：让K8s真正“感知”应用健康
很多人把存活探针和就绪探针混为一谈，或者只配置了存活探针。这是一个严重的误解。存活探针决定Pod是否重启，就绪探针决定Service是否将流量转发到Pod。正确的做法是：就绪探针应该反映应用是否能够处理新请求，比如检查数据库连接池是否可用、缓存是否预热完成；存活探针则应该只检测进程是否死锁或陷入不可恢复的僵尸状态。探针的初始延迟和超时设置同样关键，如果延迟时间设置过短，应用启动稍慢就会被反复重启，形成恶性循环。建议结合启动探针（startupProbe）来保护慢启动应用，给初始化留出充足时间，然后再启用存活和就绪探针。
优雅停机与滚动更新：别让用户感受到抖动
默认情况下，Pod被删除时会收到SIGTERM信号，但如果应用没有处理这个信号，它会被强制杀死，导致正在处理的请求中断。最佳实践是，在应用代码中捕获SIGTERM，停止接收新请求，等待现有请求处理完毕（通常设置30秒的宽限期），然后主动退出。同时，Deployment的滚动更新策略需要精细调优：maxUnavailable设为0，maxSurge设为1或25%，确保更新过程中始终有旧版本Pod在服务。配合preStop钩子（比如sleep 5秒）和terminationGracePeriodSeconds（设置为60秒），可以极大减少更新期间的错误率。这些细节，往往就是用户感知“稳定”与“不稳定”的分水岭。
网络策略与安全上下文：安全不是事后诸葛
默认情况下，Kubernetes集群内的Pod之间可以自由通信，这等于给攻击者敞开了大门。启用NetworkPolicy，按照“默认拒绝，白名单放行”的原则，为每个服务定义清晰的入站和出站规则。同时，不要以root用户运行容器，设置securityContext中的runAsNonRoot为true，并指定runAsUser为任意非零UID。对于文件系统，考虑将根文件系统设为只读（readOnlyRootFilesystem），只挂载必要的临时目录。这些措施不会影响正常功能，但能显著缩小攻击面。如果集群使用云厂商托管服务，务必开启私有网络和加密通信，避免控制平面暴露在公网。
可观测性：没有指标，就无法优化
很多团队在Kubernetes上跑起来了，但监控体系还停留在“看Pod状态”的层次。真正的可观测性需要三根支柱：指标、日志、追踪。指标层面，除了基础的CPU和内存，一定要采集Kubernetes自身的调度延迟、API Server延迟、etcd健康状态，以及每个工作负载的QPS和错误率。日志要统一收集到集中式平台，并按照命名空间和服务打上索引。对于分布式调用，引入OpenTelemetry标准，将Trace数据与指标关联起来。记住，Kubernetes本身不会告诉你“为什么慢”，只有完整的可观测性数据才能让你在故障发生时快速定位根因，而不是靠猜。
成本管理：让每一分钱都花在刀刃上
云上运行Kubernetes的成本往往超出预期。最佳实践是定期分析每个命名空间和每个Deployment的资源利用率，找出那些requests设置过高但实际使用率极低的“僵尸资源”。使用Karpenter或Cluster Autoscaler的缩容策略，在非高峰时段自动缩减节点。对于无状态且可容忍延迟的批处理任务，考虑使用Spot实例（抢占式虚拟机）来降低成本，但要确保它们被标记为可中断，并且有相应的重试机制。最后，设置预算告警，当某个部门的月度费用超过阈值时自动通知，避免月底收到账单时才发现失控。
结论部分
Kubernetes是一把双刃剑，它赋予了前所未有的弹性和扩展能力，但同时也把复杂性转移到了运维和开发层面。真正的“最佳实践”并不是某一条命令或某一个配置，而是一套持续演进的工程文化：重视资源规划、敬畏网络边界、拥抱可观测性、主动管理成本。从今天起，审视你的集群，找出那些“能跑但不够稳”的角落，逐步用这些实践去打磨。你会发现，当每一个细节都被认真对待时，Kubernetes不再是运维的负担，而是业务创新最坚实的底座。
