Client-go之Informer机制初探

Client-go之Informer机制初探

在这里插入图片描述

启航

本篇将开始我的源码剖析之路,先会讲client-go中的一些经典的机制和代码,然后讲一些我是用client-go中的一些小示例。最后开始读k8s scheduler源码。

背景

在k8s系统中,组件之间仅通过Http协议进行通信,没有中间件,其实蛮好奇k8s内部通信是如何保证消息实时性、可靠性和顺序性的,实现这些性能的关键在于Informer机制,Informer机制中的ListAndWatch、DeltaFIFO队列和Indexer等对于实现以上特性非常重要。下面这张图就是Informer机制运行原理图:
在这里插入图片描述

简要概述:上图涉及了Informer机制中的几个重要概念:controller,reflector,DeltaFIFO和Indexer。后面的文章会着重介绍这几个组件的源码设计。那我们说说Informer机制的流程是啥?起点是自定义的Controller,Controller会通过ListAndWatch机制从apiserver获取感兴趣的资源对象信息(初始化controller时,会指定感兴趣资源对象的List和watch方法)。controller的内部包含了reflector和DeltaFIFO,controller就是通过reflector中的list和watch将资源对象信息装入DeltaFIFO队列,然后Controller会一直尝试从队列中pop数据,并根据数据中对象的操作类型作事件通知给各Listener并将资源对象存入本地存储Indexer中。在Informer架构中的和信息组件将在下面进行介绍:

Reflector

Reflector用于监控(watch)指定的k8s资源,当监控的资源发生变化时触发相应的变更事件,例如Add事件、Update事件和Delete事件,并将资源对象的增量放入DeltaFIFO队列中。

DeltaFIFO队列

DeltaFIFO可以分开理解,FIFO是先进先出队列,它拥有队列操作的方法,而Delta是一个资源对象的增量,他可以保存资源对象的操作类型,例如Add操作类型等

Indexer

Indexer是client-go中用来存储资源对象并自带索引功能的本地存储,Refelctor从DeltaFIFO中消费出资源对象然后存储进Indexer中。Indexer中资源对象的存储与Etcd中是一致的。client-go可以方便的从本地存储中读取资源对象,而不必请求apiserver,以减轻apiserver和etcd集群的压力(k8s中把资源对象数据存在etcd的)。

总结

本篇是Innformer机制的开篇,主要介绍Informer机制的主要流程,对于其中的核心过程,后面几篇文章会有详细源码解析的过程,敬请期待。

猜你喜欢

转载自blog.csdn.net/u013276277/article/details/108576227