这来自我们最优秀的工程师之一，八年后端经验，压力下能保持冷静，是你希望在处理故障时在场的那种人。他并非因工作时间过长而倦怠，他的薪酬也并不低，他的绩效评估也未被否决。

最根本的原因，他被Kubernetes耗尽了心力。

就在那时，我意识到大多数团队都不敢大声承认的一点：

Kubernetes之所以难，并非因为工程师能力不足，而是因为我们把它变成了一个没人真正负责的第二操作系统。

理论上，Kubernetes只是编排工具。

现实中，它悄然变成了工作本身。

你最初怀着良好的意图：

• "我们将标准化部署流程。"

• "我们将实现正确的自动扩缩容。"

• "这将减少运维开销。"

六个月后，你的工程师们在调试：

• 凌晨2点的Pod驱逐行为

• 没人理解的边车（sidecar）内存泄漏

• 为什么同样的YAML在预发环境能用，到了生产环境就崩溃

• 为什么CPU限制存在，但其表现却不像CPU限制

在某个时刻，功能开发变成了支线任务。Kubernetes成了主线剧情。

而最糟糕的是？没人有足够的信心去简化它。

在一次可靠性评审中，我们审计了我们的集群。

以下是我们的发现：

• 40%的YAML文件超过一年无人修改

• 多个Helm图表以略微不同的方式部署着相同的模式

• 资源配置请求被盲目地从旧服务复制过来

• 无人能再解释清楚的自动扩缩容配置

每个工程师都假定有其他人理解这一切。

实际上，没人理解。

Kubernetes已经变成了制度性的知识债务——无形、增长且代价悄然高昂。

人们谈论云成本，却没人谈论认知成本。

Kubernetes要求：

• 深厚的Linux知识

• 网络直觉

• 分布式系统思维

• 以及持续的情境切换

这对平台工程师来说没问题。

但我们将这种复杂性推给了每一位后端开发者，甚至包括那些只想交付API的人。

最终，优秀的工程师们不再提问。

接着他们不再提议更改。

然后他们不再关心。

有时候，他们离开了。

我们没有彻底移除Kubernetes。那样做太鲁莽了。

我们做了件更令人不适的事：我们减少了允许开发者直接接触它的程度。

以下是真正有所帮助的措施：

• 为每种服务类型提供一个规范化的部署模板

• 未经书面说明，禁止使用自定义的Helm值（values）

• 明确所有权：平台团队负责集群，而非"所有人"

• 开发者部署应用，而非基础设施原语

• 更少的旋钮、更少的标志位、更少的"以防万一"配置

Kubernetes再次变得乏味起来。

而乏味的基础设施，才是健康的基础设施。

Kubernetes没有辜负我们。

是我们辜负了它，把它当作工程成熟度的徽章，而非一个成本中心。

大多数团队并不需要：

• 奇特的自动扩缩容策略

• 自定义调度器

• 十层抽象

他们需要：

• 可预测的部署

• 快速的回滚

• 更少的心智陷阱

复杂性应该是努力赢得的，而非继承来的。

如果你明天招聘了一位才华横溢的工程师...

他们会把第一个月花在：

• 学习你的业务逻辑？

• 还是逆向工程你的Kubernetes设置上？

如果是后者，问题不在于招聘。

而在于架构。

Kubernetes可以扩展系统。但若缺乏管理，它也会逐渐放大挫败感。

而这笔成本不会出现在你的AWS账单上——它体现在悄无声息的离职申请和不再提出质疑的团队中。