先说结论：我到现在还是每天在用Kubernetes，公司的核心业务也跑在上面。但如果你问我，要不要把所有东西都塞进K8s？我的回答是：你先把三个月后的账单想清楚再说。
去年我们组接过一个内部项目，把一个跑在裸金属上的老旧的库存系统容器化。当时领导拍板，说要跟上云原生潮流。我打开GitLab里那个项目的Dockerfile，好家伙，Java 8，Oracle JDK，还有一堆靠着本地文件系统缓存数据的骚操作。当时我就知道，这不是迁移，这是考古。
为了把状态迁到PVC上，我们临时搭了一个NFS服务端，结果跨节点的IO延迟飙到几十毫秒。后来换了Ceph，但配置块存储、调内核参数、修rbd map的坑，又花了两周。最气的是，你把存储问题解决了，接下来还有网络。Calico的IPIP模式性能损耗就不提了，但那个节点间MTU不一致导致的诡异丢包，你能想象凌晨三点起来看tcpdump的心情吗？
很多人聊K8s，张口就是自动伸缩、自愈、声明式API。这些是真的，但没人告诉你，从裸金属到K8s，你丢掉了什么：直接看IPTables能看懂流量的能力，出了问题能grep日志就能定位的简单，还有对Linux文件系统那份安心。你换来的是一堆yaml文件里互相引用的configmap，以及一个动不动就Evicted的Pod。
我记得有一次生产环境某个节点磁盘压力爆了，kubelet直接把它上面的Pod全部给干掉了。明明我的业务进程还好好的，就因为K8s的驱逐策略，全被重启了。那一刻我真的很想回到systemd时代——至少那是我自己在manage，不是让一个调度器来替我决定生死。
再说说版本升级这事。社区每三个月发一个大版本，你要是不跟上，就会陷入Vulnerability的泥潭。但跟升级吧，从1.22升到1.23，中间因为API版本移除，我们的跨部门小团队改了一个星期。大部分时间不是在改业务，而是在跟kube-state-metrics和prometheus-operator的兼容性搏斗。
你还要算上人力的成本。招一个懂K8s还愿意扛on-call的运维，薪资比传统运维高多少你心里有数。关键是他们其实也只懂皮毛，碰到一个诡异的CNI问题照样抓瞎。而外面那些宣传“K8s让运维更简单”的厂商，永远不会替你在凌晨三点处理一个CrashLoopBackOff。
那是不是说K8s就一无是处？不是。我们后来把一个完全无状态、流量有明显波段的推荐服务搬到K8s上，HPA配合ingress确实玩得很爽。而且灰度发布比原来的Jenkins脚本靠谱多了。但这件事的真相是——这个服务本身就适合容器化，而不是因为K8s才变得适合。相反那个库存系统，如果留在那台IBM小机上，可能比现在活得更好。
如果你还在做技术选型，我想给你几个倒杯冷水的问题：你的服务是不是真的需要秒级横向扩容？你能接受网络层变成黑盒吗？你的团队有没有人能在Pod起不来时，快速判断是镜像问题、资源问题还是调度问题？如果你只想管理二三十台机器，私有云上装个Portainer配docker-swarm可能都更舒服。
这年头发布一个技术方案，不带上Kubernetes就像犯了罪。但技术不是给别人写PPT的，是你自己熬夜背锅的。我曾经也站在那台崩溃的NFS服务器前面，看着监控大屏上闪烁的红色告警，告诉自己：以后再也不碰这些花里胡哨的东西了。结果冷静下来之后，还是老老实实把K8s的证书考了。你要问我为什么？因为大环境就是这样，你绕不开它。但至少，在你决定上K8s之前，我希望你比我当时多想一步：你是真的需要容器编排，还是只是需要一台干净的Linux服务器？