Informer 默认同步全集群导致内存飙升，因其启动时List拉取所有命名空间对象；需通过fieldSelector在ListWatch的ListFunc和WatchFunc中统一过滤namespace，并验证API Server支持、日志及缓存大小。
为什么 Informer 默认同步全集群会吃掉大量内存
因为 SharedInformer 启动时默认调用 List 拉取该资源类型在所有命名空间下的全部对象，哪怕你只关心 default 空间。一个中等规模集群里，Pod 对象轻松上万，每个 Pod 结构体在 Go runtime 里占几百字节，加上 indexer 的 map key/value 开销、reflector 缓存、delta fifo 队列，单个 Informer 常驻内存很容易突破 100MB。
用 cache.ListWatch + fields.OneTermEqualSelector 过滤命名空间
不能靠启动后手动遍历过滤——那样只是“看不见”，对象依然被缓存、索引、监听。必须从源头掐断无关对象的流入。
- 构造
cache.ListWatch时传入自定义clientset.CoreV1().Pods("").List和clientset.CoreV1().Pods("").Watch，注意命名空间参数填空字符串（表示全量），真正的过滤交给fieldSelector - 用
fields.OneTermEqualSelector("metadata.namespace", "default")构造 selector，传给ListOptions.FieldSelector和WatchOptions.FieldSelector - 确保你的 Kubernetes API server 支持该字段索引（1.21+ 默认支持
metadata.namespace，旧版本需确认是否开启--runtime-config=api/all=true）
示例关键片段：
selector := fields.OneTermEqualSelector("metadata.namespace", "default")
lw := &cache.ListWatch{
ListFunc: func(options metav1.ListOptions) (runtime.Object, error) {
options.FieldSelector = selector.String()
return clientset.CoreV1().Pods("").List(context.TODO(), options)
},
WatchFunc: func(options metav1.ListOptions) (watch.Interface, error) {
options.FieldSelector = selector.String()
return clientset.CoreV1().Pods("").Watch(context.TODO(), options)
},
}
别忽略 ResyncPeriod 和 Indexers 的副作用
即使做了 namespace 过滤，如果启用了自定义 Indexers（比如按 label 索引），或设置了过短的 ResyncPeriod，仍可能放大内存压力。
立即学习“go语言免费学习笔记（深入）”；
-
ResyncPeriod设为 0 表示禁用 resync；设为非 0 值时，Informer 会定期重新 list 全量（已过滤过的）对象并重建本地缓存，频繁 resync 会触发大量对象拷贝和 map 重建 - 自定义
Indexers会额外维护一份 map，键是索引值，值是对象指针数组——哪怕只索引一个 label，只要该 label 出现在上千个 Pod 上，就多一份千级长度的 slice 引用 - 如果不需要索引能力，初始化
NewSharedIndexInformer时传cache.Indexers{}，而非cache.Indexers{"by-label": ...}
验证是否真正生效：看 Reflector 日志和实际缓存大小
光看代码不等于过滤成功。API server 可能静默忽略不支持的 FieldSelector（返回全量），而 client-go 不报错。
- 启用
client-go调试日志：export GODEBUG=http2debug=2或在代码中设置klog.SetLevel(4)，观察List请求 URL 是否含?fieldSelector=metadata.namespace%3Ddefault - 在 Informer 启动后，用
informer.GetStore().List()打印长度，对比全量 namespace 下的 Pod 数量，应明显更少 - 用
pprof抓 heap profile，重点关注*corev1.Pod实例数和cache.threadSafeMap占用，确认没残留其他 namespace 的对象
namespace 过滤不是开关式操作，它依赖 API server 字段支持、client-go 版本兼容性、以及你是否在 List/Watch 两个路径都一致应用了 selector——漏掉 Watch 就会导致后续新增对象不受控。
