client-go Watch 必须带有效 ResourceVersion 启动，否则返回410或重推全量；应先List获取RV再Watch，并处理Error事件重试；Informer自动维护缓存与重连，更适合长期运行。
用 client-go Watch 监听 Pod 状态变化时收不到事件？
Watch 不是“启动就一直有事件”，它必须带有效的 ResourceVersion 启动，否则会返回 410 Gone 或重复推送历史全量事件。常见错误是直接调 Watch() 不带参数，或用了过期的 ResourceVersion。
正确做法是：先调一次 List() 获取当前资源快照和最新 ResourceVersion，再用这个值发起 Watch()。例如：
list, err := clientset.CoreV1().Pods(namespace).List(ctx, metav1.ListOptions{
LabelSelector: "app=my-go-app",
})
if err != nil { /* handle */ }
rv := list.ResourceVersion
<p>watcher, err := clientset.CoreV1().Pods(namespace).Watch(ctx, metav1.ListOptions{
ResourceVersion: rv,
LabelSelector: "app=my-go-app",
})
- 务必加
LabelSelector和Namespace，否则默认监听全集群 Pod，权限不足会报错，权限够了也会拖慢性能 - 监听到
watch.Event.Type == watch.Error时，大概率是连接断开或ResourceVersion过期，需自动触发重试：重新List()→ 更新ResourceVersion→ 再Watch() - 别假设
Deleted事件一定会来——Pod 进入Terminating状态后可能卡住数秒才真正删除；更可靠的做法是监听pod.DeletionTimestamp != nil或pod.Status.Phase变更为Failed/Succeeded
为什么 Informer 比裸 Watch 更适合长期运行？
如果你不止要“收到事件”，还要频繁查当前有哪些 Pod 在运行、某个 Pod 的最新 Phase 是什么，裸 Watch 就得自己维护缓存、处理重连、去重、丢事件恢复——这些 cache.NewSharedIndexInformer 都已内置。
初始化一个 Pod Informer 很简单：
立即学习“go语言免费学习笔记（深入）”；
informer := informerFactory.Core().V1().Pods(namespace).Informer()
informer.AddEventHandler(cache.ResourceEventHandlerFuncs{
AddFunc: func(obj interface{}) {
pod := obj.(*corev1.Pod)
// 注意：不要直接保存 pod 指针！Informer 会复用对象
// 应 deep-copy 或只取需要的字段，如 pod.Name, pod.Status.Phase
},
UpdateFunc: func(old, new interface{}) {
newPod := new.(*corev1.Pod)
// 检查 phase 是否变化：old.(*corev1.Pod).Status.Phase != newPod.Status.Phase
},
})
informerFactory.Start(wait.NeverStop)
- 缓存中的数据可直接用
informer.GetIndexer().List()或ByIndex("namespace", ns)查，不走网络 - 启动前必须调
informer.Run(stopCh)，且stopCh要在程序退出时关闭，否则 goroutine 泄漏 - 别在
AddFunc/UpdateFunc里做耗时操作（如发 HTTP 请求），应投递到 worker queue 异步处理
本地调试时 client-go 连不上集群？证书或权限问题怎么快速定位？
报错 x509: certificate signed by unknown authority 不代表证书真有问题，而是 client-go 没加载对配置。本地调试时，别手写 rest.Config，优先用 clientcmd.BuildConfigFromFlags()。
它会自动处理：certificate-authority-data 的 base64 解码、insecure-skip-tls-verify: true 标志、用户证书路径拼接。
- 确认 kubeconfig 文件路径传对了，比如
clientcmd.BuildConfigFromFlags("", "/home/user/.kube/config") - 临时跳过 TLS 校验仅限开发：设
config.Insecure = true，但上线前必须删掉 - 若用
rest.InClusterConfig()（即 Pod 内运行），确保 ServiceAccount 已绑定含list/watch pods权限的 Role/ClusterRole - 验证权限是否足够：用
kubectl auth can-i list pods -n myns测试，别依赖 “能连上” 就等于 “能读资源”
要不要自己直连 /api/v1/pods?watch=true？
可以，但只推荐极简场景：单文件诊断脚本、CI 中临时检查、嵌入式工具等不想引入 client-go 依赖时。它绕过了所有 client-go 的可靠性保障，你得自己处理流式响应、连接保活、重试逻辑。
关键点在于响应体是 JSON Lines（每行一个完整 JSON 对象），不能用 json.Unmarshal() 一次性解整个 body：
resp, _ := http.Get("https://apiserver/api/v1/namespaces/default/pods?watch=true&resourceVersion=12345")
decoder := json.NewDecoder(resp.Body)
for {
var event watch.Event
if err := decoder.Decode(&event); err != nil {
break // EOF or network error
}
// 处理 event.Type, event.Object
}
- 每次请求必须带
resourceVersion，否则可能收全量历史事件甚至 410 错误 - 没有自动重连，连接断开就得自己重建请求、重新
List获取新ResourceVersion - 没 RBAC 权限校验提示，出错时只看到 403，不如 client-go 的错误信息明确
实际部署中，最易被忽略的是：Informer 缓存与真实 API Server 状态之间存在几秒延迟，且 ResourceVersion 是按 namespace 级别推进的，跨 namespace 的事件顺序无法严格保证。如果业务逻辑强依赖“绝对实时”或“全局有序”，得在应用层加版本号比对或时间戳兜底。
