kubebuilder 实战之三：基础知识速览，Java 学习的三个终极问题及学习路线规划

本篇概览

• 作为《kubebuilder 实战》系列的第三篇，本该进入真枪实弹的 operator 开发环节，却突然发现 kubebuilder 涉及的知识点太多太零散，如果现在就敲命令写代码去实战，即便完成了一次 operator 开发，但缺失大量信息（例如操作顺序怎么安排、步骤之间如何关联等），不但《kubebuilder 实战》系列失去参考价值，过几个月就连我自己都看不懂这些内容了，因此，本篇暂缓实战，咱们一起对 kubebuilder 开发过程中的知识点做一次速记，再从容的启动开发工作；

• 特别说明：webhook 是 operator 中的重要功能，其理论和实战都需要大量篇幅，因此后面会有这方面专门的文章，本文不会涉及 webhook 的知识点；

• 接下来，大串讲开始；

知识储备

• 能看懂 kubebuilder 官方 demo 的代码、会用 client 对象操作 kubernetes 资源，以上两点是胜任 operator 开发的最基本要求，否则在开发过程中会有种寸步难行的感觉，达到这些条件需要少量的知识储备，现在欣宸已经为您准备好了，希望您能简单浏览一下：

1. 《Kubernetes的Group、Version、Resource学习小记》
   

2. 《client-go实战之一：准备工作》
   

3. 《client-go实战之二:RESTClient》
   

4. 《client-go实战之三：Clientset》
   

5. 《client-go实战之四：dynamicClient》
   

6. 《client-go实战之五：DiscoveryClient》
   

初始化相关知识点

• 创建 operator 的第一步，就是用 kubebuilder 命令行创建整个项目，这个在《kubebuilder实战之二：初次体验kubebuilder》已经试过，当时执行的是如下三行命令：

mkdir -p $GOPATH/src/helloworld

cd $GOPATH/src/helloworld

kubebuilder init --domain com.bolingcavalry

• 在用上 module 之后，大家已经脱离了$GOPATH的束缚，像上面那样中规中矩的去$GOPATH/src 下面操作就略有些别扭了，来试试不用 $GOPATH 的初始化方式；

1. 随处新建一个目录(路径中不要有中文和空格)，例如/Users/zhaoqin/temp/202102/15/elasticweb

2. 在目录中用 go mod init elasticweb 命令新建名为 elasticweb 的工程；

3. 再执行 kubebuilder init --domain com.bolingcavalry，即可新建 operator 工程；

基础设施

• operator 工程新建完成后，会新增不少文件和目录，以下几个是官方提到的基础设施：

1. go.mod：module 的配置文件，里面已经填充了几个重要依赖；

2. Makefile：非常重要的工具，前文咱们也用过了，编译构建、部署、运行都会用到；

3. PROJECT：kubebuilder 工程的元数据，在生成各种 API 的时候会用到这里面的信息；

4. config/default：基于 kustomize 制作的配置文件，为 controller 提供标准配置，也可以按需要去修改调整；

5. config/manager：一些和 manager 有关的细节配置，例如镜像的资源限制；

6. config/rbac：顾名思义，如果像限制 operator 在 kubernetes 中的操作权限，就要通过 rbac 来做精细的权限配置了，这里面就是权限配置的细节；

main.go

• main.go 是 kubebuilder 自动生成的代码，这是 operator 的启动代码，里面有几处值得注意：

1. 两个全局变量，如下所示，setupLog 用于输出日志无需多说，scheme 也是常用的工具，它提供了 Kind 和 Go 代码中的数据结构的映射，：

var (

scheme = runtime.NewScheme()

setupLog = ctrl.Log.WithName("setup")

)

2. 另外还有些设置，例如监控指标相关的，以及管理 controller 和 webhook 的 manager，它会一直运行下去直到被外部终止，关于这个 manage 还有一处要注意的地方，就是它的参数，下图是默认的参数，如果您想让 operator 在指定 namespace 范围内生效，还可以在下午的地方新增 Namespace 参数，如果要指定多个 nanespace，就使用 cache.MultiNamespacedCacheBuilder(namespaces)参数：

• main.go 的内容在大多数场景无需改动，了解即可，接下来的 API 是重头戏；

API 相关（数据核心）

• API 是 operator 的核心，当您决定使用 operator 时，就应该从真实需求出发，开始设计整个 CRD，而这些设计最终体现在 CRD 的数据结构，以及对真实值和期望值的处理逻辑中；

• 在《kubebuilder 实战之二：初次体验 kubebuilder》咱们创建过 API，当时的命令是：

kubebuilder create api \

--group webapp \

--version v1 \

--kind Guestbook

• kubebuilder 自动新增了很多内容，如下图，都是为了这个 CRD 服务的：

• 新增的内容中，最核心的当然是 CRD 了，也就是上图中 Guestbook 数据结构所在的 guestbook_types.go 文件，这个最重要的数据结构如下：

type Guestbook struct {

metav1.TypeMeta json:",inline"

metav1.ObjectMeta json:"metadata,omitempty"

Spec GuestbookSpec json:"spec,omitempty"

Status GuestbookStatus json:"status,omitempty"

}

1. metav1.TypeMeta：保存了资源的 Group、Version、Kind

2. metav1.ObjectMeta：保存了资源对象的名称和 namespace

3. Spec：期望状态，例如 deployment 在创建时指定了 pod 有三个副本

4. Status：真实状态，例如 deployment 在创建后只有一个副本(其他的还没有创建成功)，大多数资源对象都有此字段，不过 ConfigMap 是个例外（想想也是，配置信息嘛，配成啥就是啥，没有什么期望值和真实值的说法）；

• 还有一个数据结构，就是 Guestbook 对应的列表 GuestbookList，就是单个资源对象的集合；

• guestbook_types.go 所在目录下还有两个文件：groupversion_info.go 定义了 Group 和 Version，以及注册到 scheme 时用到的实例 SchemeBuilder，zz_generated.deepcopy

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

.go 用于实现实例的深拷贝，它们都无需修改，了解即可；

controller 相关（业务核心）

• 前面聊过了数据核心，接下来要讨论如何实现业务需求了，在 operator 开发过程中，尽管业务逻辑各不相同，但有两个共性：

1. Status(真实状态)是个数据结构，其字段是业务定义的，其字段值也是业务代码执行自定义的逻辑算出来的；

2. 业务核心的目标，是确保 Status 与 Spec 达成一致，例如 deployment 指定了 pod 的副本数为 3，如果真实的 pod 没有三个，deployment 的 controller 代码就去创建 pod，如果真实的 pod 超过了三个，deployment 的 controller 代码就去删除 pod;

• 以上就是咱们的 controller 要做的事情，接下来看看代码的细节，kubebuilder 创建的 guestbook_controller.go 就是 controller，咱们的业务代码都写在这个文件中，来看看 kubebuilder 帮我们准备了什么：

3. 数据结构定义，如下所示，操作资源对象时用到的客户端工具 client.Client、日志工具、Kind 和数据结构的关系 Scheme，这些都帮我们准备好了，真贴心：

type GuestbookReconciler struct {