确立目标
理解Informer的数据存储方式 大致理解Pod的分配流程理解Informer的数据存储方式 代码在k8s.io/client-go/tools/cache/controller
Process 查看消费的过程
Index 掌握Index数据结构
Index 的定义为资源的本地存储,保持与etcd中的资源信息一致。
distribute 信息的分发distribute
理解一个pod的被调度的大致流程
Scheduler
在前面,我们了解了Pod调度算法的注册和Informer机制来监听kube-apiserver上的资源变化,这一次,我们就将两者串联起来,看看在kube-scheduler中,Informer监听到资源变化后,如何用调度算法将pod进行调度。
SchedulingQueue
scheduleOne
ScheduleResult 调度计算结果
Assume 初步推算
Bind 实际绑定
Update To Etcd
站在前人的肩膀上,向前辈致敬,Respect!
Summary
Informer 依赖于 Reflector 模块,它有个组件为 xxxInformer,如 podInformer 具体资源的 Informer 包含了一个连接到kube-apiserver的client,通过List和Watch接口查询资源变更情况
检测到资源发生变化后,通过Controller 将数据放入队列DeltaFIFOQueue里,生产阶段完成
在DeltaFIFOQueue的另一端,有消费者在不停地处理资源变化的事件,处理逻辑主要分2步
将数据保存到本地存储Indexer,它的底层实现是一个并发安全的threadSafeMap 有些组件需要实时关注资源变化,会实时监听listen,就将事件分发到对应注册上来的listener上,自行处理distribute将object分发到同步监听或者普通监听的列表,然后被对应的handler处理
Pod的调度是通过一个队列SchedulingQueue异步工作的 监听到对应pod事件后,放入队列 有个消费者从队列中获取pod,进行调度单个pod的调度主要分为3个步骤:
根据Predict和Priority两个阶段,调用各自的算法插件,选择最优的Node Assume这个Pod被调度到对应的Node,保存到cache,加锁保证一致性。 用extender和plugins进行验证,如果通过则绑定Bind绑定成功后,将数据通过client向kube-apiserver发送,更新etcd
以上就是Kubernetes Informer数据存储Index与Pod分配流程解析的详细内容,更多关于Kubernetes Informer数据存储的资料请关注服务器之家其它相关文章!
原文链接:https://juejin.cn/post/7156895285996683295