為什麼要懂 K8s 架構？
新手常見的疑問：
「我會 kubectl apply -f xxx.yaml，這樣不夠嗎？要懂底層架構幹嘛？」
會用 yaml 是 30 分，懂架構是 70 分。差別在這裡：
- 不懂架構：Pod 卡在
Pending你只會盯著螢幕 - 懂架構：你會看 events、檢查 scheduler、看 node 狀態，3 分鐘定位
K8s 架構：Master + Worker
K8s 是一個叢集（cluster），由兩種角色的機器組成：
┌──────────────── 整個 K8s 叢集 ────────────────┐
│ │
│ Master Node │
│ ┌────────────────────────┐ │
│ │ 「決策層」（管理者） │ │
│ │ • 決定 Pod 跑哪台 │ │
│ │ • 監控所有資源狀態 │ │
│ │ • 接收 kubectl 指令 │ │
│ └────────────────────────┘ │
│ │
│ Worker Node 1 Worker Node 2 Worker N │
│ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │「執行層」 │ │「執行層」 │ │「執行層」│ │
│ │ 跑 Pod │ │ 跑 Pod │ │ 跑 Pod │ │
│ └──────────┘ └──────────┘ └────────┘ │
└────────────────────────────────────────────────┘比喻：
- Master Node = 公司管理層（決策、調度、監控）
- Worker Node = 員工（實際執行工作）
- kubectl = 你發給管理層的工作單
Master Node 上的四大組件
Master 上有 4 個組件，缺一個叢集就掛：
1. API Server — 叢集的大門
職責：所有請求的唯一入口。
你 ──► kubectl ──► API Server ──► 其他組件不管是你打 kubectl get pods、Dashboard 點按鈕、還是組件之間互通，全部都要先走 API Server。它做三件事：
- 驗證身份（你是誰？token 有效嗎？）
- 檢查權限（你能不能做這件事？RBAC）
- 轉發請求 + 寫狀態到 etcd
2. etcd — 叢集的大腦
職責：儲存整個叢集的狀態。
etcd 是一個 key-value 資料庫（類似 Redis 但保證一致性）。它記了：
- 叢集裡有哪些 Node、狀態如何
- 部署了哪些 Pod、跑在哪台 Node、健康嗎
- 你定義的所有 Deployment / Service / ConfigMap...
備份 etcd = 備份整個叢集設定。etcd 掛了 = 叢集記憶喪失，是正式環境最重要的備份對象。
3. Scheduler — 調度員
職責：新 Pod 該分配到哪個 Worker？
當你建立一個 Pod，Scheduler 會：
例：Node A 用了 80% CPU、Node B 用了 20% → 新 Pod 派給 Node B。
新手最常見的錯：以為 Pod 卡在 Pending 是 Pod 壞了，通常是 Scheduler 找不到合適的 Node（資源不夠 / nodeSelector 沒節點符合 / 有 taint）。
4. Controller Manager — 自我修復的引擎
職責：持續監控「現狀 vs 期望」是否一致，不一致就修。
你說：「我要 3 個 nginx Pod」（期望狀態，存 etcd）
Controller Manager 一直在問：「現在真的有 3 個嗎？」
├─ 有 → 沒事
└─ 只剩 2 個（一個掛了）→ 通知 Scheduler 補一個K8s 的「自我修復」、「自動擴縮容」、「滾動更新」全部都是 Controller Manager 在背後做。
它裡面有很多種 Controller：Deployment Controller、ReplicaSet Controller、Node Controller、Job Controller... 每個負責一種資源。
Worker Node 上的三大組件
Worker 上的組件比較少，3 個：
1. kubelet — 節點管家
職責：管理這個 Node 上的所有 Pod。
API Server: 「kubelet，幫我在你的 Node 上跑一個 nginx Pod」
kubelet: 「收到」── 呼叫 Container Runtime 把容器跑起來
（定時回報 Pod 健康狀態給 API Server）比喻：每個 Worker 上的「值班 leader」，接收指令、回報狀況。
2. Container Runtime — 真正跑容器的引擎
職責：拉 image、建容器、啟停容器。
K8s 不直接跑容器，它叫 Container Runtime 去跑。常見的：
- containerd（K8s 主流，輕量）
- CRI-O（Red Hat 系統用）
- Docker Engine（早期支援，1.24 後移除直接支援）
3. kube-proxy — 網路轉發
職責：實作 Service 的網路規則（讓 Service 真正能用）。
當你建立一個 Service，kube-proxy 在每個 Node 上維護一張轉發表：
Service 10.0.0.5:80 → 後端 Pod IP1:8080 / Pod IP2:8080 / Pod IP3:8080請求進到 Service 的虛擬 IP，kube-proxy 把它負載均衡轉到後端某個 Pod。
技術上是用 iptables 或 IPVS 實作的——不用記細節，知道「Service 能轉發是 kube-proxy 的功勞」就夠。
一個完整流程：你打了 kubectl apply 之後發生什麼
你輸入：kubectl apply -f deployment.yaml（要 3 個 nginx Pod）
1️⃣ kubectl ────► API Server
送請求過去
2️⃣ API Server
驗證身份 + 權限 → 通過
把「要 3 個 nginx Pod」寫進 etcd
3️⃣ Deployment Controller（在 Controller Manager 裡）
發現有個新 Deployment → 建立 ReplicaSet
ReplicaSet Controller 發現要 3 個 Pod → 建 3 個 Pod 物件
4️⃣ Scheduler
發現有 3 個 Pod 還沒分配 Node
挑 Node：Pod-1 → Node-A, Pod-2 → Node-B, Pod-3 → Node-C
把決定寫回 etcd
5️⃣ kubelet（各 Node 上的）
發現 etcd 說「你要跑這個 Pod」
呼叫 Container Runtime → 拉 image → 跑容器
回報「Pod Running」給 API Server
6️⃣ Controller Manager
持續監控：3 個 Pod 都活著嗎？
有一個掛了 → 立刻補新的
整個流程平均 5~10 秒。中間任何一個組件掛了都會卡住。
怎麼親眼看到這些組件？
K8s 自己的組件就是用 Pod 跑的，住在 kube-system namespace：
kubectl get pods -n kube-system你會看到：
- coredns（叢集內 DNS）
- kube-proxy（每個 Node 一份）
- kube-apiserver（API Server 本身）
- kube-scheduler
- kube-controller-manager
- etcd
重點整理
- K8s = Master 管理層 + Worker 執行層，叢集架構
- Master 4 組件：API Server（大門）+ etcd（資料庫）+ Scheduler（調度）+ Controller Manager（自我修復）
- Worker 3 組件：kubelet（管家）+ Container Runtime（跑容器）+ kube-proxy（網路）
- 你打
kubectl apply走完整個流程：API Server → etcd → Controller → Scheduler → kubelet → Container Runtime - 不懂架構排錯會很痛——Pod Pending 通常是 Scheduler 問題、Pod 起不來通常是 kubelet 拉不到 image
下一步
架構懂了，但目前都是紙上談兵。下一篇我們真的把 K8s 裝起來：k3d 跟 minikube 怎麼選？新手安裝指南 ——本機跑一個迷你 K8s 叢集，跟著做後面所有實戰。
📅 下一篇（2026-05-02 已上線）：本地裝 K8s：k3d 與 minikube 怎麼選？新手安裝指南
k3d 輕量快、minikube 老牌穩，實測比較加完整安裝步驟（macOS / Windows / Linux）。
📚 完整系列總覽：K8s 系列教學首頁（共 40 課，按學習路徑順序排）