上周跟一个做运维的老同事喝酒，他吐槽说团队刚花了三个月把二十多个业务全迁去容器，结果上周大促还是挂了三个服务。
根因说出来都好笑。某个跑了六年的老Java应用，堆内存还是按物理机的配置设的4G，根本没对齐容器的cgroup内存限制，节点OOM的时候内核直接把容器里的主进程杀了，业务侧连个像样的告警都没收到，等用户反馈的时候已经丢了近千笔订单。
先把”容器化到底解决了什么”掰明白
很多团队谈容器化，上来就列一堆好处：轻量、弹性、快。说白了，容器最核心的价值从来不是”比虚拟机轻多少”，而是把应用运行时的环境依赖、资源配额、启动规则全部固化成可版本化的配置文件。之前那种”我本地跑是好的，怎么到测试环境就崩”的破事，本质就是环境没有统一标准，容器本来是治这个病的。
但太多人从一开始就把方向走偏了。把容器当轻量虚拟机用，一个镜像塞三四个应用，连端口映射、日志路径全跟原来物理机的配置一模一样，迁完了跟原来的部署方式没区别，纯纯白费功夫。我之前碰到过一个团队，迁完容器故障量反而涨了40%，原因就是他们直接把原来给物理机写的启动脚本扔到容器里，日志路径还写死在容器的可写层，容器一重启，所有历史日志全没，排查问题连个线索都找不到。
真要算明白容器的价值，你得先对着自己的现有部署流程数问题：是不是每次上线都要靠运维手动调环境？是不是不同环境的版本差异经常导致线上故障？是不是资源利用率低到一半的服务器在空跑？如果这些问题你一个都没碰到，那谈容器化根本就是无的放矢。
别上来就追着K8s全量迁
行业里现在有个很奇怪的共识，好像谈容器化就必须上K8s，必须搭完整的云原生体系，不然就不算落地。麻烦在于，K8s本身的学习曲线，比写Dockerfile的门槛高三个量级都不止。没有专职平台运维的中小团队，硬上K8s的隐性成本，远比你用三台物理机跑业务的成本高得多。
之前碰过一个二十人不到的创业团队，后端加运维一共三个人，花了俩月搭了K8s集群，最后因为没人懂网络策略，整个集群的NodePort端口全暴露在公网，被人扫到跑了一周的挖矿程序，光云资源损失就小十万。这种事真不是个例。
说实话，很多场景根本不需要K8s。你就两三个内部系统，连基础的CI/CD流水线都没搭明白，用个docker-compose把应用编排起来，每天自动拉新镜像重启，就已经拿到了容器70%的好处。真没必要为了跟同行对齐，硬啃那些你三个月都用不上的CRD、Operator概念。我见过太多团队把容器化的KPI定成”迁多少个应用到K8s”，最后迁完了，业务发布效率没提升，故障排查时间反而翻了一倍，纯粹是为了指标做指标。
那些没人愿意提前算的落地代价
很多人算容器化的账，只算”写Dockerfile需要多久”，根本不算后面持续要投的成本。首先是老应用的适配成本，那些跑了五六年的老C++应用，根本没考虑过容器的文件系统是只读的，写临时文件的路径全错，光改这些路径就得花两三周。然后是可观测性的改造，原来的监控agent是直接装在物理机上的，现在容器是跨节点飘着的，你得把监控指标、日志采集链路全改成适配容器网络的，不然你连服务挂在哪台节点上都找不到。
还有最容易被忽略的长期维护成本。容器的镜像分层、资源配额的优化，是个持续的投入，不是迁完就完事的一锤子买卖。很多团队一开始写的Dockerfile全是从网上抄的，最后镜像体积搞到几个G，拉一次镜像要五分钟，发布的时候光等镜像拉取就占了一半时间，最后大家嫌麻烦，又回去用原来的物理机部署，容器化的项目直接烂尾。
这事没那么玄。我从来不会劝所有团队都上容器化。如果你的业务一年发不了两次版本，跑在物理机上稳得很，连个宕机都没有，那你费那个劲迁容器干啥？纯纯给自己找事。
之前跟一个做了十年运维的老前辈聊天，他说现在行业里总把容器化吹成数字化转型的标配，好像不搞容器就落后了。其实哪有那么多标配。工具就是工具。你用得顺手，能解决你现在的实际问题，那它就是好东西。你为了追风口硬上，最后踩的坑，全是你自己要填的。