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 实战;
评论