上周跟一个做电商的运维吃饭，他说他们半年前咬咬牙上了Kubernetes，现在每天醒了先刷3分钟节点告警，比刷早高峰路况还紧张。我当时没忍住笑，因为这已经是这半年来我听到的第五个类似的吐槽了。
先搞懂你到底在为什么买单
很多人对Kubernetes的第一印象来自云厂商的宣传，说上了就能自动扩缩容，就能把人力成本砍一半。真不是。大部分团队踩的第一个坑，是把Kubernetes当成了降本工具，而不是一套需要持续运维的分布式系统。
说白了，你部署一套Kubernetes集群，不是装个Word那样打开就能用。光控制面的三个组件——apiserver、etcd、scheduler，你就得保证高可用，至少三个节点撑着，这还不算你跑业务的工作节点。你原来跑3台服务器就能兜住的内部小系统，上了Kubernetes，光控制面的资源开销，就够你再跑两个业务应用了。这事没那么玄。别信那些吹得神乎其神的宣传。很多小团队为了赶时髦上集群，最后发现原来3个人的运维团队，现在要抽一个人专门盯着集群，整体人力成本反而涨了，图啥？
那些被文档藏起来的隐性成本
Kubernetes的官方文档写得很全，从安装到部署应用，每一步都有示例。但文档不会告诉你，你在生产环境要踩的坑，90%都不在核心流程里。最常见的就是存储。很多人刚上手的时候图方便，直接用节点本地存储跑有状态的应用，结果Pod因为节点资源不够被调度到别的机器上，原来存在本地磁盘的数据直接读不到，业务报错的时候连排查方向都找不到。还有网络。很多人用默认的iptables做服务发现，节点上Pod数量超过100个的时候，规则同步的延迟能到十几秒，业务刚发完版，服务发现还没刷出来，用户访问直接502。我见过最夸张的一个团队，为了调通跨节点的Pod通信，整整熬了两个大夜，最后发现是机房交换机的VLAN划分错了，跟集群本身半毛钱关系没有。Kubernetes 文档里不会写的是，你要补的周边组件，比核心系统本身还费精力。
你要搞存储就得选合适的CSI插件，要搞网络就得调CNI的参数，要做安全就得配NetworkPolicy，要做证书自动轮转就得装cert-manager，这些东西没有一个是开箱即用的，每一个都得你花时间试错。甚至连你怎么给不同业务线分配资源，怎么避免某个大应用把整个集群的CPU吃满，都是要慢慢磨的经验，没有通用的标准答案。你以为你省下来的运维时间，最后都会变成你排查网络策略、存储挂载、证书过期这些破事的时间，甚至比原来花的还多。
什么时候你真的需要它
别凑热闹。真的。如果你团队就三五个人，跑个内部管理系统，每天访问量没多少，真的没必要硬上Kubernetes。用docker-compose把服务跑起来，配合脚本做个简单的备份，足够用了。
什么时候它的价值才真的体现出来？你手上同时跑20个以上的微服务，每天要发好几个版本，不同业务线的资源经常打架，原来靠人工调度、写shell脚本的方式已经兜不住了——这时候Kubernetes的能力才真的能帮你省力气。它的自动调度能力，能把闲置的资源利用起来，不用你每天手动盯着哪个机器闲了把服务挪过去。它的滚动发布能力，能让你发版的时候不用停服，出问题了一键回滚。但代价是，你得有专门的人懂这套系统的运维逻辑，知道etcd出问题了怎么恢复，知道证书过期了怎么更新，知道节点NotReady的时候怎么快速把上面的Pod挪走。
昨天那个运维朋友给我发消息，说他们把非核心的小应用全部从集群迁出去了，现在只跑核心的交易服务，告警量直接降了七成。你看，不是Kubernetes不好，是很多人一开始就把它用错了地方。对吧？