1.kubelet 簡介

1.1.kubelet 是什麼

• 前面kubernetes架構講解時，對 kubelet 的初步認識：

• 每個節點上都會跑一個Kubelet，負責上報 節點狀態，pod狀態、pod資源使用情況等信息到ApiServer，由ApiServer寫入etcd。
• 同時，Kubelet也會和apiserver交互，當發現 有pod被 Schedule 調度到自己所在node時，就會調用一系列標準接口，拉起pod的進程，併為之掛載網絡和存儲。
• kubelet通過對 容器運行時（CRI）、容器網絡標準（CNI）、容器存儲標準（CSI） 的調用，完成pod 容器、網絡、存儲 的管理

• Kubelet 是 Kubernetes 集羣 工作節點 的核心代理組件

• 我們前面學習的 etcd、apiserver、scheduler、controller-manager等，都屬於上級管理部門，負責 存儲數據、進行決策、下發命令，不會直接參與幹活
• Kubelet 是真正的worker，是Node的核心代理組件，它直接與節點上的容器運行時（如 Docker、containerd）交互，確保 Pod 及其容器按照集羣控制平面下發的指令正確運行，是 Kubernetes 實現“節點自治”能力的關鍵模塊

1.2.kubelet 的核心功能

1.3.kubelet核心工作流程

API_Server Kubelet Container_Runtime Container 下發 PodSpec 變更事件 調用 CRI 接口創建容器 返回容器狀態 上報 Pod 運行狀態 執行探針檢測 返回健康狀態 loop [健康檢查] API_Server Kubelet Container_Runtime Container

1.4.kubelet 對節點的管理

1.5.kubelet 的 pod事件來源

參考：https://kubernetes.feisky.xyz/concepts/components/kubelet#pod-guan-li

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

2.Kubelet 工作原理

2.1.kubelet 架構設計

• API 接口層

• kubelet API
• cAdvisor API
• 只讀API
• 健康檢查 API

• 核心功能層，可分為3個模塊：

• 核心管理模塊：PLEG、cAdvisor、GPUManager、OOMWatcher、ProbeManager、DiskSpaceManager、EvictionManager
• 運行時協調模塊：syncLoop、PodWorker
• 容器生命週期管理模塊：StatusManager、VolumeManager、ImageGC、ContainerGC、ImageManager、CertificateManager

• CRI 接口層

• 容器執行引擎接口，作為grpc client 與真正的容器運行時（Dockershim/rkt/containerd）交互

2.2.kubelet 管理pod核心流程

• API Server/static file/http/PLEG：事件生產者
• syncLoop：類似 controller reconcile 的消費者，不停接收pod變更事件，進行處理

• worker：syncLoop包含多個worker，負責處理pod事件

• syncPod：處理pod的核心方法
• computePodActions：根據當前事件+集羣資源現狀，推斷應該進行的操作，然後調用cri的對應接口。

• 比如 create事件+環境中沒有資源，則調用cri的 create 接口
• 比如 delete事件+環境中有資源，則調用cri的 kill 接口

• PLEG：

• 定期調用cri接口，收集當前節點中所有的pod信息，一方面根據環境變化觸發syncLoop，另一方面將狀態上報到master
• PLEG的relist動作是有開銷的，當pod數量過多，或環境有問題時，relist響應過慢頻繁超時，node會被認為不ready

3.kubelet API 接口層

3.1.kubelet API 主通信端口：10250

3.1.1.端口 10250 的核心作用

• Kubelet 的 10250 端口 是其默認的 HTTPS 主通信端口，承擔以下核心功能：

• Pod 生命週期管理：接收來自 API Server 的指令，創建、更新或刪除 Pod。
• 資源監控數據暴露：提供容器和節點的性能指標（通過集成 cAdvisor）。
• 調試與運維接口：支持訪問容器日誌、執行命令（如 kubectl exec）、端口轉發等。
• 節點狀態上報：向 API Server 彙報節點健康狀態和資源容量。

3.1.2.協議與認證機制

