上周在南京新街口附近的咖啡馆，跟一个做工业设备数据采集的技术负责人坐了一下午。他端着冰美式皱着眉。说去年年中咬咬牙把所有业务容器化迁到Kubernetes之后，最初三个月确实爽。扩容不用半夜爬起来登服务器敲命令，节点挂了自动漂移，之前运维团队天天救火的日子好像一下就过去了。
就这股爽劲没撑过半年，新的麻烦全冒出来了。
别被开源项目的宣传页骗了
说白了，你能在网上找到的所有Kubernetes快速入门教程，教你装完集群跑个Nginx，跑个示例Demo，那离生产环境能用的集群差了十万八千里。很多人一开始抱着“装完就能用”的期待踩进来，最后才发现，装集群的步骤加起来也就半天，调集群的适配参数能耗掉你几个月的精力。
他们最开始踩的第一个大坑，就是没搞懂QoS等级的调度逻辑。一开始照着社区默认的配置给每个Pod设置资源请求，留的CPU配额不高，跑工业数据采集的峰值任务时，Pod动不动就被驱逐，业务断流的告警一天能弹十几次。前后排查了快两周才搞明白，社区默认的Burstable类别的Pod，在节点资源紧张的时候是最先被调度器杀掉的对象。
没人提前说这个。
后来他们又碰到网络插件兼容的问题，Calico版本升级之后，跨节点Pod的通信延迟从正常的2ms涨到了20ms，整个数据上报的链路卡得不行。查了三天日志才发现，新版本默认开启了BGP全量路由同步，跟他们之前搭的物理网络架构完全冲突。这种细碎的、没有写在官方文档显眼位置的坑，你不亲自踩一遍，根本摸不到规律。
集群规模上来之后的管理成本
最开始集群只有3个节点，跑12个业务服务，靠kubectl命令行敲两下就能看明白全集群的状态。现在集群扩到47个节点，跑了快200个工作负载，光控制平面组件的配置yaml文件就攒了快3个G。
头大。
很多人算Kubernetes的使用成本，只算服务器的采购费用，完全忽略了配套的人力投入。他们现在专门招了两个有集群运维经验的技术人员，薪资比之前的普通运维高出近40%，还要定期给全开发团队做培训——不然开发写的资源配置不合理，要么是节点资源占满调度不上去新任务，要么是有的节点CPU使用率不到10%，资源全浪费在空转上。
上次就碰到个刚入职的开发，给一个离线数据清洗的任务设了4核的CPU请求，实际跑批的时候根本用不到三分之一，资源占着不释放，导致后续的实时计算任务卡在调度队列里等了四个小时才跑起来。
这事没那么玄。不是Kubernetes本身不好，是你要搭一整套配套的流程管控，从资源申请、权限划分、变更审计到故障排查的链路，全要跟得上。没有这整套流程，集群就是个吃资源的黑洞，你投进去的服务器和人力，最后可能换不来之前预想的效率提升。
什么时候你真的需要Kubernetes
别听别人忽悠什么“上云原生就得用Kubernetes”，纯粹是脱离实际的废话。比如你公司就跑个企业官网，两个后端服务，一天的总访问量不到一千，你花一周时间搭个三节点Kubernetes集群，纯粹是给自己找额外的活。
那个技术负责人说现在回头想，如果他们当时的业务规模只有现在的三分之一，根本没必要费这么大劲迁移，用Docker Compose加个简单的定时备份脚本，足够撑个两三年的业务发展。
Kubernetes真正能发挥价值的场景，是你有十几个以上的独立服务，需要频繁做版本迭代，有明显的弹性扩容需求，多环境的配置要统一管理。这时候它的编排能力、服务发现、自愈能力，才会帮你把之前零散的运维成本摊薄。反过来，业务规模没到那个程度，你投入的学习成本、运维成本，远大于它能给你带来的收益。
真的。
我之前见过个五人规模的创业团队，上来就跟风搭Kubernetes集群，光维护集群日常状态就占了一个后端开发一半的工作时间，最后实在扛不住运维压力，花了两个月把所有业务迁回了传统虚拟机部署，前后折腾的精力，够他们多做两个核心功能模块了。
现在他团队的应对方式，是把Kubernetes底层复杂的操作全封装成了内部的简易平台，开发不用懂yaml怎么写，只要填个表单就能申请服务上线，慢慢把之前耗在调集群上的精力省出来。说到底，Kubernetes从来不是什么万能的解药，它就是个工具。工具好不好，全看你用的场景对不对，能不能扛得住它背后藏着的那些隐形成本。