在三大Hadoop发行商接连运转不顺之际，公众对Hadoop的担心迅速蔓延至Kubernetes。众所周知，Kubernetes的学习门槛较高、学习曲线较长，这一点已经被很多开发人员吐槽过，这被猜测是否会让其与Hadoop面临同样的处境，在辉煌过后开始走向下坡路。

如今，Kubernetes是开源领域备受关注的项目，就好像曾经的Hadoop是大数据领域的事实标准一样。随着三大围绕Hadoop进行商业化的厂商Cloudera、Hortonworks 和MapR在公司运转层面先后出现问题（Cloudera股价大跌、MapR融资困难甚至被报道总部可能关闭），开源Hadoop生态的复杂性问题再次被提起，而这场讨论迅速将Kubernetes卷入其中。

近日，外媒InfoWorld发表了一篇题为“Will complexity kill Kubernetes?（复杂性会杀死Kubernetes吗？）”的文章，指出了Kubernetes本身过于复杂的事实，并分析了这种复杂性与Hadoop是否雷同，以及Kubernetes最终会不会重蹈Hadoop的覆辙。针对上述问题，InfoQ第一时间对阿里巴巴高级技术专家张磊进行了独家采访，共同探讨Kubernetes背后的复杂性问题。

Kubernetes的复杂性

Kubernetes确实是一个比较复杂的开源项目，尤其是对大多数开发人员来说。——张磊

关于Kubernetes的复杂性问题，InfoQ此前曾进行过简单报道。作为Jira和代码库Bitbucket背后的公司，Atlassian的Kubernetes团队首席工程师Nick Young在采访中表示，虽然当初选择 Kubernetes的战略是正确的（至少到现在也没有发现其他可能的选择），解决了现阶段遇到的许多问题，但部署过程异常艰辛。

此外，将KubeSphere容器平台开源的青云QingCloud公司应用及容器平台研发总监周小四也曾在接受采访中提到Kubernetes 存在很多问题，比如学习门槛较高、学习曲线较长：

我曾经花了三个月时间学习 Kubernetes，但还是感觉没有完全掌握，之后又花了整整一年时间才把 Kubernetes 真正搞明白，这个时长对企业而言是很难接受和付出的。

所以，复杂性会成为阻碍Kubernetes发展的重要因素吗？

作为Kubernetes的创建者之一，Heptio（VMware）的Joe Beda在Twitter上表示：

First off: Kubernetes is a complex system. It does a lot and brings new abstractions. Those abstractions aren’t always justified for all problems. I’m sure that there are plenty of people using Kubernetes that could get by with something simpler.

参考译文：Kubernetes 是一个复杂的系统，它做并带来了很多新的抽象，但这并不适合所有问题。我确定，很多人通过更简单的工具实现Kubernetes的功能。

在随后的讨论中，Beda强调，相比于学习的复杂性，工程师往往更擅长削减构建复杂性。当工程师决定使用Jenkins、Bash、Puppet、Terraform等创建系统时，最终会得到一个独特的复杂系统，工程师本人会感到很舒适，这可能解决了某些问题。但对新人而言，试图了解这些系统太过复杂。但是，这种复杂性与某些特定系统中的复杂性还不同，Kubernetes是存在行业标准的，基本只要学习一次就可以在各处应用。

那么，Kubernetes的复杂性到底来源于哪里？

采访中，张磊表示，Kubernetes 本质上是一个分布式系统而不是一个简单的SDK或者编程框架，这本身已经将其复杂度提升到了系统级分布式开源项目的位置（换言之，不可以简单地将Kubernetes的复杂性与编程框架等同日而语）。此外，Kubernetes 第一次将声明式 API 的思想在开源基础设施领域普及开来，并以此为基础提出了系列诸如容器设计模式和控制器模型等使用范式，这些具有一定先进性和前瞻性的设计也使得 Kubernetes 项目被大众接受是存在一定学习周期的。

