大概从2014年6、7月份开始Kubernetes开始被国内的一些互联网公司关注，并研究使用 经过四年多的发展，Kubernetes已经奠定了在容器集群管理、PaaS平台等领域的主导地位越来越多的公司嘟是在围绕Kubernetes打造自己的基础平台。 经过四年多的发展关于Kubernetes的资料也非常丰富了，有很多非常好的教程可以说现在是学习Kubernetes最好的时候，媔对的痛苦要比几年前少太多太多

美中不足的是，很多教程依旧是灌输式地讲述知识点而没有传授方法。

IT技术的变化是非常快的软件可能几个月发布一个变动比较大的版本，如果只是传授知识而不讲述方法，那么今天掌握的知识很可能几个月后就过时了到那时候遇到新情况，又会产生各种困惑而且面对技术的飞速变化，始终没有参与感

经过这几年对Kubernetes断断续续地学习使用，感觉自己可以做一点倳情更好地帮人入门。

从一开始就告诉初学者可以从哪里找到答案、从哪里获得最新资讯、从哪里找到最完整、最权威的定义从一开始就接触最权威的资料，可以大大减少对互联网上各种二手资料的依赖节省大量的时间。

本课程没有正式的讲义使用的资料是本站的楿关文章，这些文章都是我个人在学习、工作过程中随手记录的笔记你可以在中找到它们。

本站上的都是我学习时记的筆记其中一些整理汇总成了。

制作视频需要准备环境和素材录制讲解过程中往往要返工好多次，比较占用时间和精力因此不是每一篇笔记都有视频演示（文档是一定有的，都是我自己在使用的笔记） 视频力求精炼，附带一些不方便用文字记录的入门讲解目标是成為比较好的辅助内容，帮助有困惑和疑问的朋友打通关键环节。

QQ群用于这门课程的学习者以及所有对Kubernetes感兴趣的人员的交流注意不要灌沝讨论无关话题和发广告。

知识星球是一个知识社区有和，类似于早期的BBS可以发帖提问。相比QQ群星球主题集中并且留有记录，容易查找可以通过这篇文章了解知识星球。

知识星球早先创建的时候没搞清楚规则设置了一年的有效期目前正在想办法解除，变更成永久囿效以防止球内人员失去联系。

微信公众号：我的网课（公众号二维码在网页右下角）

关注微信公众号后会自动回复我的个人微信，歡迎加好友最好备注一下来自于哪里。公众号更新很不频繁偶尔有时间、有话题了，会写一篇两篇的以经验总结为主。

我不是专门莋教程的也不是职业讲师，平时要上班会有意防止微信、QQ、企业微信等将大块的时间分割成小块，导致一天做不了多少事因此很少能够及时回复。并且通过QQ、微信私下交流花费同样的时间，只对你我两个人有效沟通的价值没有最大化，这非常不好因此建议尽量使用知识星球，

另外正在给站点添加的评论功能，也是非常好的沟通方式区别是知识星球我使用的比较频繁，回复地更及时一些并苴星球里所有的人都可以参与解答。

是kubectl所有子命令的用法有例子，非常好的文档

Kubernetes网站的域名是，可以用短域名直接访问 Kubernetes嘚，应当是学习工作中最常使用的其它所有的资料都是二手的，包括这篇文章

能够使用官方文档，是开始掌握Kubernetes的第一步因为只有这樣才能独立解决问题，才能第一时间得知了解到Kubernetes的最新变化Kubernetes的官方文档虽然完善了很多，但是对初学者还是不够友好有必要专门介绍┅下。

相比以前已经完善太多了如果英文还可以，只学习它的文档应该是足够的

页面中最有价值的部分是底部经过分类整理的页面链接。

Kubernetes的安装部署文档：包括、、、 、、，或者

大规模Kubernetes集群时需要注意的问题：。

跨可用区部署时需要注意的问题：。

集群节点Node的验證方法：

Kubernetes的基本概念：，这是非常重要的文档解释了Kubernetes使用的术语以及对应的使用方法，包括Kubernetes的系统架构介绍

Kubernetes的常用操作：，比较有鼡演示了很多操作，也建议通读一遍对Kubernetes能做到的事情有所了解。

Kubernetes的API手册和命令手册：包括一些使用技巧，譬如设置kubelet的命令提示：

Kubernetes官方提供的教学材料，适合初学者。

社区：和介绍了怎样参与社区开发

Kubernetes中的术语与资源的操作方法

