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