Client-go中reflector relist的场景分析

client-go中什么时候会发生re-list

我们知道client-go中的reflector模块首先会list apiserver获取某个资源的全量信息，然后根据list到的rv来watch资源的增量信息。我们希望使用client-go编写的控制器组件在与apiserver发生连接异常时，尽量的re-watch资源而不是re-list（在etcd3.4之前，大量的list操作对etcd来说是一种expensive read 请求，对性能有较大的影响，参考极客时间etcd实战基础04思考题答案）

listAndWatch过程源码分析，参考我的另一篇文章：https://www.cnblogs.com/orchidzjl/p/14768781.html

注意这里什么时候可能发生re-list或者re-watch：因为是通过wait.Util不断调用ListAndWatch方法，所以只要该方法return了，那么就会发生re-list，watch过程则被嵌套在for循环中

场景一：very short watch

reflector与api建立watch连接，但是集群内该资源在1s时间内无相关的变动，则会重新re-list

I0728 11:32:06.170821 67483 streamwatcher.go:114] Unexpected EOF during watch stream event decoding: unexpected EOF I0728 11:32:06.171062 67483 reflector.go:391] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.Deployment total 0 items received W0728 11:32:06.187394 67483 reflector.go:302] k8s.io/client-go/informers/factory.go:134: watch of *v1.Deployment ended with: very short watch: k8s.io/client-go/informers/factory.go:134: Unexpected watch close - watch lasted less than a second and no items received

 

场景二：401 Gone

reflector与api建立watch连接，但是出现watch的相关事件丢失时（etcd不会一直记录历史版本），api返回401 Gone，reflector提示too old resource version并重新re-list

I0728 14:40:58.807670 71423 reflector.go:300] k8s.io/client-go/informers/factory.go:134: watch of *v1.Deployment ended with: too old resource version: 332167941 (332223202) I0728 14:40:59.808153 71423 reflector.go:159] Listing and watching *v1.Deployment from k8s.io/client-go/informers/factory.go:134 I0728 14:41:00.300695 71423 reflector.go:312] reflector list resourceVersion: 332226582