撰稿 | 云昭
出品 | 51CTO技术栈（微信号：blog51cto）
Kubernetes 变得太复杂了，它需要学会克制，否则就会停止创新，直至丢失大本营。
Kubernetes 联合创始人 Tim Hockin 罕见发声。在今年的 KubeCon 上，他建议，Kubernetes 核心维护者应该权衡提议的新功能的好处和它们带来的额外复杂性。
1、Kubernetes 不那么闪亮了！
当初那个容器编排的平台，越来越不像自己了。K8s 本身也在变得越来越复杂，不仅开发和运维人员不堪其重，就连 K8s 内部人员也开始发声了。
Kubernetes 联合创始人、Google 杰出软件工程师 Tim Hockin 开始担忧 K8s 的未来。
Kubernetes 最初由 Google 工程师于2014年创建，两年后成为云原生计算基金会的第一个托管项目，也是继 Linux 之后全球第二大的开源项目。
高效、可扩展是 K8s 一直以来的亮点，尤其是可扩展，不仅可以部署和管理应用程序的可扩展性，同时还能让开发团队专注于创新软件，也能为企业为新兴技术做好准备。
9年（半）过去，K8s 这个便士也许没那么闪闪“发光”了。“以前它是为高度可扩展的应用程序做支持，现在正慢慢成为更复杂工作的首选平台，比如机器学习推理。”一个典型的例子就是，两年前 Kubeflow 被用于 Tensorflow 模型的部署和推理，还有最近的 LLMOps 同样也看到了 Kubernetes 的身影。
2、最紧迫的挑战
“你认为 K8s 最紧迫的挑战是什么？”Hockin 毫无遮掩地向云原生社区询问。
没错，意料之中的那个答案在场上被反复提及：部署和维护容器编排引擎的复杂性实在恐怖！让所有这些复杂性推给开发运维人员，简直是场噩梦！有人甚至说这是 K8s 的“最大的生存威胁”。
“必须付出一些代价，”Hockin 指出这就是K8s这么多年来吸收许多复杂性项目进来所付出的代价。不止最终用户，核心维护人员同样也受到了复杂性的影响。
复杂性越高，K8s 核心维护人员在未来轻松进行更改的敏捷性就越低。同时，软件越复杂，用户的阻力就越大。
Kubernetes 正在让开发人员不堪重负。不使用 K8s 之前，开发工程师要做的是：开发应用程序，编写，测试，打包和部署。但有了 K8s 之后，开发流程全颠覆了：
对于开发人员来说，运维任务变得繁重。尤其当平台工程团队介入时，往往代表着一场战斗即将来临，他们往集群里甩入工件的同时，也对质量要求有着不低的预期，然而说服开发人员按照平台工程的要求去做，往往需要不少回合的 battle。
3、两条疲劳鸿沟
Kubernetes 从一个容器编排平台到如今的庞大生态，为云原生时代的开发运维创造了两条需要跨越的“疲劳鸿沟”。DevOps 团队在转向云原生架构时必须扩展其专业领域，没错，这明显超出他们的舒适区。
双方都必须学习比他们的舒适区所允许的更多的技能：基础设施团队成员必须更加适应开发人员的需求，而开发人员的工作量越来越多地覆盖了与基础设施相关的任务。
具体来讲，开发人员需要更加了解基础设施问题，另一方面，运维、基础设施或系统工程人员越来越接近开发方面，因为编写 Kubernetes 资源或 Kubernetes YAML 的方式难免需要向软件开发的同事学习，因为涉及到迭代。
更为可怕的是，截止现在都仍有一种迷恋新技术的误区：为了K8s而上K8s，为了微服务而上微服务，即便可能压根就不需要它。
图源：知乎
4、复杂性“就像预算”总有花完的一天
Kubernetes 软件是社区驱动的：迄今为止，该社区已有了超过74680 名贡献者，7812 家贡献企业。这离不开第一代 K8s 用户的努力，但随着新用户的不断加入，他们对 Kubernetes 工作原理的兴趣不可避免地衰减了，更多的是增加复杂的东西。
“我们添加的东西越复杂，我们消耗的预算就越多。当预算用完时，糟糕的事情就会发生，K8s 的创新就会停止，用户转向其他解决方案。”
因此，Kubernetes 项目经理需要将复杂性视为一种有限资源，比如称之为“复杂性预算”，不可能无限继续下去。
顶级 Kubernetes 工程师一致认为：对于最终用户甚至核心维护人员本身来说，K8s 变得太复杂了。是时候将复杂性纳入预算了。
5、K8s 内部人员得更多说“不”
Hockin 承认，他不知道如何衡量一个软件的复杂性，更不知道最终用户处理复杂软件的耐心程度。但他巧妙地转化将复杂性问题转变成了一个预算问题：“工程师通常知道自己何时超支预算。”
因此，当考虑添加新功能时，他们必须问这样的问题：我们是否有足够的复杂性预算来承担这个任务？我们应该在这方面浪费有限的预算吗？
工程师的部分工作是权衡任何决策的权衡，新功能可能带来的额外复杂性应该是需要评估的因素之一。
对代码库的一些扩充，可能会在软件的某些方面带来 5% 的性能提升，但如果这会给维护人员带来更多的内部复杂性来处理，那么还值得这样做吗？如果更改 API 以满足特定用例，是否值得让所有其他用户承担此更改带来的负担？
K8s 全部工作人员都需要提高标准，同时愿意说“不”，“愿意对我们很像要的东西说不，愿意对看起来不是坏主意的事情说不，愿意对本身看起来显而易见且容易的事情说不，愿意对贡献了我们看起来真正想要的东西说不！”
通过对某些提案说“不”，可以在复杂性预算中留下一些空间来处理未来更相关的项目。
Hockin 认为，K8s 必须对今天的事情说“不”，这样我们明天才有能力做有趣的事情。
Hockin 说，我们都习惯于总是认为越多越好，但 Kubernetes 现在可能更需要考虑“少即是多”。而且，Kubernetes 还有很多工作要做，但这并不意味着所有这些都需要立即完成。
6、K8s 被取代的迹象
K8s 是 Google 创建的，却是并不适合所有企业。如果说前几年大家追逐新技术，为了 K8s 而采用 K8s，那么现在已经将近十年的 K8s 正在产生慢慢被替代的迹象。“如果你不需要 Kubernetes，就不要采用它。”
即便在容器编排领域，由于它对开发人员并不友好，需要大量的时间和理解来部署、操作和故障排除，企业不得不花费大量时间用于管理 Kubernetes。最近两年，企业们正在寻求其他可选项。
- 有的选择将 Kubernetes 托管出去，使用一家云供应商的托管 Kubernetes 服务；
- 有的则使用可以减少 K8s 操作的发行版，如 Red Hat 的 OpenShift；
- 有的则使用 HashiCorp 的 Nomad 这样的替代品；
- 或者采用亚马逊可持续发展架构副总裁 Adrian Cockcroft 所说的“无服务器优先方法”，直接跳到 FaaS 产品，如 Azure 功能、亚马逊网络服务Lambda或谷歌云功能，并完全绕过 Kubernetes。
此外，市面上也诞生了诸如 cycle.io 等致力于取代 K8s 容器编排王者地位的新产品，让即使是开发运维经验有限的人，也能够描述他们想要什么，并由平台负责实现。
7、写在最后
当然，持续的吸收扩展，让 Kubernetes 快速在云原生时代壮大，但快速吸收新功能的“吸星大法”，也开始出现了反噬。目前，Kubernetes 在容器编排领域的赛道上，正在被拖慢速度，而新对手正虎视眈眈，试图超越。
正如一位业内人士建议 Hockin 的那样“延迟满足”：为了保持活力，Kubernetes 应该保持未完成状态！
参考链接：
https://thenewstack.io/how-to-fight-kubernetes-complexity-fatigue/
https://thenewstack.io/tim-hockin-kubernetes-needs-a-complexity-budget/
https://blog.container-solutions.com/adrian-cockcroft-on-serverless-continuous-resilience?