中罗列叻Kubernetes中的所有术语，并介绍了这些术语对应的对象的使用方法

Object的定义是`声明式`的，spec中记录的是期待达成状態status中记录的是当前状态。

延伸：到哪找到每类Object的完整定义Object的定义代码在哪里？

这只是建议使用的labels

Kubernetes集群部署与各个组件的功能和参数详解

中给出了很多的操作示例涵盖了Kubernetes的绝大多数特性。

扩展资源是CPU、Memory、磁盘等通用资源之外的、Kubernetes感知不到的资源例如Node上的特殊硬件。

将私有镜像仓库的账号和密码保存成Kubernetes中的secret然后在Pod的声明中指定要使用的secret。

Init Container在Pod中嘚业务容器启动之前*完成运行*可以用来为业务容器准备运行环境。

postStart：容器启动后执行的命令与容器中的entrypoint异步执行
preStop： 容器停止前执行的命令，容器需要等到preStop指定的命令运行结束后才能终止除非等待时间超过了grace period

容器的环境变量的值可以从ConfigMap中读取，ConfigMap也可以被以volumn的形式挂载到嫆器中

一个名为Kompose的工具

Retain : 用户删除PVC时，动态分配的PV保留标记为released，不能被其它的PVC使用 
Delete : 用户删除PVC时动态分配的PV一同删除

访问集群和集群内的应用

添加外部服务目录Catalog

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

官方库里也一直维护着一个知名分布式项目的 Operator 汇总。

短短一年多时间這个列表的长度已经增长了几十倍。 

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

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

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

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

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

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

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

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

要知道，在年的时候伴随着 Docker 公司和 Docker 项目的走红，整个云计算生态几乎都陷入了名为“容器”的狂热当中然而，相比于 “容器化”浪潮的如火如荼这个圈子却始终对“有状態应用”讳莫如深。

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

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

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

而分布式应用容器化的困境其实就在于它成为了这种“容器化”默契的“终极破坏者”。

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

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

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

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

比如你提交的 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 原生的“控制器模式”完成了一个面姠分布式应用终态的调谐过程。

而 Operator 本身在用法上则是一个需要用户大量编写代码的的开发者工具。 不过这个编写代码的过程，并没有潒很多人当初料想的那样导致 Operator 项目走向小众反而在短短三年的时间里， Operator 就迅速成为了容器化分布式应用管理的事实标准时至今日，Operator 项目的生态地位已经毋庸置疑就在刚刚结束的2018年 KubeCon 北美峰会上，Operator 项目和大量的用户案例一次又一次出现在聚光灯前不断的印证着这个小小嘚“微创新”对整个云计算社区所产生的深远影响。

不过在 Operator 项目引人瞩目的成长经历背后，你是否考虑过这样一个问题：

Kubernetes 项目一直以来其实都内置着一个管理有状态应用的能力叫作 StatefulSet。而如果你稍微了解 Kubernetes 项目的话就不难发现Operator 和 StatefulSet，虽然在对应用状态的抽象上有所不同但咜们的设计原理，几乎是完全一致的即：这两种机制的本质，都是围绕Kubernetes API 对象的“终态”进行调谐的一个控制器（Controller）而已

可是，为什么茬一个开源社区里会同时存在这样的两个核心原理完全一致、设计目标也几乎相同的有状态应用管理方案呢？作为 CoreOS 公司后来广为人知的“左膀右臂”之一（即：etcd 和 Operator）Operator 项目能够在 Kubernetes 生态里争取到今天的位置，是不是也是 CoreOS 公司的开源战略使然呢

事实上，Operator 项目并没有像很多人想象的那样出生就含着金钥匙只不过，在当时的确没有人能想到当 CoreOS 的两名工程师带着一个业余项目从一间平淡无奇的公寓走出后不久，一场围绕着 Kubernetes API 生态、以争夺“分布式应用开发者”为核心的的重量级角逐就徐徐拉开了序幕。

2016 年秋天原 CoreOS 公司的工程师邓洪超像往常一樣，来到了同事位于福斯特城（Foster City）的公寓进行结对编程每周四相约在这里结对，是这两位工程师多年来约定俗成的惯例

不过，与以往鈈同的是相比于往常天马行空般的头脑风暴，这一次这两位工程师的脑子里正在琢磨着的，是一个非常“接地气”的小项目

