17370845950

用 Go 写 Kubernetes 控制器易拖慢集群，主因是 client-go 误用：监听范围过大、未限速并发、全量 ListWatch、耗时操作阻塞事件队列、缺乏服务端过滤及 informer 缓存泄漏。

为什么用 Go 写 Kubernetes 控制器容易拖慢集群

Kubernetes 的核心组件（如 api-server、controller-manager）本身就是 Go 编写的，但这不意味着随便写个 Go 控制器就“天然高效”。常见瓶颈不是语言本身，而是对 client-go 的误用、资源监听范围过大、或未控制并发节奏。比如一个监听

全部 Pod 的 informer，在千节点集群里可能每秒触发数百次事件，而你的处理逻辑若包含同步 HTTP 调用或未加限速的写操作，就会快速拖垮 etcd 压力或耗尽控制器内存。

• 默认 SharedInformer 会全量 List 所有资源，首次启动时可能卡住数秒甚至分钟（尤其 Pod 数超 10k）
• 未设置 ResyncPeriod: 0 会导致周期性全量重同步，无意义放大负载
• 直接在 OnAdd/OnUpdate 回调里做耗时操作（如调用外部 API），会阻塞整个 informer 的事件队列

用 client-go 的正确姿势：Informer + Workqueue + RateLimitingQueue

标准优化路径不是“换语言”，而是用对 client-go 提供的原生机制。关键不在自己造轮子，而在组合好官方推荐的三件套：

• Informer 负责本地缓存和事件分发，务必通过 cache.NewSharedIndexInformer 构建，并用 cache.Indexers 加索引（例如按 namespace 索引，避免遍历全量缓存）
• workqueue.RateLimitingInterface 替代裸 channel，它自带重试退避（DefaultControllerRateLimiter()）、去重（WithDedupKeyFunc）和并发控制
• 所有业务逻辑必须收口到 processNextWorkItem() 中异步执行，且每个 item 处理完必须调用 queue.Done(key)，否则会持续堆积

queue := workqueue.NewRateLimitingQueue(workqueue.DefaultControllerRateLimiter())
informer.AddEventHandler(cache.ResourceEventHandlerFuncs{
	AddFunc: func(obj interface{}) {
		key, _ := cache.MetaNamespaceKeyFunc(obj)
		queue.Add(key)
	},
	UpdateFunc: func(old, new interface{}) {
		key, _ := cache.MetaNamespaceKeyFunc(new)
		queue.Add(key)
	},
})

避免 ListWatch 泛滥：用 fieldSelector 和 namespace 限定范围

一个没加过滤的 ListWatch 对象，等价于对整个集群做全表扫描。Kubernetes 支持服务端过滤，但 client-go 默认不启用。必须显式传入 fieldSelector 或 namespace 参数，否则即使你只关心某几个命名空间下的 Deployment，informer 也会拉下全部 10 万+ 条记录再本地过滤。

• 永远优先用 cache.NewSharedIndexInformer 的 cache.ListWatch 构造函数，而不是 cache.NewListWatchFromClient —— 后者难控制参数
• 通过 cache.WithFieldSelector 限制字段（例如 status.phase=Running），比在内存里 if pod.Status.Phase == corev1.PodRunning 高效得多
• 若只监控单 namespace，用 cache.NewNamespacedSharedIndexInformer，它自动注入 namespace 查询参数，减少 90%+ 的 watch 流量

GC 和内存泄漏：别让 informer 缓存越积越多

Go 的 GC 能力强，但 SharedInformer 的本地缓存是 map + slice 结构，不会被 GC 自动清理。如果你频繁创建/销毁 informer（比如按需启动多个 controller 实例），旧缓存对象可能长期驻留，导致 RSS 持续上涨。更隐蔽的是，忘记调用 informer.Run(stopCh) 或提前 close stopCh，会让 informer 协程卡在 WaitForCacheSync 里，持续持有引用。

• 每个 informer 必须绑定唯一、长生命周期的 stopCh（通常来自 context.Background().Done()），且不能重复 Run
• 避免在循环中 new informer；若需动态监听不同资源，复用同一个 rest.Config 和 cache.SharedInformerFactory
• 用 pprof 定期看 /debug/pprof/heap，重点关注 *unstructured.Unstructured 和 *v1.Pod 实例数量是否随时间线性增长

Go 本身不是性能瓶颈，真正吃资源的是没节制的 ListWatch、没压测过的重试逻辑、以及把 informer 当成黑盒随意 new 的习惯。集群规模上来后，一个没设 fieldSelector 的 Pod informer，比十个 Python 脚本更伤 etcd。