在kubernetes集群中，每個Node節點上都運行一個Kubelet服務進程，默認監聽10250端口，接收并執行Master發來的指令，管理Pod及Pod中的容器。每個Kubelet進程會在API Server上注冊所在Node節點的信息，定期向Master節點匯報該節點的資源使用情況，并通過cAdvisor監控節點和容器的資源。

一、Kubelet內部結構

如下kubelet內部組件結構圖所示，Kubelet由許多內部組件構成：

圖1：kubelet內部結構

1)Kubelet API：包括 10250 端口的認證 API、4194 端口的 cAdvisor API、10255端口的只讀API以及10248端口的健康檢查 API。

2)syncLoop：從API或者manifest 目錄接收 Pod 更新，發送到podWorkers處理，大量使用channel處理來處理異步請求。

3)輔助的manager：如cAdvisor、PLEG、Volume Manager等，處理syncLoop以外的其他工作。

4)CRI：容器執行引擎接口，負責與container runtime shim通信。

5)容器執行引擎：如dockershim、rkt 等(注：rkt 暫未完成CRI的遷移)。

6)網絡插件：目前支持CNI和kubenet。

二、了解Kubelet

1、節點管理

節點管理主要是節點自注冊和節點狀態更新：

• Kubelet可以通過設置啟動參數 --register-node來確定是否向API Server注冊自己；
• 如果Kubelet沒有選擇自注冊模式，則需要用戶自己配置Node資源信息，同時需要告知Kubelet集群上的API Server的位置；
• Kubelet在啟動時通過 API Server 注冊節點信息，并定時向 API Server 發送節點新消息，API Server在接收到新消息后，將信息寫入Etcd中。

2、Pod管理

Kubelet以PodSpec的方式工作。PodSpec 是描述一個 Pod 的YAML或JSON對象。kubelet采用一組通過各種機制提供的PodSpecs(主要通過apiserver)，并確保這些PodSpecs中描述的Pod正常健康運行。

向Kubelet提供節點上需要運行的Pod清單的方法：

文件：啟動參數--config指定的配置目錄下的文件 (默認/ etc/kubernetes/manifests/)。該文件每 20 秒重新檢查一次(可配置)。

HTTP endpoint (URL)：啟動參數--manifest-url設置。每20秒檢查一次這個端點(可配置)。

API Server：通過API Server監聽Etcd目錄，同步Pod清單。

HTTP server：kubelet 偵聽 HTTP請求，并響應簡單的API以提交新的Pod清單。

本章主要學習通過API Server監聽Etcd目錄，同步Pod列表的方式。

Kubelet 通過API Server Client(Kubelet啟動時創建)使用Watch加List的方式監聽"/registry/nodes/$當前節點名"和“/registry/pods”目錄，將獲取的信息同步到本地緩存中。

Kubelet監聽Etcd，所有針對Pod的操作都將會被Kubelet監聽到。如果發現有新的綁定到本節點的Pod，則按照Pod清單的要求創建該Pod。

如果發現本地的Pod被修改，則Kubelet會做出相應的修改，比如刪除Pod中某個容器時，則通過Docker Client刪除該容器。 如果發現刪除本節點的Pod，則刪除相應的Pod，并通過Docker Client刪除Pod中的容器。

Pod 啟動流程

圖2：Pod 啟動流程圖

啟動流程如下：

1)、用戶通過Kubectl或其他API客戶端提交Pod spec給API Server；

2)、API Server嘗試著將Pod對象的相關信息存入Etcd中，待寫入操作執行完成，API Server即會返回確認信息至客戶端；

3)、API Server開始反映Etcd中的狀態變化；

4)、所有的Kubernetes組件均使用Watch機制來跟蹤檢查API Server上的相關變動；

5)、Kube-scheduler通過其Watch覺察到API Server創建了新的Pod對象但尚未綁定至任何工作節點

6)、Kube-scheduler為Pod對象挑選一個工作節點并將結果信息更新至API Server；

7)、調度結果信息由API Server更新至Etcd，而且API Server也開始反映此Pod對象的調度結果；

8)、Pod被調度到目標工作節點上的kubelet嘗試在當前節點上調用Docker啟動容器，并將容器的結果狀態回送至API Server；

?9)、API Server將Pod狀態信息存入Etcd中；

10)、在Etcd確認寫入操作成功完成后，API Server將確認信息發送至相關的Kubelet，時間將通過它被接受。

3、容器健康檢查

Pod通過兩類探針檢查容器的健康狀態:

(1) LivenessProbe(存活探針)探針：用于判斷容器是否健康，告訴Kubelet一個容器什么時候處于不健康的狀態。如果LivenessProbe探針探測到容器不健康，則Kubelet 將刪除該容器，并根據容器的重啟策略做相應的處理。

(2)ReadinessProbe(就緒探針)探針：用于判斷容器是否啟動完成且準備接收請求。如果ReadinessProbe探針探測到失敗，則Pod的狀態將被修改。

Kubelet定期調用容器中的LivenessProbe探針來診斷容器的健康狀況。LivenessProbe包含如下三種實現方式：

ExecAction：在容器內部執行一個命令，如果該命令的退出狀態碼為 0，則表明容器健康；

TCPSocketAction：通過容器的IP地址和端口號執行TCP檢查，如果端口能被訪問，則表明容器健康；

HTTPGetAction：通過容器的IP地址和端口號及路徑調用HTTP GET方法，如果響應的狀態碼大于等于200且小于400，則認為容器狀態健康。

LivenessProbe和ReadinessProbe探針包含在Pod定義的某個主容器中。

4、Kubelet驅逐

Kubelet會監控資源的使用情況，并使用驅逐機制防止計算和存儲資源耗盡。在驅逐時，Kubelet將Pod的所有容器停止，并將PodPhase設置為Failed。

5、cAdvisor資源監控

cAdvisor是一個開源的分析容器資源使用率和性能特性的代理工具，集成到Kubele中，當Kubelet啟動時會同時啟動cAdvisor，且一個cAdvisor只監控一個Node節點的信息。cAdvisor自動查找所有在其所在節點上的容器，自動采集CPU、內存、文件系統和網絡使用的統計信息。cAdvisor通過它所在節點機的Root容器，采集并分析該節點機的全面使用情況。

6、Container Runtime

容器運行時(Container Runtime)是Kubernetes最重要的組件之一，負責真正管理鏡像和容器的生命周期。Kubelet通過 容器運行時接口(Container Runtime Interface，CRI) 與容器運行時交互，以管理鏡像和容器。

基于CRI容器引擎包括：

1)Docker

2)RKT

3)Virtlet

總結

以上是生活随笔為你收集整理的kubelet启动失败_《蹲坑学kubernetes》之10-1：kubelet原理详解的全部內容，希望文章能夠幫你解決所遇到的問題。

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