Kubernetes 落地三年踩过的那些坑
上周在南京珠江路的一家咖啡馆，跟三个做运维的老哥们坐了一下午。
茶凉了两回。
聊来聊去绕不开一个事——当初咬着牙把所有业务迁到Kubernetes上的决定，到现在算下来，到底是赚了还是赔了。
去年接触过一个做本地生活SaaS的小团队，总共后端开发5个人，运维1个，连专职的SRE都没有。上来就把所有单体应用拆成十几个容器，塞到K8s集群里。麻烦在哪？集群本身要维护啊。节点升级要处理，网络插件出问题要查，证书过期了没人盯，半夜三点告警电话打给那个唯一的运维，人直接在电话里骂街。
Kubernetes 集群日常运维告警界面
Kubernetes从根上是给那种有几十上百个服务、团队规模几十人以上的中大型团队设计的。你就三五个服务，流量峰值也就撑死一百QPS，用个systemd加个简单的监控脚本，足够跑的稳稳的。硬上K8s，相当于你天天骑个共享单车通勤，非要买个半挂卡车停楼下，光年检保养就能把你耗死。
我见过太多小团队，为了追技术潮流硬上K8s，最后折腾了大半年，集群跑的还不如以前的物理机稳定，又灰溜溜迁回去的。丢的时间成本，够把业务做上两个台阶了。
错。
最大的成本从来不是机器。是你要花至少三到六个月的时间，让所有开发、测试、运维团队重新适应一套完全不一样的工作流——以前改完代码直接打个包扔到服务器上重启就行，现在要写Dockerfile，要配CI流水线，要搞资源配额，要处理以前从来没遇到过的容器网络冲突、存储挂载权限问题。
有个老哥算过，他们团队迁K8s的头半年，整体的研发效率直接掉了40%。以前一天能上线三个小需求，现在光等流水线跑通、排个存储的问题，半天就过去了。更别说团队里有两个老开发，到现在看到yaml文件就头大，写个配置经常把缩进搞错，一跑就报错。
Kubernetes YAML配置文件报错提示
迁移的隐性成本从来不会写在云厂商的销售方案里。很多销售跟你说托管K8s开箱即用，却不会告诉你，你团队的人要花多久才能熟练写对配置，要踩多少网络、存储的坑，才能把以前的老业务稳稳跑在上面。
很多人会说，忍过这半年就好了。是，等流程跑顺了，效率确实会回来，甚至比以前更高。但代价是什么？是你这半年里，业务侧的需求排期全往后压，老板问你为什么新功能出的慢，你总不能跟他说我们在折腾一个叫Kubernetes的东西吧？
别被厂商的技术宣传给绑死
说实话，托管K8s确实省了很多维护集群本身的麻烦，但麻烦没消失，只是换了个地方。比如你用厂商的托管服务，你的网络策略、存储卷、监控告警全是跟厂商的产品深度绑定的，哪天你想换个云厂商？那迁移的成本比你第一次从物理机迁到K8s还要高。
之前有个团队从一个公有云迁到另一个，光把所有的存储类配置、Ingress规则重新适配，就花了整整两个星期。中间还出了好几次线上故障，用户投诉的电话把客服的线都打炸了。
Kubernetes本身是个好东西，但它从来不是什么必须要追的政治正确。你要想清楚，你用它到底是要解决什么问题。是要应对每天波动很大的流量峰值？还是要把几十个分散的服务统一管理？还是单纯看别人都在用，自己也不想落后？
想清楚这个问题，比你把K8s的所有官方文档背下来都有用。
上周聊到最后，三个老哥的共识其实很一致：现在他们的K8s集群跑的很稳，平时告警很少，弹性伸缩的能力确实帮他们扛过了好几次大促的流量高峰，算下来省的服务器成本，早就把之前投进去的人力成本收回来了。但他们也一致同意，当初要是早知道有那么多隐性的坑，当初做迁移决定的时候，肯定会再谨慎一点，不会一上来就把所有业务全迁过去，先挑几个非核心的业务试个水，慢慢过渡。
茶凉了两回。
聊来聊去绕不开一个事——当初咬着牙把所有业务迁到Kubernetes上的决定，到现在算下来，到底是赚了还是赔了。
不是所有团队都配用Kubernetes
很多人刚接触Kubernetes的时候，被官方文档里的弹性伸缩、自愈、服务发现那一套勾得心里发痒，觉得不上这个就是技术落后。说白了，这跟刚买了新锤子看什么都像钉子没区别。去年接触过一个做本地生活SaaS的小团队，总共后端开发5个人，运维1个，连专职的SRE都没有。上来就把所有单体应用拆成十几个容器，塞到K8s集群里。麻烦在哪？集群本身要维护啊。节点升级要处理，网络插件出问题要查，证书过期了没人盯，半夜三点告警电话打给那个唯一的运维，人直接在电话里骂街。
Kubernetes从根上是给那种有几十上百个服务、团队规模几十人以上的中大型团队设计的。你就三五个服务，流量峰值也就撑死一百QPS，用个systemd加个简单的监控脚本，足够跑的稳稳的。硬上K8s，相当于你天天骑个共享单车通勤，非要买个半挂卡车停楼下，光年检保养就能把你耗死。
我见过太多小团队，为了追技术潮流硬上K8s，最后折腾了大半年，集群跑的还不如以前的物理机稳定，又灰溜溜迁回去的。丢的时间成本，够把业务做上两个台阶了。
迁移过程里最容易被忽略的隐性成本
很多人算K8s的账，只算服务器的钱，觉得同样的业务量，用容器编排能省30%的机器成本，怎么算都划算。错。
最大的成本从来不是机器。是你要花至少三到六个月的时间，让所有开发、测试、运维团队重新适应一套完全不一样的工作流——以前改完代码直接打个包扔到服务器上重启就行，现在要写Dockerfile，要配CI流水线，要搞资源配额，要处理以前从来没遇到过的容器网络冲突、存储挂载权限问题。
有个老哥算过，他们团队迁K8s的头半年，整体的研发效率直接掉了40%。以前一天能上线三个小需求，现在光等流水线跑通、排个存储的问题，半天就过去了。更别说团队里有两个老开发，到现在看到yaml文件就头大，写个配置经常把缩进搞错，一跑就报错。
迁移的隐性成本从来不会写在云厂商的销售方案里。很多销售跟你说托管K8s开箱即用，却不会告诉你，你团队的人要花多久才能熟练写对配置，要踩多少网络、存储的坑，才能把以前的老业务稳稳跑在上面。
很多人会说，忍过这半年就好了。是，等流程跑顺了，效率确实会回来，甚至比以前更高。但代价是什么？是你这半年里，业务侧的需求排期全往后压，老板问你为什么新功能出的慢，你总不能跟他说我们在折腾一个叫Kubernetes的东西吧？
别被厂商的技术宣传给绑死
说实话，托管K8s确实省了很多维护集群本身的麻烦，但麻烦没消失，只是换了个地方。比如你用厂商的托管服务，你的网络策略、存储卷、监控告警全是跟厂商的产品深度绑定的，哪天你想换个云厂商？那迁移的成本比你第一次从物理机迁到K8s还要高。
之前有个团队从一个公有云迁到另一个，光把所有的存储类配置、Ingress规则重新适配，就花了整整两个星期。中间还出了好几次线上故障，用户投诉的电话把客服的线都打炸了。
Kubernetes本身是个好东西，但它从来不是什么必须要追的政治正确。你要想清楚，你用它到底是要解决什么问题。是要应对每天波动很大的流量峰值？还是要把几十个分散的服务统一管理？还是单纯看别人都在用，自己也不想落后？
想清楚这个问题，比你把K8s的所有官方文档背下来都有用。
上周聊到最后，三个老哥的共识其实很一致：现在他们的K8s集群跑的很稳，平时告警很少，弹性伸缩的能力确实帮他们扛过了好几次大促的流量高峰，算下来省的服务器成本，早就把之前投进去的人力成本收回来了。但他们也一致同意，当初要是早知道有那么多隐性的坑，当初做迁移决定的时候，肯定会再谨慎一点，不会一上来就把所有业务全迁过去，先挑几个非核心的业务试个水，慢慢过渡。