Kubernetes 核心架構全景：API Server、etcd 分散式狀態、Kubelet 與 Controller Manager 協同調度

在雲原生（Cloud Native）時代，Kubernetes（K8s） 已成為跨雲、跨資料中心調度容器化應用的事實作業系統。

然而，許多工程師對 Kubernetes 的理解僅停留在「寫 YAML、跑 kubectl apply」的層面，一旦線上叢集出現節點失聯、Pod 處於 Pending 狀態或 etcd 延遲抖動時，往往無從下手。

Kubernetes 的設計哲學本質上是一個基於宣告式 API（Declarative API）的分散式自動控制反饋系統。

本文將帶你深入 Kubernetes 內核，完整拆解控制面組件、etcd 狀態儲存與節點 Worker 的底層協同架構。

1. Kubernetes 總體架構拓撲：控制面與資料面

Kubernetes 叢集嚴格劃分為兩大層級：控制平面（Control Plane） 與 工作節點（Worker Nodes）。

職責：叢集所有操作的唯一入口，提供 RESTful API。
無狀態設計（Stateless）：API Server 本身不儲存任何狀態，可透過水平擴展部署多個實例進行負載平衡。
請求處理管線： HTTP 請求 ➔ 認證 (Authentication) ➔ 授權 (RBAC) ➔ 准入控制 (Admission Controllers / Webhooks) ➔ 寫入 etcd。

職責：儲存 Kubernetes 叢集全部物件的元數據與期望狀態（Desired State）。
底層原理：基於 Raft 共識協議 的強一致性 KV 資料庫。
鐵律：在整個 Kubernetes 叢集中，只有 kube-apiserver 具備直接讀寫 etcd 的權限，其餘所有組件必須透過 API Server 進行通訊！

職責：監聽所有處於未調度狀態（spec.nodeName 為空）的 Pod，為其挑選最合適的工作節點。
兩階段調度演算法：
1. 預選階段（Filtering / Predicates）：硬性過濾不符合條件的節點（如節點 CPU/RAM 資源不足、Port 衝突、Taints 污點排斥）；
2. 優選階段（Scoring / Priorities）：對通過預選的節點進行多維度打分（如節點映像檔預加載評分、親和性 Affinity、資源均勻分散），得分最高者獲勝。

核心哲學：控制循環（Reconciliation Loop）：不斷執行 實際狀態 (Actual State) vs. 期望狀態 (Desired State) 比對。一旦發現差異（例如 Node 宕機導致實際副本數少於期望），立即向 API Server 發送指令發起修復。

運行在每個 Worker Node 上的代理進程。
定期向 API Server 上報本節點的健康狀態與資源消耗。
透過 CRI（Container Runtime Interface） 調用底層容器運行時（如 containerd 或 CRI-O）建立、重啟或銷毀容器。