对企业IT来说Kubernetes已经变得过于复杂了吗?


【编者的话】本文主要讲了Kubernetes的发展历程,介绍了Kubernetes的容器发现机制原理和遇到的质疑,Kubernetes中YAML文件遇到的质疑。最后,说到Kubernetes还处在不断地完善和发展中。

当软件工程师花时间——努力去发现——去消化其他的堆积如山的新想法或新信息。或许来自最近在哥本哈根举办的KubeCon+CloudNativeCon的灵感,关于Kubernetes及其生态系统状态的一个清晰的、尊重的并且真实的新对话正在兴起。

这项讨论开始于 Hacker News,表面是在问Kubernetes是否向组织带来了更多的复杂性而不是移除更多的复杂性。事实上,并没有引起太多的反应,而大部分共享的内容主要是保证任何由协调器(orchestrator)或通过协调器(orchestrator)引入的复杂性必然可以通过调度和执行的效率得到补偿。

对话接下来会转移到Twitter,谷歌计算引擎的共同创造者和Heptio首席技术官Joe Beda努力隔离并确定协调器(orchestrator)的痛点可能在哪里。Beda始终认为:一个有机的架构组件,除了围绕他的服务外,很难引进新的进入者。但他还是继续了这个主题:Kubernetes创造了一个全新的舞台世界,尽管在一开始会让人感到困惑,但这最终是有益的。

“Kubernetes提供了一套解决一系列常见问题的抽象概念。因为人们围绕这些问题总结了经验和技术,所以他们在大多数情况下更有效率。这是一个陡峭的学习曲线!但是这种技能现在在环境,项目和工作之间变得非常有价值和可移植......计算其实就是在创造抽象概念。起初感到拙劣的事情现在变成了一个新的标准。越高级的层面越不简单,但却更适配不同的任务。”Beda写到。

“我认为就像一个工程师一样,我们倾向于低估我们构建的复杂性和我们学习的复杂性。”Beda继续写到。

到目前为止,这个话题还没有那么多的讨论。直到DataDog的软件工程师Jason Moiron将它加入到自己的私人博客,并提出了一个(与Kubernetes)很相关的问题:Kubernetes是否因为其明确的需求而造成了复杂性,但主要是为了让事情更容易?当Kubernetes这样做的时候,它是否创造了这样一种情况:即它所管理的应用程序的环境比其部署的可扩展性要低得多?换言之,你是否坚持你所构建的(Kubernetes)?

“在宕机期间,我们使用了带有健康检查和自我诊断的服务发现可以去做一些相当有趣的事情,更重要的是可以降速。这些都是很难解决的问题,虽然我们在某个地方相当粗略地解决了这些问题,但这些解决方案仍然为我们提供了一系列证明系统稳定性的必要技术。”Moiron写到。

“不幸的是,我们的方法与Kubernetes的集中式的方法稍微有点不兼容。通常,当出现这种情况时,是因为你的需求太复杂了。但是在这种情况下,Kubernetes为了在一个合适的复杂程度进行处理的方法已经相当复杂了。这是一个深思熟虑和成熟的方法,但是它的架构却跟我们恰恰相反。在不兼容的模式下,这是两个世界中最糟糕的方式。”

服务发现本质上是一个系统凭借一个应用或者一个系统来影响其他的服务。比如DNS,其他服务并不是直接构建在系统中的,但可以通过DNS去连接它需要的特定服务。微软Windows操作系统总是随着时间慢下来的原因是它针对服务发现问题的解决办法太简单但却很庞大:一个庞大的系统注册数据库,就像一个由Tribbles填充的城市黄页。

当两个不在一起的Windows应用程序,需要共享功能时,它们必须在各自的本地版本的注册表中安装相同的“类型库”——就好像从同一个电话簿中撕下来相同的一页一样。这将保证发送方所引用的函数与被接收方查找的函数是相同的。危险之处在于较新版本的应用程序可能无法将远程过程调用(RPC)放置到同一个应用程序的旧版本中。总之,扩大规模的唯一途径是一起扩展。

Windows的旧解决方案明显造成了分布式系统的问题:将正在分发的系统尽可能精确地复制时,它们工作得最好。改变系统,当应用被安装在你自己的系统以外的其他位置时,谁知道你是否可以找到你要查找的服务。

DNS给网页服务提供了一种方法,使包含所请求服务的接收系统具有动态性和灵活性,并使其自身的应用能够根据自己的时间进行扩展。或许RPC可以起作用或许不会,但是结果从来都不是灾难性的,可以有选择的被处理。

Moiron的牢骚——可能正如众所周知的——提出了Kubernetes(或者谷歌)的针对服务发现问题的解决措施是否仅仅只适用于Google的环境的问题。这是黄页为tribbles的问题,只是在另一个层面,通过围绕自己的环境集中服务,Kubernetes是否能确保——就像Windows和Windows服务器确保的方式一样——正在进行协调的系统无法发展?诚然,它们可以变得更大或更小,但那不是重点:它们能增长吗?