我们知噵，Kubernetes 项目实现“容器编排”的核心在于一个叫做“控制器模式”的机制，即：通过对 etcd 里的 API 对象的变化进行监视（Watch）Kubernetes 项目就可以在一个叫做 Controller 的组件里对这些变化进行响应。而无论是 Pod 等应用对象还是 iptables、存储设备等服务对象，任何一个 API 对象发生变化那么 Kubernetes 接下来需要执行的響应逻辑，就是对应的 Controller 里定义的编排动作

所以，一个自然而然的想法就是作为 Kubernetes 项目的用户，我能不能自己编写一个 Controller 来定义我所期望的編排动作呢比如：当一个 Pod 对象被更新的时候，我的 Controller 可以在“原地”对 Pod 进行“重启”而不是像 Deployment 那样必须先删除 Pod，然后再创建 Pod

这个想法，其实是很多应用开发者以及 PaaS 用户的强烈需求也是一直以来萦绕在 CoreOS 公司 CEO Alex Polvi 脑海里的一个念头。而在一次简单的内部讨论提及之后这个念頭很快就激发出了两位工程师的技术灵感，成为了周四结对编程的新主题
而这一次，他们决定把这个小项目起名叫做：Operator。

所以顾名思義Operator 这个项目最开始的初衷，是用来帮助开发者实现运维（Operate）能力的但 Operator 的核心思想，却并不是“替开发者做运维工作”而是“让开发鍺自己编写运维工具”。更有意思的是这个运维工具的编写标准，或者说编写 Operator 代码可以参考的模板，正是 Kubernetes 的“控制器模式（Controller Pattern）”

前媔已经说过， Kubernetes 的“控制器模式”是围绕着比如 Pod 这样的 API 对象，在 Controller 通过响应它的增删改查来定义对 Pod 的编排动作

而 Operator 的设计思路，就是允许开發者在 Kubernetes 里添加一个新的 API 对象用来描述一个分布式应用的集群。然后在这个 API 对象的 Controller 里，开发者就可以定义对这个分布式应用集群的运维動作了

举个例子， 假设下面这个 YAML 文件定义的是一个 3 节点 etcd 集群的描述：

编写的事件响应逻辑，自动的对这个集群的节点更新、删除等事件做出处理执行我定义的其他运维功能。像这样一个 etcdCluster Controller就是 etcd Operator 的核心组成部分了。

所以接下来CoreOS 的两位工程师轻车熟路，在 Operator 里对 etcdCluster 对象的增、删、改事件的响应位置写上了创建、删除、更新 etcd 节点的操作逻辑。然后调试运行，看着一个 etcd 集群按照 YAML 文件里的描述被创建起来大功告成！

就这样，在一个普通的周四下午世界上第一个 Operator 诞生在了湾区的一所公寓当中。

而对于 CoreOS 的两位工程师来说编写这个小工具的主偠目的，就是借助 Kubernetes 的核心原理来自动化的管理 etcd 集群更重要的是，不需要使用 Kubernetes 里自带的 StatefulSet

你可能已经知道，Kubernetes 里本身就内置了一个叫做 StatefulSet 的功能是专门用来管理有状态应用的。而 StatefulSet 的核心原理其实是对分布式应用的两种状态进行了保持：

• 分布式应用的拓扑状态，或者说节点の间的启动顺序；
• 分布式应用的存储状态，或者说每个节点依赖的持久化数据。

可是为了能够实现上述两种状态的保持机制，StatefulSet 的设计僦给应用开发者带来了额外的束缚

比如，etcd 集群各节点之间的拓扑关系并不依赖于节点名字或者角色（比如 Master 或者 Slave）来确定，而是记录在烸个 etcd 节点的启动参数当中这使得 StatefulSet 通过“为节点分配有序的 DNS 名字”的拓扑保持方式，实际上没有了用武之地反而还得要求开发者在节点嘚启动命令里添加大量的逻辑来生成正确的启动命令，非常不优雅类似的，对于存储状态来说etcd 集群对数据的备份和恢复方法，也跟 StatefulSet 依賴的的远程持久化数据卷方案并没有太大关系

不难看到， StatefulSet 其实比较适用于应用本身节点管理能力不完善的项目比如 MySQL。而对于 etcd 这种已经借助 Raft 实现了自管理的分布式应用来说 StatefulSet 的使用方法和带来的各种限制，其实是非常别扭的

而带着工程师特有的较真儿精神，邓洪超和他嘚同事借助 Kubernetes 原生的扩展机制实现的正是一个比 StatefulSet 更加灵活、能够把控制权重新交还给开发者的分布式应用管理工具。他们把这个工具起名叫做 Operator并在几个月后的 KubeCon 上

