Kubernetes 的組件

概述#

Kubernetes（K8s）是用來大規模執行分散式應用的容器編排平台。要支撐這樣的能力，背後必然有一套穩固的架構。本章拆解 Kubernetes 叢集中的關鍵組件，並說明它們各自扮演的角色。

依官方文件，Kubernetes 叢集的設計遵循三項原則：

部署完成後，至少會擁有一個完整的 Kubernetes 叢集，並可依需求擴充。每個叢集包含兩種角色：

下方分別說明這兩種節點上會執行哪些組件。

節點（Node）是 Pod 真正執行的主機，可能是實體機，也可能是虛擬機，是 Kubernetes 中能夠承載工作負載的最小主機單位。每個節點上至少需要執行：

Pod 是 Kubernetes 物件模型中最小、最基礎的單元，代表一個應用實例。Pod 由一個或多個容器組成（多數情況只有一個），同時支援掛載永久儲存（Volume），可執行有狀態的應用。

每個節點都需要一個容器執行環境來實際啟動容器。除了大家熟悉的 Docker 之外，Kubernetes 也支援其他符合 Open Container Initiative（OCI）規範的執行環境，例如 containerd、CRI-O、rkt 等。

每個節點上都會有一個 kubelet 行程，負責與控制平面通訊。當控制平面需要在節點上完成某個動作（例如啟動 Pod、執行健康檢查）時，實際執行者就是 kubelet。它會確保 Pod 內的容器處於應有的執行狀態。

kube-proxy 是節點上的網路代理，負責處理叢集內外的網路流量。它會操作作業系統的封包過濾層或自行轉發流量，為 Service 提供叢集內部的服務探索與負載均衡能力。

控制平面是叢集的中樞神經，負責保存叢集狀態、調度資源、處理請求，確保容器以期望的數量與資源持續執行。一般情況下不需要使用者額外設定。

API Server 是整個控制平面的前端，所有對叢集的操作（包含 kubectl、UI 工具、其他元件）最終都會透過 REST 呼叫送到 API Server。它負責公開 Kubernetes API，並驗證、處理進來的請求。

Scheduler 是容器調度器，負責把新建立、尚未綁定節點的 Pod 分派到最適合的工作節點。調度過程會考量使用者定義的篩選（Filtering）與評分（Scoring）策略，從候選節點中挑選最理想的目標。

Controller Manager 把多個控制器（Controller）組合在同一個行程中執行。控制器負責持續比對「期望狀態」與「實際狀態」，例如：

etcd 是一個分散式的 Key-Value 資料庫，用來儲存叢集的所有狀態與設定。當叢集發生故障時，可以依靠 etcd 中的資料快速還原當下的狀態。

把各個組件拼起來，一個典型的 Pod 建立流程大致是：

理解組件的職責對日後的實作非常關鍵：當叢集出現問題時，可以快速判斷該檢查哪一個組件的紀錄。後續章節會開始實際操作 Kubernetes，並在過程中反覆驗證這個結構。