云原生之Kubernetes：16、详解Operator控制器

1、为什么需要Operator？

我们前面讲了很多很多基础的资源对象和控制器，如pod、deployment、service、deployment等等，仿佛已经满足了我们大多数情况的场景和需求了，那我们为什么还需要operator呢？

我们之前所讲到无状态应用（如nginx）的扩容是最方便的，我们只要使用deployment控制器中的ReplicaSet字段申明，我们需要几个数量的nginx节点即可。

那有状态的应用又该怎么办呢？

此时你应该会想到这之前所说的，StatefulSet控制器，没错！他的确能够帮助我们解决有状态应用基础的扩缩容动作和行为逻辑，但是还有大多数场景，他是完成不了的。

比如mysql主从集群、多主集群的扩缩容、备份、数据迁移等包含一系列传统架构中，都需要运维人员介入，并通过脚本处理一些复杂的操作。

另外，在Kubernetes上运维人员通常喜欢使用自动化来处理重复的任务。

Operator控制器就是将运维人员的知识、操作和预期翻译成代码片段，如果你了解jenkins，就好比jenkins file、DSL和groovy。
这是我一直坚信和推崇的一个理念：
“基础设施即代码”（Infrastructure as Code）

正是如此，他们每个节点具有不同的角色配置文件、启动顺序、依赖性和自动化操作。

此时，StatefulSet控制器已经胜任不了了，Operator就此诞生！

2、什么是Operator？

Operator由CoreOS开发的，通过软件的方式进行扩展kubernetes。
Operator通过使用CRD（自定义资源）来管理他们各有应用和基础组件。

CRD(CustomResourceDefinition)：通过扩展kubernetesAPI，从而满足用户的定制化需求。
我们后面会具体讲解

同时，Operator也遵循了kubernetes的原理、尤其是控制循环。

注意：Operator的开发和维护工作，并不属于kubernetes本身，而是在于各产品线（mysql、jenkins、prometheus等等）。
他们才是致力于维护各自Operator的主角，并帮助用户快速在kubernetes集群上搭建、维护和高效使用自己的产品。

3、Operator原理

Operator通过扩展Kubernetes定义Custom Controller，观察应用并根据实际状态执行自定义任务。

应用被定义为Kubernetes对象：Custom Resource （CR），它包含yaml spec和被API服务接受的对象类型。

如图所示，Operator控制器的调度逻辑和以往原生控制器调度的逻辑有以下的不同点：

1、Operator通过Custom Controller协调应用的spec属性，原生控制器则通过kubelet；
2、Operator可以独立运行在集群内部或外部，原生控制器则必须运行于集群内部。

Operator控制器真正价值来自于你对应用失败状态处理的最佳实践，以及Operator如何协同人工干预的期望逻辑。

4、Operator应用场景

如果有以下涉及的工作内容刚需，你可以选择operator来帮助你：

1、按需部署应用程序
2、获取并恢复应用程序状态的备份数据
3、处理应用程序升级相关的变更需求，如数据库库表，或者是额外事项的配置
4、发布一个服务，使得原本kubernetes API原生不支持的应用可以发现它
5、模拟整个或部分集群中的故障以测试其弹性
6、在没有内部成员选举程序的情况下，为分布式应用程序选择一位领导者

5、如何部署Operator

我们部署Operator最常见也是最通用的方法就是，在我们的kubernetes集群中，新增相应的CRD资源，以及和他相关联的控制器。

这个控制器通常运行于控制平面(https://kubernetes.io/docs/reference/glossary/?all=true#term-control-plane)之外。

这里我还整理了两个市面上主流的Operator资源社区，供你实践时参考使用：
operatorhub.io(