• 協議：使用 HTTPS（TLS 加密），確保通信安全性。
• 認證方式：

• X.509 客户端證書：Kubelet 自動生成證書，由集羣 CA 簽發。
• Bearer Token：基於 ServiceAccount 的 JWT Token（需 RBAC 授權）。
• 匿名訪問（默認關閉）：需顯式啓用 --anonymous-auth=true（不推薦）。

3.1.3.關鍵 API 端點

• 通過 https://<Node-IP>:10250 可訪問以下核心接口

3.1.3.1.監控與指標

• /metrics：Prometheus 格式的 Kubelet 自身指標（如 goroutine 數量、請求延遲）。
• /metrics/cadvisor：容器資源使用指標（CPU、內存、網絡等），由 cAdvisor 提供。
• /metrics/resource：Kubernetes 資源模型指標（如 kubelet_container_cpu_usage_seconds_total）。

3.1.3.2.Pod 與容器操作**

• /pods：獲取節點上所有 Pod 的詳細信息（JSON 格式）。
• /containerLogs/<namespace>/<pod>/<container>：查看容器日誌（對應 kubectl logs）。
• /exec/<namespace>/<pod>/<container>：在容器內執行命令（對應 kubectl exec）。
• /portForward/<namespace>/<pod>：端口轉發到容器（對應 kubectl port-forward）。

3.1.3.3.調試與健康檢查**

• /healthz：檢查 Kubelet 是否健康（返回 200 OK 或錯誤碼）。
• /configz：獲取 Kubelet 的當前配置（需啓用 --enable-debugging-handlers=true）。

3.1.4.安全配置

3.1.4.1.證書與 TLS

• Kubelet 證書：

• 由集羣 CA 自動簽發（若啓用 --rotate-certificates 支持證書輪換）。
• 存儲在節點上的 /var/lib/kubelet/pki 目錄。

• 客户端訪問：

• 使用集羣 CA 證書驗證 Kubelet 服務端身份。
• 客户端需提供有效證書或 Token 進行身份認證。

3.1.4.2.RBAC 授權

