簡介
從官方的架構(gòu)圖中很容易就能找到 kubelet
執(zhí)行 kubelet -h 看到 kubelet 的功能介紹：
- kubelet 是每個 Node 節(jié)點上都運行的主要“節(jié)點代理”。使用如下的一個向 apiserver 注冊 Node 節(jié)點：主機的 hostname；覆蓋 host 的參數(shù)；或者云提供商指定的邏輯。
- kubelet 基于 PodSpec 工作。PodSpec 是用 YAML 或者 JSON 對象來描述 Pod。Kubelet 接受通過各種機制（主要是 apiserver）提供的一組 PodSpec，并確保里面描述的容器良好運行。
除了由 apiserver 提供 PodSpec，還可以通過以下方式提供： - 文件
- HTTP 端點
-
HTTP 服務(wù)器
kubelet 功能歸納一下就是上報 Node 節(jié)點信息，和管理（創(chuàng)建、銷毀）Pod。 功能看似簡單，實際不然。每一個點拿出來都需要很大的篇幅來講，比如 Node 節(jié)點的計算資源，除了傳統(tǒng)的 CPU、內(nèi)存、硬盤，還提供擴展來支持類似 GPU 等資源；Pod 不僅僅有容器，還有相關(guān)的網(wǎng)絡(luò)、安全策略等。
截圖 2024-07-23 09-39-36.png
架構(gòu)
kubelet 的架構(gòu)由 N 多的組件組成，下面簡單介紹下比較重要的幾個：
PLEG
即 Pod Lifecycle Event Generator，字面意思 Pod 生命周期事件（ContainerStarted、ContainerDied、ContainerRemoved、ContainerChanged）生成器。
其維護(hù)著 Pod 緩存；定期通過 ContainerRuntime 獲取 Pod 的信息，與緩存中的信息比較，生成如上的事件；將事件寫入其維護(hù)的通道（channel）中。
PodWorkers
處理事件中 Pod 的同步。核心方法 managePodLoop() 間接調(diào)用 kubelet.syncPod() 完成 Pod 的同步：
如果 Pod 正在被創(chuàng)建，記錄其延遲
生成 Pod 的 API Status，即
v1.PodStatus：從運行時的 status 轉(zhuǎn)換成 api status記錄 Pod 從
pending到running的耗時在
StatusManager中更新 pod 的狀態(tài)殺掉不應(yīng)該運行的 Pod
如果網(wǎng)絡(luò)插件未就緒，只啟動使用了主機網(wǎng)絡(luò)（host network）的 Pod
如果 static pod 不存在，為其創(chuàng)建鏡像（Mirror）Pod
為 Pod 創(chuàng)建文件系統(tǒng)目錄：Pod 目錄、卷目錄、插件目錄
使用
VolumeManager為 Pod 掛載卷獲取 image pull secrets
調(diào)用容器運行時（container runtime）的
#SyncPod()方法
PodManager
存儲 Pod 的期望狀態(tài)，kubelet 服務(wù)的不同渠道的 Pod
StatusProvider
提供節(jié)點和容器的統(tǒng)計信息，有 cAdvisor 和 CRI 兩種實現(xiàn)。
ContainerRuntime
顧名思義，容器運行時。與遵循 CRI 規(guī)范的高級容器運行時進(jìn)行交互。
Deps.PodConfig
PodConfig 是一個配置多路復(fù)用器，它將許多 Pod 配置源合并成一個單一的一致結(jié)構(gòu)，然后按順序向監(jiān)聽器傳遞增量變更通知。
配置源有：文件、apiserver、HTTP
syncloop
接收來自 PodConfig 的 Pod 變更通知、定時任務(wù)、PLEG 的事件，以及 ProbeManager 的事件，將 Pod 同步到期望狀態(tài)。
PodAdmitHandlers
Pod admission 過程中調(diào)用的一系列處理器，比如 eviction handler（節(jié)點內(nèi)存有壓力時，不會驅(qū)逐 QoS 設(shè)置為 BestEffort 的 Pod）、shutdown admit handler（當(dāng)節(jié)點關(guān)閉時，不處理 pod 的同步操作）等。
OOMWatcher
從系統(tǒng)日志中獲取容器的 OOM 日志，將其封裝成事件并記錄。
VolumeManager
VolumeManager 運行一組異步循環(huán)，根據(jù)在此節(jié)點上調(diào)度的 pod 確定需要附加/掛載/卸載/分離哪些卷并執(zhí)行操作。
CertificateManager
處理證書輪換。
ProbeManager
實際上包含了三種 Probe，提供 probe 結(jié)果緩存和通道。
LivenessManager
ReadinessManager
StartupManager
EvictionManager
監(jiān)控 Node 節(jié)點的資源占用情況，根據(jù)驅(qū)逐規(guī)則驅(qū)逐 Pod 釋放資源，緩解節(jié)點的壓力。
PluginManager
PluginManager 運行一組異步循環(huán)，根據(jù)此節(jié)點確定哪些插件需要注冊/取消注冊并執(zhí)行。如 CSI 驅(qū)動和設(shè)備管理器插件（Device Plugin）。
CSI
Container Storage Interface，由存儲廠商實現(xiàn)的存儲驅(qū)動。
DevicePlugin
Kubernetes 提供了一個 設(shè)備插件框架，你可以用它來將系統(tǒng)硬件資源發(fā)布到 Kubelet。
供應(yīng)商可以實現(xiàn)設(shè)備插件，由你手動部署或作為 DaemonSet 來部署，而不必定制 Kubernetes 本身的代碼。目標(biāo)設(shè)備包括 GPU、高性能 NIC、FPGA、 InfiniBand 適配器以及其他類似的、可能需要特定于供應(yīng)商的初始化和設(shè)置的計算資源。
生命周期事件生成器PLEG
對于 Pod來說，Kubelet 會從多個數(shù)據(jù)來源（api、file以及http） watch Pod spec 中的變化。對于容器來說，Kubelet 會定期輪詢?nèi)萜鬟\行時，以獲取所有容器的最新狀態(tài)。隨著 Pod 和容器數(shù)量的增加，輪詢會產(chǎn)生較大開銷，帶來的周期性大量并發(fā)請求會導(dǎo)致較高的 CPU 使用率峰值，降低節(jié)點性能，從而降低節(jié)點的可靠性。為了降低 Pod 的管理開銷，提升 Kubelet 的性能和可擴展性，引入了 PLEG（Pod Lifecycle Event Generator）。改進(jìn)了之前的工作方式：
減少空閑期間的不必要工作(例如 Pod 的定義和容器的狀態(tài)沒有發(fā)生更改)。
減少獲取容器狀態(tài)的并發(fā)請求數(shù)量。
為了進(jìn)一步降低損耗，社區(qū)推出了基于event實現(xiàn)的PLEG，當(dāng)然也需要CRI運行時支持。
它定期檢查節(jié)點上 Pod 運行情況，如果發(fā)現(xiàn)感興趣的變化，PLEG 就會把這種變化包 裝成 Event 發(fā)送給 Kubelet 的主同步機制 syncLoop 去處理。
syncLoop
Kubelet啟動后通過syncLoop進(jìn)入到主循環(huán)處理Node上Pod Changes事件，監(jiān)聽來自file,apiserver,http三類的事件并匯聚到kubetypes.PodUpdate Channel（Config Channel）中，由syncLoopIteration不斷從kubetypes.PodUpdate Channel中消費。
