HDUO Lab

深入 K8S Operator 陷阱排查：Informer 全量缓存与 Status 更新死循环引发的 APIServer 瘫痪实战

作者：

ningniu

在

K8S Operator 发生 OOM 或引发 APIServer 限流，90% 源于两点：一是 Informer 未配置过滤导致全量缓存集群资源撑爆内存；二是 Reconcile 中未比对 Generation 且误用全量 Update 更新状态，触发 Informer 无休止的 Requeue 死循环。核心解法：CRD 开启 Status Subresource，按 Label 过滤 Cache，严格使用 GenerationChangedPredicate 阻断热循环。

现场还原：Etcd 穿透与 Operator OOMKilled

排查过程中接到告警，某生产集群（K8S v1.26）的 APIServer CPU 突增至 80+ 核，P99 延迟突破 3 秒，核心组件调度瘫痪。伴随而来的是集群 Etcd 出现大量 apply request took too long 和高频的 Leader 切换。

切到现场，第一看全局指标，第二看异常调用源。 抓取 APIServer 的 apiserver_request_total 指标，发现某个特定 Namespace 下的 PUT 请求速率达到了离谱的 3000 QPS。通过审计日志（Audit Log）过滤 User-Agent，直接锁定了一个内部开发的自定义 Operator。

此时查看该 Operator 的 Pod 状态：

$ kubectl get pod -n ops-system -l control-plane=controller-manager
NAME                                READY   STATUS      RESTARTS   AGE
my-operator-6b7975c48-abcde         0/1     OOMKilled   12         1h

内存限制配了 2GB 依然被 OOMKilled，且在存活的短短几分钟内对集群发起了毁灭性的写压榨。典型的 Operator 踩坑连环计：Informer 内存泄露叠加 Reconcile 状态死循环。

为什么一个简单的 Status Update 会引发重试风暴？

我们先看开发人员写的一段典型“毒药代码”（基于 controller-runtime v0.15.0）：

func (r *MyCustomReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    var myCR mygroupv1.MyCR
    if err := r.Get(ctx, req.NamespacedName, &myCR); err != nil {
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }

    // ... 业务逻辑：创建对应的 Deployment ...

    // 更新状态
    myCR.Status.Phase = "Running"
    if err := r.Update(ctx, &myCR); err != nil {
        return ctrl.Result{}, err
    }
    return ctrl.Result{}, nil
}

这段代码存在两个致命缺陷，直接导致了 APIServer 的写风暴：

  1. 误用全量更新 (r.Update)：未使用 Subresource 更新状态。当使用 r.Update() 修改对象时，APIServer 会更新该对象的 ResourceVersion。

  2. 缺乏事件过滤机制：APIServer 返回成功后，底层的 Informer 监听到 ResourceVersion 发生变化，立刻生成一个 Update 事件推入 Workqueue。Reconcile 再次被触发，走同样的逻辑，再次 Update，ResourceVersion 再次改变…… 形成了没有延时的死循环（Hot Loop）。

正确的防御性编程姿势

第一步：强制开启 Status Subresource 在 CRD 的 types.go 中，必须加上 //+kubebuilder:subresource:status 注解。随后在代码中替换为 Status().Update()。这能保证你的更新只作用于 Status 字段，防止并发修改 Spec 导致的冲突。

第二步：利用 Generation 阻断循环 在 K8S 的设计语义中，Spec 的改变会触发 Generation 的递增，而 Status 或 Metadata（如 Label/Annotation）的改变只会递增 ResourceVersion，不会改变 Generation。 我们在 SetupWithManager 中，必须注入 predicate.GenerationChangedPredicate，直接在源头把非 Spec 变化的事件丢弃：

import "sigs.k8s.io/controller-runtime/pkg/predicate"

func (r *MyCustomReconciler) SetupWithManager(mgr ctrl.Manager) error {
    return ctrl.NewControllerManagedBy(mgr).
        For(&mygroupv1.MyCR{}).
        // 核心防御：忽略仅 Status/Metadata 改变引起的触发
        WithEventFilter(predicate.GenerationChangedPredicate{}).
        Complete(r)
}

改造后，状态更新导致的 ResourceVersion 变化会被 Predicate 拦截，不再入队，死循环迎刃而解。

Informer 全量缓存引发的 OOM 惨案

解决完热循环，我们再看为什么 Operator 会吃掉 2GB 内存并触发 OOM。

