怎么分析kubelet中的Pod同步流程，相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

任丘網(wǎng)站制作公司哪家好，找成都創(chuàng)新互聯(lián)公司！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、APP開(kāi)發(fā)、響應(yīng)式網(wǎng)站等網(wǎng)站項(xiàng)目制作，到程序開(kāi)發(fā)，運(yùn)營(yíng)維護(hù)。成都創(chuàng)新互聯(lián)公司成立于2013年到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來(lái)保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選成都創(chuàng)新互聯(lián)公司。

1.核心流程

kubelet最核心的功能就是根據(jù)master的指示，在節(jié)點(diǎn)上創(chuàng)建并管理pod。目前對(duì)于kubelet而言，有三種途徑來(lái)獲取所管理的pod清單：

• 文件 - 通過(guò)啟動(dòng)參數(shù)–config指定配置目錄，定期檢查變更。

• HTTP Endpoint - 通過(guò)--manifest-url參數(shù)指定，定期檢查更新。

• API Server - 通過(guò)API Server監(jiān)聽(tīng)etcd目錄，實(shí)時(shí)同步pod清單。

通過(guò)API Server監(jiān)聽(tīng)Pod清單，并在節(jié)點(diǎn)上維護(hù)對(duì)應(yīng)的Pod實(shí)例，這是整個(gè)kubelet進(jìn)程的核心主流程。下圖近似描述了這個(gè)過(guò)程：

注意：在實(shí)際研究過(guò)程中，發(fā)現(xiàn)go語(yǔ)言實(shí)現(xiàn)的系統(tǒng)在調(diào)用邏輯上和Java/C++這些語(yǔ)言實(shí)現(xiàn)的系統(tǒng)有很大差異。go語(yǔ)言除了對(duì)象之間相互方法調(diào)用之外，還存在大量的goroutine間通過(guò)channel發(fā)送消息調(diào)用的情況。因此，從邏輯上來(lái)講，go語(yǔ)言的調(diào)用事實(shí)上是并發(fā)的，類似于網(wǎng)狀的。而不是傳統(tǒng)的同步調(diào)用，線性的關(guān)系。因此，感覺(jué)很難用UML圖來(lái)表示對(duì)象間的調(diào)用順序。上圖僅僅是把關(guān)鍵的對(duì)象及方法入口表示出來(lái)而已，而且有很多省略。當(dāng)中如果有錯(cuò)誤或更好的表述方式，也請(qǐng)告知作者。

2.核心結(jié)構(gòu)及調(diào)用關(guān)系

2.1 Kubelet

/pkg/kubelet/kubelet.go文件中的Kubelet結(jié)構(gòu)體是整個(gè)kubelet進(jìn)程的核心數(shù)據(jù)結(jié)構(gòu)，它持有了所有關(guān)聯(lián)的實(shí)體對(duì)象。Kubelet有兩個(gè)主要的入口方法：

• NewMainKubelet - 創(chuàng)建并初始化一個(gè)Kubelet結(jié)構(gòu)（將所有關(guān)聯(lián)實(shí)例都初始化好）。

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

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

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

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

2.2 PodWorkers

/pkg/kubelet/pod_workers.go文件中的podWorkers結(jié)構(gòu)，是一個(gè)協(xié)程池。podWorkders會(huì)為每個(gè)pod單獨(dú)起一個(gè)goroutine，專門用于消費(fèi)該pod相關(guān)的update信息，實(shí)施pod的操作。

podWorkers有兩個(gè)關(guān)鍵方法：

• UpdatePod - update入口，啟動(dòng)并管理每個(gè)pod的update協(xié)程。

• managePodLoop - worker的實(shí)際邏輯，最終調(diào)用Kubelet.syncPod方法。

在managePodLoop每次Pod同步完成之后，會(huì)調(diào)用wrapUp方法。該方法用于周期性同步pod，即使沒(méi)有收到API Server推送的變更。

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

2.3 kubeGenericRuntimeManager

在1、Kubelet關(guān)鍵模塊 文檔中有描述，該結(jié)構(gòu)體實(shí)現(xiàn)了kubecontainer.Runtime接口，封裝了Container & Image相關(guān)的操作。

主流程中調(diào)用的是該結(jié)構(gòu)體的SyncPod方法，它會(huì)計(jì)算出當(dāng)前該P(yáng)od上所需要執(zhí)行的操作，通過(guò)CRI接口執(zhí)行。

2.4 dockerService & kubeDockerClient

dockershim中對(duì)CRI接口的實(shí)現(xiàn)，kubeGenericRuntimeManager和dockerService之間實(shí)際上通過(guò)gRPC來(lái)通訊。

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

看完上述內(nèi)容，你們掌握怎么分析kubelet中的Pod同步流程的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！