031.Kubernetes核心組件-kubelet

一 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清單。

1. 文件：kubelet啟動參數“--config”指定的配置文件目錄下的文件（默認目錄為“/etc/kubernetes/manifests/”）。通過--file-checkfrequency設置檢查該文件目錄的時間間隔，默認為20s。
2. HTTP端點（URL）：通過“--manifest-url”參數設置。通過--http-check-frequency設置檢查該HTTP端點數據的時間間隔，默認為20s。
3. 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任務，則做如下處理：

1. 為該Pod創建一個數據目錄。
2. 從API Server讀取該Pod清單。
3. 為該Pod掛載外部卷（ExternalVolume）。
4. 下載Pod用到的Secret。
5. 檢查已經運行在節點上的Pod，如果該Pod沒有容器或Pause容器（“kubernetes/pause”鏡像創建的容器）沒有啟動，則先停止Pod里所有容器的進程。如果在Pod中有需要刪除的容器，則刪除這些容器。
6. 用“kubernetes/pause”鏡像為每個Pod都創建一個容器。該Pause容器用於接管Pod中所有其他容器的網絡。每創建一個新的Pod，kubelet都會先創建一個Pause容器，然后創建其他容器。“kubernetes/pause”鏡像大概有200KB，是個非常小的容器鏡像。
7. 為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種實現方式：

1. ExecAction：在容器內部執行一個命令，如果該命令的退出狀態碼為0，則表明容器健康。
2. TCPSocketAction：通過容器的IP地址和端口號執行TCP檢查，如果端口能被訪問，則表明容器健康。
3. HTTPGetAction：通過容器的IP地址和端口號及路徑調用HTTPGet方法，如果響應的狀態碼大於等於200且小於等於400，則認為容器狀態健康。

LivenessProbe探針被包含在Pod定義的spec.containers.{某個容器}中。

示例1：HTTP檢查方式

[root@k8smaster01 study]# vi myweb-liveness.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: myweb
spec:
  containers:
  - name: myweb
    image: kubeguide/tomcat-app:v1
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /index.html
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 5
      timeoutSeconds: 1
#kubelet發送一個HTTP請求到本地主機、端口及指定的路徑，來檢查容器的健康狀態。

示例2：運行一個具體的命令。

[root@k8smaster01 study]# vi myweb-liveness.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: myweb
spec:
  containers:
  - name: myweb
    image: kubeguide/tomcat-app:v1
    ports:
    - containerPort: 8080
    livenessProbe:
      exec:
        command:
          - cat
          - /tmp/health
      initialDelaySeconds: 5
      timeoutSeconds: 1
#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）采集和存儲。