核心組件
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 的流程爲
用戶通過 REST API 創建一個 Pod
API Server 將其寫入 etcd
Scheduluer 檢測到未綁定 Node 的 Pod，開始調度並更新 Pod 的 Node 綁定
Kubelet 檢測到有新的 Pod 調度過來，通過 Container Runtime 運行該 Pod
Kubelet 通過 Container Runtime 取到 Pod 狀態，並更新到 API Server 中
端口號
Master node(s)
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)
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 在同一個版本
參考文檔
Last updated