作者：炯思（钟炯恩）、雪尧（郭耀星）
这是我们的《Kubernetes资源编排系列》的第四篇——CRD+Operator篇。在前面的文章中，常常会提到CRD和k8s operator，但并没有对此进行深入的探讨。作为k8s中的一大亮点，在本篇文章中，我们会详细展开讲讲。
一、 什么是CRD
如果K8S中的自带资源类型不足以满足业务需求，需要定制开发资源怎么办？自定义资源（Custom Resource）由此产生。那么，如何让Kubernetes认识这些自定义的资源呢？CRD（Custom Resource Definition）就承担了一个说明书的角色，让Kubernetes来认识这个自定义资源CR。
那么CRD是怎么来的呢？最早是谷歌提出Third Party Resource的概念，希望开发者以插件化形式扩展K8s API对象模型，以增强整个k8s的生态。基于Third Party Resource这一概念，Kubernetes社区在1.7版本中提出了CRD的概念。
随便打开一个CRD的YAML可以看到，其主体部分是使用OpenAPI v3 schema来描述CR的字段结构，类似编程语言中的强类型声明。
apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: lights.light.sreworks.io spec: group: light.sreworks.io names: kind: Light plural: lights scope: Namespaced versions: - name: v1 served: true storage: true schema: openAPIV3Schema: description: ... type: object properties: spec: type: object properties: company: type: string ...
|
有了CRD之后，我们可以自由地增加各种内置资源平级的资源，原本很多之前只维护在软件内部的元数据，也可以被写入到k8s集群中。这极大地拓宽了我们的想象力，什么交换机、作业、路由等各种关联的资源都一股脑地放进集群里面去。
在各种自定义资源被放进去之后，就会有人问，这放进去是挺方便的，但是放进去就会生效吗？是的，资源的生效就是Operator的功劳。下面我们就开始介绍Operator。
二、 什么是Operator
首先随便翻看一本词典看一下operator这个词的定义：操作员/运算符，是个名词。那么，operator描述的应该是一个围绕“操作、控制”概念的东西。为了让大家有个更直观的认识，我们来举一个例子，比如1+2=3，这个“+”就是一个operator（运算符），这个“+”让两个数字发生了一些互动（相加）。
有了词典里的概念铺垫后，我们继续往下分析，既然是一种操作或运算，那么在k8s中，是谁来操作？而被操作的对象又是什么呢？让我们来看一下OperatorFramework官网上对于Operator的解释：
WHAT IS AN OPERATOR AFTER ALL?
An Operator represents human operational knowledge in software, to reliably manage an application. They are methods of packaging, deploying, and managing a Kubernetes application.
从这个定义中，我们可以看到，这个operator是指由人发出的，对k8s应用（Kubernetes application）展开的操作。一般围绕应用的操作有哪些？部署、升级、扩缩容、卸载等等。我们可以先这样理解，operator应该就是一个类似控制器的东西，里面含有一些运维操作（后面会继续展开，其实不仅仅是这些）。
较真一点的读者可能会问，既然这样，这东西叫controller是不是会更贴切一点呢？事实上，问出这个问题的读者，和真相很接近了，每个operator基本都会有个控制器，但又不仅仅只有一个控制器，还会有前面提到过的资源定义：CRD（CustomResourceDefinition）。每种自定义资源背后都会有一个或多个控制器，让这些资源看起来像活的一样，我们举一个比较切近生活的例子：
我们为家里的灯制作一个CRD和operator，把这个operator和灯开关连起来，当用户修改这个YAML的时候，operator会向开关转发指令。
apiVersion: v1 kind: Light metadata: name: bedroom spec: power: on brightness: 70 colorTemperature: 5000k
|
从名字可以看出这盏灯被放在卧室（bedroom），当power=on的时候电灯打开，power=off的时候电灯关闭，修改亮度（brightness）和色温（colorTemperature）能操纵这盏灯在打开状态下的视觉效果。
通过上面这段灯的YAML我们可以发现，在CRD+operator的场景下，我们可以只关注对象终态，而不去关注其中的控制过程。比如当前家中网络不太稳定，要花1-2秒，重试3次operator才能成功下发指令打开灯，这些重试我们是不感知的。我们只知道只要将power设置为on，灯就会亮。类比到k8s的日常实践，也是这样：一个Pod被放到集群后，控制器会想方设法去克服困难：从仓库拉取镜像，启动工作负载，如果crash掉了就立即重试，直到稳定运行为止。我们只关心这个Pod是否最终拉起可用。
所以，operator其实是一种架构理念，它区别于常见的shell等运维脚本方案：operator希望应用能够自己管理自己，而不是由运维人员写脚本从外围来控制他们。不过，如果仅仅是这样，可能operator也只能叫controller了，只是一些自控制的逻辑而已。从最前面提到的operator的概念可以看出，operator能够让两种以上的资源产生一些互动关系，那么这是如何实现的呢？
我们继续用上面的灯的例子再加个YAML让大家感受一下：
我们把自己的家也用一个自定义资源对象来描述，用来承载一些家中的全局设置。
apiVersion: v1 kind: Home metadata: name: jiongsi-home spec: nobody: false stayOpen: []
|
当我们家中所有人都出门的时候，家中就没有人了，于是将nobody设为true。然后Home的operator会遍历家中所有的开关、电器、灯等设备，全部都给关上（在YAML上设置power=off）。同时也会根据常亮的策略（stayOpen），保持某些电器不关闭，比如冰箱。
从上面的例子可以看出，每个控制器只负责自己的那部分，但从顶层往下看，已经实现了级联控制，能够实现牵一发而动全身的效果。这个就是上面所提到的operator的更深一层的机制：能够像运算符一样，让几种资源产生某种互动关系，一起协作完成一些复杂的工程动作。
三、 如何实现K8S Operator
不管是原生YAML/Helm还是Kustomize，都是通过配置来搞定各类事情。然而CRD+Operator就不一样了，它们让你直接接入apiserver，作为K8S的一部分监听所有你关心的对象，并通过代码进行状态维持及管理。因为CRD的开发是非常复杂的，除了业务逻辑之外，还需要做很多基础的工作，非常不便，所以有了Operator的开发框架（常见的有KubeBuilder和Operator-SDK），让开发人员专注于CRD的业务代码开发。
我们可以来看一下operator的架构实现，这个有助于我们理解operator的工作原理：
如图可知，Operator内部有个控制器来监听CR的变化，同时由于每个变化对应的函数执行需要一定的耗时，所以引入一个队列来依次执行这些函数。由于整个逻辑的执行链路不同于普通的web服务，所以也需要一个框架来承载请求的流转。
市面上的KubeBuilder或Operator-SDK开发框架可以降低Operator的难度，但Operator的开发在当前所有的几类组件托管方案当中仍然是最为复杂的。前前后后需要CRD设计及安装，编译Operator及部署到集群，最后再下发CR，外围为了配套这些内容可能还需要上面Helm或Kustomize的协助，配合对应的CICD流程及工具。
• Spark Operator
Spark Operator是大数据分布式系统在k8s场景一次经典的实践。原本Spark的作业提交是需要通过spark-submit命令，但有了Spark Operator之后，我们可以直接向k8s提交作业YAML，然后Spark Operator监听CR，将这一作业提交给控制器。实现了我们前文提到的，将作业资源放在k8s集群进行管理这一目标。
