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

时间:2024-02-17 10:23:03

欢迎访问我的GitHub

https://github.com/zq2599/blog_demos

内容:所有原创文章分类汇总及配套源码,涉及Java、Docker、Kubernetes、DevOPS等;

系列文章链接

  1. kubebuilder实战之一:准备工作
  2. kubebuilder实战之二:初次体验kubebuilder
  3. kubebuilder实战之三:基础知识速览
  4. kubebuilder实战之四:operator需求说明和设计
  5. kubebuilder实战之五:operator编码
  6. kubebuilder实战之六:构建部署运行
  7. kubebuilder实战之七:webhook
  8. kubebuilder实战之八:知识点小记

本篇概览

  • 作为《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》

初始化相关知识点

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")
)
  1. 另外还有些设置,例如监控指标相关的,以及管理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.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帮我们准备了什么:
  1. 数据结构定义,如下所示,操作资源对象时用到的客户端工具client.Client、日志工具、Kind和数据结构的关系Scheme,这些都帮我们准备好了,真贴心:
type GuestbookReconciler struct {
	client.Client
	Log    logr.Logger
	Scheme *runtime.Scheme
}
  1. SetupWithManager方法,在main.go中有调用,指定了Guestbook这个资源的变化会被manager监控,从而触发Reconcile方法:
func (r *GuestbookReconciler) SetupWithManager(mgr ctrl.Manager) error {
	return ctrl.NewControllerManagedBy(mgr).
		For(&webappv1.Guestbook{}).
		Complete(r)
}
  1. 如下图,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世界...
https://github.com/zq2599/blog_demos