kubebuilder 实战之三：基础知识速览

• 在《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. 《一线大厂 Java 面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》开源 deepcopy.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 {

client.Client

Log logr.Logger

Scheme *runtime.Scheme

}

4. SetupWithManager 方法，在 main.go 中有调用，指定了 Guestbook 这个资源的变化会被 manager 监控，从而触发 Reconcile 方法：

Java 开源项目【ali1024.coding.net/public/P7/Java/git】

func (r *GuestbookReconciler) SetupWithManager(mgr ctrl.Manager) error {

return ctrl.NewControllerManagedBy(mgr).

For(&webappv1.Guestbook{}).

Complete(r)

}

5. 如下图，Reconcile 方法前面有一些+kubebuilder:rbac 前缀的注释，这些是用来确保 controller 在运行时有对应的资源操作权限，例如红框中就是我自己添加的，这样 controller 就有权查询 pod 资源对象了：

• guestbook_controller.go 是 operator 的业务核心，而 controller 的核心是其 Reconcile 方法，将来咱们的大部分代码都是写在这里面的，主要做的事情就是获取 status，然后让 status 和 spec 达成一致；

• 关于 status，官方的一段描述值得重视，如下图红框，主要是说资源对象的状态应该是每次重新计算出来的，这里以 deployment 为例，想知道当前有多少个 pod，有两种方法，第一种准备个字段记录，每次对 pod 的增加和删除都修改这个字段，于是读这个字段就知道 pod 数量了，第二种方法是每次用 client 工具去实时查询 pod 数量，目前官方明确推荐使用第二种方法：

• 至此，基础知识串讲就完成了，咱们按照官方资料的顺序把知识点过了一遍，接下来，就是按照官方资料的顺序去实战了，让大家久等了，下一篇，operator 实战；

[](()你不孤单，欣宸原创一路相伴

1. [Java 系列](()

2. [Spring 系列](()

3. [Docker 系列](()

4. [kubernetes 系列](()

5. [数据库+中间件系列](()

6. [DevOps 系列](()

[](()欢迎关注公众号：程序员欣宸

微信搜索「程序员欣宸」，我是欣宸，期待与您一同畅游 Java 世界…

面试资料整理汇总

这些面试题是我朋友进阿里前狂刷七遍以上的面试资料，由于面试文档很多，内容更多，没有办法一一为大家展示出来，所以只好为大家节选出来了一部分供大家参考。

面试的本质不是考试，而是告诉面试官你会做什么，所以，这些面试资料中提到的技术也是要学会的，不然稍微改动一下你就凉凉了

在这里祝大家能够拿到心仪的 offer！