推翻了自己的三次理论,最终确定informer流程。自己梳理,有错请提示,以便及时改正
一、流程图
偷的图~
偷的图~不想画图了
图1为整体流程,图2位细节流程
二、主要组件
- Reflector-负责与API-Server进行绑定
- Delta FIFO-增量先进先出队列
- Indexer-本地缓存
- ResourceEventHandler-可以注册EventHandler的client(用于回调)
- Work Queue-工作队列,负责用户处理
- Handler-用户的Handler,负责处理真正的业务逻辑
三、步骤解析
- informer分两步,一步为k8s内部处理,一步为Custom用户自行处理
- Reflector负责ListAndWatch与api-server连通。List短连接一次性获取所有最新版本的API对象,WATCH长链接“监听”API对象的变化
- 获取到的数据推入Delta FIFO队列中,并同时更新Indexer本地缓存数据(key=>val格式)
- 从Delta FIFO中pop一个数据,触发EventHandler回调,将key推送到Work Queue队列
- 从Work Queue中pop一个key,然后根据key去Indexer取到val。根据当前的EventHandler(增、删、更新)进行创建pod操作。
四、细节分析 - 第3步和第4步,用了两个队列的原因,为了监听获取到的数据和用户处理数据时间不一致。导致用户时间处理过长,进而阻塞住Delta FIFO。导致崩死。分成两个队列处理解耦,”消费者“/”生产者“进行区分
- resync机制,该机制是通过定时(10分钟)读取本地缓存indexer并且list遍历,重新推到队列中,在触发EventHandler的update操作。为了用户端的回调失败或未执行,确保再次触发统一操作。会重新讲key推入到Delta FIFO中,逐步到达Work Queue后,通过判断新的(LIST过来的)和老的(曾经indexer中的)数据的版本号进行比对,如果相同则跳过,否则更新。该机制是为了确保Custom Controller在最后一步创建pod时失败。