一、概要
kubelet 是運(yùn)行在每個(gè)節(jié)點(diǎn)上的主要的“節(jié)點(diǎn)代理”，每個(gè)節(jié)點(diǎn)都會(huì)啟動(dòng) kubelet進(jìn)程，用來處理 Master 節(jié)點(diǎn)下發(fā)到本節(jié)點(diǎn)的任務(wù)，按照 PodSpec 描述來管理Pod 和其中的容器（PodSpec 是用來描述一個(gè) pod 的 YAML 或者 JSON 對(duì)象）。
kubelet 通過各種機(jī)制（主要通過 apiserver ）獲取一組 PodSpec 并保證在這些 PodSpec 中描述的容器健康運(yùn)行。
二、kubelet 的主要功能
1、kubelet 默認(rèn)監(jiān)聽四個(gè)端口，分別為 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 通信的端口，定期請(qǐng)求 apiserver 獲取自己所應(yīng)當(dāng)處理的任務(wù)，通過該端口可以訪問獲取 node 資源以及狀態(tài)。
10248（健康檢查端口）：通過訪問該端口可以判斷 kubelet 是否正常工作, 通過 kubelet 的啟動(dòng)參數(shù)
--healthz-port和--healthz-bind-address來指定監(jiān)聽的地址和端口。
$ curl http://127.0.0.1:10248/healthz
ok
- 4194（cAdvisor 監(jiān)聽）：kublet 通過該端口可以獲取到該節(jié)點(diǎn)的環(huán)境信息以及 node 上運(yùn)行的容器狀態(tài)等內(nèi)容，訪問 http://localhost:4194 可以看到 cAdvisor 的管理界面,通過 kubelet 的啟動(dòng)參數(shù)
--cadvisor-port可以指定啟動(dòng)的端口。
$ curl http://127.0.0.1:4194/metrics
- 10255 （readonly API）：提供了 pod 和 node 的信息，接口以只讀形式暴露出去，訪問該端口不需要認(rèn)證和鑒權(quán)。
// 獲取 pod 的接口，與 apiserver 的
// http://127.0.0.1:8080/api/v1/pods?fieldSelector=spec.nodeName= 接口類似
$ curl http://127.0.0.1:10255/pods
// 節(jié)點(diǎn)信息接口,提供磁盤、網(wǎng)絡(luò)、CPU、內(nèi)存等信息
$ curl http://127.0.0.1:10255/spec/
2、kubelet 主要功能：
pod 管理：kubelet 定期從所監(jiān)聽的數(shù)據(jù)源獲取節(jié)點(diǎn)上 pod/container 的期望狀態(tài)（運(yùn)行什么容器、運(yùn)行的副本數(shù)量、網(wǎng)絡(luò)或者存儲(chǔ)如何配置等等），并調(diào)用對(duì)應(yīng)的容器平臺(tái)接口達(dá)到這個(gè)狀態(tài)。
容器健康檢查：kubelet 創(chuàng)建了容器之后還要查看容器是否正常運(yùn)行，如果容器運(yùn)行出錯(cuò)，就要根據(jù) pod 設(shè)置的重啟策略進(jìn)行處理。
容器監(jiān)控：kubelet 會(huì)監(jiān)控所在節(jié)點(diǎn)的資源使用情況，并定時(shí)向 master 報(bào)告，資源使用數(shù)據(jù)都是通過 cAdvisor 獲取的。知道整個(gè)集群所有節(jié)點(diǎn)的資源情況，對(duì)于 pod 的調(diào)度和正常運(yùn)行至關(guān)重要。
三、kubelet 組件中的模塊
上圖展示了 kubelet 組件中的模塊以及模塊間的劃分。
1、PLEG(Pod Lifecycle Event Generator）
PLEG 是 kubelet 的核心模塊,PLEG 會(huì)一直調(diào)用 container runtime 獲取本節(jié)點(diǎn) containers/sandboxes 的信息，并與自身維護(hù)的 pods cache 信息進(jìn)行對(duì)比，生成對(duì)應(yīng)的 PodLifecycleEvent，然后輸出到 eventChannel 中，通過 eventChannel 發(fā)送到 kubelet syncLoop 進(jìn)行消費(fèi)，然后由 kubelet syncPod 來觸發(fā) pod 同步處理過程，最終達(dá)到用戶的期望狀態(tài)。2、cAdvisor
cAdvisor（https://github.com/google/cadvisor）是 google 開發(fā)的容器監(jiān)控工具，集成在 kubelet 中，起到收集本節(jié)點(diǎn)和容器的監(jiān)控信息，大部分公司對(duì)容器的監(jiān)控?cái)?shù)據(jù)都是從 cAdvisor 中獲取的 ，cAvisor 模塊對(duì)外提供了 interface 接口，該接口也被 imageManager，OOMWatcher，containerManager 等所使用。3、OOMWatcher
系統(tǒng) OOM 的監(jiān)聽器，會(huì)與 cadvisor 模塊之間建立 SystemOOM,通過 Watch方式從 cadvisor 那里收到的 OOM 信號(hào)，并產(chǎn)生相關(guān)事件。4、probeManager
probeManager 依賴于 statusManager,livenessManager,containerRefManager，會(huì)定時(shí)去監(jiān)控 pod 中容器的健康狀況，當(dāng)前支持兩種類型的探針：livenessProbe 和readinessProbe。
livenessProbe：用于判斷容器是否存活，如果探測(cè)失敗，kubelet 會(huì) kill 掉該容器，并根據(jù)容器的重啟策略做相應(yīng)的處理。
readinessProbe：用于判斷容器是否啟動(dòng)完成，將探測(cè)成功的容器加入到該 pod 所在 service 的 endpoints 中，反之則移除。readinessProbe 和 livenessProbe 有三種實(shí)現(xiàn)方式：http、tcp 以及 cmd。5、statusManager
statusManager 負(fù)責(zé)維護(hù)狀態(tài)信息，并把 pod 狀態(tài)更新到 apiserver，但是它并不負(fù)責(zé)監(jiān)控 pod 狀態(tài)的變化，而是提供對(duì)應(yīng)的接口供其他組件調(diào)用，比如 probeManager。6、containerRefManager
容器引用的管理，相對(duì)簡(jiǎn)單的Manager，用來報(bào)告容器的創(chuàng)建，失敗等事件，通過定義 map 來實(shí)現(xiàn)了 containerID 與 v1.ObjectReferece 容器引用的映射。7、evictionManager
當(dāng)節(jié)點(diǎn)的內(nèi)存、磁盤或 inode 等資源不足時(shí)，達(dá)到了配置的 evict 策略， node 會(huì)變?yōu)?pressure 狀態(tài)，此時(shí) kubelet 會(huì)按照 qosClass 順序來驅(qū)趕 pod，以此來保證節(jié)點(diǎn)的穩(wěn)定性?？梢酝ㄟ^配置 kubelet 啟動(dòng)參數(shù)--eviction-hard=來決定 evict 的策略值。8、imageGC
imageGC 負(fù)責(zé) node 節(jié)點(diǎn)的鏡像回收，當(dāng)本地的存放鏡像的本地磁盤空間達(dá)到某閾值的時(shí)候，會(huì)觸發(fā)鏡像的回收，刪除掉不被 pod 所使用的鏡像，回收鏡像的閾值可以通過 kubelet 的啟動(dòng)參數(shù)--image-gc-high-threshold和--image-gc-low-threshold來設(shè)置。9、containerGC
containerGC 負(fù)責(zé)清理 node 節(jié)點(diǎn)上已消亡的 container，具體的 GC 操作由runtime 來實(shí)現(xiàn)。10、imageManager
調(diào)用 kubecontainer 提供的PullImage/GetImageRef/ListImages/RemoveImage/ImageStates 方法來保證pod 運(yùn)行所需要的鏡像。11、volumeManager
負(fù)責(zé) node 節(jié)點(diǎn)上 pod 所使用 volume 的管理，volume 與 pod 的生命周期關(guān)聯(lián)，負(fù)責(zé) pod 創(chuàng)建刪除過程中 volume 的 mount/umount/attach/detach 流程，kubernetes 采用 volume Plugins 的方式，實(shí)現(xiàn)存儲(chǔ)卷的掛載等操作，內(nèi)置幾十種存儲(chǔ)插件。12、containerManager
負(fù)責(zé) node 節(jié)點(diǎn)上運(yùn)行的容器的 cgroup 配置信息，kubelet 啟動(dòng)參數(shù)如果指定--cgroups-per-qos的時(shí)候，kubelet 會(huì)啟動(dòng) goroutine 來周期性的更新 pod 的 cgroup 信息，維護(hù)其正確性，該參數(shù)默認(rèn)為true，實(shí)現(xiàn)了 pod 的Guaranteed/BestEffort/Burstable 三種級(jí)別的 Qos。13、runtimeManager
containerRuntime 負(fù)責(zé) kubelet 與不同的 runtime 實(shí)現(xiàn)進(jìn)行對(duì)接，實(shí)現(xiàn)對(duì)于底層 container 的操作，初始化之后得到的 runtime 實(shí)例將會(huì)被之前描述的組件所使用?？梢酝ㄟ^ kubelet 的啟動(dòng)參數(shù)--container-runtime來定義是使用docker 還是 rkt，默認(rèn)是docker。14、podManager
podManager 提供了接口來存儲(chǔ)和訪問 pod 的信息，維持 static pod 和 mirror pods 的關(guān)系，podManager 會(huì)被statusManager/volumeManager/runtimeManager 所調(diào)用，podManager 的接口處理流程里面會(huì)調(diào)用 secretManager 以及 configMapManager。
在 v1.12 中，kubelet 組件有18個(gè)主要的 manager（kubernetes/pkg/kubelet/kubelet.go）：
certificateManager
cgroupManager
containerManager
cpuManager
nodeContainerManager
configmapManager
containerReferenceManager
evictionManager
nvidiaGpuManager
imageGCManager
kuberuntimeManager
hostportManager
podManager
proberManager
secretManager
statusManager
volumeManager
tokenManager
其中比較重要的模塊后面會(huì)進(jìn)行一一分析。
四、總結(jié)
本片文章主要講解了 kubelet 在 kubernetes 系統(tǒng)中的功能，所監(jiān)聽四個(gè)端口的主要作用，自身架構(gòu)中包含的組件以及各組件的用途。
參考：
微軟資深工程師詳解 K8S 容器運(yùn)行時(shí)
kubernetes 簡(jiǎn)介： kubelet 和 pod
Kubelet 組件解析
