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

从理论上看，Kubernetes不过是个编排工具。但现实往往不会按照剧本走——它悄无声息地，就成了工作的主角。

回想一下，团队最初的想法总是美好的：

“我们需要标准化部署流程。”
“要实现合理的自动扩缩容。”
“这样能降低运维负担。”

结果呢？六个月后，工程师们深夜埋头处理的，尽是些意想不到的状况：

凌晨两点Pod为啥被驱逐？
那个没人说得清的边车（sidecar）内存泄漏到底怎么回事？
一模一样的YAML，在预发环境跑得好好的，一到生产就崩？
明明设置了CPU限制，可它怎么就不按规矩来？

不知不觉中，功能开发成了“支线任务”，而Kubernetes运维反而成了每天必须面对的“主线剧情”。更棘手的是，到了这个地步，团队里已经没有人有足够的把握去简化这套体系了。

无人提及的YAML坟场

我们曾在一次可靠性评审中，彻底审计了集群配置。看到的结果，恐怕很多团队都不陌生：

超过40%的YAML文件，已经一年以上没人动过。
多个Helm图表，用着大同小异的方式部署着几乎相同的模式。
资源配置请求像“传家宝”一样，被盲目地从旧服务复制到新服务。
那些连制定者自己都解释不清的自动扩缩容配置，依然在运行。

每个人都假设，“总有人懂这个吧”。而残酷的真相是，很可能谁也不懂。此时的Kubernetes，已经演变成一种制度性的知识债务——看不见，却在不断增长，并且正悄无声息地消耗着团队的精力。

无人预算的情感成本

云成本常常被挂在嘴边，但有一个隐性成本却鲜少被讨论：认知成本。

要真正玩转Kubernetes，对工程师的要求着实不低：

需要扎实的Linux知识储备，
要对网络有良好的直觉，
得理解分布式系统的思维模式，
还要能承受持续不断的上下文切换。

这对于专业的平台工程师来说，或许不是问题。但问题是，我们把这份复杂性直接推给了每一位后端开发者，包括那些只想专注写好业务API的伙伴。

时间一长，优秀的工程师会经历什么变化？他们先是停止了提问，然后不再主动提议改进，最终，可能连关注的兴趣都失去了。有时候，离开就成了最终的选择。

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

我们没有选择彻底移除Kubernetes，那太极端了。我们做了一件更“反人性”、但也更有用的事：大幅减少开发者直接接触它的机会。

真正带来转机的措施包括：

为每种服务类型提供唯一、规范的部署模板。

设立铁律：未经书面说明和审批，禁止使用自定义的Helm values。

明确所有权：平台团队对集群负责，而不是“人人有责，人人不负责”。

让开发者专注于部署应用，而不是去摆弄基础设施的原始构件。

总而言之，就是提供更少的旋钮、更少的开关、更少的“以防万一”的复杂配置。

结果就是，Kubernetes重新变得“乏味”了。而一个乏味的基础设施，才恰恰是健康、可靠的基础设施。

没人爱听的残酷真相

其实，Kubernetes并没有辜负我们。恰恰相反，可能是我们辜负了它——把它当成了彰显工程成熟度的“勋章”，而不是一个需要审慎管理的成本中心。

说实话，大多数团队并不需要：

什么奇特的自动扩缩容策略，
或者自定义调度器，
抑或是堆叠了十层的抽象。

他们真正需要的是：

可预测的部署过程，
快速稳当的回滚能力，
以及更少、更清晰的心智负担。

复杂性，本应该是团队通过努力去赢得的奖赏，而不该是一上来就不得不继承的“遗产”。

一个值得深思的问题

不妨设想一下：如果明天你招聘到一位才华横溢的工程师。

他入职的第一个月，会把时间主要花在：

钻研你的核心业务逻辑上？
还是用来逆向工程你那套复杂的Kubernetes配置上？

如果答案是后者，那问题的根源恐怕不在于招聘，而在于架构本身了。

Kubernetes无疑能扩展你的系统规模，但如果疏于管理，它同样会成倍地放大团队的挫败感。而这笔最大的成本，并不会出现在你的AWS账单上——它体现在那些悄无声息提交的离职申请里，以及那些不再提出质疑的沉默团队中。

作者丨Sneha 编译丨dbaplus社群

来源丨网址：https://aws.plainenglish.io/kubernetes-made-my-best-engineer-quit-and-it-wasnt-a-skill-issue-5c8c615ea0aa