Kubernetes Operator 开发实战：用 CRD 让运维自动驾驶

为什么需要 Kubernetes Operator？

手动管理有状态应用（数据库、消息队列、缓存集群）是 K8s 运维最头疼的事情。Operator 模式的核心思想很简单：把运维经验写成代码，让 K8s 自己管自己。

CRD 是什么？

Custom Resource Definition（CRD）是 Kubernetes 的扩展机制。你可以定义自己的资源类型，比如：

apiVersion: myapp.example.com/v1
kind: MyDatabase
metadata:
  name: production-db
spec:
  replicas: 3
  version: "15.2"
  storage: 100Gi
  backup:
    schedule: "0 2 * * *"
    retention: 7d

用户只需要声明"我要一个3副本的数据库"，Operator 负责搞定所有细节。

实战：用 kubebuilder 创建 Operator

1. 初始化项目

kubebuilder init --domain example.com --repo github.com/myorg/db-operator
kubebuilder create api --group myapp --version v1 --kind MyDatabase

2. 定义 CRD Spec

type MyDatabaseSpec struct {
    Replicas int32  `json:"replicas"`
    Version  string `json:"version"`
    Storage  string `json:"storage"`
}

type MyDatabaseStatus struct {
    Ready    bool   `json:"ready"`
    Phase    string `json:"phase"`
    Replicas int32  `json:"readyReplicas"`
}

3. 编写 Reconcile 逻辑

Reconcile 是 Operator 的核心——它不断对比"期望状态"和"实际状态"，然后做出调整：

func (r *MyDatabaseReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    var db myappv1.MyDatabase
    if err := r.Get(ctx, req.NamespacedName, &db); err != nil {
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }

    // 1. 确保 StatefulSet 存在且副本数正确
    sts := r.buildStatefulSet(&db)
    if err := r.createOrUpdate(ctx, sts); err != nil {
        return ctrl.Result{}, err
    }

    // 2. 确保 Service 存在
    svc := r.buildService(&db)
    if err := r.createOrUpdate(ctx, svc); err != nil {
        return ctrl.Result{}, err
    }

    // 3. 更新状态
    db.Status.Phase = "Running"
    db.Status.Ready = true
    r.Status().Update(ctx, &db)

    return ctrl.Result{RequeueAfter: 30 * time.Second}, nil
}

4. 高级特性：自动备份

func (r *MyDatabaseReconciler) ensureBackupCronJob(ctx context.Context, db *myappv1.MyDatabase) error {
    if db.Spec.Backup == nil {
        return nil
    }
    cronJob := &batchv1.CronJob{
        Spec: batchv1.CronJobSpec{
            Schedule: db.Spec.Backup.Schedule,
            JobTemplate: batchv1.JobTemplateSpec{
                Spec: batchv1.JobSpec{
                    Template: corev1.PodTemplateSpec{
                        Spec: corev1.PodSpec{
                            Containers: []corev1.Container{{
                                Name:    "backup",
                                Image:   "myorg/db-backup:latest",
                                Command: []string{"/backup.sh"},
                            }},
                        },
                    },
                },
            },
        },
    }
    return r.createOrUpdate(ctx, cronJob)
}

Operator 开发的几个坑

1. 幂等性是生命线：Reconcile 可能被反复调用，所有操作必须幂等
2. Finalizer 别忘了：删除 CR 时需要清理外部资源，用 Finalizer 拦截删除事件
3. Status 和 Spec 分离：永远不要在 Reconcile 里修改 Spec，只更新 Status
4. 错误重试策略：合理设置 RequeueAfter，避免疯狂重试打爆 API Server
5. RBAC 最小权限：只授予 Operator 必要的资源访问权限

什么场景适合写 Operator？

场景	适合度
有状态应用生命周期管理	非常适合
自动扩缩容策略	适合
备份恢复自动化	非常适合
无状态应用部署	不需要，Deployment 够了
一次性任务	不需要，Job 够了

总结

Operator 把"人肉运维"变成"代码运维"，是 Kubernetes 生态最强大的扩展模式。如果你管理的应用需要复杂的运维逻辑（扩缩容、备份、升级、故障恢复），写一个 Operator 是一劳永逸的选择。

推荐工具：kubebuilder（Go）、Operator SDK（Go/Ansible/Helm）、KUDO（声明式）。

开始动手吧，让你的集群学会自己照顾自己。