Kubernetes 项目的定位与用户群体

首先，张磊认为，Kubernetes 项目的核心定位是要做一个 “Platform for Platform”的项目，即“用来帮助使用者构建分布式系统的分布式系统”。这也就意味着，Kubernetes 项目的首要目标用户其实是分布式应用的开发人员。当然，这里的分布式应用可以是稍具规模的网站，也可以是 TiDB 这样复杂的数据库系统。但这也就使得对不少技术从业者来说，Kubernetes 项目的很多设计与思想，都会比较难以一下子被理解和接受。这其实也是很自然的情况，举例来说，如果 Kubernetes 声明式 API 背后的控制器模型不能为这些用户带来直接好处，那么这个声明式 API 在这部分用户眼中就是累赘。然而，对于另一部分真正在使用控制器模型的用户来说，声明式 API 却是这个项目最具魅力的特性之一。因此，对于这样一个全世界排名前列的开源项目是否被认为“复杂”，更大程度取决于使用者对该项目的具体诉求。

当然，Kubernetes 项目时不时就会被与“复杂”联系在一起，这也就意味着业界一定广泛存在Kubernetes 使用者的诉求与项目定位不一致的问题。

除了分布式应用的开发者，在Kubernetes 项目当前的使用者群体中，还有很大一部分来自于 Docker 生态以及 PaaS 社区，这些用户往往是普通应用而非复杂应用的开发者。相比于纠结“高可用”、“高性能”和“大规模”，这些用户关注的价值点是他们编写的业务逻辑本身，而非程序和代码。对于这些用户来说，他们希望 Kubernetes 提供的，其实是朴素的应用托管和底层基础设施屏蔽能力。这些诉求对于 Kubernetes 项目来说当然不是问题，但是却很难透出 Kubernetes 项目核心设计思想带来的种种好处。

此外，Kubernetes 项目还有一部分用户是应用运维人员。对于这些用户来说，他们希望 Kubernetes 提供的主要是基础设施与资源管理能力，以帮助他们来运维业务方即应用开发者编写的应用。在这个场景下，Kubernetes 项目本身自然也没有问题。但是传统运维模式与 Kubernetes 提倡的声明式 API 和控制器模型之间，其实有着不小的思想与技术鸿沟需要跨越。

综上，这两部分用户群体与 Kubernetes 项目自身定位的”错位关系“，其实是 Kubernetes 项目“复杂性”控诉的主要来源。

Kubernetes的复杂性是否有望降低？

2018年底，Heptio曾委托第三方公司对各行各业近 400 名 IT 决策者进行调查，试图了解哪些团队或企业正在转向 Kubernetes，过程中遇到了哪些障碍以及他们如何从技术中受益。

调查结果显示，团队在评估和运行 Kubernetes 的时候都遇到了不同程度的问题，包括早期的设计和部署决定（47%），内部团队对通用技术的统一认识（47%），内部缺少专家资源（45%），在关键任务中保证可靠性（43%），复杂策略的管理（42%），仅有 4% 的受访者表示，部署Kubernetes时不需要帮助，这意味着要想在生产环境中成功运行Kubernetes是不容易的。

如果，Kubernetes社区可以采取相应动作降低部分复杂性，想必会让整个部署过程更为顺利。

对此，张磊表示，Kubernetes 社区的未来一定是继续向民主化和可扩展方向上不断演进，并且不断优化用户的使用体验。事实上，早在1.14版本发布时，Kubernetes 的核心API已经基本处于“锁定”状态，核心组件的很多特性也都被建议通过CRD实现，而像容器运行时接口（CRI），容器存储接口（CSI），容器网络接口（CNI），Admission Hook 等已经被广泛使用的扩展机制就更无需赘述了。

不过，越来越多的插件和可扩展机制，以及这种设计背后带来的技术复杂度，实际上往往会让上述提到的两部分错位的用户感到更加困惑，并进一步增加了学习曲线的陡峭度。

