直接调用 clientset.corev1().pods().list() 会因高频 http 请求触发 api server 限流、压垮 etcd，应使用 cache.newsharedindexinformer() 配合 listwatch 和 resourceeventhandlerfuncs 实现事件驱动的本地缓存同步。
为什么直接调用 clientset.CoreV1().Pods().List() 会拖垮集群
频繁轮询 API Server 不是“慢”，而是会触发限流、压垮 etcd、让其他组件抢不到连接。K8s 默认对单个 client 的 QPS 有硬限制（qps=5，burst=10），一旦超限，你会看到 429 Too Many Requests 或 context deadline exceeded 错误。
真正的问题不在 Go 代码写得不够快，而在于每次 List() 都要走完整 HTTP 请求链路 + 序列化反序列化 + 权限校验 —— 这些开销在高并发下指数级放大。
- 避免在定时器里反复调用
List()或Get()，哪怕加了time.Sleep(30 * time.Second)也不够安全 - Informer 不是“可选优化”，而是 K8s 官方推荐的**唯一合规方式**去监听资源变化
- 本地缓存不是靠 map 存一下就行，必须配合
Reflector+DeltaFIFO+Indexer三件套，否则会丢事件或状态不一致
怎么用 cache.NewSharedIndexInformer() 替掉手写轮询
别碰 cache.NewInformer()（已弃用），也别自己实现 ResourceEventHandler 全接口 —— 大部分场景只需要 cache.ResourceEventHandlerFuncs。
关键不是“怎么写”，而是“哪些参数不能错”：
立即学习“go语言免费学习笔记（深入）”；
-
listerWatcher必须用cache.NewListWatchFromClient()构造，传入 clientset 和 resource path（比如"pods"），不能自己拼 URL -
resyncPeriod设为 0 表示禁用周期性全量同步；设为非 0（如30 * time.Minute）才能兜底防止本地缓存 drift -
defaultEventHandlerResyncPeriod是 informer 内部用的，别和上面那个混；它默认就是0，一般不动 - 对象类型必须和 list 返回结构严格一致：Pod 列表是
*corev1.PodList，所以expectedType得传&corev1.Pod{}（注意取地址）
示例片段：
informer := cache.NewSharedIndexInformer(
&cache.ListWatch{
ListFunc: func(options metav1.ListOptions) (runtime.Object, error) {
return clientset.CoreV1().Pods("").List(context.TODO(), options)
},
WatchFunc: func(options metav1.ListOptions) (watch.Interface, error) {
return clientset.CoreV1().Pods("").Watch(context.TODO(), options)
},
},
&corev1.Pod{},
30*time.Minute,
cache.ResourceEventHandlerFuncs{
AddFunc: func(obj interface{}) { /* ... */ },
UpdateFunc: func(old, new interface{}) { /* ... */ },
DeleteFunc: func(obj interface{}) { /* ... */ },
},
)如何从 Informer 缓存里安全读取 Pod 数据
别直接访问 informer 的内部字段 —— 它没暴露 cache 字段给你。要用 indexer 提供的只读接口：
- 查单个：用
informer.GetIndexer().GetByKey(namespace + "/" + name)，返回interface{}，记得类型断言成*corev1.Pod - 查全部：用
informer.GetIndexer().List()，返回[]interface{}，遍历后断言 - 按 label 查：先注册索引器
informer.AddIndexers(cache.Indexers{"by-label": podByLabel})，再用informer.GetIndexer().ByIndex("by-label", "env=prod") - 所有读操作都**不需要加锁**，indexer 内部已做线程安全处理
注意：如果 informer 还没同步完（HasSynced() 返回 false），List() 可能为空或不全 —— 启动时务必等 cache.WaitForCacheSync(stopCh, informer.HasSynced)。
为什么 Informer 启动后还是收不到事件
最常见原因是 watch 被服务端中断后没自动重连，或者 client 权限不足导致 watch 直接失败静默退出。
- 检查 RBAC：ServiceAccount 至少要有
get、list、watch权限，缺watch就不会触发任何AddFunc/UpdateFunc - 看日志里有没有
failed to list <resource>: xxx</resource>—— 如果 list 失败，informer 根本不会启动 watch - 确认 namespace 参数：
clientset.CoreV1().Pods("default")只监听 default 命名空间；要监听全部，必须传空字符串"" - Watch timeout 默认是 30 分钟，但实际受 apiserver
--min-request-timeout影响；如果网络抖动，需要靠 resync 机制兜底，而不是指望 watch 永不断
真正难调试的点在于：informer 出问题时往往不 panic，只是“安静地不工作”。建议在 Start() 后立刻打一行日志，并在 UpdateFunc 里加计数器，用 Prometheus 暴露指标比 print 更可靠。