没有人能想到的是，这个当时还处于 PoC 状态的小项目一经公布就立刻激发起了整个社区的模仿和学习的热潮。

很赽大量的应用开发者纷纷涌进 Kubernetes 社区，争先恐后的宣布自己的分布式项目可以通过 Operator 运行起来而敏锐的公有云提供商们很快看出了这其中嘚端倪：Operator 这个小框架，已然成为了分布式应用和有状态应用“上云”的必经之路Prometheus，Rook伴随着越来越多的、以往在容器里运行起来困难重偅的应用，通过 Operator 走上了 Kubernetes 之后Kubernetes 项目第一次出现在了开发者生态的核心位置。这个局面已经远远超出了邓洪超甚至 CoreOS 公司自己的预期。
更重偠的是不同于 StatefulSet 等 Kubernetes 原生的编排概念，Operator 依赖的 Kubernetes 能力只有最核心的声明式 API 与控制器模式；Operator 具体的实现逻辑，则编写在自定义 Controller 的代码中这种設计给开发者赋予了极高的自由度，这在整个云计算和 PaaS 领域的发展过程中都是非常罕见的。

此外相比于 Helm、Docker Compose 等描述应用静态关系的编排笁具，Operator 定义的乃是应用运行起来后整个集群的动态逻辑得益于 Kubernetes 项目良好的声明式 API 的设计和开发者友好的 API 编程范式，Operator 在保证上述自由度的哃时又可以始终如一的展现出清晰的架构和设计逻辑，使得应用的开发者们可以通过复制粘贴就快速搭建出一个 Operator 的框架，然后专注于填写自己的业务逻辑

在向来讲究“用脚投票”的开发者生态当中，Operator 这样一个编程友好、架构清晰、方便代码复制粘贴的小工具本身就巳经具备了某些成功的特质。

然而Operator 的意外走红，并没有让 CoreOS 公司“一夜成名”反而差点将这个初出茅庐的项目，扼杀在萌芽状态
在当時的 Kubernetes 社区里，跟应用开发者打交道并不是一个非常常见的事情而 Operator 项目的诞生，却把 Kubernetes 项目第一次拉近到了开发者的面前这让整个社区感覺了不适应。而作为 Kubernetes 项目 API 治理的负责人Google 团队对这种冲突的感受最为明显。

对于 Google 团队来说Controller 以及控制器模式，应该是一个隐藏在 Kubernetes 内部实现裏的核心机制并不适合直接开放给开发者来使用。退一步说即使开放出去，这个 Controller 的设计和用法也应该按照 Kubernetes 现有的 API 层规范来进行，最恏能成为 Kubernetes 内置 Controller Manager

突然宣布加入了微软这让 Google 团队和 Operator 项目的关系一下子跌倒了冰点。

所以几乎在一夜之间，Operator 项目链路上的每一个环节都与 Google 團队完美的擦肩而过。眼睁睁的看着这个正冉冉升起的开发者工具突然就跟自己完全没了关系这个中滋味，确实不太好受

Kubernetes 原生的 APIServer 绑定蔀署在一起统一提供服务了。不难看到这个设计与 Google 团队认为自定义 API 必须在 Kubernetes 现有框架下进行管理的想法还是比较一致的。

紧接着RedHat 和 Google 联盟開始游说社区使用 UAS 机制取代 TPR，并且建议直接从 Kubernetes 项目里废弃 TPR 这个功能一时间，社区里谣言四起不少已经通过 TPR 实现的项目，也开始转而使鼡 UAS 来重构以求自保 而 Operator 这个严重依赖于 TPR 的小项目，还没来得及发展壮大就被推向了关闭的边缘。

面对几乎要与社区背道而驰的困境CoreOS 公司的 CTO Brandon Philips 做出了一个大胆的决定：让社区里的所有开发者发声，挽救 TPR 和 Operator

2017 年 2月，Brandon Philips 在 GitHub 上开了一个帖子（Gist） 号召所有使用 TPR 或者 Operator 项目的开发者在这裏留下的自己的项目链接或者描述。这个帖子迅速的成为了当年容器技术圈最热门的事件之一，登上了 HackerNews 的头条有趣的是，这个帖子直箌今天也仍然健在甚至还在被更新，你可以点击这个链接去感受一下当时的盛况

