🏪k8s informer 架构

整体视角

informer 架构由 Reflector、DeltaFIFO、Indexer、EventHandler 和 WorkQueue 构成。

Reflector 负责 List+Watch API Server，所有变化进入 DeltaFIFO 队列。

Informer 从队列 Pop 事件更新到本地缓存 Indexer，并触发事件回调。

事件回调把 key 入队到 WorkQueue，Controller 的 worker 再处理调谐逻辑。

通过缓存减少 API Server 压力，通过队列保证事件顺序，通过事件驱动实现最终一致性。

Reflector

Reflector 是 Informer 的最上游数据采集器，它使用 ListAndWatch 拉取和监听资源变化，并把每次变化（Delta）压入 DeltaFIFO。它不缓存数据，只负责同步事件

ListAndWatch实现原理

List 本质就是：

• 标准 HTTP/1.1

• 一次性返回所有对象

• 响应体是 JSON，包含 items + resourceVersion

Watch 是：

1. HTTP/1.1 长连接兼容性好

2. 无需升级协议

3. 更易于做代理、审计、RBAC、认证

4. gRPC 出现之前，最容易实现的服务端推送方式

Kubernetes 的 Watch 本质是使用 HTTP/1.1 的 chunked transfer encoding 实现的长连接流式响应。客户端发起 GET watch=true 后，APIServer 不关闭连接，而是不断通过 HTTP 流推送 JSON 事件。客户端通过 resourceVersion 来保证断线续传

Delta fifo queue

DeltaFIFO 是 Informer 事件处理的第一站，它接收 Reflector 发来的 Add/Update/Delete/Sync 事件；

它为每个 key 合并事件（防抖、去重），并用 FIFO 维护事件处理顺序；

Informer 的 Controller 会从 DeltaFIFO.Pop 中取出事件，更新 Indexer，再把事件分发给 Processor 和 Handler。

因此 DeltaFIFO 是保证 Informer 高效、无重复地处理资源变化的关键组件。

indexer

Indexer 是 Informer 的本地缓存，它存储所有从 APIServer 同步下来的对象。

除了基本的 key-value 存储，它还支持按任意维度构建索引，比如 namespace、ownerRef、node 等。

Controller 在处理调谐逻辑时，大部分查询都依赖 Indexer 而不是访问 API Server，因此效率极高，也减轻了集群压力。

items 是存对象的，indexers 是生成索引值的规则，而 indices 是真正加速查询的索引表。对象进入 items 后，通过 indexers 计算索引，并写入 indices，从而使 ByIndex 查询非常高效。

Resource event handler

ResourceEventHandler 是 Informer 在资源发生变化时调用的回调。

它将 Add/Update/Delete 事件转化为 Controller 可处理的逻辑。

实际项目中，这些 Handler 通常把对象 key 加入工作队列，由 Reconcile 循环从缓存读取最新对象状态执行调谐。

Event Handler 是 Informer → Controller 之间的桥梁。

workQueue

Workqueue 是 Kubernetes Controller 的任务调度队列，它支持去重、限流、延迟和自动重试。

Informer 的事件处理器只负责将对象的 key 放入 Workqueue；

Workers 从队列取 key，执行 Reconcile，并从缓存（Indexer）读取对象最新状态。

Workqueue 提供失败重试机制（AddRateLimited），成功后 Forget 清除计数。

因为使用 key 而不是对象本身，保证了调谐逻辑总是基于最新缓存状态，实现最终一致性。