目录
概念
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工作模式:
- 用户创建一个自定义资源 (CRD);
- apiserver 根据自己注册的一个 pass 列表,把该 CRD 的请求转发给 webhook;
- webhook 一般会完成该 CRD 的缺省值设定和参数检验。webhook 处理完之后,相应的 CR 会被写入数据库,返回给用户;
- 与此同时,controller 会在后台监测该自定义资源,按照业务逻辑,处理与该自定义资源相关联的特殊操作;
- 上述处理一般会引起集群内的状态变化,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 这类上层操作的支持更好一些。