简介： 本文咱们将首先理解到 Operator 是什么，之后逐渐理解到 Operator 的生态建设，Operator 的要害组件及其根本的工作原理，上面让咱们来一探到底吧。

作者 | 匡大虎、阚俊宝  

基于 Kubernetes 平台，咱们能够轻松的搭建一些简略的无状态利用，比方对于一些常见的 web apps 或是挪动端后台程序，开发者甚至不必非常理解 Kubernetes 就能够利用 Deployment，Service 这些根本单元模型构建出本人的利用拓扑并裸露相应的服务。因为无状态利用的个性反对其在任意时刻进行部署、迁徙、降级等操作，Kubernetes 现有的 ReplicaSets，ReplicationControllers，Services 等元素曾经足够撑持起无状态利用对于主动扩缩容、实例间负载平衡等根本需要。

在治理简略的有状态利用时，咱们能够利用社区原生的 StatefulSet 和 PV 模型来构建根底的利用拓扑，帮忙实现相应的长久化存储，按程序部署、程序扩容、程序滚动更新等个性。

而随着 Kubernetes 的蓬勃发展，在数据分析，机器学习等畛域相继呈现了一些场景更为简单的分布式应用零碎，也给社区和相干利用的开发运维人员提出了新的挑战：

• 不同场景下的分布式系统中通常保护了一套本身的模型定义标准，如何在 Kubernetes 平台中表白或兼容出利用原先的模型定义？
• 当利用零碎产生扩缩容或降级时，如何保障以后已有实例服务的可用性？如何保障它们之间的可连通性？
• 如何去重新配置或定义简单的分布式应用？是否须要大量的业余模板定义和简单的命令操作？是否能够向无状态利用那样用一条 kubectl 命令就实现利用的更新？
• 如何备份和管理系统状态和利用数据？如何协调系统集群各成员间在不同生命周期的利用状态？

而所有的这些正是 Operator 心愿解决的问题，本文咱们将首先理解到 Operator 是什么，之后逐渐理解到 Operator 的生态建设，Operator 的要害组件及其根本的工作原理，上面让咱们来一探到底吧。

初识 Operator

首先让咱们一起来看下什么是 Operator 以及它的诞生和倒退历程。

1. 什么是 Operator

CoreOS 在 2016 年底提出了 Operator 的概念，过后的一段官网定义如下：

“An Operator represents human operational knowledge in software, to reliably manage an application.”

对于一般的利用开发者或是大多数的利用 SRE 人员，在他们的日常开发运维工作中，都须要基于本身的利用背景和畛域常识构建出相应的自动化工作满足业务利用的治理、监控、运维等需要。在这个过程中，Kubernetes 本身的根底模型元素曾经无奈撑持不同业务畛域下简单的自动化场景。

与此同时，在云原生的大背景下，生态系统是掂量一个平台胜利与否的重要规范，而宽广的利用开发者作为 Kubernetes 的最间接用户和服务推广者，他们的业务需要更是 Kubernetes 的生命线。于是，谷歌率先提出了 Third Party Resource 的概念，容许开发者依据业务需要以插件化模式扩大出相应的 K8s API 对象模型，同时提出了自定义 controller 的概念用于编写面向畛域常识的业务管制逻辑，基于 Third Party Resource，Kubernetes 社区在 1.7 版本中提出了 custom resources and controllers 的概念，这正是 Operator 的外围概念。

基于 custom resources 和相应的自定义资源控制器，咱们能够自定义扩大 Kubernetes 原生的模型元素，这样的自定义模型能够如同原生模型一样被 Kubernetes API 治理，反对 kubectl 命令行；同时 Operator 开发者能够像应用原生 API 进行利用治理一样，通过申明式的形式定义一组业务利用的冀望终态，并且依据业务利用的本身特点进行相应控制器逻辑编写，以此实现对利用运行时刻生命周期的治理并继续保护与冀望终态的一致性。这样的设计范式使得利用部署者只须要专一于配置本身利用的冀望运行状态，而无需再投入大量的精力在手工部署或是业务在运行时刻的繁琐运维操作中。