业务需求是该 Operator 需要监控它创建出来的 Secret 对象，于是代码里写了：

    // 在 SetupWithManager 中
    Owns(&corev1.Secret{})

开发者的预期是：Operator 只监听归属于自己 CR 的 Secret。 底层真实原理：controller-runtime 的默认机制是，一旦你宣告关注某种内置资源（如 Pod、Secret、ConfigMap），它的 cache.Cache 实例就会在后台启动对应类型的 SharedIndexInformer。由于没有指定条件，这个 Informer 会向 APIServer 发起一次全量 LIST，把集群里所有的 Secret 拉到本地内存中，并建立长连接持续 WATCH。

恰巧该集群部署了海量的 Helm Release（以 Secret 形式存储状态），集群内有将近 10 万个 Secret。几百 MB 的 JSON 数据反序列化进 Go 的内存，加上对象指针的开销，瞬间打爆了 2GB 内存配额。

按需过滤：Cache Options 的正确配置

在 controller-runtime (v0.15.x+) 中，初始化 Manager 时必须对内置高频资源做严格的缓存过滤，限制 Informer 的作用域范围。通常使用 LabelSelector 方案：

    mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
        Scheme: scheme,
        MetricsBindAddress: ":8080",
        // 防御性缓存配置：只缓存包含特定 Label 的 Secret
        Cache: cache.Options{
            ByObject: map[client.Object]cache.ByObject{
                &corev1.Secret{}: {
                    Label: labels.SelectorFromSet(labels.Set{
                        "app.kubernetes.io/managed-by": "my-operator",
                    }),
                },
            },
        },
    })

通过这一层拦截，Informer 发给 APIServer 的请求就变成了 GET /api/v1/secrets?labelSelector=...，内存消耗瞬间从 2GB 暴降到 50MB。

CRD 架构与幂等性设计底线

在重构这个 Operator 时，我还对团队定下了三条不容挑战的架构底线：

  1. Reconcile 必须是纯粹的无状态与幂等函数：无论 Reconcile 被同一个请求触发 1 次还是 1000 次，只要 CR 的状态和集群真实状态一致，它就必须立即返回 nil，不能产生任何副作用（如重复发起外部 API 请求）。

  2. 拒绝盲目的 RequeueAfter：除非你需要做定时轮询（如检测外部系统状态），否则绝对不要在正常完成逻辑后返回 return ctrl.Result{RequeueAfter: 5*time.Second}, nil。依赖 K8S 原生的事件驱动（Watch）才是正途。

  3. 安全清理资源 (Finalizers)：如果你的 Operator 申请了集群外的资源（如云盘、LB、外部数据库账户），必须挂载 Finalizer。并在 Reconcile 开头检查 !myCR.ObjectMeta.DeletionTimestamp.IsZero() 逻辑，完成外部资源清理后再 RemoveFinalizer。

常见问题

Q1：代码中明明用 WithEventFilter 配置了过滤，为什么 Operator 重启时还是会对所有对象执行一次 Reconcile？ A：Informer 启动时，会对所有符合过滤条件的存量资源进行一次全量同步（Sync）。对于这些资源，触发的是 Create 事件。GenerationChangedPredicate 只针对 Update 事件生效，所以存量资源在重启时必然会过一次 Reconcile，这要求你的 Reconcile 代码必须具备高度幂等性。

Q2：为什么我的 Operator 启动时，日志一直卡在 Waiting for caches to sync 然后 Crash？ A：99% 的概率是 RBAC 权限配置缺失。Informer 试图 LIST 资源，但 APIServer 返回 403 Forbidden。controller-runtime 的缓存机制会不断重试直到超时。请检查集群中的 ClusterRole 或 Role 是否包含目标资源的 list 和 watch 权限。

Q3：如何监控 Operator 内部的队列积压情况以防范性能瓶颈？ A：controller-runtime 默认在 8080 端口暴露了 Prometheus metrics。必须配置告警规则监控以下核心指标：

  • workqueue_depth：队列当前积压数（持续大于0说明消费速度跟不上）。

  • workqueue_retries_total：失败重试次数（突增通常意味着遇到无法解决的代码错误或网络异常）。

  • controller_runtime_reconcile_time_seconds：Reconcile 函数的执行耗时（P99 应当控制在百毫秒级以内）。

更多文章