上周帮一个创业团队排查线上故障。
他们把核心订单服务直接扔到裸的Kubernetes集群上，连资源配额都没设。
凌晨三点整个节点被打满，所有Pod反复重启，整个网站瘫了四十分钟。
这事真不怪开发。
太多人把Kubernetes想成开箱即用的万能运维工具了。
别上来就追求集群规模
很多人刚接触Kubernetes，上来就照着官方文档搭三节点高可用集群，什么etcd冗余、跨可用区调度，配置拉满。实际呢？如果团队总共就三个开发，月活刚破十万，业务系统也就三四个微服务，真的没必要。
单节点能跑稳的业务，硬上多节点集群，最后要维护的组件比业务代码还多。
之前见过一个团队，为了追最新的Kubernetes版本，每个月花在集群升级上的时间，比写业务需求的时间还多。麻烦在于，Kubernetes本身的抽象层太多了，你要懂kubelet、kube-proxy、CNI网络插件、CSI存储插件，任何一个组件出问题，排查的时间成本远高于直接在虚拟机上跑进程。
之前有个做内容站的团队，之前用裸虚拟机跑了五年，稳定得很，去年跟风迁到Kubernetes，光调通Nginx Ingress的长连接超时问题就花了两周。最后算下来，迁移带来的弹性伸缩收益，还抵不上两个运维工程师半个月的排查工时。
对吧？
这事没那么玄。你要算的是，你的业务流量到底有多大的波峰波谷，是不是真的需要秒级弹性，而不是看别人都在用，你也必须上。
那些文档不会写的隐性成本
很多官方教程里的Kubernetes，都是跑个Nginx、跑个Demo程序，点几下就通了。真到生产环境，问题全是文档里没写的。
比如你用默认的CoreDNS配置，高并发场景下，服务间调用的DNS解析超时率能飙到5%以上，你得自己改CoreDNS的缓存参数，配上游DNS的兜底。再比如你用默认的Pod驱逐策略，节点资源紧张的时候，系统会随机杀掉上面的业务Pod，根本不管这个Pod是不是承载核心交易链路。
默认配置的Kubernetes集群，本质上是给测试环境用的，离生产可用差了至少二十个调优步骤。
很多人忽略了镜像拉取的问题。你在国内用公有云的Kubernetes集群，默认去Docker Hub拉镜像，稍微大一点的镜像，拉取超时是常事。之前有个团队的大促活动，扩容Pod的时候因为镜像拉不下来，扩容了十分钟都没把副本数拉满，眼睁睁看着流量打进来。
还有个很容易踩的坑，就是存储。很多人一开始用本地存储跑有状态服务，比如MySQL、Redis，等到节点故障，数据直接丢了。再换网络存储，又要处理存储插件的权限问题、挂载延迟问题，等你把这些都调顺，半年都过去了。
说白了，Kubernetes从来不是一个“装完就好”的工具，它的所有灵活性，都是用你的运维时间换回来的。
什么时候你真的需要Kubernetes
我从来不会劝小团队上来就用Kubernetes。但有几种场景，你硬扛着不用，最后成本会高到离谱。
比如你同时维护十几个微服务，每个服务的发布频率是每周两三次，之前靠人工在虚拟机上部署，每次发布要写一堆shell脚本，还要手动回滚，稍不注意就把生产环境搞挂。这时候Kubernetes的滚动更新、一键回滚的能力，才真的能帮你省时间。
再比如你的业务流量波动特别大，比如电商大促、直播活动，平时只需要十个副本，大促的时候要扩到一千个副本，等活动结束再缩回来。这种场景下，你手动扩容根本来不及，靠Kubernetes的HPA自动弹性，才能把服务器成本压到最低。
还有个判断标准，就是你的团队里，有没有人真的愿意花时间去搞懂Kubernetes的运行逻辑。如果所有人都是照着网上的教程抄配置，出了问题就搜百度，那不如老老实实买个托管PaaS服务，不要自己搭集群。
之前见过太多团队，自己搭了Kubernetes集群，出了问题连日志在哪看都不知道，最后又退回到虚拟机部署的模式，之前花的几个月时间全打了水漂。
上周和一个做了八年运维的老大哥聊天，他说现在很多人谈Kubernetes，都在谈云原生、谈微服务架构，好像不用就落伍了。其实真不是。
工具从来都是解决问题的。
你如果现在用虚拟机跑业务，一年出不了两次故障，发布也不麻烦，那完全没必要折腾。