简略来看，Operator 定义了一组在 Kubernetes 集群中打包和部署简单业务利用的办法，它能够不便地在不同集群中部署并在不同的客户间流传共享；同时 Operator 还提供了一套利用在运行时刻的监控治理办法，应用领域专家通过将业务关联的运维逻辑编写融入到 operator 本身控制器中，而一个运行中的 Operator 就像一个 7*24 不间断工作的优良运维团队，它能够时刻监控利用本身状态和该利用在 Kubernetes 集群中的关注事件，并在毫秒级别基于冀望终态做出对监听事件的解决，比方对利用的自动化容灾响应或是滚动降级等高级运维操作。

进一步讲，Operator 的设计和实现并不是千篇一律的，开发者能够依据本身业务需要，一直演进利用的自定义模型，同时面向具体的自动化场景在控制器中扩大相应的业务逻辑。很多 Operator 的呈现都是起源于一些绝对简略的部署和配置需要，并在后续演进中不断完善补充对简单运维需要的自动化解决。

1. Operator 的倒退

时至今日，Kubernetes 曾经确立了本人在云原生畛域平台层开源软件中的相对位置，咱们能够说 Kubernetes 就是当今容器编排的事实标准；而在 Kubernetes 我的项目弱小的影响力下，越来越多的企业级分布式应用抉择拥抱云原生并开始了本人的容器化路线，而 Operator 的呈现无疑极大的减速了这些传统的简单分布式应用的上云过程。无论在生态还是生产畛域，Operator 都是容器利用部署上云过程中广受欢迎的实现标准，本大节就让咱们来一起回顾下 Operator 的诞生和倒退历史。

2014 到 2015 年，Docker 无疑是容器畛域的相对霸主，容器技术本身麻利、弹性和可移植性等劣势使其迅速成为了过后煊赫一时的焦点。在这个过程中，尽管市场上涌现了大量利用镜像和技术分享，咱们却很难在企业生产级别的分布式系统中寻找到容器利用的胜利案例。容器技术的实质是提供了主机虚构层之上的隔离，这样的隔离尽管带来了麻利和弹性的劣势，但同时也给容器和内部世界的交互带来了多一层的阻碍；尤其是面向简单分布式系统中，在解决本身以及不同容器间状态的依赖和保护问题上，往往须要大量的额定工作和依赖组件。这也成为了容器技术在云原生利用生产化路线上的一个瓶颈。

与此同时，谷歌于 2014 年基于其外部的分布式底层框架 Borg 推出了 Kubernetes 并实现了第一次代码提交。

2015 年，Kubernetes v1.0 版本正式公布，同时云原生计算基金会 Cloud Native Computing Foundation，简称 CNCF）正式成立，基于云原生这个大背景，CNCF 致力于保护和集成优良开源技术以撑持编排容器化微服务架构利用。

2016 年是 Kubernetes 进入主干道，开始蓬勃发展的一年。这一年的社区，开发者们从最后的种种疑虑转为对 Kubernetes 的鼎力追捧，无论从 commit 数量到集体贡献者数量都有了显著增长；同时越来越多的企业抉择 Kubernetes 作为生产零碎容器集群的编排引擎，而以 Kubernetes 为外围构建企业外部的容器生态曾经开始逐步成为云原生大背景下业界的共识。也正是在这一年，CoreOS 正式推出了 Operator，旨在通过扩大 Kubernetes 原生 API 的形式为 Kubernetes 利用提供创立、配置以及运行时刻生命周期治理能力，与此同时用户能够利用 Operator 不便的对利用模型进行更新、备份、扩缩容及监控等多种简单运维操作。

在 Kubernetes 实现容器编排的核心思想中，会应用控制器（Controller）模式对 etcd 里的 API 模型对象变动放弃一直的监听（Watch），并在控制器中对指定事件进行响应解决，针对不同的 API 模型能够在对应的控制器中增加相应的业务逻辑，通过这种形式实现利用编排中各阶段的事件处理。而 Operator 正是基于控制器模式，容许利用开发者通过扩大 Kubernetes API 对象的形式，将简单的分布式应用集群形象为一个自定义的 API 对象，通过对自定义 API 模型的申请能够实现根本的运维操作，而在 Controller 中开发者能够专一实现利用在运行时刻治理中遇到的相干简单逻辑。