• 為監控工具或管理員配置最小權限的 RBAC 規則：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kubelet-reader
rules:
- apiGroups: [""]
  resources: ["nodes/metrics", "nodes/proxy", "nodes/log", "nodes/spec"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubelet-reader-binding
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: kubelet-reader
  apiGroup: rbac.authorization.k8s.io

3.1.5.訪問方式示例

3.1.5.1.使用 kubectl proxy（繞過 TLS 驗證）

kubectl proxy --port=8080 &
curl http://localhost:8080/api/v1/nodes/<node-name>/proxy/metrics/cadvisor

3.1.5.2.直接訪問（需證書或 Token）

# 使用 ServiceAccount Token
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
curl -k -H "Authorization: Bearer $TOKEN" https://<Node-IP>:10250/metrics/cadvisor

# 使用客户端證書（如 kubeconfig 中的證書）
curl --cert /path/to/client.crt --key /path/to/client.key --cacert /path/to/ca.crt https://<Node-IP>:10250/metrics

3.1.6.生產環境最佳實踐

• 禁用匿名訪問：確保 Kubelet 啓動參數包含 --anonymous-auth=false。
• 啓用證書輪換：配置 --rotate-certificates=true 提升密鑰安全性。
• 限制網絡訪問：

• 通過防火牆規則僅允許 API Server 和監控系統訪問 10250 端口。
• 使用 Kubernetes NetworkPolicy 限制 Pod 到 Kubelet 的通信。

• 源碼位置：

• pkg/kubelet/server/server.go（核心服務端實現）
• pkg/kubelet/server/auth.go（認證鑑權邏輯）

3.2.cAdvisor資源監控數據採集 端口：4194

3.2.1.cAdvisor 的作用

• cAdvisor 是一個開源的容器資源監控工具，集成在 Kubelet 中，用於實時收集節點和容器的資源使用數據，包括：

• CPU 使用率
• 內存使用量
• 文件系統（磁盤）使用情況
• 網絡流量統計
• 容器的啓動時間和運行狀態等。

• 這些數據通過 REST API 暴露，供 Prometheus、Heapster 或其他監控系統採集。

3.2.2.端口 4194 現已不支持

• 在 Kubernetes 早期版本（如 1.7 之前），cAdvisor 默認通過端口 4194 對外暴露監控數據。
• 用户可以直接訪問 http://<Node-IP>:4194/metrics 獲取容器的 Prometheus 格式指標
• 從 Kubernetes 1.12 開始，出於安全性和架構簡化的考慮，Kubelet 默認不再單獨監聽 4194 端口，而是將 cAdvisor 的 API 集成到 Kubelet 的主 API 端口（默認 10250）中。具體變化包括：

• cAdvisor 數據路徑合併：cAdvisor 的監控數據現在通過 Kubelet 的 /metrics/cadvisor 端點暴露，訪問地址為 https://<Node-IP>:10250/metrics/cadvisor。
• 認證與授權：訪問需要經過 Kubelet 的 TLS 認證（如使用 ServiceAccount Token 或客户端證書），避免未授權訪問風險。
• 舊端口棄用：4194 端口默認關閉，若需啓用需顯式配置 Kubelet 參數（不推薦）。

3.2.3.通過 Kubelet 主端口（10250）訪問 cAdvisor 數據

# 使用 kubectl 代理繞過 TLS 認證（僅測試環境）
kubectl proxy --port=8080 &
curl http://localhost:8080/api/v1/nodes/<node-name>/proxy/metrics/cadvisor

# 直接訪問（需配置證書或 Token）
curl -k -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://<Node-IP>:10250/metrics/cadvisor

• 通過 /metrics/cadvisor 獲取的 Prometheus 格式數據片段：

container_cpu_usage_seconds_total{container="nginx", namespace="default", pod="nginx-abc123"} 12345.67
container_memory_usage_bytes{container="nginx", namespace="default", pod="nginx-abc123"} 56789012

• 源碼位置：

• pkg/kubelet/cadvisor/cadvisor_linux.go（平台相關實現）
• vendor/github.com/google/cadvisor/manager/manager.go（核心邏輯）

3.3.只讀API 端口10255（狀態查詢）

3.3.1.端口 10255 的基本作用

• Kubelet 的 10255 端口 是一個 只讀（Read-Only）HTTP 端口，主要用於暴露節點和 Pod 的監控數據及健康狀態。它提供無需認證的訪問，常用於以下場景：

• 資源監控：獲取節點和容器的 CPU、內存、磁盤等指標。
• 健康檢查：檢查 Kubelet 和節點的工作狀態。
• 調試與診斷：快速查看節點上運行的 Pod 列表或容器狀態。

3.3.2.端口 10255 的暴露端點

• 通過 http://<Node-IP>:10255 可訪問以下關鍵端點：

• /healthz：檢查 Kubelet 的健康狀態，返回 200 OK 表示正常。
• /pods：返回節點上所有 Pod 的清單（JSON 格式）。
• /metrics：暴露 Prometheus 格式的監控指標（包括 cAdvisor 數據）。
• /metrics/cadvisor：直接獲取容器的詳細資源使用指標（與 10250 端口的路徑一致）。
• /spec：返回節點的硬件和操作系統信息（如 CPU 核心數、內存大小等）。

3.3.3.只讀端口10255已默認棄用

• 早期版本（如 Kubernetes 1.10 之前）：

• 默認啓用 10255 端口，供監控工具（如 Heapster）或管理員直接訪問，無需認證。

• 安全改進（Kubernetes 1.10+）：

• 由於無需認證的特性存在安全風險，Kubernetes 逐步棄用該端口：
• 1.10+ 版本：默認關閉 10255 端口，需顯式啓用。
• 1.18+ 版本：部分發行版（如 Kubeadm 部署的集羣）完全禁用該端口。
• 1.20+ 版本：Kubelet 參數 --read-only-port 被標記為廢棄，未來可能移除。

• 直接查看kubelet配置，可以看到確實已標記廢棄

# kubelet -h | grep read-only-port
--read-only-port int32  The read-only port for the Kubelet to serve on with no authentication/authorization (set to 0 to disable) (default 10255) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)

