4. 控制器模式基础：Informer、WorkQueue、Reconciler 的工作原理与交互流程

在 Kubernetes 控制器生态中，Informer、WorkQueue 与 Reconciler 构成了核心的“事件驱动-异步处理-状态调和”三角模型。理解这三者的职责与协作关系，是调试 QuotaOperator 乃至任何自定义控制器的前提。

4.1 三角模型总览

控制器并非直接监听 API Server 的每一次变化，而是通过一套成熟的缓存与队列机制实现高性能、低延迟的调和循环。下表概括了三个核心组件的职责与数据流方向：

4.2 Informer：事件源与本地缓存

Informer 是控制器与 API Server 之间的桥梁。它通过 List & Watch 机制获取全量数据并持续监听增量变化，同时将数据写入线程安全的本地缓存（Indexer）。

4.2.1 核心工作流程

1. List 阶段： 启动时调用 API Server 的 List 接口获取资源全量快照，存入 Indexer。
2. Watch 阶段： 基于 resourceVersion 建立长连接，持续接收 ADDED / MODIFIED / DELETED 事件。
3. 事件分发： 每个事件经过 ResourceEventHandler 回调（OnAdd / OnUpdate / OnDelete）处理。
4. 增量同步： 默认每 10 分钟（ResyncPeriod）触发一次全量重新同步，确保缓存与集群状态一致。

4.2.2 回调函数与入队逻辑

在 QuotaOperator 中，ResourceEventHandler 通常不直接调用 Reconciler，而是将对象的 命名空间/名称 键（namespace/name）写入 WorkQueue：

// 典型 Informer 事件回调示例
podInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{
    AddFunc: func(obj interface{}) {
        key, _ := cache.MetaNamespaceKeyFunc(obj)
        queue.Add(key)  // 将对象键加入工作队列
    },
    UpdateFunc: func(oldObj, newObj interface{}) {
        key, _ := cache.MetaNamespaceKeyFunc(newObj)
        queue.Add(key)
    },
    DeleteFunc: func(obj interface{}) {
        key, _ := cache.DeletionHandlingMetaNamespaceKeyFunc(obj)
        queue.Add(key)
    },
})

4.3 WorkQueue：去重、延迟与限速

WorkQueue（client-go/util/workqueue）是控制器异步化的核心。它解决了三个关键问题：

• 去重： 同一对象的多个事件在队列中只保留一个键，避免重复处理。
• 延迟重试： 处理失败时，对象键不会立即重新入队，而是按指数退避策略延迟加入。
• 速率限制： 通过 RateLimiter 控制每秒处理速率，防止异常流量打垮 API Server。

3.3.1 队列类型对比

4.4 Reconciler：状态调和的核心逻辑

Reconciler 从 WorkQueue 中取出对象键，通过 Indexer 获取本地缓存中的最新状态，然后执行调和逻辑。其核心原则是 幂等性：无论执行多少次，结果都应一致。

4.4.1 标准调和循环

// 标准 Reconciler 循环骨架
func (r *Reconciler) Reconcile(ctx context.Context, req reconcile.Request) (reconcile.Result, error) {
    // 1. 从 Indexer 获取当前对象
    obj, exists, err := r.indexer.GetByKey(req.NamespacedName.String())
    if err != nil {
        return reconcile.Result{}, err
    }
    if !exists {
        // 对象已删除，执行清理逻辑
        return r.cleanup(req)
    }

    // 2. 获取期望状态（通常来自对象 Spec）
    quota := obj.(*corev1.ResourceQuota)
    desired := extractDesiredState(quota)

    // 3. 获取当前状态（通常通过 List 或 Get 实时查询）
    current := r.fetchCurrentState(quota)

    // 4. 对比并执行变更
    if !reflect.DeepEqual(desired, current) {
        err := r.applyChanges(quota, desired)
        if err != nil {
            // 失败时返回错误，WorkQueue 会自动重试
            return reconcile.Result{}, err
        }
    }

    // 5. 成功，无需重试
    return reconcile.Result{}, nil
}

4.5 交互流程：从事件到调和

下图展示了 Informer、WorkQueue、Reconciler 三者之间的完整交互时序：

4.6 调试切入点总结

在 QuotaOperator 的调试过程中，以下三个检查点覆盖了 90% 的控制器异常场景：