先交代背景：我的团队开发了一个消息推送中间件，负责给移动端/小程序推通知，峰值QPS约8000，日推送量大概2000万条。2023年初，领导说咱们是云原生公司了，必须拥抱Kubernetes。于是花了三个月把原来跑在四台ECS上的十几个Docker Compose服务硬生生掰成了K8s工作负载。结果呢？迁移的第一周，光是Ingress配置就出了7个事故，有个服务因为探针的initialDelaySeconds设太短，每次滚部署就重启丢失内存队列。后来稳定性倒是上来了，可代价是Prometheus监控、Grafana告警、Loki日志、Kiali调用链，还有那台专门跑ArgoCD的服务器——全部加起来，物理资源占用比原来的裸容器的多了差不多2.5倍，原来四台ECS总内存128G，K8s集群用了六台加上管理节点，总内存256G才勉强差不多，成本直接翻倍。
你可能会说：那是你姿势不对，或者规模太小。但请让我把话说完。我们的核心业务其实就是无状态HTTP服务加两个Redis和两个MySQL。这样的系统用Docker Compose部署，配置文件加环境变量大概300行。换成K8s之后，光是一套YAML模板就膨胀到1200行，还没算Helm Chart和Kustomize的补丁。而这些额外的复杂度换来的是什么？自动扩缩容？我们用了是的，但Prometheus的HPA从Pod 4个扩到12个的响应时间大约2分钟，瓶颈其实在Kafka消费端。滚动更新确实比原来优雅，但我们原有Compose循环更新也只要把所有ECS的容器逐个重启就行，代价是每个实例约40秒不可用。K8s的滚动更新把不可用时间压到0，但需要配置预算、镜像拉取策略、preStop钩子——很多新手根本写不对。真是讽刺，我们业务允许的停机时间是2%，根本不需要这种精准。
真正让我决定放弃K8s的是一次半夜的证书过期事件。我们的cert-manager没有自动续期成功，导致整个Ingress网关拒绝服务。而之前用Docker Compose的时候，只需要在Nginx容器里挂crontab，每天检测证书剩余天数，剩余小于7天就跑acme.sh重签，如果失败curl一个企业微信Webhook报错。很简单。但在K8s里，我调试了三个小时发现，是cert-manager的ClusterIssuer指定了一个已经失效的ACME账户密钥。那一刻我盯着屏幕上的六层YAML，问自己：如果我是在用Docker Compose，我现在是不是已经修完睡觉了？答案是——最多十分钟。
我知道有人会说，Kubernetes是标准，是趋势。但我要提出一个反直觉的观点：很多项目根本不需要Kubernetes。什么是适合的？像K8s创始人来自谷歌，谷歌面临的是上百个微服务每天被自动调度、清理、批量重建，内部资源池巨大，需要靠Borg/LameOS来隔离。但你的创业公司或者企业内部系统，如果只有三个业务服务，一个网关，两个数据库，一个Redis，那么Docker Compose + systemd 或者干脆用云厂商的托管容器服务（比如AWS ECS Fargate），才是资源效率和人力成本上的最优解。根据Datadog 2024年度容器报告，有53%的容器工作负载仍然跑在Docker Compose或未使用编排器？其实这个数字我不太记得，但我查过同一份报告里小于10个节点的K8s集群平均资源浪费率大约27%。那些K8s宣传的自动伸缩、自愈，在资源利用率极低的小集群里，完全是在烧钱。
当然，我并不是完全否定K8s。如果你的服务数量超过30个，或者你依赖K8s的命名空间做多环境隔离，或者你已经有了专业运维团队，能随时应对etcd性能问题、Ingress Controller选型、CSI插件兼容性等麻烦，那用它当然合理。但在此之前，我现在的决策原则是：能用虚拟机解决的上虚拟机，能用云数据库的别自己搭。我的最新替代方案是：单台8C32G的ECS跑Docker Compose，按时夜间把数据库备份到OSS，内存使用率峰值大约70%，部署加回滚只需要一条命令，整个CI/CD流程用GitHub Actions跑完不到6分钟。我把K8s集群拆掉之后，每个月的云支出少了2600块钱，没有那么多！但省下的时间足够让我好好打磨业务代码了。如果你也在为“架构先进度”焦虑，不妨先想想你的业务真实需要多少台机器，多少个服务，多少个告警。可能一杯咖啡的时间，你就能得出结论：你需要的不是K8s，而是一个好的部署脚本。
