最高效可靠的方式是使用 client-go 的 Watch 机制或 Informer；Watch 实现低延迟事件驱动监听，Informer 则自动管理缓存、重连与事件分发，适合生产环境。
在 Go 中监控 Kubernetes Pod 状态，最高效、可靠的方式是使用 client-go 提供的 Watch 机制或更高层封装的 Informer。它们能避免轮询开销，实现低延迟、事件驱动的状态同步。
用 Watch 监听 Pod 变化
Watch 是 Kubernetes API 的原生能力，client-go 封装为 Watch() 方法，返回一个 watch.Interface，持续接收 watch.Event（如 Added、Modified、Deleted）。
- 需构造带版本号（ResourceVersion）的 ListOptions，首次调用
List()获取初始状态和 resourceVersion，再传给Watch()启动监听 - Watch 连接断开时会自动重连，但需手动处理
resourceVersionTooOld错误：捕获该错误后重新 List 再 Watch - 事件对象的
Object字段是*v1.Pod类型，可直接类型断言使用
用 Informer 实现自动缓存与事件分发
Informer 是 client-go 对 Watch 的增强封装，内置本地缓存（Store）、DeltaFIFO 队列、Reflector（负责 Watch）、Indexer（支持按标签/字段索引），并提供 AddFunc、UpdateFunc、DeleteFunc 等回调。
- 通过
cache.NewSharedIndexInformer()或更常用的cache.NewSharedInformer()创建，传入 ListWatch 对象和 resync 周期（0 表示禁用定期同步） - 注册事件回调后调用
Run(stopCh)启动；stopCh用于优雅退出 - 缓存中的 Pod 可通过
informer.GetIndexer().List()或ByIndex()快速查询，无需反复请求 API Server
处理常见场景的实用建议
真实业务中需兼顾健壮性与可观测性：
立即学习“go语言免费学习笔记（深入）”；
- 对关键 Pod（如 job 主容器），在
UpdateFunc中检查pod.Status.Phase和pod.Status.Conditions，区分 Pending / Running / Succeeded / Failed / Unknown - 监听
pod.Status.ContainerStatuses获取每个容器的就绪、重启、状态详情（如Waiting.Reason == "CrashLoopBackOff"） - 结合 namespace 和 label selector 过滤目标 Pod，避免全集群监听带来的性能与权限问题
- 日志中记录 event.Type + pod.Name + pod.Namespace + event.Object.(*v1.Pod).ResourceVersion，便于排障和审计
不依赖 client-go 的轻量替代方案
若项目无法引入 client-go（如嵌入式工具或极简脚本），可用 http.Client 直接调用 kube-apiserver 的 watch endpoint：
- GET
/api/v1/namespaces/{ns}/pods?watch=true&resourceVersion={rv} - 响应是流式 JSON，每行一个
watch.Event对象（需逐行解析） - 需自行处理连接保活、重试、resourceVersion 更新、TLS 认证（ServiceAccount token + ca.crt）
- 适合一次性诊断脚本，长期运行服务仍推荐 Informer
基本上就这些。Watch 是基础能力，Informer 是生产首选——它省去了缓存管理、重连逻辑和事件去重，让关注点真正回到业务状态判断上。
