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

posted @ 2021-08-01 09:53  JL_Zhou  阅读(180)  评论(0编辑  收藏  举报