87%的开发者第一次接触容器编排时，都会经历同一个幻觉：Docker已经够用了。
这个幻觉通常持续到第一次生产事故——凌晨2点，某个容器挂了，监控群里没人醒着，你的手机在床头柜上震动得像要起飞。
从"一次构建"到"到处崩溃"
Docker解决的痛点很直白：环境一致性。你本地跑通的镜像，测试环境能跑，生产环境也能跑。
但Docker没告诉你的是：当容器数量从1个变成20个，从单台机器变成跨可用区部署，"能跑"和"跑得稳"之间隔着一条马里亚纳海沟。
手动管理20个容器的启动顺序、网络发现、健康检查？这活儿比写业务代码累十倍。某次我把数据库连接池配错了，三个服务同时启动瞬间打爆连接数，回滚花了47分钟——足够泡三杯咖啡，喝完两杯，倒掉一杯。
Kubernetes的入门陷阱：术语轰炸
我第一次打开Kubernetes文档时，被Pod、Deployment、Service、Ingress、ConfigMap、StatefulSet这些词直接劝退。感觉像走进一家菜单全是生僻字的餐厅，点单前得先查字典。
后来想通了：别硬背，找类比。
Pod就是"逻辑主机"——一个Pod里的容器共享IP和存储，像合租室友共用厨房和WiFi。Deployment是"管家"，负责保证你指定数量的Pod活着，死了就拉新的。Service是"前台"，不管后端Pod怎么换，它给外部一个固定地址。
换句话说，Kubernetes不是替代Docker，而是给Docker容器配了一个24小时值班的运维团队。
那个让我真香的YAML
真正让我态度转变的，是一次线上故障的自愈过程。
之前用Docker Compose，节点宕机意味着手动登录、拉镜像、起容器，平均恢复时间8分钟。换成Kubernetes后，Deployment检测到Pod异常，自动在另一节点重建，整个过程23秒——我还没从床上坐起来，服务已经恢复了。
这个自动调度背后没什么魔法，就是一段几十行的YAML声明：我要3个副本，CPU限制500m，内存限制512Mi，健康检查路径/health，失败3次就重启。
以前这些逻辑写在脆弱的Shell脚本里，现在变成可版本控制、可回滚、可审计的配置。
当然坑也没少踩。曾把resource limits设得太低，导致Pod反复OOMKilled，查日志查到怀疑人生。也曾没配好readiness probe，流量涌向还没启动完成的实例，直接触发雪崩。
现在的问题变了
从Docker切到Kubernetes后，我的焦虑点从"环境不一致"变成了"配置即代码的复杂度"。
Helm chart怎么写才不像意大利面条？GitOps流程里，谁有权限合并到生产分支？集群升级时，怎么保证零停机？
这些问题没有标准答案。但有个感受很真实：三年前我以为容器化是终点，现在发现它只是基础设施自动化的起点。
你现在生产环境跑多少个容器？手动管理的那个凌晨，你醒了吗？
热门跟贴