📚 课程目录第3章 Operator基础回顾

3、Operator基础回顾：Operator模式与Kubernetes控制器、Operator SDK与Kubebuilder简介、Reconcile循环

3.1 Operator模式与Kubernetes控制器

Operator是Kubernetes上打包、部署和管理复杂有状态应用的扩展机制。其核心思想是将运维领域知识编码为软件，通过控制循环（Control Loop）持续观测集群实际状态与期望状态的偏差，并自动执行调谐动作。

  核心定义：Operator = Kubernetes控制器 + 自定义资源定义（CRD）+ 领域特定运维逻辑。

Kubernetes原生控制器（如Deployment Controller、ReplicaSet Controller）管理内置资源；Operator则通过CRD扩展API，管理自定义资源（Custom Resource, CR）。

对比维度	Kubernetes原生控制器	Operator
管理对象	内置资源（Pod、Service、Deployment等）	自定义资源（CRD实例）
运维逻辑	通用、平台级	领域特定、应用级
状态管理	无状态或简单状态	复杂有状态（备份、扩缩容、升级）
扩展方式	内置代码，不可修改	用户自定义，可编程

关键理解：Operator本质上是“有状态的控制器”，它利用CRD将应用运维知识（如Etcd集群的成员管理、数据库的备份恢复）声明式地暴露给Kubernetes API。

3.2 Operator SDK与Kubebuilder简介

社区提供了两个主流框架来加速Operator开发：Operator SDK（Red Hat主导）和Kubebuilder（Kubernetes SIG主导）。两者底层都依赖controller-runtime库，核心概念和生成代码结构高度相似。

特性	Operator SDK	Kubebuilder
维护方	Red Hat / CNCF	Kubernetes SIG API Machinery
脚手架工具	`operator-sdk init`	`kubebuilder init`
API生成	`operator-sdk create api`	`kubebuilder create api`
Webhook支持	内置（Admission、Conversion）	内置（Admission、Conversion）
测试框架	envtest + 集成测试	envtest + 集成测试
Helm/Ansible支持	支持（Go、Helm、Ansible三种类型）	仅Go

两种框架生成的Operator项目结构基本一致，核心目录包括：

api/：定义CRD的Go结构体（Spec、Status）
controllers/：Reconcile循环实现
config/：Kubernetes YAML清单（RBAC、CRD、Webhook）
main.go：入口，注册Scheme、启动Manager

# 使用Kubebuilder初始化一个Operator项目
kubebuilder init --domain example.com --repo github.com/example/my-operator
kubebuilder create api --group cache --version v1alpha1 --kind Memcached --resource=true --controller=true

选择建议：如果团队以Go为主要语言且希望紧跟上游Kubernetes API演进，优先选择Kubebuilder；如果需要支持Helm/Ansible类型的Operator或更丰富的CLI功能，Operator SDK更合适。两者生成的Reconcile代码可以互相迁移。

3.3 Reconcile循环

Reconcile循环是Operator的核心执行单元。每当自定义资源发生变化（创建、更新、删除）或集群中相关资源状态变更时，controller-runtime会将事件入队，触发Reconcile函数。

  Reconcile函数签名：func (r *MemcachedReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error)

典型的Reconcile循环包含以下步骤：

获取CR实例：通过r.Get(ctx, req.NamespacedName, &memcached)读取期望状态
检查当前状态：查询集群中由该CR管理的子资源（如Deployment、Service）
计算偏差：对比期望状态（CR.Spec）与实际状态（子资源当前配置）
执行调谐：创建、更新或删除子资源，使实际状态趋近期望状态
更新状态：将调谐结果写回CR.Status
返回结果：返回ctrl.Result{RequeueAfter: 30 * time.Second}或ctrl.Result{}

// 简化的Reconcile实现示例
func (r *MemcachedReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    logger := log.FromContext(ctx)

    // 1. 获取CR实例
    var memcached cachev1alpha1.Memcached
    if err := r.Get(ctx, req.NamespacedName, &memcached); err != nil {
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }

    // 2. 检查当前Deployment状态
    var deploy appsv1.Deployment
    deploy.Name = memcached.Name
    deploy.Namespace = memcached.Namespace
    if err := r.Get(ctx, client.ObjectKeyFromObject(&deploy), &deploy); err != nil {
        if !apierrors.IsNotFound(err) {
            return ctrl.Result{}, err
        }
        // Deployment不存在，需要创建
        deploy = *buildDeployment(&memcached)
        if err := r.Create(ctx, &deploy); err != nil {
            return ctrl.Result{}, err
        }
    }

    // 3. 调谐副本数
    if *deploy.Spec.Replicas != memcached.Spec.Replicas {
        deploy.Spec.Replicas = &memcached.Spec.Replicas
        if err := r.Update(ctx, &deploy); err != nil {
            return ctrl.Result{}, err
        }
    }

    // 4. 更新CR状态
    memcached.Status.ReadyReplicas = deploy.Status.ReadyReplicas
    if err := r.Status().Update(ctx, &memcached); err != nil {
        return ctrl.Result{}, err
    }

    return ctrl.Result{}, nil
}

Reconcile设计要点：

幂等性：Reconcile函数必须可重复执行且结果一致，不能依赖外部状态
错误处理：返回error会触发重新入队；返回ctrl.Result{RequeueAfter: duration}实现周期性调谐
并发安全：同一CR的Reconcile默认串行执行，但不同CR可并行
状态更新：使用r.Status().Update()更新CR状态子资源，避免与Spec更新冲突

3.4 Operator生命周期中的策略集成点

理解Reconcile循环后，可以识别出OPA策略在Operator生命周期中的三个关键集成点：

集成点	触发时机	策略作用
Admission Webhook	CR创建/更新请求到达API Server时	验证CR.Spec字段合法性、默认值注入
Reconcile循环内部	每次调谐执行时	根据集群全局策略决定是否执行调谐动作
子资源变更审计	Operator创建/更新子资源后	审计子资源是否符合安全基线、标签规范

常见误区：不要将OPA策略仅放在Admission Webhook层。Reconcile循环内部的策略检查可以捕获运行时状态变化（如集群资源不足、节点故障），这是Webhook无法覆盖的。