一、概要

kubelet 是運行在每個節(jié)點上的主要的“節(jié)點代理”，每個節(jié)點都會啟動 kubelet進程，用來處理 Master 節(jié)點下發(fā)到本節(jié)點的任務，按照 PodSpec 描述來管理Pod 和其中的容器（PodSpec 是用來描述一個 pod 的 YAML 或者 JSON 對象）。

kubelet 通過各種機制（主要通過 apiserver ）獲取一組 PodSpec 并保證在這些 PodSpec 中描述的容器健康運行。

二、kubelet 的主要功能

1、kubelet 默認監(jiān)聽四個端口，分別為 10250 、10255、10248、4194。

LISTEN 0 128 *:10250 *:* users:(("kubelet",pid=48500,fd=28)) LISTEN 0 128 *:10255 *:* users:(("kubelet",pid=48500,fd=26)) LISTEN 0 128 *:4194 *:* users:(("kubelet",pid=48500,fd=13)) LISTEN 0 128 127.0.0.1:10248 *:* users:(("kubelet",pid=48500,fd=23))

• 10250（kubelet API）：kubelet server 與 apiserver 通信的端口，定期請求 apiserver 獲取自己所應當處理的任務，通過該端口可以訪問獲取 node 資源以及狀態(tài)。
• 10248（健康檢查端口）：通過訪問該端口可以判斷 kubelet 是否正常工作, 通過 kubelet 的啟動參數(shù) --healthz-port 和 --healthz-bind-address 來指定監(jiān)聽的地址和端口。

$ curl http://127.0.0.1:10248/healthzok

• 4194（cAdvisor 監(jiān)聽）：kublet 通過該端口可以獲取到該節(jié)點的環(huán)境信息以及 node 上運行的容器狀態(tài)等內容，訪問 http://localhost:4194 可以看到 cAdvisor 的管理界面,通過 kubelet 的啟動參數(shù) --cadvisor-port 可以指定啟動的端口。

$ curl http://127.0.0.1:4194/metrics

• 10255 （readonly API）：提供了 pod 和 node 的信息，接口以只讀形式暴露出去，訪問該端口不需要認證和鑒權。

// 獲取 pod 的接口，與 apiserver 的 // http://127.0.0.1:8080/api/v1/pods?fieldSelector=spec.nodeName= 接口類似$ curl http://127.0.0.1:10255/pods// 節(jié)點信息接口,提供磁盤、網(wǎng)絡、CPU、內存等信息$ curl http://127.0.0.1:10255/spec/

2、kubelet 主要功能：

• pod 管理：kubelet 定期從所監(jiān)聽的數(shù)據(jù)源獲取節(jié)點上 pod/container 的期望狀態(tài)（運行什么容器、運行的副本數(shù)量、網(wǎng)絡或者存儲如何配置等等），并調用對應的容器平臺接口達到這個狀態(tài)。
• 容器健康檢查：kubelet 創(chuàng)建了容器之后還要查看容器是否正常運行，如果容器運行出錯，就要根據(jù) pod 設置的重啟策略進行處理。
• 容器監(jiān)控：kubelet 會監(jiān)控所在節(jié)點的資源使用情況，并定時向 master 報告，資源使用數(shù)據(jù)都是通過 cAdvisor 獲取的。知道整個集群所有節(jié)點的資源情況，對于 pod 的調度和正常運行至關重要。

三、kubelet 組件中的模塊

上圖展示了 kubelet 組件中的模塊以及模塊間的劃分。

