Kubernetes代码解读-apiserver之list-watch

最新推荐文章于 2024-08-20 08:16:59 发布

云计算运维工程师

最新推荐文章于 2024-08-20 08:16:59 发布

阅读量1.1k

点赞数

分类专栏：技术干活

本文链接：https://blog.csdn.net/u014389734/article/details/89327079

版权

本文深入探讨了Kubernetes apiserver的list-watch功能，解释了如何通过list-watch获取资源变化，以及apiserver如何处理watch请求。apiserver根据组件的需求发起带条件的watch请求，并在watch失败时使用list作为补偿。apiserver内部通过Cacher和WatchCache等结构实现数据缓存和过滤，确保高效地将事件传递给客户端。

摘要由CSDN通过智能技术生成

list-watch，作为k8s系统中统一的异步消息传递方式，对系统的性能、数据一致性起到关键性的作用。今天我想从代码这边探究一下list-watch的实现方式。并看是否能在后面的工作中优化这个过程。

list-watch的需求

Kubernetes代码解读-apiserver之list-watchKubernetes代码解读-apiserver之list-watch

上图是一个典型的Pod创建过程，在这个过程中，每次当kubectl创建了ReplicaSet对象后，controller-manager都是通过list-watch这种方式得到了最新的ReplicaSet对象，并执行自己的逻辑来创建Pod对象。其他的几个组件，Scheduler/Kubelet也是一样，通过list-watch得知变化并进行处理。这是组件的处理端代码：

go
c.NodeLister.Store, c.nodePopulator = framework.NewInformer(
    c.createNodeLW(),                                            ...(1)
    &api.Node{},                                                 ...(2)
    0,                                                           ...(3)
    framework.ResourceEventHandlerFuncs{                         ...(4)
        AddFunc:    c.addNodeToCache,                            ...(5)
        UpdateFunc: c.updateNodeInCache,
        DeleteFunc: c.deleteNodeFromCache,
    },
)

其中(1)是list-watch函数，(4)(5)则是相应事件触发操作的入口。

list-watch操作需要做这么几件事

由组件向apiserver而不是etcd发起watch请求，在组件启动时就进行订阅，告诉apiserver需要知道什么数据发生变化。Watch是一个典型的发布-订阅模式。

组件向apiserver发起的watch请求是可以带条件的，例如，scheduler想要watch的是所有未被调度的Pod，也就是满足Pod.destNode=””的Pod来进行调度操作；而kubelet只关心自己节点上的Pod列表。apiserver向etcd发起的watch是没有条件的，只能知道某个数据发生了变化或创建、删除，但不能过滤具体的值。也就是说对象数据的条件过滤必须在apiserver端而不是etcd端完成。

list是watch失败，数据太过陈旧后的弥补手段，这方面详见基于list-watch的Kubernetes异步事件处理框架详解-客户端部分。list本身是一个简单的列表操作，和其它apiserver的增删改操作一样，不再多描述细节。

watch的API处理

既然watch本身是一个apiserver提供的http restful的API，那么就按照API的方式去阅读它的代码，按照apiserver的基础功能实现一文所描述，我们来看它的代码，

关键的处理API注册代码pkg/apiserver/api_installer.go

func (a *APIInstaller) registerResourceHandlers(path string, storage rest.Storage,...

...
lister, isLister := storage.(rest.Lister)
watcher, isWatcher := storage.(rest.Watcher)                     ...(1)
...    
    case "LIST": // List all resources of a kind.                ...(2)
        doc := "list objects of kind " + kind
        if hasSubresource {
            doc = "list " + subresource + " of objects of kind " + kind
        }
        handler := metrics.InstrumentRouteFunc(action.Verb, resource, ListResource(lister, watcher, reqScope, false, a.minRequestTimeout)) ...(3)

一个rest.Storage对象会被转换为watcher和lister对象,提供list和watch服务的入口是同一个，在API接口中是通过 GET /pods?watch=true 这种方式来区分是list还是watch,API处理函数是由lister和watcher经过ListResource()合体后完成的。

那么就看看ListRe