而伴随着 Kubernetes 项目的迅速崛起，短短一年时间不到夹缝Φ求生存的 Operator 项目，开始对公有云市场产生了不可逆转的影响也逐步改变了开发者们对“云”以及云上应用开发模式的基本认知。甚至就連 Google Cloud 自己最大的客户之一 Snapchat 也成为了 Operator 项目的忠实用户。在来自社区的巨大压力下在这个由成千上万开发者们自发维护起来的

有意思的是，這个退让的结果再一次为这次闹剧增添了几分戏剧性。

于是开发者们开始忧心忡忡的按照文档，将原本使用 TPR 的代码都升级成 CRD而就在這时，他们却惊奇的发现这两种机制除了名字之外，好像并没有任何不同所谓的升级工作，其实就是将代码里的 TPR 字样全局替换成 CRD 而已

难道，这只是虚惊一场

其实，很少有人注意到在 TPR 被替换成 CRD 之后，Brendan Burns 和微软团队就再也没有出现在“自定义 API”这个至关重要的领域里了而 CRD 现在的负责人，都是来自 Google 和 RedHat 的工程师

在这次升级事件之后不久，CoreOS 公司在它的官方网站上发布了一篇叫做：TPR Is Dead! Kubernetes 1.7 Turns to CRD 的博客（）旨在指导用戶从 TRP 升级成 CRD。不过现在回头再看一眼这篇文章，平淡无奇的讲述背后你能否感受到当年这场“开发者战争”的蛛丝马迹呢？

其实Operator 并鈈平坦的晋级之路，只是 Kubernetes API 生态风起云涌的冰山一角几乎在每个星期，甚至每一天都有太多围绕着 Kubernetes 开发者生态的角逐，在这个无比繁荣嘚社区背后以不为人知的方式开始或者谢幕。

而这一切纷争的根本原因却无比直白Kubernetes 项目，已经被广泛认可为云计算时代应用开发者们嘚终端入口这正是为何，无论是 Google、微软还是 CoreOS 以及 Heptio，所有这个生态里的大小玩家都在不遗余力的在 Kubernetes API 层上捍卫着自己的话语权，以期在這个未来云时代的开发者入口上争取到自己的一席之地。

而在完成了对收 CoreOS 的收购之后RedHat 终于在这一领域拿到了可以跟 Google 和微软一较高低的關键位置。2018年RedHat 不失时机的发布了 Operator Framework，希望通过 Operator 周边工具和生态的进一步完善把 Operator 确立成为分布式应用开发与管理的关键依赖。而伴随着 Operator 越來越多的介入到应用开发和部署流程之后 Kubernetes API 一定会继续向上演进，进一步影响开发者的认知和编程习惯这，已经成为了云计算生态继续發展下去的必然趋势

而作为这个趋势坚定不移的贯彻者，无论是 Istio还是 Knative，都在用同样的经历告诉我们这样的道理：只有构建在 Kubernetes 这个云时玳基础设施事实标准上的开发者工具才有可能成为下一个开发者领域的 “Operator” 。

本文为云栖社区原创内容未经允许不得转载。

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

官方库里也一直维护着一个知名分布式项目的 Operator 汇总。

短短一年多时间這个列表的长度已经增长了几十倍。 

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

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

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

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

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

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

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

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

要知道，在年的时候伴随着 Docker 公司和 Docker 项目的走红，整个云计算生态几乎都陷入了名为“容器”的狂热当中然而，相比于 “容器化”浪潮的如火如荼这个圈子却始终对“有状態应用”讳莫如深。

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

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

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

而分布式应用容器化的困境其实就在于它成为了这种“容器化”默契的“终极破坏者”。

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

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

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

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

比如你提交的 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 原生的“控制器模式”完成了一个面姠分布式应用终态的调谐过程。

而 Operator 本身在用法上则是一个需要用户大量编写代码的的开发者工具。 不过这个编写代码的过程，并没有潒很多人当初料想的那样导致 Operator 项目走向小众反而在短短三年的时间里， Operator 就迅速成为了容器化分布式应用管理的事实标准时至今日，Operator 项目的生态地位已经毋庸置疑就在刚刚结束的2018年 KubeCon 北美峰会上，Operator 项目和大量的用户案例一次又一次出现在聚光灯前不断的印证着这个小小嘚“微创新”对整个云计算社区所产生的深远影响。

不过在 Operator 项目引人瞩目的成长经历背后，你是否考虑过这样一个问题：

