概述
kubebuilder 是创建自定义控制器的工具，可以理解成用 Go 生成一个 Go 的项目，社区中类似的项目是不少的，比较有名的还有类似 swag 这样的项目。
为什么会需要Operator
这个问题其实是我们比较关注的，讲道理，Kubernetes 原生的一些基本资源已经可以满足不少场景了，比如部署一个 Deployment 替换了原来的虚拟机、物理机上的无状态的服务，又或者是通过 StatefulSet 来部署一些有状态的服务。但是由于一些公司业务和架构的复杂性，当在使用 Kubernetes 越来越深入的时候，就会发现，仅有这些资源对象，还不足以应付所有的场景，或者换句话说，通过 Operator 这样的方式来扩展我们使用 Kubernetes 的使用方式，可以让我们在业务和架构上受益，比如说减少了一些人肉运维的工作，又或者是让原来的服务运行的更稳定等等。
搞清楚几个概念
- Groups: API Groups是指k8s里一系列的功能或者资源，Groups是有版本Versions的，可以有一个或者多个
- Versions: 是指某个k8s的Groups的版本
- Kinds: 一般来说一个Groups下会有一个或者多个API类型，当然这些Kinds根据Groups里的Version也可能会不太一样
- Resources: 一般是在k8s API的角度去考虑，Resources就是k8s里的一个资源，类似一个叫Pod的Kind，以及对应的pods
- GVK: 也叫GroupVersionKind，GVK一般是从Go的类型来考虑的
- API: 一般G+V+K，就代表着API了，可以通过理解kubebuilder create api…来理解
QuickStart操作
下面这个几个命令，基本上是你开发自定义资源控制器的时候经常会用到的命令了，最好了解一下这些命令的含义，建议在可以访问外网的环境下操作，否则就需要配置各种代理。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
# download kubebuilder and install locally.
curl -L -o kubebuilder https://go.kubebuilder.io/dl/latest/$(go env GOOS)/$(go env GOARCH)
chmod +x kubebuilder && mv kubebuilder /usr/local/bin/
mkdir -p /tmp/projects/guestbook
cd /tmp/projects/guestbook
kubebuilder init --domain my.domain --repo my.domain/guestbook
kubebuilder create api --group webapp --version v1 --kind Guestbook
# 这里会咨询是否创建自定义资源和Controller，都选Y就行了
make manifests
make install
# 这只是二进制的方式运行，没有跑进去集群的
make run
# 在集群创建资源，但只有资源没有controller
kubectl apply -f config/samples/
# 最好有私有的镜像仓库
make docker-build docker-push IMG=core.harbor.domain/library/test:v1
make deploy IMG=core.harbor.domain/library/test:v1
make uninstall
make undeploy
|
CronJob
上面的 QuickStart 是比较简单的操作版本，下面的例子会更深入的去了解如何构建更复杂的自定义资源和控制器。
1
2
3
4
5
6
7
|
cd /tmp
# create a project directory, and then run the init command.
mkdir project
cd project
# we'll use a domain of tutorial.kubebuilder.io,
# so all API groups will be <group>.tutorial.kubebuilder.io.
kubebuilder init --domain tutorial.kubebuilder.io --repo tutorial.kubebuilder.io/project
|
查看一下 project 目录下的文件清单。
添加一个新的 API。
1
|
kubebuilder create api --group batch --version v1 --kind CronJob
|
Controller 的逻辑如下:
- 加载资源Cronjob
- List所有active的job，以及Update他们的状态
- 根据history limits清理过期的job
- 进入下一次调度
- 创建一个新的job
还可以通过 kubebuilder 来创建 webhook。
1
|
kubebuilder create webhook --group batch --version v1 --kind CronJob --defaulting --programmatic-validation
|
Controller 的业务代码都写好了之后，就可以将 Controller 安装到集群了。
1
2
3
4
5
6
7
8
9
|
make manifests
make install
# 不开启webhook
make run ENABLE_WEBHOOKS=false
# 创建资源
kubectl create -f config/samples/batch_v1_cronjob.yaml
# 测试
kubectl get cronjob.batch.tutorial.kubebuilder.io -o yaml
kubectl get job
|
架构
下面这个架构图可以帮助理解通过 kubebuilder 构建出来的 controller 的作用以及原理。
关于多版本
一般在公司内部要自研一个 Operator，多版本是需要考虑的问题。一般来说，很多公司内部如果使用了多年的的 Kubernetes 集群，那么版本肯定是会有些差异的，比如内部还有些旧的还没有迁移的集群，例如1.8的 Kubernetes 集群，那么在开发 Operator 的时候就必须要考虑多版本了，毕竟最新的 Kubernetes 已经到1.26了（当然版本差异太多，API的变化会很大，要同时部署多个集群版本的话需要充分测试）。
参考资料
- Kubebuilder Quick Start
- Building CronJob
警告
本文最后更新于 2017年2月1日，文中内容可能已过时，请谨慎参考。