3.3.4.如何啓用 10255 端口（不推薦）

• 若需臨時啓用（僅限測試環境），需配置 Kubelet 的啓動參數：

# 編輯 Kubelet 配置文件（如 /etc/kubernetes/kubelet.conf）
KUBELET_ARGS="--read-only-port=10255"

# 或者通過 systemd 服務文件添加參數
ExecStart=/usr/bin/kubelet --read-only-port=10255 ...

• 注意：啓用後需確保節點防火牆限制對該端口的訪問！

3.3.5.訪問示例

• 查看節點上所有 Pod 信息：

curl http://<Node-IP>:10255/pods

• 獲取 Prometheus 監控指標：

curl http://<Node-IP>:10255/metrics

• 檢查 Kubelet 健康狀態：

curl -v http://<Node-IP>:10255/healthz

3.3.6.使用 kubelet API 主通信端口 10250 替代 10255

• 默認的 Kubelet HTTPS 端口（10250）提供相同功能，但需認證：

# 使用 ServiceAccount Token 訪問（需 RBAC 授權）
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
curl -k -H "Authorization: Bearer $TOKEN" https://<Node-IP>:10250/metrics

• 與端口 10250 的對比

3.4.健康檢查 /healthz 端口10248

3.4.1./healthz 端點簡介

• /healthz 是 kubelet 的關鍵健康檢查接口，用於指示其運行狀態：
• 功能與用途

• 存活探針（Liveness Probe）：供 kubelet 自身或外部系統（如 API Server）檢查其是否正常運行。
• 健康狀態反饋：返回 200 OK 表示健康，其他狀態碼（如 500）表示異常。
• 依賴項檢查：某些配置下會驗證 kubelet 依賴的組件（如容器運行時）是否可用。

• /healthz 端點的訪問端口 默認10248
• 可以通過kubelet 參數 --healthz-port 指定端口

3.4.2./healthz 訪問示例

• 響應為ok，則表示節點健康

# 查看本地端口監聽情況
# ss -tuln | grep 10248
tcp    LISTEN     0      4096   127.0.0.1:10248                 *:*

# curl http://localhost:10248/healthz
ok

• 安全性設計

• 本地訪問限制：默認僅監聽 127.0.0.1，不暴露給外部網絡。
• 無認證機制：由於僅限本機訪問，無需額外認證。

3.4.3.10248 與主端口 10250 的區別

3.4.4.--healthz-port 參數狀態與版本變化

• 棄用狀態：

• --healthz-port 參數已被標記為 廢棄（DEPRECATED），Kubernetes 推薦通過 kubelet 配置文件（由 --config 指定）設置相關參數。

• 棄用原因：

• Kubernetes 逐步淘汰命令行參數，轉向統一的配置文件管理，以提高可維護性。

• 版本影響：

• 1.10+ 版本：開始推薦使用配置文件。
• 1.23+ 版本：部分發行版可能默認關閉該端口。

請見：Kubernetes控制平面組件：Kubelet詳解（二）：核心功能層

• 本文主要講解了 kubelet 架構中的核心功能層，包括核心管理模塊的 PLEG、cAdvisor、GPUManager、OOMWatcher、ProbeManager、DiskSpaceManager、EvictionManager；運行時協調模塊的 syncLoop、PodWorker，以及容器生命週期管理模塊的 StatusManager、VolumeManager、ImageGC、ContainerGC、ImageManager、CertificateManager，對每個組件都做了詳細講解

5.kubelet CRI 容器運行時接口層

• 請見：Kubernetes控制平面組件：Kubelet詳解（三）：CRI 容器運行時接口層

• 本文是 kubernetes 的控制面組件 kubelet 系列文章第三篇，主要講解了CRI容器運行時接口相關內容，包括CRI是什麼、核心功能、高級/低級運行時、如何選擇運行時、cai-api/cri-client源碼目錄梳理等-