前言

寫這篇想要分享的重點：
帶領讀者瞭解 Kubernetes Cluster（Control Plane 與 Worker Node）的更細部的工作模式，並掌握組件之間的協同運作流程與除錯觀念。
這篇想要講什麼：

1. Control Plane 與 Worker Node 的核心組件職責劃分。
2. 一個 Pod 被建立時，背後跨組件的 5 大步驟。
3. Static Pods & DaemonSet 概念

為何要寫這篇：
延續前一章我們有了清楚的架構圖之後，我們要深入理解 Control Plane 和 Worker Node 的內部細節。

名詞對應

Control Plane: 主控面板
Worker Node: 工作節點
Scheduler: 調度器
Controller Manager: 控制器管理器
adapter: 轉接器

Control Plane 與 Worker Node 的核心組件職責劃分

我們重新recap一下架構全景, Kubernetes 採用經典的主從式（Master-Worker）架構, 其中可以直接劃分為兩大部份：

1. Control Plane
2. Worker Nodes

+-----------------------------------------------------------------------+
|                         Control Plane (Master)                        |
|                                                                       |
|   +-------------------+     +------------------+    +-------------+   |
|   |     etcd (KV)     |<--->|  kube-apiserver  |<---| scheduler   |   |
|   +-------------------+     +------------------+    +-------------+   |
|                                      ^                                |
|                                      |              +-------------+   |
|                                      +--------------| controller- |   |
|                                                     |  manager    |   |
|                                                     +-------------+   |
+-----------------------------------------------------------------------+
                                       ^
                         gRPC / HTTPS  |  (TLS Standard Port 6443)
                                       v
+-----------------------------------------------------------------------+
|                             Worker Node                               |
|                                                                       |
|   +-------------------+     +------------------+    +-------------+   |
|   |      kubelet      |<--->| Container Engine |    |  kube-proxy |   |
|   +-------------------+     | (containerd/CRI) |    +-------------+   |
|                             +------------------+                      |
+-----------------------------------------------------------------------+

1. Control Plane 核心成員

Control Plane 負責控管 Worker Node 的大小事，但實際上執行具體容器任務的是 Worker Nodes。這有點像是公司的管理層（Control Plane）負責制定策略、調度資源與監督進度，而不會直接跑去第一線經手各部門（Worker Node）的具體業務。

具體來說，Control Plane 負責整個 Cluster 的全域決策（如 Pod 調度）、監控 Cluster 狀態，以及回應 Cluster 事件。

kube-apiserver（Cluster 的總經理 / 唯一對外窗口）

• 職責：所有大小事都要過他，沒有他蓋章審核通通不能做！暴露 K8s API，是 Control Plane 中唯一的對外與對內通信入口。
• 特性：
  • 禁止私下溝通：所有組件（kubectl、kubelet、scheduler 等）都只能透過 API Server 交換資訊，組件之間不直接通信。
  • 嚴格把關：負責 Request 的認證（Authentication）、授權（Authorization）與入場控制（Admission Control）。
  • 彈性擴充：本身是無狀態（Stateless）服務，可以進行橫向擴展（Horizontal Scaling）來扛住高流量。

etcd（Cluster 的中央資料庫 / 機密檔案室）

• 職責：整個 Cluster 的記憶大腦。高度可用、強一致性的 Key-Value 分散式資料庫，儲存整個 K8s Cluster 的所有狀態與Metadata。
• 特性：
• 分散式共識：基於 Raft 演算法 運作，確保資料不遺失、不混亂。
• 單一窗口權限：只有 kube-apiserver 可以直接讀寫 etcd，其他組件(Components)想查資料都必須透過 API Server (kuber-apiserver)。
• 維護重點：Cluster 的命脈！必須定期對 etcd 進行 Snapshot 備份與恢復演練。

kube-scheduler（資源調度主管）

• 職責：有點像專案經理（PM），負責看哪裡有新任務(container)要弄一個人（Pod）來做，評估各部門（Node）的負載與能力，把任務指派給最合適的部門，但自己不經手實際業務。

• Schedule 兩大階段：

  1. Filtering（Predicates，硬性條件過濾）：過濾掉不符合 Pod 資源要求的 Node（例如 CPU/Memory 不足、標記了 Taints 污點）。
  2. Scoring（Priorities，軟性條件打分）：對通過過濾的 Node 進行綜合評分，選擇分數最高的 Node 進行綁定（Binding）。

kube-controller-manager（營運稽核主管 / 自動化維護者）

• 職責：負責盯緊公司的營運狀況。隨時比較「實際狀態（Current State）」與「預期狀態（Desired State）」，一旦發現不符（例如有員工離職、Pod 意外掛掉），立刻派人補齊。
• 常見內部控制器：
  • Node Controller：監控 Node 健康狀態，發現 Node 離線時觸發應變機制。
  • ReplicaSet Controller：確保指定數量的 Pod 副本時刻都在線上運作。
  • Endpoints Controller：維護 Service 與 Pod 之間的對應關係。

