标签：

昨天我们介绍了k8s中资源插件机制的核心关键组件，今天我们继续来看下各个组件是如何进行通信的，，以及k8s中针对事件措置惩罚惩罚背后的关键设计

1.PluginManager

PluginManager是一个上层组件，其内部包罗了上篇文章中的关键组件，并且协调其内部数据流，而且还供给针对差别插件的具体的控制器

1.1 核心数据布局

核心布局里面其实就是凭据数据流来进行设计的，首先需要一个感知插件desiredStateOfWorldPopulator用于感知后端处事的创建或者删除，然后将感知到的事件插手到desiredStateOfWorld期望状态缓存，由reconciler卖力期进行底层的注册和下线，并且将功效存储到actualStateOfWorld实际状态缓存

type pluginManager struct { // 插件感知 desiredStateOfWorldPopulator *pluginwatcher.Watcher // 协调器插件 reconciler reconciler.Reconciler // 实际状态缓存 actualStateOfWorld cache.ActualStateOfWorld // 期望状态缓存 desiredStateOfWorld cache.DesiredStateOfWorld } 1.2 初始化

初始化中会将dsw和asw都交给reconciler用于进行事件的感知和更新对应的缓存

func NewPluginManager( sockDir string, recorder record.EventRecorder) PluginManager { asw := cache.NewActualStateOfWorld() dsw := cache.NewDesiredStateOfWorld() // 这里会将期望状态缓存和实际状态缓存，都交给reconciler reconciler := reconciler.NewReconciler( operationexecutor.NewOperationExecutor( operationexecutor.NewOperationGenerator( recorder, ), ), loopSleepDuration, dsw, asw, ) pm := &pluginManager{ // 启动一个watcher并且存储dsw期望状态缓存，后续reconciler就可以通过dsw感知到新的状态了 desiredStateOfWorldPopulator: pluginwatcher.NewWatcher( sockDir, dsw, ), reconciler: reconciler, desiredStateOfWorld: dsw, actualStateOfWorld: asw, } return pm } 1.3 启动插件打点器

插件打点器启动其实就是启动内部的desiredStateOfWorldPopulator就会讲watcher感知的事件，不停的改削本身的内部缓存这样reconciler就可以不停的通过期望状态缓存，进行对应grpc的挪用从而满足期望状态

func (pm *pluginManager) Run(sourcesReady config.SourcesReady, stopCh <-chan struct{}) { defer runtime.HandleCrash() // 运行期望状态缓存，其实主要是通过watcher感知到的事件，改削自身的缓存 // 后续reconciler会周期性的获取 pm.desiredStateOfWorldPopulator.Start(stopCh) klog.V(2).Infof("The desired_state_of_world populator (plugin watcher) starts") klog.Infof("Starting Kubelet Plugin Manager") // 周期性的运行校证数据 go pm.reconciler.Run(stopCh) metrics.Register(pm.actualStateOfWorld, pm.desiredStateOfWorld) <-stopCh klog.Infof("Shutting down Kubelet Plugin Manager") } 1.4 控制器注册

控制器其实主要是指的reconciler通过比拟期望缓存和实际缓存之间的差异，孕育产生对应的事件之后，针对该类型的插件，后续的措置惩罚惩罚流程是什么，好比注册/下线具体的grpc接口和对应插件类型的措置惩罚惩罚机制

func (pm *pluginManager) AddHandler(pluginType string, handler cache.PluginHandler) { pm.reconciler.AddHandler(pluginType, handler) } 1.5 CSI与普通设备

当前的kubelet中有注册两种类型的插件控制器，CSI与DEVICPLUGIn，从名字上大家也能知道概略的意思

kl.pluginManager.AddHandler(pluginwatcherapi.CSIPlugin, plugincache.PluginHandler(csi.PluginHandler)) kl.pluginManager.AddHandler(pluginwatcherapi.DevicePlugin, kl.containerManager.GetPluginRegistrationHandler()) 2. PluginHandler

这里我们只介绍一个即DevicePlugin的核心实现机制

2.1 Endpoint

Endpoint其实指的就是某个供给扩展资源的处事，在之前说的reconciler中，会获取其对应的grpc处事的地点，后续则会直接挪用grpc进行通信

Endpoint需要感知对应的资源设备的变革，同时将对应的设备信息，回调通知给当前的

2.2 Manager

Manager则是主要卖力实现后端真正的Register/UnRegister的具体实现，其在内部会为每个Device创建一个Endpoint并卖力收集后端供给资源处事上报上来的信息, 最终会讲对应的信息发送给kubelet,然后由kubelet在卖力节点信息更新的时候，将信息通报给APIServer

2.3 Checkpoint

Checkpoint机制其实在很多系统中都对照常用，主要是用于周期性的将内存中的数据序列化存储到本地的磁盘中，在后续恢复的时候，会通过磁盘从头加载之前的数据，从而实现内存资源的快速恢复

扩展资源的整体实现流程概略就是这个样子，从如何感知数据，注册资源处事，获取资源处事的资源信息，并最终陈述请示给kubelet，同时落地本地磁盘，实现了完整的资源从感知到上报的整体流程的探测，其不敷主要是在于关于资源实体的描述，从而导致资源的分配和资源的上报上有对照大的扩展性限制，好比要实现精细化的资源分配扩展，则不太能实现