031.核心組件-kubelet_ZenDei技術網路在線

一 kubelet概述 1.1 kubelet作用在Kubernetes集群中，在每個Node（又稱Minion）上都會啟動一個kubelet服務進程。該進程用於處理Master下發到本節點的任務，管理Pod及Pod中的容器。每個kubelet進程都會在API Server上註冊節點自身的信息，定 ...

一 kubelet概述

1.1 kubelet作用

在Kubernetes集群中，在每個Node（又稱Minion）上都會啟動一個kubelet服務進程。該進程用於處理Master下發到本節點的任務，管理Pod及Pod中的容器。每個kubelet進程都會在API Server上註冊節點自身的信息，定期向Master彙報節點資源的使用情況，並通過cAdvisor監控容器和節點資源。

二節點管理

節點通過設置kubelet的啟動參數“--register-node”，來決定是否向API Server註冊自己。如果該參數的值為true，那麼kubelet將試著通過API Server註冊自己。在自註冊時，kubelet啟動時還包含下列參數。

--api-servers：API Server的位置。

--kubeconfig：kubeconfig文件，用於訪問API Server的安全配置文件。

--cloud-provider：雲服務商（IaaS）地址，僅用於公有雲環境。

提示：通常可能每個kubelet都被授予創建和修改任何節點的許可權。生產環境中，建議kubelet的許可權進行限制，僅允許它修改和創建所在節點的許可權。 如果在集群運行過程中遇到集群資源不足的情況，用戶就很容易通過添加機器及運用kubelet的自註冊模式來實現擴容。在某些情況下，Kubernetes集群中的某些kubelet沒有選擇自註冊模式，用戶需要自己去配置Node的資源信息，同時告知Node上Kubelet API Server的位置，需要手動創建和修改節點信息。如果需要手動創建節點信息，則通過設置kubelet的啟動參數“--registernode=false”即可關閉自註冊模式。 kubelet在啟動時通過API Server註冊節點信息，並定時向API Server發送節點的新消息，API Server在接收到這些信息後，將這些信息寫入etcd。通過kubelet的啟動參數“--node-status-update-frequency”設置kubelet每隔多長時間向API Server報告節點狀態，預設為10s。

三 Pod管理

kubelet通過以下幾種方式獲取自身Node上要運行的Pod清單。

文件：kubelet啟動參數“--config”指定的配置文件目錄下的文件（預設目錄為“/etc/kubernetes/manifests/”）。通過--file-checkfrequency設置檢查該文件目錄的時間間隔，預設為20s。

HTTP端點（URL）：通過“--manifest-url”參數設置。通過--http-check-frequency設置檢查該HTTP端點數據的時間間隔，預設為20s。

API Server：kubelet通過API Server監聽etcd目錄，同步Pod列表。

所有以非API Server方式創建的Pod都叫作Static Pod。kubelet將Static Pod的狀態彙報給API Server，API Server為該Static Pod創建一個Mirror Pod和其相匹配。Mirror Pod的狀態將真實反映Static Pod的狀態。當Static Pod被刪除時，與之相對應的Mirror Pod也會被刪除。對於通過API Server獲得Pod清單的方式，kubelet會使用API Server Client的Watch加List的方式監聽“/registry/nodes/$”當前節點的名稱和“/registry/pods”目錄，將獲取的信息同步到本地緩存中。 kubelet監聽etcd，所有針對Pod的操作都會被kubelet監聽。如果發現有新的綁定到本節點的Pod，則按照Pod清單的要求創建該Pod。如果發現本地的Pod被修改，則kubelet會做出相應的修改，比如在刪除Pod中的某個容器時，會通過Docker Client刪除該容器。如果發現刪除本節點的Pod，則刪除相應的Pod，並通過Docker Client刪除Pod中的容器。 kubelet讀取所監聽的信息，如果是創建和修改Pod任務，則做如下處理：

從API Server讀取該Pod清單。

為該Pod掛載外部捲（ExternalVolume）。

下載Pod用到的Secret。

檢查已經運行在節點上的Pod，如果該Pod沒有容器或Pause容器（“kubernetes/pause”鏡像創建的容器）沒有啟動，則先停止Pod里所有容器的進程。如果在Pod中有需要刪除的容器，則刪除這些容器。

用“kubernetes/pause”鏡像為每個Pod都創建一個容器。該Pause容器用於接管Pod中所有其他容器的網路。每創建一個新的Pod，kubelet都會先創建一個Pause容器，然後創建其他容器。“kubernetes/pause”鏡像大概有200KB，是個非常小的容器鏡像。

為Pod中的每個容器做如下處理：

為容器計算一個Hash值，然後用容器的名稱去查詢對應Docker容器的Hash值。若查找到容器，且二者的Hash值不同，則停止Docker中容器的進程，並停止與之關聯的Pause容器的進程；若二者相同，則不做任何處理。

如果容器被終止了，且容器沒有指定的restartPolicy（重啟策略），則不做任何處理。

