怎么分析kubelet中的Pod同步流程

怎么分析kubelet中的Pod同步流程，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

1.核心流程

kubelet最核心的功能就是根據master的指示，在節點上創建并管理pod。目前對于kubelet而言，有三種途徑來獲取所管理的pod清單：

• 文件 - 通過啟動參數–config指定配置目錄，定期檢查變更。

• HTTP Endpoint - 通過--manifest-url參數指定，定期檢查更新。

• API Server - 通過API Server監聽etcd目錄，實時同步pod清單。

通過API Server監聽Pod清單，并在節點上維護對應的Pod實例，這是整個kubelet進程的核心主流程。下圖近似描述了這個過程：

注意：在實際研究過程中，發現go語言實現的系統在調用邏輯上和Java/C++這些語言實現的系統有很大差異。go語言除了對象之間相互方法調用之外，還存在大量的goroutine間通過channel發送消息調用的情況。因此，從邏輯上來講，go語言的調用事實上是并發的，類似于網狀的。而不是傳統的同步調用，線性的關系。因此，感覺很難用UML圖來表示對象間的調用順序。上圖僅僅是把關鍵的對象及方法入口表示出來而已，而且有很多省略。當中如果有錯誤或更好的表述方式，也請告知作者。

2.核心結構及調用關系

2.1 Kubelet

/pkg/kubelet/kubelet.go文件中的Kubelet結構體是整個kubelet進程的核心數據結構，它持有了所有關聯的實體對象。Kubelet有兩個主要的入口方法：

• NewMainKubelet - 創建并初始化一個Kubelet結構（將所有關聯實例都初始化好）。

• Run - 啟動所有輔助的goroutines以及上文中提到的主流程。

在NewMainKubelet方法中，調用了一個makePodSourceConfig的私有方法，該方法會返回一個PodConfig對象指針。其中有一個field叫做updates chan kubetypes.PodUpdate，用于傳遞pod更新消息。

updates通道一邊連接著從三種來源獲取pod更新信息的goroutines。一邊被kubelet的主流程消費，即獲取pod更新信息，并同步操作Pod實例。

kubelet的主流程方法入口是Kubelet.syncLoopIteration，用于不斷分發updates通道中的消息。

2.2 PodWorkers

/pkg/kubelet/pod_workers.go文件中的podWorkers結構，是一個協程池。podWorkders會為每個pod單獨起一個goroutine，專門用于消費該pod相關的update信息，實施pod的操作。

podWorkers有兩個關鍵方法：

• UpdatePod - update入口，啟動并管理每個pod的update協程。

• managePodLoop - worker的實際邏輯，最終調用Kubelet.syncPod方法。

在managePodLoop每次Pod同步完成之后，會調用wrapUp方法。該方法用于周期性同步pod，即使沒有收到API Server推送的變更。

wrapUp方法會在podWorkers的workQueue中push下次發生同步的時間戳。同時kubelet.syncLoopIteration方法會周期性從podWorkers.workQueue中拉取當前時刻需要同步的pod列表，并觸發SyncPod操作。

2.3 kubeGenericRuntimeManager

在1、Kubelet關鍵模塊 文檔中有描述，該結構體實現了kubecontainer.Runtime接口，封裝了Container & Image相關的操作。

主流程中調用的是該結構體的SyncPod方法，它會計算出當前該Pod上所需要執行的操作，通過CRI接口執行。

2.4 dockerService & kubeDockerClient

dockershim中對CRI接口的實現，kubeGenericRuntimeManager和dockerService之間實際上通過gRPC來通訊。

kubeDockerClient是對libdocker.Interface接口的封裝，通過HTTP(s)和docker daemon通訊。

看完上述內容，你們掌握怎么分析kubelet中的Pod同步流程的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！