• 1、PLEG(Pod Lifecycle Event Generator） PLEG 是 kubelet 的核心模塊,PLEG 會一直調用 container runtime 獲取本節(jié)點 containers/sandboxes 的信息，并與自身維護的 pods cache 信息進行對比，生成對應的 PodLifecycleEvent，然后輸出到 eventChannel 中，通過 eventChannel 發(fā)送到 kubelet syncLoop 進行消費，然后由 kubelet syncPod 來觸發(fā) pod 同步處理過程，最終達到用戶的期望狀態(tài)。
• 2、cAdvisor cAdvisor（https://github.com/google/cadvisor）是 google 開發(fā)的容器監(jiān)控工具，集成在 kubelet 中，起到收集本節(jié)點和容器的監(jiān)控信息，大部分公司對容器的監(jiān)控數(shù)據(jù)都是從 cAdvisor 中獲取的 ，cAvisor 模塊對外提供了 interface 接口，該接口也被 imageManager，OOMWatcher，containerManager 等所使用。
• 3、OOMWatcher 系統(tǒng) OOM 的監(jiān)聽器，會與 cadvisor 模塊之間建立 SystemOOM,通過 Watch方式從 cadvisor 那里收到的 OOM 信號，并產(chǎn)生相關事件。
• 4、probeManager probeManager 依賴于 statusManager,livenessManager,containerRefManager，會定時去監(jiān)控 pod 中容器的健康狀況，當前支持兩種類型的探針：livenessProbe 和readinessProbe。 livenessProbe：用于判斷容器是否存活，如果探測失敗，kubelet 會 kill 掉該容器，并根據(jù)容器的重啟策略做相應的處理。 readinessProbe：用于判斷容器是否啟動完成，將探測成功的容器加入到該 pod 所在 service 的 endpoints 中，反之則移除。readinessProbe 和 livenessProbe 有三種實現(xiàn)方式：http、tcp 以及 cmd。
• 5、statusManager statusManager 負責維護狀態(tài)信息，并把 pod 狀態(tài)更新到 apiserver，但是它并不負責監(jiān)控 pod 狀態(tài)的變化，而是提供對應的接口供其他組件調用，比如 probeManager。
• 6、containerRefManager 容器引用的管理，相對簡單的Manager，用來報告容器的創(chuàng)建，失敗等事件，通過定義 map 來實現(xiàn)了 containerID 與 v1.ObjectReferece 容器引用的映射。
• 7、evictionManager 當節(jié)點的內存、磁盤或 inode 等資源不足時，達到了配置的 evict 策略， node 會變?yōu)?pressure 狀態(tài)，此時 kubelet 會按照 qosClass 順序來驅趕 pod，以此來保證節(jié)點的穩(wěn)定性。可以通過配置 kubelet 啟動參數(shù) --eviction-hard= 來決定 evict 的策略值。
• 8、imageGC imageGC 負責 node 節(jié)點的鏡像回收，當本地的存放鏡像的本地磁盤空間達到某閾值的時候，會觸發(fā)鏡像的回收，刪除掉不被 pod 所使用的鏡像，回收鏡像的閾值可以通過 kubelet 的啟動參數(shù) --image-gc-high-threshold 和 --image-gc-low-threshold 來設置。
• 9、containerGC containerGC 負責清理 node 節(jié)點上已消亡的 container，具體的 GC 操作由runtime 來實現(xiàn)。
• 10、imageManager 調用 kubecontainer 提供的PullImage/GetImageRef/ListImages/RemoveImage/ImageStates 方法來保證pod 運行所需要的鏡像。
• 11、volumeManager 負責 node 節(jié)點上 pod 所使用 volume 的管理，volume 與 pod 的生命周期關聯(lián)，負責 pod 創(chuàng)建刪除過程中 volume 的 mount/umount/attach/detach 流程，kubernetes 采用 volume Plugins 的方式，實現(xiàn)存儲卷的掛載等操作，內置幾十種存儲插件。
• 12、containerManager 負責 node 節(jié)點上運行的容器的 cgroup 配置信息，kubelet 啟動參數(shù)如果指定 --cgroups-per-qos 的時候，kubelet 會啟動 goroutine 來周期性的更新 pod 的 cgroup 信息，維護其正確性，該參數(shù)默認為 true，實現(xiàn)了 pod 的Guaranteed/BestEffort/Burstable 三種級別的 Qos。
• 13、runtimeManager containerRuntime 負責 kubelet 與不同的 runtime 實現(xiàn)進行對接，實現(xiàn)對于底層 container 的操作，初始化之后得到的 runtime 實例將會被之前描述的組件所使用。可以通過 kubelet 的啟動參數(shù) --container-runtime 來定義是使用docker 還是 rkt，默認是 docker。
• 14、podManager podManager 提供了接口來存儲和訪問 pod 的信息，維持 static pod 和 mirror pods 的關系，podManager 會被statusManager/volumeManager/runtimeManager 所調用，podManager 的接口處理流程里面會調用 secretManager 以及 configMapManager。

在 v1.12 中，kubelet 組件有18個 manager：

certificateManager cgroupManager containerManager cpuManager nodeContainerManager configmapManager containerReferenceManager evictionManager nvidiaGpuManager imageGCManager kuberuntimeManager hostportManager podManager proberManager secretManager statusManager volumeManager tokenManager

其中比較重要的模塊后面會進行一一分析。

參考：

微軟資深工程師詳解 K8S 容器運行時

kubernetes 簡介： kubelet 和 pod Kubelet 組件解析

總結

以上是生活随笔為你收集整理的kubelet启动失败_kubelet 架构浅析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。