你有没有遇到过这种场景？凌晨两点，手机疯狂震动，K8s集群又报警了。Pod重启、节点NotReady、磁盘写满……运维群里炸开了锅。说实话，K8s经典问题翻来覆去就那么几个，但每次都能精准踩坑。今天咱们不聊虚的，直接掏干货，聊聊那些让无数团队夜不能寐的容器编排痛点。
第一个坑：资源请求和限制，你设置对了吗？
很多朋友上来就写resources: {}，觉得“反正云上资源多”。结果呢？节点CPU被打满，kubelet开始驱逐Pod，业务直接抖动。Kubernetes调度的核心逻辑就是基于你声明的requests和limits做决策。你没声明，调度器就瞎猜，节点资源碎片化严重。
我们团队去年做过一次统计：未设置资源限制的命名空间，故障率是规范配置的3.2倍。更可怕的是，某个Java服务内存泄漏，直接拖垮同节点其他Pod。记住，容器编排不是把镜像跑起来就完事，你得给每个工作负载画好“安全边界”。建议用VPA（Vertical Pod Autoscaler）先观察一周，再手动固化配置。
第二个坑：探针配置像玄学，失败一次就重启？
livenessProbe和readinessProbe，这俩兄弟你搞明白了吗？很多人把initialDelaySeconds设成0，结果应用还在加载Spring容器，探针就失败了。K8s一看“哎，这Pod不健康”，咔嚓给你重启。微服务架构下，这种误杀比真实故障还频繁。
我见过最离谱的案例：一个Node.js服务启动要40秒，探针3秒就探测，结果每30秒重启一次，日志全是“SIGTERM”。后来我们把periodSeconds调成10，failureThreshold设成6，世界安静了。云原生技术讲究的是“优雅”，不是“暴力”。探针参数要根据应用启动曲线来调，别拍脑袋。
第三个坑：Ingress配置混乱，灰度发布全靠手速？
生产环境想做个金丝雀发布，结果Ingress规则写错，流量全打到新版本上。用户反馈“页面打不开”，你慌慌张张回滚，手一抖又把旧版本删了。DevOps实践告诉我们，发布流程要自动化，但前提是网络配置得清晰。
我们内部有个铁律：所有Ingress必须用annotations标注版本号，配合Argo Rollouts做渐进式交付。上个月刚帮客户迁移了120个服务，用了nginx.ingress.kubernetes.io/canary-weight: "10"，先放10%流量，观察错误率低于0.1%再全量。集群管理不是靠胆大，是靠流程。
总结：K8s经典问题，其实都是“人”的问题
回头看，K8s本身不复杂，复杂的是我们怎么用它。资源配额、探针调优、流量治理，这三板斧砍下去，你的集群稳定性至少提升80%。别总想着“上了K8s就高枕无忧”，它只是工具，用得好不好全看你的运维习惯。
最后送你一句话：“K8s不会让你失业，但瞎用K8s一定会让你加班。” 如果你也想摆脱半夜报警的噩梦，不妨从今天开始，逐个检查你的Deployment配置。要是觉得工作量太大，私信我，我们团队有现成的集群健康巡检脚本，免费送给你。评论区扣“巡检”，我私发你。