Kubernetes watch监听出现事件丢失问题排查问询

你遇到的是client-go使用watch机制的典型疏漏，有两个非常明显的配置/逻辑问题：

1. 未处理ResourceVersion导致事件断层 #

Kubernetes的watch机制完全基于resourceVersion（etcd的版本号）实现增量事件同步，你现在的代码每次重启watch时完全没有传递上一次处理到的resourceVersion，每次重连都会从头开始同步或者直接跳过中间事件，在高频率Job创建/更新的场景下必然会出现事件丢失。

2. 无断连检测导致TCP半开连接Hang住 #

你观察到的「事件丢失15分钟以上」是典型的TCP静默断开问题：kube-apiserver前面的负载均衡/代理默认的空闲连接超时通常是15分钟，当连接被中间网络设备静默断开时，没有心跳检测的客户端完全感知不到连接已经失效，会一直等待接收事件，直到TCP层超时才会断开连接，这段时间内的所有事件都无法收到。

代码层面修改 #

调整Watch调用参数 #

timeout := int64(600) // 超时改长到10分钟，不要用30秒这么短的强制超时
// 每次调用watch时传递上次的resourceVersion，启用Bookmark心跳
return k.clientset.BatchV1().Jobs(namespace).Watch(context.TODO(), metav1.ListOptions{
    TimeoutSeconds: &timeout,
    ResourceVersion: latestRV, // latestRV是全局保存的上次处理到的最新版本号
    AllowWatchBookmarks: true, // 启用K8s的心跳事件，1.17+版本支持
})

调整监控循环逻辑 #

func monitorAllPods() {
    var latestRV string
    for {
        // 如果resourceVersion失效，先全量list同步一次最新状态和版本号
        if latestRV == "" {
            list, err := kube.clientset.CoreV1().Pods(namespace).List(context.TODO(), metav1.ListOptions{})
            check(err)
            latestRV = list.ResourceVersion
            // 全量list的结果也要同步处理，避免漏掉重启期间的状态变更
            for _, pod := range list.Items {
                handlePodEvent(watch.Added, &pod)
            }
        }
        watch, err := kube.podWatch(latestRV) // 把latestRV传给watch调用
        check(err)
    eventLoop:
        for {
            select {
            case event, ok := <-watch.ResultChan():
                if !ok {
                    // 通道关闭，检查错误
                    err = watch.Err()
                    break eventLoop
                }
                // 处理Bookmark心跳事件，更新resourceVersion
                if event.Type == watch.Bookmark {
                    if meta, ok := event.Object.(metav1.Object); ok {
                        latestRV = meta.GetResourceVersion()
                    }
                    continue
                }
                pod, ok := event.Object.(*corev1.Pod)
                if !ok {
                    log.Printf("Got event %v, but couldn't convert to pod\n", event)
                    continue
                }
                // 每次处理完正常事件更新resourceVersion
                latestRV = pod.ResourceVersion
                handlePodEvent(event.Type, pod)
            case <-time.After(2 * time.Minute): // 2分钟没收到任何事件主动重连
                watch.Stop()
                break eventLoop
            }
        }
        // 处理watch错误，如果是resourceVersion过期，重置后重连
        if err != nil && errors.IsResourceExpired(err) {
            latestRV = ""
        }
    }
}

兜底策略优化 #

你现在用的轮询兜底方案是合理的，watch机制本身无法保证100%不丢事件，生产环境必须搭配定期全量轮询做状态对齐，你可以把轮询间隔调整到1~5分钟，不需要30秒就重启watch这么激进。

你使用的K8s 1.21版本本身没有严重的watch事件漏发bug，社区遇到这类问题90%以上都是没有正确处理resourceVersion和心跳检测导致的。

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