[阅读指南]
基于kubernetes 1.27 stage版本
为了方便阅读,后续所有代码均省略了错误处理及与关注逻辑无关的部分。
文章目录
- 关于client-go
- Informer是什么
- 为什么需要informer
- Informer工作流程
- 后续分析计划
关于client-go
client-go是kubernetes节点与服务端进行资源交互的客户端库,提供了非常多的功能与组件,用来与Kubernetes API 进行交互与操作。常见的功能有管理和同步kubernetes资源、管理本地kubernetes资源缓存、认证和授权等。
Informer是什么
Informer 是一种建立在client-上的资源同步和事件监听的机制。它可以监控集群中的资源变化,并在资源发生变化时触发事件通知。他用到了Informer 通过与 Kubernetes API Server 进行交互,获取资源的最新状态,再将这些状态同步到本地缓存中。
为什么需要informer
当涉及大规模、高性能的系统时,直接与 API Server 通信可能会导致一些挑战和性能问题,而 Informer 的引入可以有效地减少 API Server 的压力,降低网络开销,实现响应式事件监听,提高应用程序的性能和响应速度,以及处理资源同步和冲突问题。这使得系统更加高效、稳定和可靠。
举个栗子。公司举办团建,如果通过私聊每个人来通知活动地点和活动,需要花费非常多的时间和精力。而将参与活动的人拉群并发一条公告,就能快速地同步团建信息了。informer就像是给clients拉了个群,将api-server的信息通过公告进行同步。
Informer工作流程
informer用到client-go的几个关键组件
reflecter
负责监听特定的kubernetes资源变化事件。informer
负责从delta FIFO队列中取出资源变化事件,并进行缓存与索引的操作。indexer
负责管理存储资源对象的索引。custom controller
根据资源变化实现本地节点的一些管理操作,本地的kubernetes应用可以通过实现controller监控服务端资源的变化。
下面的图介绍了各个模块之间是怎么交互和工作的。
根据这个关系图,可以了解到客户端的整个资源同步流程。简单地看就是如下几步,
- reflecter通过list/watch方法监听kubernetes api的资源变化 ->
1
- reflecter将监听到的资源变化对象添加到fifo队列中 ->
2
- informer从队列取出资源变化对象,并将取出的对象同步到本地缓存 ->
3,4,5
- 同步缓存时,也会将资源对象回调至custom handler ->
6
- custom handler将资源对象加入到workqueue中等待处理 ->
7
- work进程从workqueue中取出资源对象,再进行额外的处理操作 ->
8,9
后续分析计划
后续将会按照这个同步流程的顺序来详细分析每个模块的代码和设计逻辑。
分析计划:
- Informer
- Refletor
- Resync机制
- DeltaFIFO
- Indexer
- Informer
- stream list VS list