如何实现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 集群进行管理这一目标。

以上内容摘自《SREWorks 云原生数智运维工程实践》电子书，点击https://developer.aliyun.com/ebook/download/7784可下载完整版。