kubebuilder 实战之三：基础知识速览，mybatis 运行原理步骤
两个全局变量，如下所示，setupLog 用于输出日志无需多说，scheme 也是常用的工具，它提供了 Kind 和 Go 代码中的数据结构的映射，：
var (
scheme = runtime.NewScheme()
setupLog = ctrl.Log.WithName("setup")
)
另外还有些设置，例如监控指标相关的，以及管理 controller 和 webhook 的 manager，它会一直运行下去直到被外部终止，关于这个 manage 还有一处要注意的地方，就是它的参数，下图是默认的参数，如果您想让 operator 在指定 namespace 范围内生效，还可以在下午的地方新增 Namespace 参数，如果要指定多个 nanespace，就使用 cache.MultiNamespacedCacheBuilder(namespaces)参数：
main.go 的内容在大多数场景无需改动，了解即可，接下来的 API 是重头戏；
API 相关（数据核心）
API 是 operator 的核心，当您决定使用 operator 时，就应该从真实需求出发，开始设计整个 CRD，而这些设计最终体现在 CRD 的数据结构，以及对真实值和期望值的处理逻辑中；
在《kubebuilder 实战之二：初次体验 kubebuilder》咱们创建过 API，当时的命令是：
kubebuilder crea
te 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"
}
metav1.TypeMeta：保存了资源的 Group、Version、Kind
metav1.ObjectMeta：保存了资源对象的名称和 namespace
Spec：期望状态，例如 deployment 在创建时指定了 pod 有三个副本
Status：真实状态，例如 deployment 在创建后只有一个副本(其他的还没有创建成功)，大多数资源对象都有此字段，不过 ConfigMap 是个例外（想想也是，配置信息嘛，配成啥就是啥，没有什么期望值和真实值的说法）；
还有一个数据结构，就是 Guestbook 对应的列表 GuestbookList，就是单个资源对象的集合；
guestbook_types.go 所在目录下还有两个文件：groupversion_info.go 定义了 Group 和 Version，以及注册到 scheme 时用到的实例 SchemeBuilder，zz_generated.deepcopy.go 用于实现实例的深拷贝，它们都无需修改，了解即可；
controller 相关（业务核心）
前面聊过了数据核心，接下来要讨论如何实现业务需求了，在 operator 开发过程中，尽管业务逻辑各不相同，但有两个共性：
Status(真实状态)是个数据结构，其字段是业务定义的，其字段值也是业务代码执行自定义的逻辑算出来的；
业务核心的目标，是确保 Status 与 Spec 达成一致，例如 deployment 指定了 pod 的副本数为 3，如果真实的 pod 没有三个，deployment 的 controller 代码就去创建 pod，如果真实的 pod 超过了三个，deployment 的 controller 代码就去删除 pod;
以上就是咱们的 controller 要做的事情，接下来看看代码的细节，kubebuilder 创建的 guestbook_controller.go 就是 controller，咱们的业务代码都写在这个文件中，来看看 kubebuilder 帮我们准备了什么：
数据结构定义，如下所示，操作资源对象时用到的客户端工具 client.Client、日志工具、Kind 和数据结构的关系 Scheme，这些都帮我们准备好了，真贴心：
type GuestbookReconciler struct {
client.Client
Log logr.Logger
Scheme *runtime.Scheme
}
SetupWithManager 方法，在 main.go 中有调用，指定了 Guestbook 这个资源的变化会被 manager 监控，从而触发 Reconcile 方法：
func (r *GuestbookReconciler) SetupWithManager(mgr ctrl.Manager) error {
return ctrl.NewControllerManagedBy(mgr).
For(&webappv1.Guestbook{}).
Complete(r)
}
如下图，Reconcile 方法前面有一些+kubebuilder:rbac 前缀的注释，这些是用来确保 controller 在运行时有对应的资源操作权限，例如红框中就是我自己添加的，这样 controller 就有权查询 pod 资源对象了：
guestbook_controller.go 是 operator 的业务核心，而 controller 的核心是其 Reconcile 方法，将来咱们的大部分代码都是写在这里面的，主要做的事情就是获取 status，然后让 status 和 spec 达成一致；
关于 status，官方的一段描述值得重视，如下图红框，主要是说资源对象的状态应该是每次重新计算出来的，这里以 deployment 为例，想知道当前有多少个 pod，有两种方法，第一种准备个字段记录，每次对 pod 的增加和删除都修改这个字段，于是读这个字段就知道 pod 数量了，第二种方法是每次用 client 工具去实时查询 pod 数量，目前官方明确推荐使用第二种方法：
至此，基础知识串讲就完成了，咱们按照官方资料的顺序把知识点过了一遍，接下来，就是按照官方资料的顺序去实战了，让大家久等了，下一篇，operator 实战；
你不孤单，欣宸原创一路相伴
还未添加个人签名 2021.03.18 加入
还未添加个人简介
评论