kubelet启动失败_kubelet 架构浅析
一、概要
kubelet 是運(yùn)行在每個(gè)節(jié)點(diǎn)上的主要的“節(jié)點(diǎn)代理”,每個(gè)節(jié)點(diǎn)都會(huì)啟動(dòng) kubelet進(jìn)程,用來(lái)處理 Master 節(jié)點(diǎn)下發(fā)到本節(jié)點(diǎn)的任務(wù),按照 PodSpec 描述來(lái)管理Pod 和其中的容器(PodSpec 是用來(lái)描述一個(gè) pod 的 YAML 或者 JSON 對(duì)象)。
kubelet 通過(guò)各種機(jī)制(主要通過(guò) apiserver )獲取一組 PodSpec 并保證在這些 PodSpec 中描述的容器健康運(yùn)行。
二、kubelet 的主要功能
1、kubelet 默認(rèn)監(jiān)聽(tīng)四個(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ù),通過(guò)該端口可以訪問(wèn)獲取 node 資源以及狀態(tài)。
- 10248(健康檢查端口):通過(guò)訪問(wèn)該端口可以判斷 kubelet 是否正常工作, 通過(guò) kubelet 的啟動(dòng)參數(shù) --healthz-port 和 --healthz-bind-address 來(lái)指定監(jiān)聽(tīng)的地址和端口。
- 4194(cAdvisor 監(jiān)聽(tīng)):kublet 通過(guò)該端口可以獲取到該節(jié)點(diǎn)的環(huán)境信息以及 node 上運(yùn)行的容器狀態(tài)等內(nèi)容,訪問(wèn) http://localhost:4194 可以看到 cAdvisor 的管理界面,通過(guò) kubelet 的啟動(dòng)參數(shù) --cadvisor-port 可以指定啟動(dòng)的端口。
- 10255 (readonly API):提供了 pod 和 node 的信息,接口以只讀形式暴露出去,訪問(wèn)該端口不需要認(rèn)證和鑒權(quán)。
2、kubelet 主要功能:
- pod 管理:kubelet 定期從所監(jiān)聽(tīng)的數(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ù)都是通過(guò) 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 中,通過(guò) eventChannel 發(fā)送到 kubelet syncLoop 進(jìn)行消費(fèi),然后由 kubelet syncPod 來(lái)觸發(fā) pod 同步處理過(guò)程,最終達(dá)到用戶的期望狀態(tài)。
- 2、cAdvisor cAdvisor(https://github.com/google/cadvisor)是 google 開(kāi)發(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)聽(tīng)器,會(huì)與 cadvisor 模塊之間建立 SystemOOM,通過(guò) Watch方式從 cadvisor 那里收到的 OOM 信號(hào),并產(chǎn)生相關(guān)事件。
- 4、probeManager probeManager 依賴于 statusManager,livenessManager,containerRefManager,會(huì)定時(shí)去監(jiān)控 pod 中容器的健康狀況,當(dāng)前支持兩種類(lèi)型的探針: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,用來(lái)報(bào)告容器的創(chuàng)建,失敗等事件,通過(guò)定義 map 來(lái)實(shí)現(xiàn)了 containerID 與 v1.ObjectReferece 容器引用的映射。
- 7、evictionManager 當(dāng)節(jié)點(diǎn)的內(nèi)存、磁盤(pán)或 inode 等資源不足時(shí),達(dá)到了配置的 evict 策略, node 會(huì)變?yōu)?pressure 狀態(tài),此時(shí) kubelet 會(huì)按照 qosClass 順序來(lái)驅(qū)趕 pod,以此來(lái)保證節(jié)點(diǎn)的穩(wěn)定性。可以通過(guò)配置 kubelet 啟動(dòng)參數(shù) --eviction-hard= 來(lái)決定 evict 的策略值。
- 8、imageGC imageGC 負(fù)責(zé) node 節(jié)點(diǎn)的鏡像回收,當(dāng)本地的存放鏡像的本地磁盤(pán)空間達(dá)到某閾值的時(shí)候,會(huì)觸發(fā)鏡像的回收,刪除掉不被 pod 所使用的鏡像,回收鏡像的閾值可以通過(guò) kubelet 的啟動(dòng)參數(shù) --image-gc-high-threshold 和 --image-gc-low-threshold 來(lái)設(shè)置。
- 9、containerGC containerGC 負(fù)責(zé)清理 node 節(jié)點(diǎn)上已消亡的 container,具體的 GC 操作由runtime 來(lái)實(shí)現(xiàn)。
- 10、imageManager 調(diào)用 kubecontainer 提供的PullImage/GetImageRef/ListImages/RemoveImage/ImageStates 方法來(lái)保證pod 運(yùn)行所需要的鏡像。
- 11、volumeManager 負(fù)責(zé) node 節(jié)點(diǎn)上 pod 所使用 volume 的管理,volume 與 pod 的生命周期關(guān)聯(lián),負(fù)責(zé) pod 創(chuàng)建刪除過(guò)程中 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 來(lái)周期性的更新 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ì)被之前描述的組件所使用。可以通過(guò) kubelet 的啟動(dòng)參數(shù) --container-runtime 來(lái)定義是使用docker 還是 rkt,默認(rèn)是 docker。
- 14、podManager podManager 提供了接口來(lái)存儲(chǔ)和訪問(wèn) 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:
certificateManager cgroupManager containerManager cpuManager nodeContainerManager configmapManager containerReferenceManager evictionManager nvidiaGpuManager imageGCManager kuberuntimeManager hostportManager podManager proberManager secretManager statusManager volumeManager tokenManager其中比較重要的模塊后面會(huì)進(jìn)行一一分析。
參考:
微軟資深工程師詳解 K8S 容器運(yùn)行時(shí)
kubernetes 簡(jiǎn)介: kubelet 和 pod Kubelet 組件解析
總結(jié)
以上是生活随笔為你收集整理的kubelet启动失败_kubelet 架构浅析的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: 伤感网名大全542个
- 下一篇: 机器学习分类算法_机器学习分类算法