核心組件

components

Kubernetes 主要由以下幾個核心組件組成:

• etcd 保存了整個集群的狀態；

• API Server 提供了資源操作的唯一入口，並提供認證、授權、訪問控制、API 註冊和發現等機制；

• Controller Manager 負責維護集群的狀態，比如故障檢測、自動擴展、滾動更新等；

• Scheduler 負責資源的調度，按照預定的調度策略將 Pod 調度到相應的機器上；

• Kubelet 負責維護容器的生命週期，同時也負責 Volume（CVI）和網絡（CNI）的管理；

• Container Runtime 負責鏡像管理以及 Pod 和容器的真正運行（CRI）；

• Kube-proxy 負責爲 Service 提供 cluster 內部的服務發現和負載均衡；

組件通信

Kubernetes 多組件之間的通信原理爲

• API Server 負責 etcd 存儲的所有操作，且只有 API Server 才直接操作 etcd 集群

• API Server 對內（集群中的其他組件）和對外（用戶）提供統一的 REST API，其他組件均通過 API Server 進行通信

  • Controller Manager、Scheduler、Kube-proxy 和 Kubelet 等均通過 API Server watch API 監測資源變化情況，並對資源作相應的操作

  • 所有需要更新資源狀態的操作均通過 API Server 的 REST API 進行

• API Server 也會直接調用 Kubelet API（如 logs, exec, attach 等），默認不校驗 Kubelet 證書，但可以通過 --kubelet-certificate-authority 開啓（而 GKE 通過 SSH 隧道保護它們之間的通信）

比如典型的創建 Pod 的流程爲

1. 用戶通過 REST API 創建一個 Pod

2. API Server 將其寫入 etcd

3. Scheduluer 檢測到未綁定 Node 的 Pod，開始調度並更新 Pod 的 Node 綁定

4. Kubelet 檢測到有新的 Pod 調度過來，通過 Container Runtime 運行該 Pod

5. Kubelet 通過 Container Runtime 取到 Pod 狀態，並更新到 API Server 中

端口號

ports

Master node(s)

Protocol	Direction	Port Range	Purpose
TCP	Inbound	6443*	Kubernetes API server
TCP	Inbound	8080	Kubernetes API insecure server
TCP	Inbound	2379-2380	etcd server client API
TCP	Inbound	10250	Kubelet API
TCP	Inbound	10251	kube-scheduler healthz
TCP	Inbound	10252	kube-controller-manager healthz
TCP	Inbound	10253	cloud-controller-manager healthz
TCP	Inbound	10255	Read-only Kubelet API
TCP	Inbound	10256	kube-proxy healthz

Worker node(s)

Protocol	Direction	Port Range	Purpose
TCP	Inbound	4194	Kubelet cAdvisor
TCP	Inbound	10248	Kubelet healthz
TCP	Inbound	10249	kube-proxy metrics
TCP	Inbound	10250	Kubelet API
TCP	Inbound	10255	Read-only Kubelet API
TCP	Inbound	10256	kube-proxy healthz
TCP	Inbound	30000-32767	NodePort Services**

版本支持策略

活躍版本

Kubernetes 社區近維護最新的三個小版本(如 1.21.x, 1.20.x, 1.19.x)，每個小版本均會有一年的補丁支持週期 (1.18以前是9個月)。活躍版本的補丁大約每個月發佈一次，詳細的發佈日程可以參考這裏。

版本兼容性

• 在HA集群中，所有 kube-apiserver 實例最多隻能差一個小版本（如部分是 1.21，部分是 1.20）

• kubelet 最多隻能與 kube-apiserver 差兩個小版本（如 kube-apiserver 是1.21，而 kubelet 是 1.21、1.20、1.19）

• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 最多隻能差一個小版本（如 kube-apiserver 是1.21，kube-controller-manager 是1.20）

升級順序

在升級 Kubernetes 集群（如從 1.20.1 升級到 1.21.1）時，需要確保以下的升級順序和相互依賴關係：

• 在升級前，需要確保 ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 已經升級到最新的 API 版本（兼容新舊版本的 kube-apiserver）

• kube-apiserver 所有實例需要在升級其他組件（如kube-controller-manager）之前完成升級

• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 需要在 kube-apiserver 升級完成之後才能升級

• kubelet 需要在 kube-apiserver 升級完成之後才能升級，且升級前需要 kubectl drain <node>（即 kubelet 不支持本地小版本升級）

• kube-proxy 需要確保跟同節點的 kubelet 在同一個版本

參考文檔

• Master-Node communication

• Core Kubernetes: Jazz Improv over Orchestration

• Installing kubeadm

• Version Skew Policy