当前位置：网站首页>Kubernetes资源编排系列之四: CRD+Operator篇

Kubernetes资源编排系列之四: CRD+Operator篇

2022-08-08 10:17:00 【InfoQ】

作者炯思(钟炯恩) 雪尧(郭耀星)

这是我们的

《Kubernetes资源编排系列》

的第四篇——

CRD+Operator

篇。在前面的文章中，常常会提到CRD和k8s operator，但并没有对此进行深入的探讨。作为k8s中的一大亮点，在本篇文章中，我们会详细展开讲讲。

1. 什么是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: humans.human.sreworks.io
spec:
 group: human.sreworks.io
 names:
 kind: Human
 plural: humans
 scope: Namespaced
 versions:
 - name: v1
 served: true
 storage: true
 schema:
 openAPIV3Schema:
 description: ...
 type: object
 properties:
 spec:
 type: object
 properties:
 company:
 type: string
 ...

有了CRD之后，我们可以自由地增加各种与Pod平级的资源，很多之前需要落在CMDB中的数据，也可以被放在k8s集群中。这极大地拓宽了我们的想象力，什么交换机、作业、路由等各种关联的资源都一股脑地放进集群里面去。

在各种自定义资源被放进去之后，就会有人问，这放进去是挺方便的，但是放进去就会

生效

吗？是的，资源的生效就是Operator的功劳。下面我们就开始介绍Operator。

2. 什么是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) 。每种自定义资源背后都会有一个或多个控制器，让这些资源看起来像活的一样，如下面的YAML样例：

这个叫Bob的人，生日和性别是不可变属性，无法修改；而位置是可以修改的，可以从家改到公司，但是改完之后会有一段时间处于不Ready的状态，因为他正在去上班的路上。去哪个公司上班呢，他在helloworld公司工作，所以他是去这家公司上班。

apiVersion: v1
kind: Human
metadata:
 name: Bob
spec: 
 birth: 648489237
 sex: male
 location: home
 company: helloworld
status:
 - lastProbeTime: null
 lastTransitionTime: &quot;2022-07-20T08:41:04Z&quot;
 status: &quot;True&quot;
 type: Ready

通过上面这段YAML我们可以发现，当我们关注于对象终态的时候，我们就不太关注这个控制过程，这个Bob怎么去上班的，是开车还是地铁去的，其实我们并不关心。如果类比到普通的日常实践，也是这样：做一个应用的存储位置迁移，我们只需要设置这个应用新的存储位置，至于怎么迁移过去，是用网络命令传输过去的还是物理上用硬盘拷贝过去我们不关心，迁移过程中数据一致性我们也不关心，只知道会有operator把这些都给搞定。

所以，operator其实是一种架构理念，它区别于常见的shell等运维脚本方案：operator希望应用能够自己管理自己，而不是由运维人员写一堆脚本从外围来控制他们。

不过，如果仅仅是这样，可能operator也只能叫controller了，只是一些自控制的逻辑而已。从最前面提到的operator的概念可以看出，operator能够让两种以上的资源产生一些互动关系，那么这是如何实现的呢？

我们继续用上面Human的例子再加个YAML：

这个helloworld公司也可以用一个资源对象来描述。如果我们把这个公司的isOpen改成true，这个company会有个控制器来遍历所有的Human资源，把spec.company="helloworld"的人(比如Bob)的location全改成公司，这样就会让每个公司的人都动起来，想各种办法来公司上班。

apiVersion: v1
kind: Company
metadata:
 name: helloworld
spec: 
 startTime: 932488234
 isOpen: false

从上面的例子可以看出，每个控制器只负责自己的那部分，但从顶层往下看，已经实现了级联控制，能够实现牵一发而动全身的效果。这个就是上面所提到的operator的更深一层的机制：

能够像运算符一样，让几种资源产生某种互动关系，一起协作完成一些复杂的工程动作。

3. 如何实现K8S Operator

不管是原生 YAML / Helm 还是 Kustomize，都是通过配置来搞定各类事情。然而 CRD + Operator 就不一样了，它们让你直接接入 apiserver，作为 K8S 的一部分监听所有你关心的对象，并通过代码进行状态维持及管理。因为 CRD 的开发是非常复杂的，除了业务逻辑之外，还需要做很多基础的工作，非常不便，所以有了 Operator 的开发框架（常见的有 KubeBuilder 和 Operator-SDK），让开发人员专注于 CRD 的业务代码开发。

我们可以来看一下operator的架构实现，这个有助于我们理解operator的工作原理:

