最可靠方式是监听DeletionTimestamp非空和Phase变更，而非依赖Delete事件；Informer需正确启动并深拷贝回调对象，本地调试须用BuildConfigFromFlags加载kubeconfig。
你不需要写一个“监控教程”，而是要让 Go 程序可靠地感知 Kubernetes 集群状态 —— 这本质是 client-go 的使用问题，不是 Prometheus 或 kube-state-metrics 的配置问题。
client-go Watch 为什么收不到 Pod 删除事件
Watch 返回的 Delete 事件只在对象从 etcd 彻底删除后才触发，但 kubectl delete pod 后 Pod 先进入 Terminating 状态（仍在 API Server 中），几秒后才消失。很多逻辑误以为 “没看到 Delete 就没删”，导致告警延迟或漏判。
- 真正可靠的删除信号是检查
pod.ObjectMeta.DeletionTimestamp != nil—— 只要非空，就代表删除流程已启动 - 同时需监听
pod.Status.Phase变更：比如从Running→Failed或Unknown，也应纳入异常处理流 - 别依赖裸
Watch()手动重连和缓存；用cache.NewInformer()，它自动捕获Update事件中的字段变化，比等Delete更及时
本地调试时 rest.InClusterConfig() 总是失败
rest.InClusterConfig() 只适用于 Pod 内运行场景（自动挂载 /var/run/secrets/kubernetes.io/serviceaccount/），本地调试必须显式加载 kubeconfig。常见错误是手动拼 rest.Config，跳过证书 base64 解码或忽略 insecure-skip-tls-verify 字段。
- 本地开发优先用
clientcmd.BuildConfigFromFlags("", "/path/to/kubeconfig")，它会自动处理证书解码、路径解析和 TLS 跳过逻辑 - 若证书报
x509: certificate signed by unknown authority，确认kubeconfig中certificate-authority-data正确，或临时设config.Insecure = true（仅限开发） - Pod 内运行时，确保 ServiceAccount 已绑定含
get/list/watch权限的 Role/ClusterRole，否则InClusterConfig()能连上但后续请求 403
用 Informer 监听 Pod 却查不到最新状态
Informer 缓存的是 List + Watch 同步来的数据，不是实时 API 查询结果。如果初始化后没调 informer.Run(stopCh)，或者 stopCh 提前关闭，缓存就不会更新，GetIndexer().List() 返回的就是旧快照。
立即学习“go语言免费学习笔记（深入）”；
- 必须在
go informer.Run(stopCh)启动后，再调用informer.GetIndexer().List()，否则缓存为空或滞后 - 注册回调时，
OnAdd/OnUpdate的参数是*v1.Pod指针，Informer 内部复用对象内存 —— 别直接保存指针，应深拷贝或提取关键字段（如pod.Name,pod.Status.Phase） - 若需跨 namespace 监听，Informer 工厂要用
cache.NewSharedInformerFactory(clientset, 0)，而非限定 namespace 的cache.NewFilteredSharedInformerFactory
最易被忽略的点：Informer 不是“开箱即用”的实时视图，它依赖正确启动、持续运行和安全的数据消费方式；而 Watch 的语义边界（比如 Terminating 不等于 Deleted）必须由业务代码显式建模，client-go 不会替你做状态机推断。
