1.2.3 主流Operator 开发工具介绍
我们通过前面的内容了解到,Operator的运行机制是作为自定义扩展资源注册到Controller Manager,通过 List-Watch的方式监听对应资源的变化,然后在周期内的各个环节进行相应的协调。在Operator开发工具出现前,用户为了实现一个 Operator, 需要完全实现从KubernetesClient创建,到监听 KubernetesAPIServer请求,再到请求队列化,以及后面的业务逻辑等一整套逻辑。
Operator开发工具将 Operator 实现过程逻辑封装和抽象成公共的库和工具,并通过SDK等方式供开发者二次开发使用。开发者在开发 Operator 时,只需要通过开发工具生成脚手架代码——他们无须关心 Kubernetes APIServer 发来的请求是怎样进入请求队列,被依次执行的,只需要专注于如何处理当前的请求即可。其他事情,Scaffolding代码中用到的Controller-runtime 等库会帮助处理。
目前,OperatorSDK(来自于 CoreOS)和 Kubebuilder(来自于 Kubernetes)是开发Operator常用的两种SDK,或者称为大框架(Framework),两种方式都完成了步骤规范和初始化元素,并生成相应的模板,便于开发者实现加入自定义的功能。接下 来我们为大家分别介绍上述两种工具。
1. Kubebuilder
Kubebuilder是一个帮助开发者快速开发KubernetesAPI 的脚手架命令行工具,依赖Controller-tool和 Controller-runtime等库,简化 KubernetesController 的开发,并且对 Kubernetes 的几个常用库进行了封装,图 1-11为 Kubebuilder 的工作流程。
Kubebuilder 的整体工作流程如下。
(1)初始化一个新的工程目录。
(2) 创建一个或多个资源 API CRD,然后将字段添加到资源。
(3) 在控制器中实现协调循环(ReconcileLoop),监听额外的资源。
(4) 在集群中运行测试(自动安装 CRD 并自动启动控制器)。
(5)更新引导测试新字段和业务逻辑。
(6)生产环境使用 Dockerfile构建和发布容器。
其中步骤(2)和(3)是 Kubebuilder核心业务逻辑,其余步骤均通过自动生成脚手架代码方式完成。Kubebuilder脚手架生成 Operator的代码后,开发者只需要在图1-11 的 Reconciler中实现自己的控制逻辑即可完成 Operator的构建和发布。
图 1—11Kubebuider的工作流程
2. OperatorFramework
OperatorFramework是 RedHat和 Kubernetes 社区共同推出的开源项目框架,旨在帮助开发者高效、快速地开发自身业务对应的 Operator。OperatorFramework其实是一组用于快速开发Operator的开源工具集,它主要包含如下 3个组件
(1)OperatorSDK
OperatorSDK提供了一组用于构建、测试和打包 Operator的工具,一个 Operator开发者可以利用 SDK方便、高效地生成一套具备基础框架的 Operator脚手架代码,它抽象了Client-go库的实现细节,开发者无须了解如何扩展复杂的Kubernetes API模型和具体的Controller框架。OperatorSDK工具与手动编写CRD/Operator代码相比,需要完成 CRD类型创建及Reconcile控制循环,但是对于创建目录结构、定义注册和文件等通用步骤均由 OperatorSDK 自动帮助完成。
(2)Operator 生命周期管理
Operator的生命周期管理由 OLM(Operator Lifecycle Manager)完成,当开发者使用 SDK构建好自己的Operator后,可以使用 OLM将其部署到对应的 Kubernetes集群中。通过 OLM,集群管理员可以控制 Operator部署在哪些 Namespace中。除此以外,OLM还负责在Operator实例运行的生命周期中进行相应的管理工作,如 Operator和其依赖资源的自动化更新等运维操作。
(3)OperatorMetering
在 Kubernetes 广泛应用的自动扩缩容或混合云部署等业务场景下,资源计量是客户的重要需求,同时它也是业务应用计量计费的依据。另外,对于大规模分布式的 Operator应用场景,Metering也是聚合统计资源和服务使用情况的有效手段之一。