client-go的ListWatch机制通过先全量List获取资源快照，再建立HTTP长连接Watch监听ADDED/DELETED/MODIFIED事件触发数据同步；连接中断时自动断点续传，遇410 Gone则回退全量List重建缓存。
client-go 的 ListWatch 机制怎么触发数据同步
client-go 不是靠轮询拉取，而是通过 HTTP long-running watch 连接监听资源变更事件。一旦你调用 List() + Watch()（或更常见的 Informer），底层会先全量 List 当前资源快照，再建立一个持续的 WebSocket-like 连接接收 ADDED/DELETED/MODIFIED 事件。
容易踩的坑：
-
Watch连接可能因网络抖动中断，client-go 默认会自动重连并从resourceVersion断点续传——但若断开太久导致 API Server 已清理历史版本，就会报错410 Gone，此时必须回退到全量List重建本地缓存 - 不要在
Watch回调里做耗时操作（比如写 DB、发 HTTP 请求），否则会阻塞整个事件队列；应把事件推入缓冲 channel 后异步处理 -
resourceVersion=0表示“不关心一致性”，适合只读场景；生产环境控制器必须用默认值（空字符串），让 client-go 自动管理
Informer 的 sharedIndexInformer 为什么比 raw Watch 更常用
直接写 Watch 很容易漏状态、重复处理或并发冲突。sharedIndexInformer 封装了四层关键能力：本地内存缓存（DeltaFIFO）、索引机制（支持按 label selector 快速查）、事件分发（EventHandler）和周期性 resync（防状态漂移）。
实操建议：
- 用
cache.NewSharedIndexInformer初始化时，resyncPeriod设为 30s～2m，太短加重 API Server 压力，太长可能导致本地缓存与集群实际状态脱节 - 注册
EventHandler时，OnAdd/OnUpdate必须幂等——因为同一事件可能被多次投递（例如 informer 重启后重放） - 别直接操作 informer 的
Store，要用informer.GetIndexer().ByIndex("namespace", "default")这类索引方法查，性能差一个数量级
Reconcile 函数里怎么安全地对比 Desired 和 Actual 状态
Operator 的核心逻辑不是“执行命令”，而是“计算差异并收敛”。Reconcile 函数每次被调用时，都要基于当前 CR 对象（Desired）和已存在的 Kubernetes 资源（Actual）做 diff，再决定创建/更新/删除哪些对象。
常见错误现象：
- 用
DeepEqual直接比对整个*v1.Pod对象失败——因为 API Server 会注入CreationTimestamp、ResourceVersion、UID等字段，这些不该参与比对 - 忽略字段语义：比如
Pod.Spec.Containers[0].Image改变要重建 Pod，但Pod.Annotations变化通常只需 patch，不用删重建 - 没处理 “资源存在但不符合预期” 场景：例如 StatefulSet 已存在，但
replicas是 2，而 CR 要求是 3，这时该 patch 而非 delete/recreate
推荐做法：用 controllerutil.CreateOrUpdate（来自 sigs.k8s.io/controller-runtime）封装 create/update 逻辑，它会自动判断是否需要 patch，并跳过只读字段。
如何避免 Informer 缓存和 API Server 状态不一致
informer 缓存本质是最终一致模型，延迟通常在毫秒级，但极端情况下（如大规模资源变动、etcd 高负载）可能达数秒。不能假设 informer.GetStore().List() 返回的结果“就是当前集群状态”。
关键判断点：
- 对关键路径（如删除前确认 Pod 已 Terminating），必须用 clientset 同步调用
Get()或List()拉取最新状态，不能只查 informer 缓存 - 在
Reconcile中，若发现 informer 缓存里没有某个资源，不代表它真的不存在——可能是 watch 流丢失或缓存未同步完成，应补一次 direct GET - 调试时用
kubectl get --watch对比 informer 日志输出，能快速定位是缓存延迟还是逻辑 bug
最易被忽略的是：informer 启动后不会立即 ready，HasSynced() 返回 true 才表示首次 list 完成且所有初始事件已分发——任何 reconcile 逻辑都该加 if !informer.HasSynced() { return } 防空转。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
