插入关键字 文章采集器(operator概述operatorframework实战工作流程概述#基本概念#)

　　插入关键字 文章采集器(operator概述operatorframework实战工作流程概述#基本概念#)

　　本课程主要分享以下三个方面：

　　算子概览算子框架实际工作流算子概览#基本概念#

　　首先，让我们介绍一下本节涉及的基本概念。

　　根据处理类型的不同，一般可以分为两类：一类可以修改传入的对象，称为mutating webhook；一种类型将只读取传入的对象，称为验证 webhook。

　　常用算子工作模式#

　　工作过程：

　　用户创建自定义资源（CRD）；apiserver根据自己注册的pass list将CRD的请求转发给webhook；webhook一般完成CRD的默认值设置和参数校验。webhook处理完成后，会将对应的CR写入数据库并返回给用户；同时，控制器会在后台监控自定义资源，并根据业务逻辑处理与自定义资源相关的特殊操作；上述处理一般会引起集群的状态变化，控制器会监控这些关联的变化，并将这些变化记录在CRD的状态中。

　　这里是来自高层的概括介绍，后面会结合案例进行重新整理。

　　算子框架实战#算子框架概览#

　　在开始之前，我们先介绍一下算子框架。它实际上为用户提供了 webhook 和控制器的框架。其主要意义是帮助开发者屏蔽一些常见的底层细节，无需开发者实现消息通知触发、失败重新排队等，即可实现管理应用的运维逻辑。

　　主流的算子框架主要有两种：kubebuilder和operator-sdk。

　　两者其实没有本质区别，核心是使用官方的controller-tools和controller-runtime。但是，细节略有不同。比如kubebuilder有比较完善的测试部署和代码生成脚手架等；而operator-sdk对ansible operator等上层操作有更好的支持。

　　kuberbuildere战斗#

　　这里的实战是kuberbuilder。案例使用阿里云开通的kruise项目下的SidercarSet。

　　SidecarSet 的作用是将 sidecar 容器（也称为辅助容器）插入到 Pod 中。比如可以插入一些监控，记录采集来丰富Pod的功能，然后根据插入的状态和Pod的状态更新SidercarSet。记录这些辅助容器的状态。

　　第 1 步：初始化

　　操作：

　　创建一个新的 GitLab 项目并运行

　　Copykubebuilder init --domain=kruise.io

　　参数解释：

　　domain 指定后续注册的 CRD 对象的 Group 域名。

　　效果解读：

　　拉取依赖代码库，生成代码框架，生成Makefile/Dockerfile等工具文件。

　　我们来看看它生成的具体内容（为了方便演示，实际生成的文件已被部分删除）：

　　具体内容可以自己在实战中确认。

　　第 2 步：创建 API

　　操作：

　　跑

　　Copykubebuilder create api --group apps --version v1alpha1 --kind SidecarSet --namespace=false

　　实际上，不仅会生成API，也就是CRD，还会生成Controller的框架。

　　参数解释：

　　它的参数基本上可以分为两类。组、版本、种类基本对应CRD元信息的三个重要组成部分。以下是一些您在实际使用时可以参考的通用标准。namespaced 用于指定我们刚刚创建的 CRD 是全局唯一的（例如节点）还是名称空间唯一的（例如 Pod）。这里使用了 False，即 SidecarSet 被指定为全局唯一。

　　效果解读：

　　生成CRD和控制器的框架，后面需要手动填写代码。

　　实际结果如下图所示：

　　我们重点关注图中的蓝色字体。sidecarset_types.go 是定义 CRD 的地方，需要填写。 si​​decarset*controller.go 用于定义控制器，也需要填写。

　　第三步：填写 CRD 生成的 CRD 位于 pkg/apis/apps/v1alpha1/sidecarset_types.go，通常需要以下两个操作：

　　(1) 调整说明

　　代码*敏*感*词*依赖注解生成代码，所以有时需要对注解进行调整。下面列出本次实战中需要调整 SidecarSet 的注释：

　　(2) 填写字段

　　填充字段是使用户的 CRD 真正工作并真正有意义的重要部分。

　　填完后运行make重新生成代码

　　需要注意的是，开发者不需要参与 CRD 的 grpc 接口、编*敏*感*词*和其他控制器的底层实现。

　　实际的填充看起来像这样：

　　SidecarSet 的作用是将 Sidecar 注入到 Pod 中。为了完成这个功能，我们在 SidecarSetSpec（左）中定义了两条主要信息：一个是 Selector，用于选择需要注入哪些 Pod；另一个是定义 Sidecar 容器的容器。

　　状态信息在 SidecarSetStatus 中定义（右），MatchedPods 反映了 SidecarSet 实际匹配的 Pod 数量，UpdatedPods 反映了注入了多少 Pod，ReadyPods 反映了有多少 Pod 已经正常工作。

　　完整内容可参考（ ）。

　　第 4 步：生成 webhook 框架以生成 mutating webhook，运行：

　　Copykubebuilder alpha webhook --group apps --version v1alpha1 --kind SidecarSet --type=mutating --operations=create

kubebuilder alpha webhook --group core --version v1 --kind Pod --type=mutating --operations=create

　　要生成验证 webhook，请运行：

　　Copykubebuilder alpha webhook --group apps --version v1alpha1 --kind SidecarSet --type=validating --operations=create,update

　　参数解释：

　　效果解读：

　　实际生成的结果如下图所示：

　　我们执行了三个命令，生成了三个不同的需要填充的处理程序（上图中蓝色字体部分）。这里就不提了，在接下来的填充操作中会详细讲解。

　　第 5 步：填充 webhook

　　生成的 webhook 处理程序位于：

　　需要改写和填写的内容一般包括以下两部分：

　　我们来看看实际的填充结果。

　　因为在第四步，我们定义了三个：sidecarset mutating、sidecarset mutaing、pod mutating。

　　我们先来看上图左侧的sidecarset mutating。首先，setDefaultSidecarSet 设置默认值，这也是变异最常见的事情。

　　上图右边的validation也很规范，还检查了SidecarSet的一些字段。

　　关于 pod 变异，这里没有显示。这里有一些区别。这里的mutaingSidecarSetFn并没有设置默认值，而是获取setDefaultSidecarSet的值，注入到Pod中。

　　第 6 步：填充控制器

　　生成的控制器骨架位于 pkg/controller/sidecarset/sidecarset_controller.go 中。需要修改的主要有三点：

　　我们来看看 SidecarSet 的 Controller 的填充结果：

　　在 addPod 中，取出 Pod 对应的 SidecarSet，并加入到队列中供 Reconcile 处理。

　　Reconcile 取出 SidercarSet 后，根据 Selector 选择匹配的 Pod，最后根据 Pod 当前的状态信息计算集群状态，然后回填到 CRD 状态。

　　SidecarSet 的工作流程#

　　最后，让我们重新整理一下 SidecarSet 的工作流程，以便我们了解 operator 是如何工作的。

　　用户创建一个 SidecarSet；webhook 收到 SidecarSet 后，会进行默认值设置和配置项校验。这两个操作完成后，真正的存储就完成了，并返回给用户；用户创建一个 Pod；webhook会取回对应的SidecarSet，并从中取出容器注入到Pod中，这样Pod在实际入库的时候已经自带了。有了刚才的边车；控制器在后台不断轮询以检查集群的状态变化。第 4 步中的注入将触发 sidecarSet 入队，控制器将 SidecarSet 的 UpdatedPods 加 1。