Operator基础

目录

概念

工作流程

Operator Framework

---

概念

CRD (Custom Resource Definition):  允许用户自定义 Kubernetes 资源，是一个类型；

CR (Custom Resourse):  CRD 的一个具体实例；

webhook: 它本质上是一种 HTTP 回调，会注册到 apiserver 上。在 apiserver 特定事件发生时，会查询已注册的 webhook，并把相应的消息转发过去。按照处理类型的不同，一般可以将其分为两类：一类可能会修改传入对象，称为 mutating webhook；一类则会只读传入对象，称为 validating webhook。

工作队列：controller 的核心组件。它会监控集群内的资源变化，并把相关的对象，包括它的动作与 key，例如 Pod 的一个 Create 动作，作为一个事件存储于该队列中；

controller: 它会循环地处理上述工作队列，按照各自的逻辑把集群状态向预期状态推动。不同的 controller 处理的类型不同，比如 replicaset controller 关注的是副本数，会处理一些 Pod 相关的事件；

operator：是 CoreOS 推出的旨在简化复杂有状态应用管理的框架，它是一个感知应用状态的控制器，通过扩展 Kubernetes API 来自动创建、管理和配置kubernetes应用，如数据库、缓存和监控系统。从实现上来说，可以将其理解为 CRD 配合可选的 webhook 与 controller 来实现用户业务逻辑，即 operator = CRD + webhook + controller。

工作流程

常见的operator工作模式：

1. 用户创建一个自定义资源 (CRD)；
2. apiserver 根据自己注册的一个 pass 列表，把该 CRD 的请求转发给 webhook；
3. webhook 一般会完成该 CRD 的缺省值设定和参数检验。webhook 处理完之后，相应的 CR 会被写入数据库，返回给用户；
4. 与此同时，controller 会在后台监测该自定义资源，按照业务逻辑，处理与该自定义资源相关联的特殊操作；
5. 上述处理一般会引起集群内的状态变化，controller 会监测这些关联的变化，把这些变化记录到 CRD 的状态中。

 

Operator Framework

Operator Framework实际上给用户提供了 webhook 和 controller 的框架，它的主要意义在于帮助开发者屏蔽了一些通用的底层细节，不需要开发者再去实现消息通知触发、失败重新入队等，只需关注被管理应用的运维逻辑实现即可。

Operator Framework提供了如下能力用于帮助开发者更快地开发Operator：

1、Operator SDK: 提供了开发Operator的脚手架功能，稍微降低了相关的开发难度，从构建、测试打包Operator，相关功能都有包含。

Operator SDK 提供以下工作流来开发一个新的 Operator：

1）使用 SDK 创建一个新的 Operator 项目

2）通过添加自定义资源（CRD）定义新的资源 API

3）指定使用 SDK API 来 watch 的资源

4）定义 Operator 的协调（reconcile）逻辑

5）使用 Operator SDK 构建并生成 Operator 部署清单文件

2、Operator生命周期管理（OLM）：对于Operator在Kubernetes集群上从安装、更新到管理的全生命周期进行管理。

主流的 operator framework 主要有两个：kubebuilder 和 operator-sdk。

两者实际上并没有本质的区别，它们的核心都是使用官方的 controller-tools 和 controller-runtime。不过细节上稍有不同，比如 kubebuilder 有着更为完善的测试与部署以及代码生成的脚手架等；而 operator-sdk 对 ansible operator 这类上层操作的支持更好一些。