Kubernetes控制器的通用工作模式（Reconcile Loop）【20260530】001篇
文章目录
- 一、整体一句话概括
- 二、逐模块详解
- ① Watch API Server
- 发生了什么？
- Reflector 的职责
- ② Informer / 本地缓存
- 为什么需要缓存？
- 缓存特点
- ③ 事件入队（WorkQueue）
- 为什么不能直接处理？
- WorkQueue 的能力
- ④ Reconcile / Sync（核心大脑）
- 标准 Reconcile 五步法
- ① Get 当前实际状态
- ② 对比 Spec（期望状态）
- ③ 计算差异 → Act
- ④ 调用 API Server
- ⑤ 更新 Status
- 三、一个完整例子（Deployment）
- 四、设计哲学总结（非常重要）
- ✅ 1. 声明式（Declarative）
- ✅ 2. 最终一致性（Eventual Consistency）
- ✅ 3. Level Trigger（水平触发）
- ✅ 4. 幂等性（Idempotent）
- 五、一句话记住这张图
这是一张经典 Kubernetes Controller（控制器）工作原理图。下面按数据流向 + 核心组件职责逐行拆解，并补充很多文档里不会明写但很关键的细节。
一、整体一句话概括
Controller 通过 Watch API 感知集群状态变化，在本地维护缓存，把变化事件送入队列，再由 Reconcile 循环不断将“实际状态”向“期望状态”对齐。
这就是Kubernetes 的声明式控制系统核心。
二、逐模块详解
① Watch API Server
Watch API Server → Informer / Reflector发生了什么？
- Controller 启动时：
- 调用
List：全量拉取资源 - 随后开启
Watch：长连接监听变更
- 调用
- 监听的资源示例：
Pods