昨天把 K8s 存在的理由說清楚了，今天來把架構拆開來看，並說說當中元件的功能!

k8s 基礎概念

在看架構圖之前，需要先知道兩個基礎概念:

• Node：一台機器（實體或虛擬），是 K8s 用來跑工作負載的主機
• Pod：K8s 最小的執行單位，跑在 Node 上，裡面包著一個或多個 Container，共用同一個網路空間和儲存空間

一個 Node 上可以跑很多個 Pod，就像一台電腦上可以同時開很多個程式。

架構圖全貌

圖片來源：[Kubernetes 官方文件]

這張圖包含了一個 K8s Cluster 的所有核心元件，分成兩個區塊：

• 左側 Control Plane：大腦，負責決策和管理
• 右側 Worker Node：手腳，負責實際跑 Pod

Control Plane — 大腦

負責「決策」，不直接跑任何應用程式。

1. kube-api-server

• 所有指令的唯一入口。
  kubectl、CI/CD、內部元件溝通，全部都要先過它。負責驗證請求、把狀態存進 etcd、通知其他元件。

2. etcd

• 儲存整個 Cluster 的狀態（Node、Pod、Service 設定⋯⋯）。
• 只有 API Server 能讀寫它。
  etcd 掛了，Cluster 就失憶，現有服務仍在跑，但無法下任何新指令。

3. kube-scheduler

• 決定 Pod 要跑在哪個 Node 上。
  評估各 Node 的 CPU、記憶體，選出最適合的位置後，把結果寫回 API Server。
• 只負責決定放哪，不負責把 Pod 跑起來。

4. kube-controller-manager

• 確保現狀跟期望狀態一致。
  你說「我要 3 個 Pod」，它就一直盯著——少了補、多了刪。內部跑著很多 Controller，每個負責一種資源，邏輯都一樣：比對現狀和期望，有差就修正。

5. cloud-controller-manager

• 跟雲端平台（AWS、GCP、Azure）溝通的橋梁。
  建立 LoadBalancer 類型的 Service 時，它會去雲端真的建一個負載平衡器。

minikube 本地環境沒有這個元件。

Worker Node — 手腳

每個 Worker Node 都跑著三個元件：

1. kubelet

• Node 上的 K8s 代理人。
  接收 API Server 的指令、通知 Container Runtime 把 Pod 跑起來、定期回報 Pod 狀態、執行 Health Check。沒有 kubelet，這個 Node 就跟 Cluster 斷線了。

2. kube-proxy

• 處理 Node 上的網路規則。
  建立 Service 時，它在每個 Node 上設定對應的路由規則，確保流量能被正確導到對應的 Pod。

3. Container Runtime（CRI）

• 真正把 Container 跑起來的底層引擎（minikube 預設用 containerd）。

請求完整流程

當使用者打開瀏覽器請求 Todo App，流量路徑長這樣：

使用者的瀏覽器
      │
      ▼
   Ingress          ← 統一對外入口，根據規則決定送去哪個 Service
      │               （就像 nginx 反向代理，/api 送後端、/ 送前端）
      ▼
   Service          ← 穩定的內部入口，用 Label 找到對應的 Pod
      │               （Pod IP 一直在變，Service 提供固定的虛擬 IP）
      ▼
     Pod            ← 實際跑著 Container 的地方
      │               （FastAPI 後端、React 前端、MySQL 資料庫各是一組 Pod）
      ▼
   回應使用者

這條路徑上完全沒有 Control Plane 的元件。

• API Server、Scheduler、Controller Manager 負責的是「管理」確保整個系統的狀態是正確的。
• 流量是直接在 Worker Node 之間流動的，

實際操作

今天目標：親眼看到架構圖裡的元件實際存在。

Step 1：看系統元件

K8s 的系統元件本身也是 Pod，跑在 kube-system namespace：

kubectl get pods -n kube-system

你會看到類似這樣的輸出：

注意這裡沒有 cloud-controller-manager，因為 minikube 是本地環境。

K8s 用自己的機制管理自己，整個系統非常一致。

Step 2：看 Node 詳細資訊

kubectl get nodes -o wide

CONTAINER-RUNTIME 欄位會看到 containerd，這就是 CRI。

Step 3：確認 API Server 的狀態

kubectl describe pod kube-apiserver-minikube -n kube-system

看 Containers 裡的 --etcd-servers 參數，會指向 etcd 的位置——印證了「API Server 是唯一跟 etcd 溝通的元件」這件事。

Step 4：用 Dashboard 對照架構

minikube dashboard

打開之後：

1. logo旁邊的選單切換到 All Namespaces，才能看到 kube-system 裡的系統 Pod
2. 左側選單 點 Nodes，可以看到有一個 minikube 節點
3. 左側選單 點 Pods，可以看到剛剛提過架構圖裡的元件

進階：兩個重要設計觀念

這段補充架構背後的設計思路，有興趣再看。

為什麼 etcd 那麼重要？

etcd 是整個 Cluster 的唯一事實來源。所有狀態都在這裡，其他元件依據它去執行對應的動作。

etcd 掛了之後：現有 Pod 繼續跑、流量不受影響，但無法下新指令、自癒機制停止。所以生產環境的 etcd 通常會定期備份，並跑成 3 或 5 個節點的叢集（Raft 共識演算法確保高可用）。

為什麼管理面和流量路徑要分離？

這是 K8s 刻意的設計——管理面（Control Plane）和資料面（Data Plane）分離。

• 管理面：決定系統應該長什麼樣子
• 資料面：真正把流量送到對的地方
  好處是：Control Plane 升級、維護、甚至短暫不可用時，已部署的服務不受任何影響。

小結

Control Plane（大腦） 負責決策，不服務流量：

Worker Node（手腳） 負責實際執行：

最重要的一條線：使用者 → Ingress → Service → Pod，Control Plane 不在這條路徑上。

明天開始實作，寫第一個 Pod YAML，把 Todo App 的後端跑在 K8s 上，同時說清楚什麼是「宣告式思維」!