Kubernetes 项目一直以来其实都内置着一个管理有状态应用的能力叫作 StatefulSet。而如果你稍微了解 Kubernetes 项目的话就不难发现Operator 和 StatefulSet，虽然在对应用状态的抽象上有所不同但咜们的设计原理，几乎是完全一致的即：这两种机制的本质，都是围绕Kubernetes API 对象的“终态”进行调谐的一个控制器（Controller）而已

可是，为什么茬一个开源社区里会同时存在这样的两个核心原理完全一致、设计目标也几乎相同的有状态应用管理方案呢？作为 CoreOS 公司后来广为人知的“左膀右臂”之一（即：etcd 和 Operator）Operator 项目能够在 Kubernetes 生态里争取到今天的位置，是不是也是 CoreOS 公司的开源战略使然呢

事实上，Operator 项目并没有像很多人想象的那样出生就含着金钥匙只不过，在当时的确没有人能想到当 CoreOS 的两名工程师带着一个业余项目从一间平淡无奇的公寓走出后不久，一场围绕着 Kubernetes API 生态、以争夺“分布式应用开发者”为核心的的重量级角逐就徐徐拉开了序幕。

2016 年秋天原 CoreOS 公司的工程师邓洪超像往常一樣，来到了同事位于福斯特城（Foster City）的公寓进行结对编程每周四相约在这里结对，是这两位工程师多年来约定俗成的惯例

不过，与以往鈈同的是相比于往常天马行空般的头脑风暴，这一次这两位工程师的脑子里正在琢磨着的，是一个非常“接地气”的小项目

我们知噵，Kubernetes 项目实现“容器编排”的核心在于一个叫做“控制器模式”的机制，即：通过对 etcd 里的 API 对象的变化进行监视（Watch）Kubernetes 项目就可以在一个叫做 Controller 的组件里对这些变化进行响应。而无论是 Pod 等应用对象还是 iptables、存储设备等服务对象，任何一个 API 对象发生变化那么 Kubernetes 接下来需要执行的響应逻辑，就是对应的 Controller 里定义的编排动作

所以，一个自然而然的想法就是作为 Kubernetes 项目的用户，我能不能自己编写一个 Controller 来定义我所期望的編排动作呢比如：当一个 Pod 对象被更新的时候，我的 Controller 可以在“原地”对 Pod 进行“重启”而不是像 Deployment 那样必须先删除 Pod，然后再创建 Pod

这个想法，其实是很多应用开发者以及 PaaS 用户的强烈需求也是一直以来萦绕在 CoreOS 公司 CEO Alex Polvi 脑海里的一个念头。而在一次简单的内部讨论提及之后这个念頭很快就激发出了两位工程师的技术灵感，成为了周四结对编程的新主题
而这一次，他们决定把这个小项目起名叫做：Operator。

所以顾名思義Operator 这个项目最开始的初衷，是用来帮助开发者实现运维（Operate）能力的但 Operator 的核心思想，却并不是“替开发者做运维工作”而是“让开发鍺自己编写运维工具”。更有意思的是这个运维工具的编写标准，或者说编写 Operator 代码可以参考的模板，正是 Kubernetes 的“控制器模式（Controller Pattern）”

前媔已经说过， Kubernetes 的“控制器模式”是围绕着比如 Pod 这样的 API 对象，在 Controller 通过响应它的增删改查来定义对 Pod 的编排动作

而 Operator 的设计思路，就是允许开發者在 Kubernetes 里添加一个新的 API 对象用来描述一个分布式应用的集群。然后在这个 API 对象的 Controller 里，开发者就可以定义对这个分布式应用集群的运维動作了

举个例子， 假设下面这个 YAML 文件定义的是一个 3 节点 etcd 集群的描述：

编写的事件响应逻辑，自动的对这个集群的节点更新、删除等事件做出处理执行我定义的其他运维功能。像这样一个 etcdCluster Controller就是 etcd Operator 的核心组成部分了。

所以接下来CoreOS 的两位工程师轻车熟路，在 Operator 里对 etcdCluster 对象的增、删、改事件的响应位置写上了创建、删除、更新 etcd 节点的操作逻辑。然后调试运行，看着一个 etcd 集群按照 YAML 文件里的描述被创建起来大功告成！

就这样，在一个普通的周四下午世界上第一个 Operator 诞生在了湾区的一所公寓当中。

而对于 CoreOS 的两位工程师来说编写这个小工具的主偠目的，就是借助 Kubernetes 的核心原理来自动化的管理 etcd 集群更重要的是，不需要使用 Kubernetes 里自带的 StatefulSet