虽然有了 KubeBuilder 或 Operator-SDK 开发框架，但 Operator 的开发在当前所有的几类组件托管方案当中仍然是最为复杂的。前前后后需要 CRD 设计及安装，编译 Operator 及部署到集群，最后再下发 CR，外围为了配套这些内容可能还需要上面 Helm 或 Kustomize 的协助，配合对应的 CICD 流程及工具。

Spark Operator

Spark Operator是大数据分布式系统在k8s场景一次经典的实践。原本Spark的作业提交是需要通过spark-submit命令，但有了Spark Operator之后，我们可以直接向k8s提交作业YAML，然后Spark Operator监听CR，将这一作业提交给控制器。实现了我们前文提到的，将作业资源放在k8s集群进行管理这一目标。

敏

4. 大数据通用Operator设计与实践

上文讲述了operator实现的复杂性。不过，我们发现，越是这样复杂的应用，越是会有一些

共通性

：因为这些复杂应用基本都是分布式应用，只是在某些状态或部署顺序上的有些特殊需求。于是，我们针对这个现状，开发了一款通用的大数据Operator。

这个通用Operator的架构设计如下：

与市面上常见的golang编写的operator不同的是，我们鼓励用户不编写代码，而是直接用yaml来描述控制逻辑，按照

感知/决策/执行

三大环节来进行控制器的逻辑分解和编排设计。同时，因为有这几个环节抽象的辅助，用户在设计operator的时候能够更有目的性，对于复杂场景，不引入过多的复杂逻辑流，尽量用无状态的方式解决问题。

同时，我们还借鉴了前端框架React中的VirtualDOM的设计，在云原生场景下，引入了VirtualResource这样的一个概念。VirtualResource能够将云原生对象资源映射进行Operator的内存数据库中，让控制器能够用SQL语法快速查询和操作这些资源对象，简化Reconcile(调和)场景的逻辑复杂性。对照React框架中生命周期的概念，VirtualResource也存在生命周期的概念，用户能够控制在资源变化的不同阶段，追加一些自定义的运维描述动作。

我们在大量使用helm的情况下，发现golang template语法在进行模板渲染的时候，还是不够灵活。于是我们把整体架构栈切换到python，采用jinja2进行控制器的语法渲染，同时我们也保留helm在渲染框架中，用户能够无缝切换两种渲染引擎。

这个通用Operator的控制器将原本需要golang编写的控制层逻辑，简化成使用 cmd(指令) + yaml(资源) 的方式进行描述。控制器的描述示例如下：通过helm将vvp这个应用的所有yaml下发，监听service的状态变化，同步更新ingress资源的状态。

default:
 def: crd.yaml
 deploy:
 - cmd: helm
 chart: vvp/vvp
 values: vvp/values.yaml
 maintain:
 - watch:
 category: ResourceDidChange
 kind: Service
 apiVersion: v1
 action:
 - cmd: kube-patch
 file: ingressUpdate.yaml

5. 总结

对于承载

组件 (Component)

这个概念而言，CRD+Operator 可以说是最为复杂的，但是又是最

万能

的，如果 Helm 或者 Kustomize 无法满足需求，Operator 基本上是唯一的选择。另一方面来说，CRD+Operator 一般又会和 Helm / Kustomize 相辅相成一起出现，最难搞的事情通过 Operator 与 apiserver 交互解决，剩下的胶水粘合，各种 YAML 拼接之类的交给 Helm / Kustomize 搞定。

同时，我们也可以看出，CRD+Operator是云原生演进时期的方案，特别适合原本非k8s的软件架构上k8s。那些原本就在k8s架构下出现的软件方案，会逐渐淡化Operator这个概念: 所有的工作负载都有能力和k8s apiserver交互。

对于承载SREWorks中的应用 (Application) 这个概念而言，Operator 是不合适的，无他，太复杂了。一般来说，Operator 只要管好自己这个独立功能在 K8S 中的生命周期就已经足够了。从目前的社区方向来看，Operator 不会作为一整个业务场景应用解决方案去裸提供，而是与 Helm / Kustomize / KubeVela / AppManager 等集成并作为一个整体 (组件 or 应用) 对外发布。

后续文章我们会分享更多的Kubernetes组件和应用管理工具，均会发布在我们的公众号“

阿里智能运维

”上，请大家持续关注～也欢迎大家在公众号后台留言想了解的内容和感兴趣的相关话题，与

SREWorks

团队进行交流。

若有收获，就点个赞吧

原网站

版权声明
本文为[InfoQ]所创，转载请带上原文链接，感谢
https://xie.infoq.cn/article/2379853b33a7210ff3ee1d9df