因此，这里的矛盾点在于Kubernetes 项目发展的走向，并不以让所有用户都感到易用和容易上手为主要目标。更为本质的问题是，Kubernetes 项目的设计中，并没有区分用户角色，这使得“应用开发者”、“应用运维人员”、“基础设施运维人员”等多种用户群体，都必须面对同一套声明式 API ，学习同一套脱胎于 Google Borg/Omega 体系的系统架构思路。在这种“众口难调”的背景下，“复杂度”的控制其实成为一个“鱼与熊掌”般的哲学问题。

解决复杂性的关键：使用者角色解耦

当然，在 Kubernetes 良好的可扩展性机制下，要解决上述”复杂度“问题并非没有办法，关键在于实现开发与运维等使用者角色的解耦。

通过解耦，Kubernetes 项目以及对应的云服务商就可以为不同的角色暴露不同维度、更符合对应用户诉求的声明式API。比如，应用开发者只需要在 YAML 文件中声明”应用 A 要使用 5G 可读写空间“，应用运维人员则只需要在对应的 YAML 文件里声明”Pod A 要挂载 5G 的可读写数据卷“。这种”让用户只关心自己所关心的事情“所带来的专注力，是降低 Kubernetes 使用者学习门槛和上手难度的关键所在。

事实上，Kubernetes 社区一直没有停止在这个领域的持续探索，尤其是在”如何定义一个区分不同用户角色的、统一的应用描述“这个问题上，社区已经取得一些关键性的突破。张磊透露，预计到2019年底，用户就有机会了解这些改变的具体情况。

这与Hadoop的复杂性并不相同

虽然Kubernetes的复杂性被大多数人员认可，但这与Hadoop并不相同。Apache Hadoop在大致相当于“MapReduce”时就比较复杂。随着时间的推移，Hadoop的功能越来越强大，生态中可供选择的组件数量激增，但彼此之间很难协同运行。

对于此，VMware的Jared Rosoff精辟地分析了这个问题：“Hadoop的复杂性来源于典型的Hadoop环境基本由几十个独立而复杂的系统组成，这些系统有着不同的生命周期和管理模型。Flume、Chukwa、Hive、Pig和ZooKeeper等，这些名字听起来不错，但让它们协同运行起来非常困难。Rosoff补充道，Hadoop并没有考虑人们会如何扩展它，结果出现的生态系统包括不相兼容的扩展组件。与之相反，Kubernetes做得很好的一点是精心设计了扩展Kubernetes的方式。容器运行时接口（CRI）、容器存储接口（CSI）和容器网络接口（CNI），这些确保随着更多供应商加入进来，可以合理有序的方式运行。换句话说，不像Hadoop及其不兼容的扩展组件，Kubernetes在拥有众多Operator后仍然可以良好运转。

随着整体的不断发展，Hadoop变得越来越复杂，但Kubernetes的组件和工具可以彼此良好协作，最终弥补Kubernetes可能存在的不足。虽然Kubernetes本身可能永远不会“简单”，但它的复杂性与Hadoop的复杂程度并不相同。

结束语

从诞生之日起，复杂度这个问题就一直伴随着Kubernetes项目。不过，可以看到的是，Kubernetes本身也并没有因为这个问题受到太大影响，Kubernetes 项目的核心理念以及“Platform for Platform“的定位催生出整个云原生的生态，这才是其社区迅猛增长的主要动力源泉。

此外，CNCF执行官 Chris Aniszczyk强调：虽然分布式系统本质上很复杂，但Kubernetes的优势在于全球每个主流云厂商都提供符合认证的版本（无分支），这对大多数用户来说可以缓解大规模管理的复杂性。

出于这些原因，未来应该可以看到Kubernetes继续作为容器编排的行业标准而蓬勃发展。

创作场景

复杂性会成为 Kubernetes 的“致命伤”吗？