Kubernetes API 与 Operator：不为人知的开发者战争（上）

如果我问你，如何把一个 etcd 集群部署在 Google Cloud 或者阿里云上，你一定会不假思索的给出答案：当然是用 etcd Operator！

实际上，几乎在一夜之间，Kubernetes Operator 这个新生事物，就成了开发和部署分布式应用的一项事实标准。时至今日，无论是 etcd、TiDB、Redis，还是 Kafka、RocketMQ、Spark、TensorFlow，几乎每一个你能叫上名字来的分布式项目，都由官方维护着各自的 Kubernetes Operator。而 Operator 官方库里，也一直维护着一个 知名分布式项目的 Operator 汇总 ，短短一年多时间，这个列表的长度已经增长了几十倍。

而且更有意思的是，如果你仔细翻阅这个 Operator 列表，你就不难发现这样一个有趣的事实：现今 Kubernetes Operator 的意义，恐怕已经远远超过了“分布式应用部署”的这个原始的范畴，而已然成为了容器化时代应用开发与发布的一个全新途径。所以，你才会在这个列表里看到，Android SDK的开发者们，正在使用 Operator “一键”生成和更新 Android 开发环境；而 Linux 系统工程师们，则在使用Operator “一键”重现性能测试集群。

如果说，Docker 镜像的提出，完成了应用静态描述的标准化。那么 Kubernetes Operator 的出现，终于为应用的动态描述提出了一套行之有效的实现规范。更为重要的是，对于 TiDB、Kafka、RocketMQ 等分布式应用的开发者来说，这些应用运行起来之后的动态描述，才是对一个分布式应用真正有意义的信息。

而在此之前，用户如果要想将 TiDB、Kafka 这样的分布式应用很好的使用起来，就不得不去尝试编写一套复杂的管理脚本，甚至为此学习大量与项目本身无关的运维知识。更为麻烦的是，这些脚本、知识、和经验，并没有一个很好的办法能够有效的沉淀下来。而任何一种技术的传授，如果严重依赖于口口相传而不是固化的代码和逻辑的话，那么它的维护成本和使用门槛，就可以说是“灾难级”的。

所以说，Kubernetes Operator 发布之初最大的意义，就在于它将分布式应用的使用门槛直接降到了最低。

那么这个门槛具体有多低呢？

一般来说，无论这个分布式应用项目有多复杂，只要它为用户提供了 Operator，那么这个项目的使用就只需要两条命令即可搞定，以 Kafka 为例：

$ kubectl apply -f example/kafka-operator.yaml

$ kubectl apply -f example/kafka-cluster.yaml

这两条命令执行完成后，一个 Kafka 集群运行所需的节点，以及它们所依赖的 ZooKeeper 节点，就会以容器的方式自动出现在你的 Kubernetes 集群里了。

不过，简化运维和部署，其实只是 Operator 在用户层面的表象。而在更底层的技术层面，Operator 最大的价值，在于它为“容器究竟能不能管理有状态应用”这个争议话题，画上了一个优雅而巧妙的句号。

曾几何时，当 Docker 公司还在执掌整个容器世界的时候，整个云计算圈子都处于一种为容器而疯狂的状态。然而，相比于容器化浪潮的如火如荼，这个圈子却始终对“有状态应用”讳莫如深。

事实上，有状态应用（比如，Kafka ）跟无状态应用（比如，一个Jave Web网站）的不同之处，就在于前者对某些外部资源有着绑定性的依赖，比如远程存储，或者网络设备，以及，有状态应用的多个示例之间往往有着拓扑关系。这两种设计，在软件工程的世界里可以说再普通不过了，而且我们几乎可以下这样一个结论：所有的分布式应用都是有状态应用。

但是，在容器的世界里，分布式应用却成了一个“异类”。我们知道，容器的本质，其实就是一个被限制了“世界观”的进程。在这种隔离和限制的大基调下，容器技术本身的“人格基因”，就是对外部世界（即：宿主机）的“视而不见”和“充耳不闻”。所以我们经常说，容器的“状态”一定是“易失”的。其实，容器对它的“小世界”之外的状态和数据漠不关心，正是这种“隔离性”的主要体现。

但状态“易失”并不能说是容器的缺陷：我们既然对容器可以重现完整的应用执行环境的“一致性”拍手称赞，那就必然要对这种能力背后的限制了然于心。这种默契，也正是早期的 Docker 公司所向披靡的重要背景：在这个阶段，相比于“容器化”的巨大吸引力，开发者是可以暂时接受一部分应用不能运行在容器里的。

而分布式应用容器化的困境，就在于它其实是这种默契的一个“破坏者”。

一个应用本身可以拥有多个可扩展的实例，这本来是容器化应用令人津津乐道的一个优势。但是一旦这些实例像分布式应用这样具有了拓扑关系，以及，这些实例本身不完全等价的时候，容器化的解决方案就再次变得“丑陋”起来：这种情况下，应用开发者们不仅又要为这些容器实例编写一套难以维护的管理脚本，还必须要想办法应对容器重启后状态丢失的难题。而这些容器状态的维护，实际上往往需要打破容器的隔离性、让容器对外部世界有所感知才能做到，这就使得容器化与有状态，成为了两种完全相悖的需求。