💡 簡單白話來說，Desired State（預期狀態 / 期望狀態） 就是你在 YAML 檔裡面寫下的「理想目標」。

• 用我們的智慧工廠比喻：
  • Desired State（預期狀態）：老闆向中控室下達的命令，例如：「這間工廠裡面，無論如何都必須要維持 3 台 Nginx 伺服器在運作！」
  • Current State（實際狀態）：廠房第一線現在實際上的狀況。例如：「糟糕，剛剛有一台 Node 機器壞掉，現在只剩 2 台 Nginx 還活著。」

2. Worker Node（工作節點）核心成員

Worker Node 負責提供運算資源，並運行實際的 Container 應用工作負載。

kubelet（現場主管 / 廠長）

• 職責：收到來自中控室的指令後，迅速調派並生成對應的 Pod 來執行容器任務。。
• 作業方式：
  • 透過 API Server 接收分配給該 Node 的 PodSpec 任務。
  • 呼叫 Container Runtime 創建/停止容器，並持續監控容器與 Pod 的健康狀態（Liveness / Readiness / Startup Probes），將狀態回報給 API Server。
• 注意：kubelet 是直接以 systemd 服務的形式常駐在 Node OS 上，而非以 Container 方式運行。若 kubelet 掛掉，無法透過 K8s 遠端除錯，必須直接 SSH 進到該 Worker Node 檢查 systemd 服務狀態與系統日誌（journalctl -u kubelet）。

CRI (Container Runtime Interface)（任務執行規範 / 公司 SOP / 控制面板）

• 職責：它就是一套 Spec（介面規範），定義了 K8s 與底層容器溝通的標準語言。
• 特性：就像公司訂出標準 SOP，告訴大家「只要符合這套規範的工具都可以拿來用」。這樣 K8s 就不需要為了支援不同的容器軟體而一直改 code，只要 Runtime 有實作 CRI 介面就能直接使用。

💡 這裡看到CRI, 後面會遇到好多XXI, 其實他們都只是抽象化的interface拉

Container Runtime（實際做事的工具）

• 職責：遵循 CRI 規範的實體執行引擎。接收到 kubelet 的指令後，真正去拉取 Image（容器映像檔）、創建並啟動/停止容器。
• 常見實作：containerd（最主流）、CRI-O（專為 K8s 打造）。
• 補充：Docker 本身沒有直接實作 CRI，所以現在 K8s 要用 Docker，中間需要透過一個叫做 cri-dockerd 的轉接器來當翻譯官。

kube-proxy（跑腿送文件的小助理）

• 職責：在每個 Node 上的網路proxy，維護Node上的網絡規則。
• 作業方式：實現 K8s Service API 的概念，透過配置 OS 的 iptables 或 IPVS 規則，實現 Pod 之間的負載均衡與 ClusterIP 流量轉發。

概念澄清: Pod / Image / Container

筆者認為這三者應該要理解清楚, 一層一層的說明(有點像是俄羅斯娃娃XD):

最外層-> Pod: 用來跑Container的Component
內層-> Container: 用來實際跑起來你的程式的虛擬環境
內核-> Image: 用來生成Container的藍圖

+-----------------------------------------------------------------------------------+
|  POD (多功能機台 / 獨立運作環境)                                                      |
|  - K8s 最小調度單元                                                                 |
|  - 提供共享資源：專屬 Pod IP / 共享 Volume (磁碟空間) / Network Namespace              |
|                                                                                   |
|   +------------------------------------+     +--------------------------------+   |
|   | Container 1 (主應用程式)             |     | Container 2 (輔助組件 Log)      |   |
|   |                                    |     |                                |   |
|   |  實體：運作中的 Process / 虛擬環境     |     |  實體：運作中的 Process / 虛擬環境 |   |
|   |  - 真正吃 CPU / Memory 處理資料      |     |  - 真正吃 CPU / Memory 處理資料   |   |
|   +------------------^-----------------+     +---------------^----------------+   |
|                      | (實體化生產)                            | (實體化生產)        |
+----------------------|---------------------------------------|--------------------+
                       |                                       |
          +------------+------------+             +------------+------------+
          |  Image (設計藍圖 A)      |             |  Image (設計藍圖 B)       |
          |  - 唯讀規格檔案 (App)     |             |  - 唯讀規格檔案 (Sidecar) |
          +-------------------------+             +-------------------------+

你的程式實際上不是跑在Pod上, 而是跑在Container的環境裡面

關鍵運作流程：建立一個 Deployment / Pod 的生命週期

當你在 Terminal 輸入 kubectl create deployment nginx --image=nginx 時，背後其實發生了一堆事情：

1. 發送請求與驗證：
   kubectl 將 YAML/命令行請求發送給 kube-apiserver。API Server 驗證身份（Authentication）與權限（Authorization），將 Deployment 物件寫入 etcd。
