Kubernetes创始人发声!K8s在被反噬!

云昭 2023-11-29 10:52:22
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 应该保持未完成状态!

 

>>>>

参考资料

 

  • 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?

     

 

撰稿 | 云昭 
来源丨公众号:51CTO技术栈(ID:blog51cto)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn
最新评论
访客 2024年04月08日

如果字段的最大可能长度超过255字节,那么长度值可能…

访客 2024年03月04日

只能说作者太用心了,优秀

访客 2024年02月23日

感谢详解

访客 2024年02月20日

一般干个7-8年(即30岁左右),能做到年入40w-50w;有…

访客 2023年08月20日

230721

活动预告