在过后，率先提出这种扩大原生 API 对象进行利用集群定义框架的并不是 CoreOS，而是过后还在谷歌的 Kubernetes 创始人 Brendan Burns；正是 Brendan 早在 1.0 版本公布前就意识到了 Kubernetes API 可扩展性对 Kubernetes 生态系统及其平台本身的重要性，并构建了相应的 API 扩大框架，谷歌将其命名为 Third Party Resource，简称“TPR”。

CoreOS 是最早的一批基于 Kubernetes 平台提供企业级容器服务解决方案的厂商之一，他们很敏锐地捕捉到了 TPR 和控制器模式对企业级利用开发者的重要价值；并很快由邓洪超等人基于 TPR 实现了历史上第一个 Operator：etcd-operator。它能够让用户通过短短的几条命令就疾速的部署一个 etcd 集群，并且基于 kubectl 命令行一个一般的开发者就能够实现 etcd 集群滚动更新、灾备、备份复原等简单的运维操作，极大的升高了 etcd 集群的应用门槛，在很短的工夫就成为过后 K8s 社区关注的焦点我的项目。

与此同时，Operator 以其插件化、自由化的模式个性，迅速吸引了少量的利用开发者，一时间很多市场上支流的分布式应用均呈现了对应的 Operator 开源我的项目；而很多云厂商也迅速跟进，纷纷提出基于 Operator 进行利用上云的解决方案。Operator 在 Kubernetes 利用开发者中的热度大有星火燎原之势。

尽管 Operator 的呈现受到了大量利用开发者的热捧，然而它的倒退之路并不是一帆风顺的。对于谷歌团队而言，Controller 和控制器模式始终以来是作为其 API 体系外部实现的外围，从未裸露给终端利用开发者，Kubernetes 社区关注的焦点也更多的是集中在 PaaS 平台层面的外围能力。而 Operator 的呈现突破了社区传统意义上的格局，对于谷歌团队而言，Controller 作为 Kubernetes 原生 API 的外围机制，应该交由零碎外部的 Controller Manager 组件进行治理，并且听从对立的设计开发模式，而不是像 Operator 那样交由利用开发者自在地进行 Controller 代码的编写。

另外 Operator 作为 Kubernetes 生态系统中与终端用户建设连贯的桥梁，作为 Kubernetes 我的项目的设计和捐赠者，谷歌当然也不心愿错失其中的主导权。同时 Brendan Burns 忽然发表加盟微软的音讯，也进一步加剧了谷歌团队与 Operator 我的项目之间的矛盾。

于是，2017 年开始谷歌和 RedHat 开始在社区推广 Aggregated apiserver，利用开发者须要依照规范的社区标准编写一个自定义的 apiserver，同时定义本身利用的 API 模型；通过原生 apiserver 的配置批改，扩大 apiserver 会随着原生组件一起部署，并且限度自定义 API 在系统管理组件下进行对立治理。之后，谷歌和 RedHat 开始在社区大力推广应用聚合层扩大 Kubernetes API，同时倡议废除 TPR 相干性能。

然而，微小的压力并没有让 Operator 过眼云烟，就此隐没。相同，社区大量的 Operator 开发和使用者仍旧拥戴着 Operator 清晰自在的设计理念，持续保护演进着本人的利用我的项目；同时很多云服务提供商也并没有放弃 Operator，Operator 简洁的部署形式和易复制，自在凋谢的代码实现形式使其保护住了大量忠诚粉丝。在用户的抉择背后，强如谷歌，红帽这样的巨头也不得不做出让步。最终，TPR 并没有被彻底废除，而是由 Custom Resource Definition（简称 CRD）这个现在曾经广为人知的资源模型范式代替。

CoreOS 官网博客也第一工夫收回了回应文章领导用户尽快从 TPR 迁徙到 CRD：https://coreos.com/blog/custom-resource-kubernetes-v17

2018 年初，RedHat 实现了对 CoreOS 的收买，并在几个月后公布了 Operator Framework，通过提供 SDK 等管理工具的形式进一步升高了利用开发与 Kubernetes 底层 API 常识体系之间的依赖。至此，Operator 进一步坚固了其在 Kubernetes 利用开发畛域的重要位置。

1. Operator 的社区与生态

