P2-Controller与client-go

前言

K8s源码分析完整系列一键直达:k8s源码笔记-项目地址,若有帮助,欢迎star,谢谢~

Controller作为k8s的资源控制组件,必定要实时地监控对比资源的目标状态和当前状态,这其中会与apiserver产生大量的交互。在k8s中,k8s各个组件都会与apiServer交互,因此k8s在项目中封装了一个client-go公用模块,路径位于项目vendor/k8s.io/client-go,非常多的组件向ApiServer的curd操作都在client-go包中封装,client-go是k8s项目的核心包之一。它与controller的工作流程密不可分,在读controller源码理解其工作流程前,必须首先对informer有一定得了解,因此本篇专门对informer机制进行简单地介绍说明,为后面的文章铺垫。

ApiServer的连接方式

1.短连接

获取kubernetes某种资源的方式有多种,常见的如kubectl、调用apiserver restful api的接口,restful api接口详情查看官方手册。同时也可通过kubectl命令来查看操作对应的api,例如:

kubectl get pod POD_NAME -v=9

输出信息中会包含此操作对应的api url

但这种全量型的操作方式,在大集群规模下,开销还是比较大的,因此,k8s还提供长连接的watch接口。

2.长连接

watch接口是对list接口的一种改进,在调用watch接口后,首先会一次性返回list的数据,同时会保持会话连接,后续的接口对象的curd,都会产生事件由apiserver将变更数据推送给调用端,调用端接收数据后,再更新初始接收到的list的全量数据以及其他操作。

3.client-go

watch依然比较麻烦,毕竟list获取的数据以及后续watch到的数据,需要调用端在内部处理和更新缓存。索性,官方提供了一个client-go客户端工具包封装,里面提供多种apiserver相关操作,做到开箱即用,k8s各组件也都使用了它。

client-go工作模式

在client-go中,informer是对watch操作的一次再封装, Informer是一个带有本地缓存、索引功能的client端(list/watch),在绝大多数场景下,客户端与apiserver的交互都是读多写少的,因此,做好本地缓存(Store)和索引(Index)可以大幅减少开销提升性能。同时,informer可以注册相应的EventHandler事件触发器的,在执行资源更新后触发其他连锁操作。

工作流程图

流程图组件解释

图中有上下分层,上层逻辑由client-go内部封装,下层的逻辑由controller内部完成,对照上图分层说明:

上层

  • Reflector:反射器,调用 Kubernetes 的 List/Watch API,实现对 apiserver 指定类型对象的监控(List/Watch),将获取的数据,反序列化成对象实例,存入delta 缓存队列中;

  • DeltaIFIFO Queue:一个增量fifo缓存队列,接收来自 Reflector 传递的反序列化对象;

  • Informer:是这个流程中的关键重要的桥梁,主要有两个工作:1.从DeltaIFIFO Queue中获取对象,更新LocalStore的cache数据 2.触发后续的eventHandler,生成工作队列对象,加入WorkQueue,供后面的controller读取进行实际的控制处理工作。(值得注意的是,每一种资源都对应一个informer,多种资源对应多个informer,但每个informer都会与apiserver建立起一个watch长连接,通常controller都会使用SharedInformerFactory这个单例工厂模式,来使所有的informer的创建全部都经过这个单例工厂,从而保证每种资源对应的informer都是唯一且可复用的,以降低开销。)

  • LocalStore:informer 的 cache缓存,这里缓存的是从 apiserver 中获取得到的对象(其中有一部分可能还在DeltaFIFO 中没来得及放入缓存里来),此时client再查询对象的时候就直接从 cache 中查找,减少了 apiserver 的压力,LocalStore 只会被 Lister 的 List/Get 读操作的方法访问;

下层

  • ResourceEventHandler:由controller注册,由informer来触发,当resource object符合过滤规则时,触发ResourceEventHandler将其丢入WorkQueue内。

  • WorkQueue:informer更新本地的缓存后,会根据注册的相关EventHandler,生成事件放入WorkQueue内,Controller 接收 WorkQueue 中的事件,然后相应执行controller的业务逻辑,一般来说,就是保证资源对象的目标状态与实际状态达成一致的逻辑。

如果你想自定义controller,关于infomer的实践建议,参考这里:

如何用 client-go 拓展 Kubernetes 的 API

总结

本篇先简单介绍一下client-go包和controller组件的结合工作流程,为后面的几篇(deploymentCrontroller、statefulSetController)代码分析作铺垫,后面的文章会结合controller实例代码再仔细讲解细节。

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