使用client-go的Informer机制监听Kubernetes资源变更，通过SharedIndexInformer注册Add/Update/Delete回调处理Deployment等资源状态变化，需确保缓存同步、非阻塞执行、幂等处理及错误重试。
监听Kubernetes资源变更事件
在Go中处理Kubernetes事件，核心是使用client-go提供的Informer机制。它通过Watch API长连接监听API Server，本地维护资源缓存，并触发Add/Update/Delete回调。不需要手动轮询或解析原始Event对象——真正的“事件”（corev1.Event）和资源变更（如Pod、Deployment状态变化）是两回事。你通常要响应的是后者：比如Deployment更新后自动滚动检查、ConfigMap变动后触发服务重载。
用SharedIndexInformer注册变更回调
以监听Deployment为例：
- 构造
sharedInformerFactory.Apps().V1().Deployments()获取Informer - 调用
Informer.AddEventHandler()传入cache.ResourceEventHandler接口实现 - 在
OnAdd、OnUpdate、OnDelete方法里写业务逻辑，注意OnUpdate会收到旧新两个对象，需用reflect.DeepEqual或比较ResourceVersion判断是否真有变更 - 启动Informer前必须调用
informer.Run(stopCh)，且需预先cache.WaitForCacheSync(stopCh, informer.HasSynced)确保缓存已热加载
安全地执行自动响应动作
响应逻辑不能阻塞Informer的事件循环线程，否则会丢事件。建议：
- 将实际操作（如Patch Pod、创建Job）放入独立Worker Goroutine或带缓冲的Channel队列
- 对同一资源做幂等处理：用
labels或annotations标记是否已响应过，避免重复触发 - 调用ClientSet时加超时控制，例如
ctx, cancel := context.WithTimeout(context.Background(),
30*time.Second) - 捕获
apierrors.IsConflict()错误并重试，尤其修改资源时可能因版本冲突失败
30*time.Second)调试与可观测性要点
生产环境需快速定位为何没响应：
- 打印Informer同步状态：
log.Printf("Informer synced: %v", informer.HasSynced()) - 在事件处理器开头打日志，输出资源名、Namespace、ResourceVersion，确认事件确实到达
- 用
kubectl get events -n查是否有client-go权限不足、RBAC拒绝等底层错误 - 避免在Handler里直接
panic，统一recover并记录错误堆栈