Operator 开放式的设计模式使开发者能够依据本身业务自在的定义服务模型和相应的管制逻辑，能够说一经推出就在社区引起了微小的反应。

一时间，基于不同品种的业务利用涌现了一大批优良的开源 Operator 我的项目，咱们能够在这里找到其中很多的典型案例，例如对于运维要求较高的数据库集群，咱们能够找到像 etcd、Mysql、PostgreSQL、Redis、Cassandra 等很多支流数据库利用对应的 Operator 我的项目，这些 Operator 的推出无效的简化了数据库利用在 Kubernetes 集群上的部署和运维工作；在监控方向，CoreOS 开发的 prometheus-operator 早日成为社区里的明星我的项目，Jaeger、FluentD、Grafana 等支流监控利用也或由官网或由开发者迅速推出相应的 Operator 并继续演进；在平安畛域，Aqua、Twistlock、Sisdig 等各大容器平安厂商也不甘落后，通过 Operator 的模式简化了绝对门槛较高的容器平安利用配置，另外社区中像 cert-manager、vault-operator 这些热门我的项目也在很多生产环境上失去了广泛应用。

能够说 operator 在很短的工夫就成为了分布式应用在 Kubernetes 集群中部署的事实标准，同时 Operator 利用如此宽泛的覆盖面也使它超过了分布式应用这个原始的领域，成为了整个 Kubernetes 云原生利用下一个重要存在。

随着 Operator 的继续倒退，已有的社区共享模式曾经慢慢不能满足宽广开发者和 K8s 集群管理员的需要，如何疾速寻找到业务须要的可用 Operator？如何给生态中大量的 Operator 定义一个对立的质量标准？这些都成为了刚刚实现收买的 RedHat 大佬们眼中亟需解决的问题。

于是咱们看到 RedHat 在年初联结 AWS、谷歌、微软等大厂推出了 OperatorHub.io，心愿其作为 Kubernetes 社区的延长，向宽广 operator 用户提供一个集中式的公共仓库，用户能够在仓库网站上轻松的搜寻到本人业务利用对应的 Operator 并在向导页的领导下实现实例装置；同时，开发者还能够基于 Operator Framework 开发本人的 Operator 并上传分享至仓库中。

下图为一个 Operator 我的项目从开发到开源到被应用的全生命周期流程：

（Operator 开源生命周期流程图）

次要流程包含：

• 开发者首先应用 Operator SDK 创立一个 Operator 我的项目；
• 利用 SDK 咱们能够生成 Operator 对应的脚手架代码，而后扩大相应业务模型和 API，最初实现业务逻辑实现一个 Operator 的代码编写；
• 参考社区测试指南进行业务逻辑的本地测试以及打包和公布格局的本地校验；
• 在实现测试后能够依据规定格局向社区提交 PR，会有专人进行 review；
• 待社区审核通过实现 merge 后，终端用户就能够在 OperatorHub.io 页面上找到业务对应的 Operator；
• 用户能够在 OperatorHub.io 上找到业务 Operator 对应的阐明文档和装置指南，通过简略的命令行操作即可在指标集群上实现 Operator 实例的装置；
• Operator 实例会依据配置创立所需的业务利用，OLM 和 Operator Metering 等组件能够帮忙用户实现业务利用对应的运维和监控采集等治理操作。

小结

本文次要介绍了 Operator 的基本概念，让您理解 Operator 的利用场景和倒退历程。

Operator 曾经成为 Kubernetes 生态的一个重要设计模式，Kubernetes 从 PaaS 层面提供整套集群、利用编排的框架，而用户通过 Operator 的形式扩大本人的利用，并实现与 Kubernetes 的交融。文章同时也介绍了应用 Operator 的生命周期流程，您能够联合本人的业务场景实现本人的 Operator 组件。

作者简介

匡大虎 阿里云高级技术专家，从事 Kubernetes 和容器相干产品的开发。尤其关注云原生平安，是阿里云容器服务云原生平安核心成员。

阚俊宝 阿里云容器服务技术专家，专一 Kubernetes、Docker、云存储畛域，是阿里云 CSI 我的项目的外围维护者。

原文链接
本文为阿里云原创内容，未经容许不得转载。