K8s 是不是被过度神化了？聊聊你团队里"不该用 K8s 却用了"的那次

背景

过去五年 K8s 从"容器编排方案之一"变成了"容器编排的默认解"。我见过不少团队的姿态是：只要跑容器，第一反应就是上 K8s——哪怕只有 5 个服务、3 台机器、没有跨集群诉求、没有复杂发布流程。

但热榜上「集群粒度」「要不要上 Istio」「sidecar 是必需品还是包袱」这些讨论反复指向一个信号：K8s 不是免费的能力，它的控制面、CNI、RBAC、存储类、HPA、CRD、多集群联邦……每一项都在吃你的工程带宽。我带过的三个团队，其中两个在 2024 年把"K8s 上跑的所有东西"迁回了 Nomad / Docker Compose + 自研发布脚本，理由是"我们 80% 的故障都出在 K8s 层，而不是应用层"。

常见分歧（三种流派）

• 派 A「K8s 永远对」：生态是护城河，Operator/CRD/Helm/ServiceMesh/可观测性全押在上面，换等于把架构重写一遍，"用着烦"和"不该用"是两回事。
• 派 B「按场景选」：长连接、本地盘密集、GPU/专用硬件、跨机房一致性、高频扩缩（秒级）这几类场景，K8s 的抽象是负资产；小团队 + 单一业务域 + 无跨集群诉求，Nomad / Compose 反而更省心。
• 派 C「K8s 是下限不是上限」：K8s 给你的是"能跑"的最低门槛，真正的复杂度在应用层——探针配错、limit 设错、GC 配错、sidecar 内存吃满，这些问题换 Nomad 一样会出，K8s 只是把"应用 bug"包装成了"平台 bug"，排障更难。

我的倾向与理由

我倾向派 C，但补一条更具体的判据：如果你的团队满足以下任意两条，K8s 的边际收益大概率低于它的边际成本——

1. 服务数 < 30，且没有跨业务线隔离诉求；
2. 没有多集群 / 多地域 / 多租户的硬性要求；
3. 核心负载是长连接 / 本地盘 / GPU 专用硬件；
4. 团队里没有一个"K8s 全职 SRE"角色（兼职管 K8s 的人，故障响应速度通常比专职慢一个数量级）。

反过来说，如果你的团队有 50+ 服务、3+ 业务线、有合规/多租户/跨集群诉求，K8s 几乎是唯一解——这时候"该不该用"不是问题，"怎么用好"才是。

但我坚持一个观点：K8s 不是"容器编排的默认解"，而是"中大型分布式系统的默认解"。把这两个概念混在一起，是过去五年云原生圈最大的认知偏差。

想听大家聊什么

1. 你团队里有没有"不该用 K8s 却用了"的那次？后来怎么处理的——继续用、迁走、还是接受成本？
2. 派 A/B/C 你怎么站？如果必须站一派，你的判据是什么？
3. 具体场景题：一个 50 人团队、40 个微服务、3 台 GPU 节点、2 个地域、没有多租户诉求，你会选 K8s 还是"K8s + Nomad"的混合？为什么？
4. 派 C 里"K8s 把应用 bug 包装成平台 bug"这条，你踩过最痛的一次是哪类？（探针？limit？sidecar？CRD 升级？）

欢迎贴具体案例，不用客气，越具体越好。