調用Docker Client下載容器鏡像，調用Docker Client運行容器。

四容器健康檢查

4.1 健康檢查方法

Pod通過兩類探針來檢查容器的健康狀態,LivenessProbe探針和ReadinessProbe探針。

4.2 LivenessProbe探針

LivenessProbe探針，用於判斷容器是否健康並反饋給kubelet。如果LivenessProbe探針探測到容器不健康，則kubelet將刪除該容器，並根據容器的重啟策略做相應的處理。如果一個容器不包含LivenessProbe探針，那麼kubelet認為該容器的LivenessProbe探針返回的值永遠是Success。 kubelet定期調用容器中的LivenessProbe探針來診斷容器的健康狀況。LivenessProbe包含以下3種實現方式：

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

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

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

LivenessProbe探針被包含在Pod定義的spec.containers.{某個容器}中。示例1：HTTP檢查方式 [root@k8smaster01 study]# vi myweb-liveness.yaml

  1 apiVersion: v1
  2 kind: Pod
  3 metadata:
  4   labels:
  5     test: liveness
  6   name: myweb
  7 spec:
  8   containers:
  9   - name: myweb
 10     image: kubeguide/tomcat-app:v1
 11     ports:
 12     - containerPort: 8080
 13     livenessProbe:
 14       httpGet:
 15         path: /index.html
 16         port: 8080
 17         httpHeaders:
 18         - name: X-Custom-Header
 19           value: Awesome
 20       initialDelaySeconds: 5
 21       timeoutSeconds: 1
 22 #kubelet發送一個HTTP請求到本地主機、埠及指定的路徑，來檢查容器的健康狀態。

示例2：運行一個具體的命令。 [root@k8smaster01 study]# vi myweb-liveness.yaml

  1 apiVersion: v1
  2 kind: Pod
  3 metadata:
  4   labels:
  5     test: liveness
  6   name: myweb
  7 spec:
  8   containers:
  9   - name: myweb
 10     image: kubeguide/tomcat-app:v1
 11     ports:
 12     - containerPort: 8080
 13     livenessProbe:
 14       exec:
 15         command:
 16           - cat
 17           - /tmp/health
 18       initialDelaySeconds: 5
 19       timeoutSeconds: 1
 20 #kubelet在容器中執行“cat /tmp/health”命令，如果該命令返回的值為0，則表明容器處於健康狀態，否則表明容器處於不健康狀態。

4.3 ReadinessProbe探針

另一類是ReadinessProbe探針，用於判斷容器是否啟動完成，且準備接收請求。如果ReadinessProbe探針檢測到容器啟動失敗，則Pod的狀態將被修改，Endpoint Controller將從Service的Endpoint中刪除包含該容器所在Pod的IP地址的Endpoint條目。

五 cAdvisor資源監控

5.1 cAdvisor概覽

在Kubernetes集群中，應用程式生命周期內的信息可以在不同的級別上進行監測，如：容器、Pod、Service和整個集群。 Kubernetes儘可能提供用戶詳細的各個級別的資源使用信息，從而能深入地瞭解應用的執行情況，並找到應用中可能的瓶頸。 cAdvisor是一個開源的分析容器資源使用率和性能特性的代理工具，它是因為容器而產生的，因此也支持Docker容器。在Kubernetes項目中，cAdvisor被集成到Kubernetes代碼中，kubelet則通過cAdvisor獲取其所在節點及容器的數據

5.2 cAdvisor原理及作用

cAdvisor自動查找所有在其所在Node上的容器，自動採集CPU、記憶體、文件系統和網路使用的統計信息。通常cAdvisor通過它所在Node的4194埠暴露一個簡單的UI。 kubelet作為連接Kubernetes Master和各Node之間的橋梁，管理運行在Node上的Pod和容器。kubelet將每個Pod都轉換成它的成員容器，同時從cAdvisor獲取單獨的容器使用統計信息，然後通過該REST API暴露這些聚合後的Pod資源使用的統計信息。 cAdvisor只能提供2～3min的監控數據，對性能數據也沒有持久化，因此在Kubernetes早期版本中需要依靠Heapster來實現集群範圍內全部容器性能指標的採集和查詢功能。從Kubernetes1.8版本開始，性能指標數據的查詢介面升級為標準的Metrics API，後端服務則升級為全新的Metrics Server。因此，cAdvisor在4194埠提供的UI和API服務從Kubernetes1.10版本開始進入棄用流程，並於1.12版本完全關閉。若需要重新啟用該服務，可手動部署一個DaemonSet在每個Node上啟動一個cAdvisor來提供UI和API，參考：https://github.com/google/cadvisor。在新的Kubernetes監控體系中，Metrics Server用於提供CoreMetrics（核心指標），包括Node和Pod的CPU和記憶體使用數據。其他CustomMetrics（自定義指標）則由第三方組件（如Prometheus）採集和存儲。

031.核心組件-kubelet