controller-informer

本文详细介绍了Kubernetes中Informer的工作原理及其关键组件,包括Reflector、DeltaFIFO、Indexer等,并深入分析了其流程及如何避免处理过程中的阻塞问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

推翻了自己的三次理论,最终确定informer流程。自己梳理,有错请提示,以便及时改正
一、流程图

偷的图~在这里插入图片描述
偷的图~不想画图了
在这里插入图片描述

图1为整体流程,图2位细节流程
二、主要组件

  1. Reflector-负责与API-Server进行绑定
  2. Delta FIFO-增量先进先出队列
  3. Indexer-本地缓存
  4. ResourceEventHandler-可以注册EventHandler的client(用于回调)
  5. Work Queue-工作队列,负责用户处理
  6. Handler-用户的Handler,负责处理真正的业务逻辑

三、步骤解析

  1. informer分两步,一步为k8s内部处理,一步为Custom用户自行处理
  2. Reflector负责ListAndWatch与api-server连通。List短连接一次性获取所有最新版本的API对象,WATCH长链接“监听”API对象的变化
  3. 获取到的数据推入Delta FIFO队列中,并同时更新Indexer本地缓存数据(key=>val格式)
  4. 从Delta FIFO中pop一个数据,触发EventHandler回调,将key推送到Work Queue队列
  5. 从Work Queue中pop一个key,然后根据key去Indexer取到val。根据当前的EventHandler(增、删、更新)进行创建pod操作。
    四、细节分析
  6. 第3步和第4步,用了两个队列的原因,为了监听获取到的数据和用户处理数据时间不一致。导致用户时间处理过长,进而阻塞住Delta FIFO。导致崩死。分成两个队列处理解耦,”消费者“/”生产者“进行区分
  7. resync机制,该机制是通过定时(10分钟)读取本地缓存indexer并且list遍历,重新推到队列中,在触发EventHandler的update操作。为了用户端的回调失败或未执行,确保再次触发统一操作。会重新讲key推入到Delta FIFO中,逐步到达Work Queue后,通过判断新的(LIST过来的)和老的(曾经indexer中的)数据的版本号进行比对,如果相同则跳过,否则更新。该机制是为了确保Custom Controller在最后一步创建pod时失败。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值