3. Operator 设计模式：Reconciler 模式、控制器循环与 CRD 设计

Operator 是 Kubernetes 生态中实现“应用感知”自动化运维的核心模式。本章深入剖析 Operator 的三大设计支柱：Reconciler 模式、控制器循环与自定义资源定义（CRD）设计。理解这三者如何协同工作，是构建具备多集群回滚能力的 Operator 的基础。

3.1 Reconciler 模式：声明式状态机

Reconciler（调谐器）是 Operator 的大脑。它不关心“如何执行一个动作”，而是持续比较“当前状态”与“期望状态”，并执行必要的操作使前者趋近后者。这种模式天然适合多集群环境中的回滚场景——当集群状态偏离预期时，Reconciler 自动触发回滚逻辑。

Reconciler 接口定义（Go 语言示例）

type Reconciler interface {
    Reconcile(ctx context.Context, req reconcile.Request) (reconcile.Result, error)
}

每次 Reconcile 调用返回 reconcile.Result，告知控制器调度器是否需要重新入队以及等待时间。对于回滚场景，通常返回 RequeueAfter 以定期检查集群状态一致性。

3.2 控制器循环：事件驱动的调谐引擎

控制器循环是 Reconciler 的执行框架。它监听 Kubernetes API 上的事件（创建、更新、删除），并将事件转换为 Reconcile 请求。一个典型的控制器循环包含以下阶段：

1. 事件监听：通过 Informer 监听 CRD 实例及关联资源的变化。
2. 事件过滤与去重：合并短时间内的重复事件，避免调谐风暴。
3. 工作队列：将去重后的请求放入队列，支持速率限制和重试。
4. Worker 池：多个 Worker 并发从队列中取出请求并调用 Reconciler。
5. 结果处理：根据 Reconciler 返回的 Result 决定是否重新入队。

3.3 自定义资源定义（CRD）设计

CRD 是 Operator 管理自定义业务逻辑的数据模型。对于多集群回滚场景，CRD 的设计直接决定了回滚策略的灵活性和可观测性。一个设计良好的 CRD 应包含以下关键部分：

3.3.1 CRD 结构层次

3.3.2 回滚策略字段设计示例

type RollbackPolicy struct {
    // 触发回滚的条件列表
    Conditions []RollbackCondition `json:"conditions"`
    // 回滚模式：Auto 自动回滚，Manual 手动审批
    Mode string `json:"mode"`
    // 最大回滚重试次数
    MaxRetries int `json:"maxRetries"`
    // 回滚等待时间（秒），用于灰度回滚
    WaitSeconds int `json:"waitSeconds"`
}

type RollbackCondition struct {
    // 条件类型：HealthCheckFailed / VersionMismatch / Timeout
    Type string `json:"type"`
    // 阈值，例如健康检查失败次数
    Threshold int `json:"threshold"`
}

3.4 三者的协作关系

CRD 定义了“期望状态”的数据结构；控制器循环负责监听 CRD 实例的变化并触发调谐；Reconciler 读取 CRD 的 Spec，对比 Status，执行发布或回滚操作，并更新 Status。下图展示了三者在多集群回滚场景中的协作：

3.5 设计模式总结