Kubernetes controller 在"你把东西搞坏"时到底做什么

人人都知道 K8s 平台会自愈：删 pod 它回来，误扩 Deployment 有人把它调回去。几乎没人能说清它怎么工作——四个广为半懂的机制：Reconcile 收到什么、它的工作从哪来、周期 resync 是什么、predicate 关掉了什么。

作者构建了一个最小的自愈系统（一个 Echo CRD + controller 同步 Deployment/Service/ConfigMap 三个子对象），按每种失败模式故意搞坏十次，逐个机制实测。数据：reconcile 函数均值 2.71ms、77/77 次都在 25ms 内；短 resync 周期零额外 API 请求；GenerationChangedPredicate 把稳态 reconcile 砍掉 48.5% 且不影响实时修复。Repo：kirPoNik/k8s-drift-operator。

四道障碍（原文主线）

障碍 1：Reconcile 不知道什么变了。 Reconcile(ctx, req ctrl.Request) —— req 就是一个 namespace 和一个 name。不是 diff、不是"replicas 从 1 变 3"、不是对象副本。每次调用从零重读期望 spec、重算三个子对象应该长什么样。这解释了 K8s 大半行为。

障碍 2：controller 不轮询 API server。 它通过 watch/informer 收到事件流。搞清楚它做什么，才知道你的 API 负载真正从哪来。

障碍 3：resync 不是对集群的复查。 这解释了为什么短 resync 周期几乎免费——真正贵的是另一个数字。

障碍 4：predicate 不是纯优化。 它是带隐藏成本的过滤器，成本不是文档最先警告的那个。

实践建议

• 理解 controller 用 informer+watch 而非轮询：API 负载分析先看 watch 事件与重列，别归咎于轮询；
• resync 周期调短近乎免费，但别把它当"重新核对集群"的手段——那是认知错误；
• predicate 省下的每次 reconcile 是真实收益（实测 48.5%），但先量清楚它的过滤逻辑不会误伤实时修复路径。

来源：What a Kubernetes controller actually does when you break something - DEV Community