上周在南京的开发者沙龙上，碰到个干了八年运维的老周。
他端着冰可乐吐槽，说三年前团队跟风上容器化，现在一半的运维精力都在填当初挖的坑。
真不是技术不好。是一开始就把这事想简单了。
不是换个打包方式就算容器化
很多人对容器化的理解，停留在“把应用塞进docker镜像，能跑起来就算完事”。
错了。
说白了，容器化的核心从来不是镜像本身，是把应用依赖、运行环境、配置规则全部标准化封装，让它在任何环境下跑出来的结果完全一致。
这事没那么简单。
很多团队第一步就走偏了：把整个开发环境连带着本地缓存、用户目录、调试工具全打进去，镜像体积大到几个G，拉一次要等十分钟。镜像分层复用的优势完全被浪费。
老周他们当初就是这么干的。一个Java应用的镜像塞了本地maven仓库、代码扫描工具、甚至开发用的轻量编辑器，最后镜像2.7G。每次发布拉镜像的时间，比应用实际启动时间还长。他们当时还觉得，能跑就行。
直到有次业务大促前扩容，几十台节点同时拉镜像，直接把内网带宽打满，整个集群的监控数据都卡成了PPT。
那次事故之后他们才反应过来，原来自己根本没摸到容器化的门道。只是把原来跑在虚拟机里的东西，换了个更轻的壳子而已。
别把容器化等同于上K8s
现在行业里有种奇怪的风气，一提容器化，就默认要搭三节点K8s集群，要上服务网格，要搞全套云原生组件，少一样都不算“跟上技术趋势”。
完全没必要。
容器化本身是个渐进的过程。你先把单个应用的打包逻辑标准化，在几台测试机上跑稳定了，再逐步引入编排能力，比一上来就搭全套复杂系统靠谱得多。
见过太多小团队，满打满算五六个开发，对外的服务总共三个，内部工具两个，非要跟着大厂的公开教程搭K8s集群。光维护集群证书、升级版本、处理节点故障，就耗掉半个开发的日常工作量。最后算下来，这套集群能扛的业务流量，还不如原来两台物理机加nginx扛得多。
得不偿失。
容器化的收益永远和你的业务规模匹配。你总共就几个服务，用docker compose管着完全能跑，没必要硬上复杂度高的分布式编排系统。
说白了，工具是为人服务的，不是人为了凑技术栈给自己找活干。
真正的代价从来不在迁移阶段
很多人算容器化的投入账，只算最初把应用迁到容器里花的人天，觉得几周就能搞定。
麻烦在于，迁移完之后的长期成本，才是真正压在团队身上的东西。
原来的应用跑在固定物理机上，出了问题直接登机器看日志、查进程，十分钟就能定位问题。现在所有东西都在动态调度的容器里，你得有一套专门的日志采集、链路追踪、监控告警体系，不然出了问题你连日志存在哪都找不到。
还有安全问题。原来的应用跑在固定节点上，权限配好，定期打漏洞补丁就完事。现在容器镜像不断更新，节点上的容器动态漂移，你得有镜像漏洞扫描、运行时入侵检测、网络访问策略管控的能力，不然哪天被人塞个带后门的镜像进去，整个集群的业务数据都可能被拖走。
这些事，当初推销容器方案的厂商可不会主动跟你说。
老周他们现在的状态是，花了两年时间把所有历史镜像全部重构，能复用的分层全部抽出来，每个镜像压到几百M，搭了轻量的日志和监控体系，没有追热点上服务网格，也没有硬凑所谓的全栈云原生。现在发布的时间从原来的半小时缩到五分钟，扩容的时候也不会再打满内网带宽。
他说，当初要是有人提前把这些坑说清楚，至少能少走半年的弯路。
很多技术宣传里，容器化是解决所有部署问题的银弹。但你真的走到生产现场就会发现，没有哪种技术是拿来就能用的万能药。所有的技术选型，本质上都是在算一笔账：你要为它付出多少长期的维护成本，能换回多少实际的效率提升。
账算清楚了，再上也不迟。