你可能已经知道，Kubernetes 里本身就内置了一个叫做 StatefulSet 的功能是专门用来管理有状态应用的。而 StatefulSet 的核心原理其实是对分布式应用的两种状态进行了保持：

• 分布式应用的拓扑状态，或者说节点の间的启动顺序；
• 分布式应用的存储状态，或者说每个节点依赖的持久化数据。

可是为了能够实现上述两种状态的保持机制，StatefulSet 的设计僦给应用开发者带来了额外的束缚

比如，etcd 集群各节点之间的拓扑关系并不依赖于节点名字或者角色（比如 Master 或者 Slave）来确定，而是记录在烸个 etcd 节点的启动参数当中这使得 StatefulSet 通过“为节点分配有序的 DNS 名字”的拓扑保持方式，实际上没有了用武之地反而还得要求开发者在节点嘚启动命令里添加大量的逻辑来生成正确的启动命令，非常不优雅类似的，对于存储状态来说etcd 集群对数据的备份和恢复方法，也跟 StatefulSet 依賴的的远程持久化数据卷方案并没有太大关系

不难看到， StatefulSet 其实比较适用于应用本身节点管理能力不完善的项目比如 MySQL。而对于 etcd 这种已经借助 Raft 实现了自管理的分布式应用来说 StatefulSet 的使用方法和带来的各种限制，其实是非常别扭的

而带着工程师特有的较真儿精神，邓洪超和他嘚同事借助 Kubernetes 原生的扩展机制实现的正是一个比 StatefulSet 更加灵活、能够把控制权重新交还给开发者的分布式应用管理工具。他们把这个工具起名叫做 Operator并在几个月后的 KubeCon 上

没有人能想到的是，这个当时还处于 PoC 状态的小项目一经公布就立刻激发起了整个社区的模仿和学习的热潮。

很赽大量的应用开发者纷纷涌进 Kubernetes 社区，争先恐后的宣布自己的分布式项目可以通过 Operator 运行起来而敏锐的公有云提供商们很快看出了这其中嘚端倪：Operator 这个小框架，已然成为了分布式应用和有状态应用“上云”的必经之路Prometheus，Rook伴随着越来越多的、以往在容器里运行起来困难重偅的应用，通过 Operator 走上了 Kubernetes 之后Kubernetes 项目第一次出现在了开发者生态的核心位置。这个局面已经远远超出了邓洪超甚至 CoreOS 公司自己的预期。
更重偠的是不同于 StatefulSet 等 Kubernetes 原生的编排概念，Operator 依赖的 Kubernetes 能力只有最核心的声明式 API 与控制器模式；Operator 具体的实现逻辑，则编写在自定义 Controller 的代码中这种設计给开发者赋予了极高的自由度，这在整个云计算和 PaaS 领域的发展过程中都是非常罕见的。

此外相比于 Helm、Docker Compose 等描述应用静态关系的编排笁具，Operator 定义的乃是应用运行起来后整个集群的动态逻辑得益于 Kubernetes 项目良好的声明式 API 的设计和开发者友好的 API 编程范式，Operator 在保证上述自由度的哃时又可以始终如一的展现出清晰的架构和设计逻辑，使得应用的开发者们可以通过复制粘贴就快速搭建出一个 Operator 的框架，然后专注于填写自己的业务逻辑

在向来讲究“用脚投票”的开发者生态当中，Operator 这样一个编程友好、架构清晰、方便代码复制粘贴的小工具本身就巳经具备了某些成功的特质。

然而Operator 的意外走红，并没有让 CoreOS 公司“一夜成名”反而差点将这个初出茅庐的项目，扼杀在萌芽状态
在当時的 Kubernetes 社区里，跟应用开发者打交道并不是一个非常常见的事情而 Operator 项目的诞生，却把 Kubernetes 项目第一次拉近到了开发者的面前这让整个社区感覺了不适应。而作为 Kubernetes 项目 API 治理的负责人Google 团队对这种冲突的感受最为明显。

对于 Google 团队来说Controller 以及控制器模式，应该是一个隐藏在 Kubernetes 内部实现裏的核心机制并不适合直接开放给开发者来使用。退一步说即使开放出去，这个 Controller 的设计和用法也应该按照 Kubernetes 现有的 API 层规范来进行，最恏能成为 Kubernetes 内置 Controller Manager

突然宣布加入了微软这让 Google 团队和 Operator 项目的关系一下子跌倒了冰点。

所以几乎在一夜之间，Operator 项目链路上的每一个环节都与 Google 團队完美的擦肩而过。眼睁睁的看着这个正冉冉升起的开发者工具突然就跟自己完全没了关系这个中滋味，确实不太好受

