1 什么是Operator
k8s原生提供了很多资源类型，像用于无状态应用的Deployment、ReplicaSet和有状态应用的StatefulSet，用户可以通过向k8s提交yaml文件的方式进行资源的管理，但是，有时候，原生的这些资源无法满足我们的需求，例如，当用户希望在k8s中部署prometheus进行业务监控。
在prometheus的监控体系中，除了二进制程序，重要的就是几个配置文件：prometheus自身要抓取数据的目标、获取到数据后的检测规则等。因此，一种实现方式是将prometheus部署为Pod，并将它们的配置文件放到ConfigMap，prometheus从ConfigMap挂载，当用户修改ConfigMap时，在prometheus的Pod中加一个sidecar容器，该容器检测ConfigMap挂载的文件的变化，如果该文件变化，则调用prometheus接口让prometheus热加载配置，以此来完成配置的变更和加载操作。这种方式的问题是，对于不熟悉prometheus的用户还需要花时间去学习如何配置prometheus，而且，对于业务数据采集的场景下，prometheus的部署和维护可能是运维人员，用户通常只希望提供业务数据采集接口进行接入即可，最重要的是，这种方式不够k8s。
k8s提供了一种特殊的CustomResourceDefinition资源类型，用户可以通过这种资源类型向k8s增加新的资源类型，如上例，可以增加PrometheusScrapeTarget、PrometheusRule等资源类型，用户可以用k8s的方式创建这些资源。但是，创建这些资源只是让k8s知道有这个新的资源类型，没有任何组件去驱动这些资源生效，例如，当用户创建PrometehsuScrapeTarget时，在该资源中声明需要采集的Pod的selector，那么，就需要将这些Pod的IP和采集接口放到prometheus的配置文件中并加载，这就需要靠Controller。
因此，用更加k8s的方式实现上述功能，在需要告诉k8s新增资源类型的同时，还需要额外开发Controller，让新增的资源能够生效，这就是Operator，可以简单理解为Operator = CRD + Controller。
2 环境准备
2.1 安装golang
在golang下载对应平台的golang压缩包，然后解压到/usr/local目录下：
tar -xf go1.21.3.linux-amd64.tar.gz -C /usr/local/
然后在/etc/profile配置环境变量：
export GOROOT=/usr/local/go
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin
export GOPROXY=https://goproxy.cn
然后执行. /etc/profile，再执行go version可以查看golang版本：
root@ubuntu:~# go version
go version go1.21.3 linux/amd64
在/root/go_projects目录下编写一个简单的helloworld程序测试：
// helloworld.go
package main
import "fmt"
func main() {
fmt.Println("Hello, World!")
}
直接go run helloworld.go可以查看输出结果。
2.2 安装kubebuilder
curl -L -o kubebuilder "https://go.kubebuilder.io/dl/latest/$(go env GOOS)/$(go env GOARCH)"
chmod +x kubebuilder && mv kubebuilder /usr/local/bin/
然后执行kubebuilder version查看版本：
root@ubuntu:~/kubebuilder# kubebuilder version
Version: main.version{KubeBuilderVersion:"3.12.0", KubernetesVendor:"1.27.1", GitCommit:"b48f95cd5384eadcdfd02a47a02910f72ddc7ea8", BuildDate:"2023-09-06T06:04:11Z", GoOs:"linux", GoArch:"amd64"}
配置命令自动补全：
# 安装bash-completion
apt install bash-completion
echo "source <(kubebuilder completion bash)" >> /etc/profile
然后在使用kubebuilder过程中就可以通过tab键进行自动补全。
3 Operator Demo
通常一个资源的字段可能会比较多，实现起来会比较复杂，这里为了简化整个开发流程，会使用简单的例子说明。这里开发的是一个类似ReplicaSet的资源，它会负责创建一定数量的Pod，并监控Pod的状态。
3.1 初始化项目
kubebuilder init --domain tutorial.kubebuilder.io --repo github.com/demo
- GVK：Group(api组，例如apps、batch)、Version(api组的版本，例如v1、v1beta1)、Kind(例如Deployment、CronJob)
- GVR：Group(api组，例如apps、batch)、Version(api组的版本，例如v1、v1beta1)、Resource(例如deployments、cronjobs)，大部分场景下，Kind和Resource是1对1的关系
3.2 创建API
kubebuilder create api --group batch --version v1 --kind Demo
执行上面的命令后会自动创建以下目录和文件：
- api/v1/
* demo_types.go Demo的类型定义
* groupversion_info.go group和version的定义
* zz_generated.deepcopy.go 深拷贝实现，是runtime.Object接口的自动实现 - bin/
* controller-gen - config/crd/
* kustomization.yaml
* kustomizeconfig.yaml
* patches/cainjection_in_demos.yaml
* patches/webhook_in_demos.yaml - config/samples/
* batch_v1_demo.yaml 测试用例
* kustomization.yaml - internal/controller/
* demo_controller.go 控制器的调谐逻辑
* suite_test.go 单元测试
1 api/v1/demo_types.go
该文件包含CRD的定义，Demo的结构体跟常规的yaml配置文件对应，一种资源包含4个字段：
- metav1.TypeMeta 指定GVK(apiVersion和kind)
- metav1.ObjectMeta metadata部分，包含一些公共属性
- DemoSpec 用户期望的状态
- DemoStatus 资源当前实际的状态
2 api/v1/groupversion_info.go
Group和Version的定义以及注册。
3 api/v1/zz_generated.deepcopy.go
runtime.Object接口的实现，主要是DeepCopyObject()的实现。
type Object interface {
GetObjectKind() schema.ObjectKind
DeepCopyObject() Object
}
2 internal/controller/demo_controller.go
controller的实现，里面主要的内容是Reconcile()方法：
func (r *DemoReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
_ = log.FromContext(ctx)
// your logic here
return ctrl.Result{}, nil
}
创建完成api后，就需要填充Demo的字段以及控制器的实现。
3.3 填充CRD字段
这里实现Demo的简单版本，demo.spec中只有pod的模板和副本数：
type DemoSpec struct {
// pod模板
Template corev1.PodTemplateSpec `json:"template"`
// 副本数
Replicas *int64 `json:"replicas"`
// pod选择器
Selector map[string]string `json:"selector"`
}
而demo.status中只记录当前副本的数量：
type DemoStatus struct {
CurrentReplicas *int64 `json:"currentReplicas"`
}
其他的Demo和DemoList不做修改。接下来就需要实现控制器。
3.4 实现控制器
根据Demo的字段定义以及对ReplicaSet的理解，可以设想Demo Controller的逻辑如下：
- 根据selector在Demo所在命名空间查找Pod，假设查找到N个Pod
- 如果N < replicas，则依据template模板创建replicas-N个Pod
- 如果N > replicas，则按照时间顺序删除旧的Pod
- 将N更新到demo.status.currentReplicas
首先看下kubebuilder给我们生成的脚手架代码。
跟k8s中常规代码一样，控制器的入口在cmd/main.go：
func main() {
// 获取命令行参数
var metricsAddr string
var enableLeaderElection bool
var probeAddr string
flag.StringVar(&metricsAddr, "metrics-bind-address", ":8080", "The address the metric endpoint binds to.")
flag.StringVar(&probeAddr, "health-probe-bind-address", ":8081", "The address the probe endpoint binds to.")
flag.BoolVar(&enableLeaderElection, "leader-elect", false,
"Enable leader election for controller manager. "+
"Enabling this will ensure there is only one active controller manager.")
opts := zap.Options{
Development: true,
}
opts.BindFlags(flag.CommandLine)
flag.Parse()
ctrl.SetLogger(zap.New(zap.UseFlagOptions(&opts)))
// 创建控制器管理器，同时传入上面的命令行参数
mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
Scheme: scheme,
Metrics: metricsserver.Options{BindAddress: metricsAddr},
HealthProbeBindAddress: probeAddr,
LeaderElection: enableLeaderElection, // 是否启动选主逻辑，当运行多个控制器时需要开启
LeaderElectionID: "3d4b5da1.tutorial.kubebuilder.io",
})
if err != nil {
setupLog.Error(err, "unable to start manager")
os.Exit(1)
}
// 将Demo的控制器加入到控制器管理器
if err = (&controller.DemoReconciler{
Client: mgr.GetClient(),
Scheme: mgr.GetScheme(),
}).SetupWithManager(mgr); err != nil {
setupLog.Error(err, "unable to create controller", "controller", "Demo")
os.Exit(1)
}
//+kubebuilder:scaffold:builder
// 下面两个接口用于Pod的探针配置
// 控制器增加healthz接口
if err := mgr.AddHealthzCheck("healthz", healthz.Ping); err != nil {
setupLog.Error(err, "unable to set up health check")
os.Exit(1)
}
// 控制器增加ready接口
if err := mgr.AddReadyzCheck("readyz", healthz.Ping); err != nil {
setupLog.Error(err, "unable to set up ready check")
os.Exit(1)
}
// 注册SIGTERM和SIGINT信号，当收到两次信号时程序就会退出
setupLog.Info("starting manager")
if err := mgr.Start(ctrl.SetupSignalHandler()); err != nil {
setupLog.Error(err, "problem running manager")
os.Exit(1)
}
}
这里与我们的控制器相关的代码就是(&controller.DemoReconciler{}).SetupWithManager(mgr)：
// SetupWithManager sets up the controller with the Manager.
func (r *DemoReconciler) SetupWithManager(mgr ctrl.Manager) error {
return ctrl.NewControllerManagedBy(mgr).
For(&batchv1.Demo{}).
Complete(r)
}
在Complete()中会调用Build()，这里就负责创建Controller和执行ListAndWatch操作：
func (blder *Builder) Build(r reconcile.Reconciler) (controller.Controller, error) {
if r == nil {
return nil, fmt.Errorf("must provide a non-nil Reconciler")
}
if blder.mgr == nil {
return nil, fmt.Errorf("must provide a non-nil Manager")
}
if blder.forInput.err != nil {
return nil, blder.forInput.err
}
// 创建Controller
if err := blder.doController(r); err != nil {
return nil, err
}
// 执行watch
if err := blder.doWatch(); err != nil {
return nil, err
}
return blder.ctrl, nil
}
下面就可以实现我们的控制器：
// req是变化的资源的名称，因此，在调谐逻辑开始时通常会通过名称获取对应的资源
// 返回值除了常规的error，还有一个Result，Result中包含两个元素：
// Requeue bool：表明是否重新入队列处理
// RequeueAfter time.Duration：多久之后重新入队列，如果设置了RequeueAfter则不需要设置Requeue
func (r *DemoReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
_ = log.FromContext(ctx)
// 1 获取demo资源对象
var demo batchv1.Demo
if err := r.Get(ctx, req.NamespacedName, &demo); err != nil {
log.Log.Error(err, "unable to fetch demo", "demo_name", req.Name)
// 忽略掉 not-found 错误，通常出现在资源已经被删除时
return ctrl.Result{}, client.IgnoreNotFound(err)
} else {
log.Log.Info("fetch demo success", "demo_name", req.Name)
}
// 2 根据资源对象获取Pod数量
var podList corev1.PodList
if err := r.List(ctx, &podList, client.InNamespace(req.Namespace), &client.ListOptions{
LabelSelector: labels.SelectorFromSet(demo.Spec.Selector),
}); err != nil {
log.Log.Error(err, "unable to list child Pods", "demo_name", req.Name)
return ctrl.Result{}, err
} else {
log.Log.Info("list child Pods success", "demo_name", req.Name, "pod_cnt", len(podList.Items))
}
// 3 对比当前Pod数量和期望数量
var podCnt int64
podCnt = int64(len(podList.Items))
if podCnt < *demo.Spec.Replicas {
// 当前Pod数量少于期望数量，则创建Pod
name := fmt.Sprintf("%s-%d", req.Name, time.Now().UnixMicro())
pod := &corev1.Pod{
ObjectMeta: metav1.ObjectMeta{
Labels: make(map[string]string),
Annotations: make(map[string]string),
Name: name,
Namespace: req.Namespace,
},
Spec: *demo.Spec.Template.Spec.DeepCopy(),
}
// 这里本来想用demo.Spec.template.ObjectMeta.Labels，发现是空的
for k, v := range demo.Spec.Selector {
//pod.Labels[k] = v
pod.ObjectMeta.Labels[k] = v
}
if err := r.Create(ctx, pod); err != nil {
log.Log.Error(err, "unable to create Pod", "pod_name", name)
return ctrl.Result{}, err
} else {
log.Log.Info("create Pod success", "pod_name", name)
podCnt += 1
}
} else {
// 当前Pod数量大于期望数量，则需要删除多余的Pod
// 由于可能有正在删除的Pod，因此，在进行数量判断时，需要对正在删除的Pod进行筛选
podCnt = 0
var pod_tmp corev1.Pod
for _, pod_tmp = range podList.Items {
annotations := pod_tmp.GetAnnotations()
if annotations != nil {
flag := false
for k, v := range annotations {
if k == "demo-deleting" && v == req.Name {
flag = true
break
}
}
if flag == true {
continue
}
}
if pod_tmp.Status.Phase == corev1.PodRunning {
podCnt += 1
}
}
if podCnt > *demo.Spec.Replicas {
// 在删除Pod之前，给Pod加一个Annotations，然后再删除Pod，后续就可以用该Annotations判断Pod是否正在删除中
annotations := pod_tmp.GetAnnotations()
if annotations == nil {
annotations = make(map[string]string)
}
annotations["demo-deleting"] = req.Name
pod_tmp.SetAnnotations(annotations)
if err := r.Update(ctx, &pod_tmp, &client.UpdateOptions{}); err != nil {
log.Log.Error(err, "update Pod annotations failed", "pod_name", pod_tmp.Name)
return ctrl.Result{RequeueAfter: time.Second}, nil
} else {
log.Log.Info("update Pod annotations success", "pod_name", pod_tmp.Name)
}
if err := r.Delete(ctx, &pod_tmp); err != nil {
log.Log.Error(err, "delete Pod failed", "pod_name", pod_tmp.Name)
} else {
log.Log.Info("delete Pod success", "pod_name", pod_tmp.Name)
podCnt -= 1
}
return ctrl.Result{RequeueAfter: time.Second}, nil
}
}
// 4 更新status状态
demo.Status.CurrentReplicas = &podCnt
if err := r.Status().Update(ctx, &demo); err != nil {
log.Log.Error(err, "unable to update Demo status")
return ctrl.Result{}, err
} else {
log.Log.Info("update Demo status success", "demo_name", demo.Name)
}
return ctrl.Result{}, nil
}
3.5 部署测试
代码开发完成后，就需要进行部署测试，其实正常情况下，在未填充任何代码时也应该先部署测试，保证kubebuilder生成的代码可以在当前版本的k8s中使用。
首先看下生成的Makefile提供了哪些命令，执行make help可以看到支持的子命令：
开发：
- manifests 生成Webhook、ClusterRole和CRD对象，例如config/crd/bases下的CRD文件和config/crd/rbac/下面的文件
- generate 重新生成zz_generated.deepcopy.go文件
- fmt 运行go fmt格式化代码
- vet 运行go vet检查语法错误
- test 运行项目中的测试代码，主要是控制器目录的test文件
构建：
- build 构建控制器二进制
- run 在本地启动控制器
- docker-build 构建控制器镜像
- docker-push 推送控制器镜像
- docker-buildx 构建跨平台的镜像
部署：
- install 在集群中安装CRD
- uninstall 在集群中卸载CRD
- deploy 在集群中部署controller
- undeploy 在集群中卸载controller
下面就对我们开发的程序部署，跟前面说的一样，Operator主要就是CRD和Controller，部署也是一样：
- 生成CRD和RBAC：
make manifests - 为Demo资源重新生成zz_generated.deepcopy.go：
make generate - 在k8s中创建CRD：
make install - 本地运行Controller：
make run
与常规的Controller不同，这种方式就会在本地启动Controller，该控制器通过~/.kube/config文件去调用k8s api的接口进行交互。
此时，可以在k8s中看到Demo资源：
然后可以修改config/samples/batch_v1_demo.yaml文件：
apiVersion: batch.tutorial.kubebuilder.io/v1
kind: Demo
metadata:
labels:
app.kubernetes.io/name: demo
app.kubernetes.io/instance: demo-sample
app.kubernetes.io/part-of: demo
app.kubernetes.io/managed-by: kustomize
app.kubernetes.io/created-by: demo
name: demo-sample
spec:
replicas: 2
selector:
app: demo-kubebuilder
template:
metadata:
labels:
app: demo-kubebuilder
spec:
containers:
- name: nginx
image: nginx
接下来可以将该yaml提交到k8s创建Demo对象，然后就可以查看Controller的日志：
从这里面可以看出make run其实就是make manifests + make generate + make fmt + make vet + go run ./cmd/main.go，因此，如果是在本地运行时如果已经将资源对象提交到k8s，后续又没有修改资源对象的字段，只是调整了Controller的代码，可以直接执行make run。
执行kubectl edit demo demo-sample修改replicas字段会发现Pod的数量也会随之变化。
3.6 两个问题
对上面的代码测试会发现两个问题：
- 修改Demo的replicas字段发现Pod的数量会与期望保持一致，但是如果删除Pod，并没有新的Pod重建，这是因为当前Controller只监听了Demo的变化，没有监听Pod的变化
- Pod的删除是通过先设置Annotations，这种方式不够优雅
4 总结
本文用实现类似ReplicaSet的Demo资源讲解了Operator的开发过程，虽然是很简单的功能，还是需要考虑很多问题，实际的Operator开发更加复杂，考虑的问题更多，虽然k8s提供了Operator这种机制用于扩展资源，但是开发的门槛还是有些高，幸运的是，OperatorHub提供了大量可用的Operator，在开发Operator之前可以先在这里查找下是否已经有现成的Operator可以使用。
![[ Windows-Nginx ]Windows服务器，Tomcat容器部署项目，整合Nginx](https://img-blog.csdnimg.cn/020f81b891474ad586561cd46602b2a5.png)