2. 控制器回應並建立 Pod：
   Deployment Controller 透過 API Server 的 Watch 機制察覺到新 Deployment，建立對應的 ReplicaSet；ReplicaSet Controller 接著生成對應的 Pod 物件（此時 Pod 的 spec.nodeName 為空，處於 Pending 狀態），並寫入 etcd。
3. 進行 Pod 調度分配：
   kube-scheduler 監聽到未分配 Node 的 Pod，執行 Filtering 與 Scoring 流程選定最佳 Node（例如 node-01），並向 API Server 發送 Binding 請求，將 node-01 寫入 Pod 的 spec.nodeName 欄位。
4. 節點接收指令與拉取映像檔：
   位於 node-01 的 kubelet 透過 Watch 發現有分配給自己的 Pod，向 API Server 獲取細節後，透過 CRI 介面呼叫 containerd 下載 Image 並啟動 Pod 內的容器。
5. 回報狀態與更新網路：
   容器啟動完成後，kubelet 向 API Server 更新 Pod 狀態為 Running。同時，各節點上的 kube-proxy 更新 iptables/IPVS 規則，確保該 Pod 的流量可被正確路由。

特殊 Pod 類型：Static Pods 與 DaemonSet

在 Kubernetes 中，並非所有 Pod 都是透過下指令產生的，有兩種特殊案例：

1. Static Pods（靜態 Pod）

• 運作機制：由特定節點上的 kubelet 直接管理與啟動，不須透過 kube-apiserver 與 kube-scheduler。

• 配置方式：kubelet 會定期讀取本地端特定目錄（預設常見為 /etc/kubernetes/manifests）下的 YAML 檔，並根據這些檔案直接管理容器。

• 常見應用場景：

  • Kubernetes Control Plane Bootstrapping：使用 kubeadm 建置Cluster時，apiserver、etcd、scheduler 與 controller-manager 本身通常就是以 Static Pods 的形式跑在 Control Plane Node 上。

• 除錯重點：當 Control Plane 組件出問題導致 API 無法回應時，需直接登入主機查看 /etc/kubernetes/manifests 目錄，或透過系統日誌（journalctl -u kubelet）來進行除錯。

2. DaemonSet

• 運作機制：由 K8s 的 DaemonSet Controller 管理，確保 Cluster 中每一個（或符合特定條件的）Node 上，都剛好運行一個 Pod。每當有新 Node 加入 Cluster 時，Pod 會自動在該 Node 上被建立；當 Node 被移除時，該 Pod 也會自動被垃圾回收（Garbage Collected）。
• 常見應用場景：
  • 網路外掛（CNI）：如 Calico、Flannel（需在每台 Node 上做網路轉發與tunnel）。
  • 日誌收集 Agent：如 Fluentd、Logstash。
  • 節點監控 Agent：如 Prometheus Node Exporter。

比較總結：Static Pods vs. DaemonSet

結語

• 本篇總結：
  Kubernetes 的核心架構由 Control Plane 下達決策與維持 Desired State，並透過 Worker Node 上的 kubelet 與 CRI Runtime (Containerd)。組件之間全數透過 API Server 交換訊息，展現了高解耦的架構設計。
• 下一篇預告：
  理解了 Control Plane 與 Worker Node 的架構後，明天 Day 03 我們將深入剖析 【底層】 Container Runtime 的演進：Docker vs. Containerd！釐清 CRI 規範、為什麼 K8s 要移除 Dockershim，以及 crictl、nerdctl 與 ctr 的實際操作！

Takeaway（方便讀者快速複習）

• 總經理（kube-apiserver）：唯一窗口，負責審核與轉發命令。
• 機密檔案室（etcd）：記憶大腦，負責記錄全廠資產與狀態（KV 分散式資料庫）。
• 排程 PM（kube-scheduler）：負責評估各 Node 的負載與條件，決定任務落腳處。
• 營運稽核（kube-controller-manager）：負責盯緊現狀與預期，隨時自動補單（Self-healing）。
• 現場廠長（kubelet）：常駐 Node 的 systemd 服務，接收指令並指揮 Runtime 幹活。
• SOP 規範（CRI）：介面標準，讓 K8s 能夠自由抽換底層容器引擎。
• 小助理（kube-proxy）：維護 OS 的 iptables/IPVS 規則，搞定跨節點網路通訊。
• 特殊 Pod 類型(Static Pods 與 DaemonSet): Static Pods 不須透過 API Server、由 kubelet 直接管理的組件（如 Control Plane 核心）；而DaemonSet 則是確保「每一台 Node 都會存在所需要的Pod」。
• Pod / Image / Container概念: Image 是靜態「藍圖」，Container 是真正執行程式的「實體」，而 Pod 則是包裹 Container 並提供網路與儲存資源的「載體機台」。