2025年10月31日容器编排技术选型问答
问：我们这套系统要不要上 K8s？同行都在用。
答：先看三个数，别看同行。日活多少、几台机器、一个月发几次版？
客户查了下：日活 3000 上下，2 台 ECS，一个月发 2 次版，运维一个人。
那次的结论是没上
问：为什么？
答：K8s 解决的主要是「很多服务、很多机器、频繁扩缩容、要自愈」这一类麻烦。2 台机器、2 次发版、一个人运维，这套麻烦目前不存在。上去了反而多出几层要懂的东西：Ingress、Service、Pod 调度、持久化卷、还有一堆 YAML。原来一个人能管，上完可能得两个人。
问：可万一以后要扩呢？
答：那就先把「以后扩」最依赖的地基打了。那次我们做了三件：部署脚本收进 Jenkins，产物带版本号能一键回滚；MySQL 加主从和每天凌晨的备份；把配置文件从各人电脑收进仓库。这三件不管将来上不上 K8s 都用得上，而且都不需要引入新平台。
问：那什么时候该上？
答：几个信号。服务拆到 6 个以上各自发版；机器超过 5 台且经常要临时加；有明显的波峰波谷需要自动扩容；或者有人开始专门负责「部署」这件事，占掉一半时间。出现两个以上再聊，那时候 K8s 省下来的是真人力。
问：半年后呢？
答：半年后客户自己又提了一次。那会儿他们接了另一个渠道，日活翻了三倍，机器加到 6 台，发版改成一周两次，运维也加了人。三个数全变了，我们就一起做了，先只迁无状态的服务，数据库和 Redis 留在外面，没一口气全塞进去。
一句大白话
技术选型最怕「别人都在用」。别人有别人的日活。把三个数摆桌上，多数时候答案自己就出来了，不用争。
那次聊了不到 40 分钟，有 20 分钟在查那三个数。
