Kubernetes之所以让人望而生畏，并非因为工程师能力不够，而是我们把它变成了一个无人真正负责的“第二操作系统”。

我至今清楚记得那条Slack消息，它出现在深夜十一点四十七分，没有表情符号，没有咆哮，只有一行字：

“我不想再从事重度依赖Kubernetes的系统了。”

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

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

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

Kubernetes之所以如此棘手，并非工程师的能力问题，而是因为我们让它变成了一个无人真正负责的第二套操作系统。

当Kubernetes不再是基础设施，而变成了产品本身

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

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

你最初怀揣着良好的意图：

“我们将标准化部署流程。”“我们将实现正确的自动扩缩容。”“这将减少运维开销。”

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

凌晨2点的Pod驱逐行为没人理解的边车内存泄漏为什么同样的YAML在预发环境能用，到了生产环境就崩溃为什么CPU限制存在，但其表现却不像CPU限制

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

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

无人提及的YAML坟场

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

以下是我们的发现：

40%的YAML文件超过一年无人修改多个Helm图表以略微不同的方式部署着相同的模式资源配置请求被盲目地从旧服务复制过来无人能再解释清楚的自动扩缩容配置

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

实际上，没人理解。

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

无人预算的情感成本

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

Kubernetes要求：

深厚的Linux知识网络直觉分布式系统思维以及持续的情境切换

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

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

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

接着他们不再提议更改。

然后他们不再关心。

有时候，他们离开了。

我们的改变（没有“干掉Kubernetes”）

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

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

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

为每种服务类型提供一个规范化的部署模板未经书面说明，禁止使用自定义的Helm值明确所有权：平台团队负责集群，而非“所有人”更少的旋钮、更少的标志位、更少的“以防万一”配置开发者部署应用，而非基础设施

Kubernetes再次变得乏味起来。

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

没人爱听的残酷真相

Kubernetes没有辜负我们。

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

大多数团队并不需要：

奇特的自动扩缩容策略自定义调度器十层抽象

他们需要：

可预测的部署快速的回滚更少的心智陷阱

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

一个值得深思的问题

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

他们会把第一个月花在：

学习你的业务逻辑？还是逆向工程你的Kubernetes设置上？

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

而在于架构。

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

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

作者｜Sneha 编译｜dbaplus社群

来源｜