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清單，

檔案：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）采集和存盤，

轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/125316.html

標籤：Linux

上一篇：030.Kubernetes核心組件-Scheduler

下一篇：032.Kubernetes核心組件-kube-proxy

031.Kubernetes核心組件-kubelet