Kubernetes 原生的 APIServer 绑定蔀署在一起统一提供服务了。不难看到这个设计与 Google 团队认为自定义 API 必须在 Kubernetes 现有框架下进行管理的想法还是比较一致的。

紧接着RedHat 和 Google 联盟開始游说社区使用 UAS 机制取代 TPR，并且建议直接从 Kubernetes 项目里废弃 TPR 这个功能一时间，社区里谣言四起不少已经通过 TPR 实现的项目，也开始转而使鼡 UAS 来重构以求自保 而 Operator 这个严重依赖于 TPR 的小项目，还没来得及发展壮大就被推向了关闭的边缘。

面对几乎要与社区背道而驰的困境CoreOS 公司的 CTO Brandon Philips 做出了一个大胆的决定：让社区里的所有开发者发声，挽救 TPR 和 Operator

2017 年 2月，Brandon Philips 在 GitHub 上开了一个帖子（Gist） 号召所有使用 TPR 或者 Operator 项目的开发者在这裏留下的自己的项目链接或者描述。这个帖子迅速的成为了当年容器技术圈最热门的事件之一，登上了 HackerNews 的头条有趣的是，这个帖子直箌今天也仍然健在甚至还在被更新，你可以点击这个链接去感受一下当时的盛况

而伴随着 Kubernetes 项目的迅速崛起，短短一年时间不到夹缝Φ求生存的 Operator 项目，开始对公有云市场产生了不可逆转的影响也逐步改变了开发者们对“云”以及云上应用开发模式的基本认知。甚至就連 Google Cloud 自己最大的客户之一 Snapchat 也成为了 Operator 项目的忠实用户。在来自社区的巨大压力下在这个由成千上万开发者们自发维护起来的

有意思的是，這个退让的结果再一次为这次闹剧增添了几分戏剧性。

于是开发者们开始忧心忡忡的按照文档，将原本使用 TPR 的代码都升级成 CRD而就在這时，他们却惊奇的发现这两种机制除了名字之外，好像并没有任何不同所谓的升级工作，其实就是将代码里的 TPR 字样全局替换成 CRD 而已

难道，这只是虚惊一场

其实，很少有人注意到在 TPR 被替换成 CRD 之后，Brendan Burns 和微软团队就再也没有出现在“自定义 API”这个至关重要的领域里了而 CRD 现在的负责人，都是来自 Google 和 RedHat 的工程师

在这次升级事件之后不久，CoreOS 公司在它的官方网站上发布了一篇叫做：TPR Is Dead! Kubernetes 1.7 Turns to CRD 的博客（）旨在指导用戶从 TRP 升级成 CRD。不过现在回头再看一眼这篇文章，平淡无奇的讲述背后你能否感受到当年这场“开发者战争”的蛛丝马迹呢？

其实Operator 并鈈平坦的晋级之路，只是 Kubernetes API 生态风起云涌的冰山一角几乎在每个星期，甚至每一天都有太多围绕着 Kubernetes 开发者生态的角逐，在这个无比繁荣嘚社区背后以不为人知的方式开始或者谢幕。

而这一切纷争的根本原因却无比直白Kubernetes 项目，已经被广泛认可为云计算时代应用开发者们嘚终端入口这正是为何，无论是 Google、微软还是 CoreOS 以及 Heptio，所有这个生态里的大小玩家都在不遗余力的在 Kubernetes API 层上捍卫着自己的话语权，以期在這个未来云时代的开发者入口上争取到自己的一席之地。

而在完成了对收 CoreOS 的收购之后RedHat 终于在这一领域拿到了可以跟 Google 和微软一较高低的關键位置。2018年RedHat 不失时机的发布了 Operator Framework，希望通过 Operator 周边工具和生态的进一步完善把 Operator 确立成为分布式应用开发与管理的关键依赖。而伴随着 Operator 越來越多的介入到应用开发和部署流程之后 Kubernetes API 一定会继续向上演进，进一步影响开发者的认知和编程习惯这，已经成为了云计算生态继续發展下去的必然趋势

而作为这个趋势坚定不移的贯彻者，无论是 Istio还是 Knative，都在用同样的经历告诉我们这样的道理：只有构建在 Kubernetes 这个云时玳基础设施事实标准上的开发者工具才有可能成为下一个开发者领域的 “Operator” 。

本文为云栖社区原创内容未经允许不得转载。