题干与适用场景
Kubernetes Controller 通过 Informer 缓存读取对象，再把期望状态写回 API Server。集群高负载、watch 延迟或控制器重启时，缓存可能落后于 API Server；此时控制器可能重复写入、错误扩缩容，甚至基于过期 Lease 判断节点失效。请设计一套陈旧检测与缓解方案，要求只阻塞受影响对象，不拖住整个控制器。
这道题适合平台工程、SRE 与云原生控制器岗位。Kubernetes v1.36 官方文章和 KEP 5647 给出了 AtomicFIFO、LastStoreSyncResourceVersion()、按对象记录最后写入版本、跳过并重新入队，以及 DaemonSet、StatefulSet、ReplicaSet、Job 控制器的落地范围。本文是基于公开资料的面试设计推导，不声称是公司真题。
面试官考察点
面试官关注你能否解释最终一致缓存的边界，并把“读到新数据”转化为可验证的资源版本条件。强回答会覆盖缓存同步、写后读、局部队列、退避、控制器重启、监控和 feature gate；普通回答只会建议周期性直读 API Server，忽略负载与一致性成本。
回答前需要澄清的问题
- 哪些决策具有破坏性：删除 Pod、缩容、切换主节点，还是普通状态更新？
- 可接受的陈旧窗口是多少，是否能为关键操作支付一次 API Server 直读？
- 需要保证单对象写后读，还是多个对象之间的因果关系？
- 控制器重启、watch 重连和 API Server 故障时，默认保守等待还是允许有限降级？
30 秒回答框架
“我会保留 Informer 缓存作为主读路径，利用 AtomicFIFO 和最新已见 resourceVersion 判断缓存进度。控制器写入关键对象后，记录对象键到目标 resourceVersion 的映射；当缓存尚未追上时，只跳过该对象并按指数退避重新入队。对删除、扩缩容等高风险操作增加直读或熔断，暴露缓存延迟、跳过次数和队列年龄指标。重启后不清空保护状态，先等待完整同步，再恢复处理。”
分步骤深入解答
先定义陈旧。Informer 的本地 Store 由 watch 事件填充，事件可能延迟、乱序或在重启重建期间暂时不完整。Kubernetes v1.36 的 AtomicFIFO 将批量到达的初始列表事件原子化，避免列表与增量事件交错造成不一致；LastStoreSyncResourceVersion() 让客户端读取缓存已经追上的版本。
控制器为每个关键写入保存 objectKey -> resourceVersion。例如 DaemonSet 更新 Pod 后，记录 API Server 返回的版本；Pod informer 每次事件都推进“已见版本”。只有当缓存已见版本不小于最后写入版本时，才允许该 DaemonSet 进入下一轮需要新状态的 reconcile。未追上时只对该 key requeue，沿用指数退避，不能把整个 worker 池锁住。
写入与判断要幂等。API 更新使用 resourceVersion 冲突重试；重复 reconcile 不应产生额外副作用。控制器重启后，内存中的映射丢失，因此启动阶段先等待 informer cache sync，再把需要保护的状态从对象状态或队列事件重建。映射不完整时宁可延迟破坏性操作，也不要假设缓存新鲜。
对时间敏感的决策可增加 circuit breaker：先用缓存快速判断，若目标版本未知或缓存延迟超过阈值，执行一次受限直读 API Server；直读失败则暂停该对象并记录原因。直读不能成为所有 reconcile 的默认路径，否则 API Server QPS、延迟和故障半径会被放大。
观测指标至少包括 informer 当前 resourceVersion、目标写入版本、两者差值或滞后时长、因陈旧跳过的 reconcile 次数、队列等待年龄、直读成功率和每类控制器的熔断次数。日志带对象键、版本和动作，不打印 Secret。告警应区分 API Server 变慢、watch 断开、单个对象热点和控制器自身处理慢。
发布采用 feature gate 与灰度。先对一个高并发控制器和小节点池启用，验证跳过后最终收敛、重启恢复和队列无饥饿；再扩展到其他控制器。回滚时关闭新的一致性路径，但保留指标和已有对象状态，避免批量清理映射触发额外写入。
高质量示范回答
我会把陈旧处理设计成“缓存主路径、版本门槛、局部重入队、关键动作熔断”四层。Informer 通过 AtomicFIFO 保证批量初始化不会和增量事件交错，Store 暴露最新已见 resourceVersion。控制器写入对象后记录目标版本，只有缓存追上该版本才继续处理同一对象；否则指数退避重入队，不阻塞其他对象。
删除、缩容和 Lease 判断等高风险动作在缓存版本未知或滞后超阈值时做受限直读，失败就对该对象熔断。指标记录版本滞后、跳过次数、队列年龄和直读比例。重启先完成 cache sync，再恢复映射和队列。灰度验证收敛、恢复和 API Server 负载，任何时候都不全局清空保护状态。
常见错误
- 错误表现 → 每次 reconcile 都直读 API Server；失败原因 → 放大 QPS 与延迟，缓存失去意义；修正方法 → 仅在关键动作和版本未知时直读。
- 错误表现 → 发现一个对象陈旧就暂停所有 worker；失败原因 → 单个热点对象拖住全局；修正方法 → 以对象键为粒度跳过并 requeue。
- 错误表现 → 只比较时间戳；失败原因 → 时钟漂移不能表达 watch 因果顺序；修正方法 → 使用 API resourceVersion 与 Store 已见版本。
- 错误表现 → 控制器重启后删除全部保护状态；失败原因 → 重建期间可能做出旧数据决策；修正方法 → 先 cache sync，再有版本控制地恢复。
追问及应对
为什么资源版本比本地时间戳可靠？
resourceVersion 来自 API Server 的对象变更序列，可用于判断缓存是否见过某次写入；本地时间戳受时钟漂移、网络延迟和进程暂停影响，不能证明因果顺序。它仍不是跨资源事务序号，所以多对象一致性要额外设计。
如何避免某个对象一直陈旧导致队列饥饿？
为该对象设置指数退避上限和最大等待告警，同时让队列继续处理其他 key。超过阈值后可转为低频探测或一次直读；记录连续跳过次数，避免无限快速重试打满 API Server。
什么时候应该直接拒绝操作？
涉及删除、缩容、故障转移或 Lease 过期判断时，如果缓存版本未知且直读失败，应暂停该对象并保留保护状态。普通状态汇报可以在明确的陈旧窗口内继续，但必须把降级标记写入状态与指标。