# IT明星不是夢 # 圖解kubernetes資源擴展機制實現(下)

昨天咱們介紹了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，同時落地本地磁盤，實現了完整的資源從感知到上報的總體流程的探測，其不足主要是在於關於資源實體的描述，從而致使資源的分配和資源的上報上有比較大的擴展性限制，好比要實現精細化的資源分配擴展，則不太能實現

k8s源碼閱讀電子書地址: https://www.yuque.com/baxiaoshi/tyado3