不过，从上面的叙述中相信你也应该已经察觉到，分布式应用容器化的难点，并不在于容器本身有什么重大缺陷，而在于我们一直以来缺乏一种对“状态”的合理的抽象与描述，使得状态可以和容器进程本身解耦开来。这也就解释了为什么，在 Kubernetes 这样的外部编排框架逐渐成熟起了之后，业界才逐渐对有状态应用管理开始有了比较清晰的理解和认识。

而我们知道， Kubernetes 项目最具价值的理念，就是它围绕 etcd 构建出来的一套“面向终态”编排体系，这套体系在开源社区里，就是大名鼎鼎的“声明式 API”。

“声明式 API”的核心原理，就是当用户向 Kubernetes 提交了一个 API 对象的描述之后，Kubernetes 会负责为你保证整个集群里各项资源的状态，都与你的 API 对象描述的需求相一致。更重要的是，这个保证是一项“无条件的”、“没有期限”的承诺：对于每个保存在 etcd 里的 API 对象，Kubernetes 都通过启动一种叫做“控制器模式”（Controller Pattern）的无限循环，不断检查，然后调谐，最后确保整个集群的状态与这个 API 对象的描述一致。

for {

实际状态 := 获取集群中对象X的实际状态（Actual State）

期望状态 := 获取集群中对象X的期望状态（Desired State）

if 实际状态 == 期望状态{

什么都不做

} else {

执行编排动作，将实际状态调整为期望状态

}

} 

比如，你提交的 API 对象是一个应用，描述的是这个应用必须有三个实例，那么无论接下来你的 API 对象发生任何“风吹草动”，控制器都会检查一遍这个集群里是不是真的有三个应用实例在运行。并且，它会根据这次检查的结果来决定，是不是需要对集群做某些操作来完成这次“调谐”过程。当然，这里控制器正是依靠 etcd 的 Watch API 来实现对 API 对象变化的感知的。在整个过程中，你提交的 API 对象就是 Kubernetes 控制器眼中的“金科玉律”，是接下来控制器执行调谐逻辑要达到的唯一状态。这就是我们所说的“终态”的含义。

而 Operator 的设计，其实就是把这个“控制器”模式的思想，贯彻的更加彻底。在 Operator 里，你提交的 API 对象不再是一个单体应用的描述，而是一个完整的分布式应用集群的描述。这里的区别在于，整个分布式应用集群的状态和定义，都成了Kubernetes 控制器需要保证的“终态”。比如，这个应用有几个实例，实例间的关系如何处理，实例需要把数据存储在哪里，如何对实例数据进行备份和恢复，都是这个控制器需要根据 API 对象的变化进行处理的逻辑。

从上述叙述中，你就应该能够明白， Operator 其实就是一段代码，这段代码 Watch 了 etcd 里一个描述分布式应用集群的 API 对象，然后这段代码通过实现 Kubernetes 的控制器模式，来保证这个集群始终跟用户的定义完全相同。而在这个过程中，Operator 也有能力利用 Kubernetes 的存储、网络插件等外部资源，协同的为应用状态的保持提供帮助。

所以说，Operator 本身，其实是在 Kubernetes 声明式 API 基础上的一种“微创新”。它利用了 Kubernetes API 可以添加自定义 API 类型的能力，然后又巧妙的通过 Kubernetes 原生的控制器模式，完成了一个面向分布式应用终态的调谐过程。

不过，相信你也听说过，Kubernetes 本身也内置提供了对有状态应用管理的功能即StatefulSet。那么，Operator 这种机制，跟 StatefulSet 相比有什么不同和联系、又有哪些优缺点呢？

这个故事，就得从 Operator 的诞生开始讲起了。

TODO 诞生于硅谷公寓里的 Operator

说到这里，相信你也应该能够醒悟过来，Operator 这个小项目的诞生过程，其实一点都不“光鲜”，更不像 Kubernetes 生态里的明星项目比如 Istio 这样，出生就“含着金钥匙”。你甚至可以说，Operator 在当时都算不上 CoreOS 公司的一个主线产品。

可是，就是这样一个出身卑微、没有去迎合社区主流、又要求用户大量编写代码的的开发者工具，却并没有像很多人料想的那样走向小众道路，反而在短短一年多的时间里，就成为了容器化分布式应用管理的事实标准。

这期间，究竟发生了什么呢？

事实上，就在 Operator 从这间硅谷的公寓里走出不久，一场围绕着 Kubernetes API 生态、以争夺“分布式应用开发者”为核心的的重量级角逐，才刚刚拉开序幕。

作者：

• 张磊，阿里巴巴高级技术专家
• 邓洪超，阿里巴巴技术专家