client-go：如何通过watch.RetryWatcher获取资源版本单调递增的变更流

一、移除跳过旧事件代码后收到所有运行中Pod的ADDED事件 #

这是Kubernetes List-Watch机制的正常初始同步行为：

• 当建立Watch连接时，API Server不会直接只推送后续的增量变更。它会先执行一次全量List操作，把当前集群中所有符合Watch条件的资源，以ADDED事件的形式推送给客户端，目的是让程序先同步到集群的最新完整状态。
• 之后才会持续推送后续的增量变更事件（比如新创建、删除、修改资源的事件）。所以去掉跳过旧事件的逻辑后，自然会收到所有已存在Pod的ADDED事件。

二、保留跳过旧事件代码但创建新Pod时收到重复ADDED事件 #

这种情况通常和ResourceVersion管理或Watch重连逻辑有关，常见原因包括：

• ResourceVersion未正确更新：跳过旧事件的核心是记录初始List操作返回的ResourceVersion，后续只处理ResourceVersion大于该值的事件。如果代码在处理完事件后没有更新本地记录的ResourceVersion，或者初始获取的ResourceVersion不正确（比如没有从List结果中正确提取），就可能导致后续重连时API Server再次推送已经处理过的事件。
• Watch连接异常重连：Kubernetes的Watch连接是长连接，可能因网络波动、超时、API Server负载高等原因断开。客户端会自动重连，若重连时使用的是旧的ResourceVersion，API Server会从该版本开始重新推送所有未确认的事件，包括之前已经处理过的ADDED事件。
• 手动Watch实现的缺陷：如果没有使用client-go的Informer/SharedInformer组件，而是自己手动实现Watch逻辑，很容易忽略缓存去重、状态同步的细节。Informer内部会维护本地缓存，自动过滤重复事件，而手动实现时如果没有处理这些，就可能收到重复的ADDED事件。
• 事件类型判断错误：少数情况下，可能把MODIFIED事件误判为ADDED事件，比如Pod创建过程中状态更新时，代码逻辑错误触发了重复的ADDED处理逻辑。

建议的排查方向 #

• 检查代码中ResourceVersion的获取和更新逻辑，确保初始值来自List操作的返回结果，且每次处理完事件后更新到最新的ResourceVersion。
• 优先使用client-go的SharedInformer或Controller框架，这些组件已经封装了List-Watch的重连、缓存去重、事件去重逻辑，能避免大部分重复事件问题。
• 打印事件的ResourceVersion和ObjectMeta信息，对比重复事件的版本号，判断是同一版本的重复推送还是不同版本的误判。

内容的提问来源于stack exchange，提问作者Shuzheng