在SMS-speak工作的Moiron评论道,“我想要运行另一个进程,哦,我不能,除非我通过yaml hokay清楚的描述他和父类环境的每个关系。”

Heptio工程师Kate Kuchin在最近的KubeCon会议期间表示:“Kubernetes是系统工程师为他们自己设计出来的。如果你是一个系统工程师,那就太棒了。对于我们其他人来说,Kubernetes真的很吓人。除了那些刚开始接触Kubernetes的人之外,这个房间里的每个人都可能是新的Kubernetes用户,或许现在是新的Kubernetes用户,或许下周将成为新的Kubernetes用户。所以你们都知道它是相当强大的。”

Kuchin告诉她的听众,她从她的老板——Joe Beda学习了协调器(orchestrator)如何工作。虽然他的出现和经历鼓舞她去追求精通系统,但她当即表示自己已经完全可以胜任。在对他们的所作所为没有太多线索的情况下,能够彻底解释Kubernetes的基本概念。(如果我承认我理解她的处境,那么我就对我作为一名科技记者的工作透露了太多的信息。)

Kuchin指出,在给新用户(UX)介绍如何使整个Kubernetes体验对日常企业更简单时,观察到了这一点。Kubernetes很难做到这一点,可以说是围绕它的生态系统的一个支柱。 自成立以来,大多数提供Kubernetes服务的供应商都将自己定义为协调器(orchestrator)的简化者。 如果它很容易理解,不仅我们不会进行这种讨论,而且我们可能也不会有我们目前所拥有的生态系统。

好的,坏的,未市场化的。

奇怪的是,Jason Moiron最尖锐的不满之一需要使用YAML表达配置意图。借用SMS-speak的说法,他在他的博客中问道:“我怎么能知道所有的yaml呢?”

引用耶鲁大学教授Alan J.Perlis的著名的“Epigrams in Programming”,“当编程语言需要去关注那些不相关的东西的时候是相当低级的。Moiron承认,Kubernetes以知名的‘自发性’方式部署分布式系统与系统分析师可能期望的结果完全吻合,并且帮助那些不是分布式系统分析师的人在这个方向做出第一个决定。从这个意义上说,对于一些与谷歌分布式系统规模相反的人来说,协调者可能不会太低。”

Moiron说,对于已经为自己的系统做出服务发现决策的工程师,协调器(orchestrator)自己做出的决定在结构上往往与这些决定不相容。

通常,当出现这种情况时,是因为你的需求太复杂了。但是在这种情况下,Kubernetes为了在一个合适的复杂程度进行处理的方法已经相当复杂了。这是一个深思熟虑和成熟的方法,但是它的架构却跟我们恰恰相反。在不兼容的模式下,这是两个世界中最糟糕的方式。”

Heptio几乎已经提出了这个确切的论点。它的主要工具ksonnet是一种中间解释器(intermediate interpreter),它使用称为Jsonnet的JSON形式来启用更多的声明式配置文件——通常将多于一个的配置文件组合在一起。该组合的产品是Kubernetes可识别的单个YAML文件,尽管中间体允许一定程度的灵活性和可扩展性,但YAML可能不允许这样做。

Heptio的Bryan Liles在另一次KubeCon会议上解释如何使用ksonnet时说道:“我并不是说我在这里有这个神奇的工具,它可以解决所有的问题,因为这很愚蠢。我想让简单的事情变得更简单,复杂的事情变得有可能。而我们在这里做的是,我们正试图从日常工作中移除掉对YAML的需求。但没有摆脱它,只是删除了一些需求。”

在新的Twitter主题对Moiron的帖子做出了回应中,Heptio的Joe Beda实际上验证了Jason Moiron的每一个抱怨。“当我们开始使用YAML时,我们从来没有打算要做成面向用户的一个解决方案。我们将其视为'汇编代码',我很惊讶我们可以直接与它进行交互。这是失败的。 这不是一个简单的问题。我不认为有一颗银弹(a silver bullet)。通过拥有原生形式,我们确实实现了解决方案的生态系统。那些仍然是早期的,并且目前阶段的Kubernetes中的一部分是原生Kubernetes的一部分。”

Heptio首席技术官继续说道,“我们冒着使用更复杂的方式解决问题的风险,我担心像Istio那样的结果。它可以做出令人惊奇的事情,但它们都是早期的,而且更复杂。我们吸收这些东西的能力有限,Kubernetes尚未消化。”

原文链接:Has Kubernetes Already Become Too Unnecessarily Complex for Enterprise IT?(翻译:李根丰)

==============================================================
译者介绍
李根丰,毕业于西安工业大学,现就职于中软国际。主要从事Java后台开发,Docker容器在项目中的落地实施。平时对容器技术很感兴趣。希望和大家一起学习容器技术。

0 个评论

要回复文章请先登录注册