Kubernetes 架構完整解析：Control Plane、Node、元件一次搞懂

想學好 Kubernetes，第一步是搞懂它的架構。

很多人卡在這裡：看到一堆元件名稱，API Server、etcd、kubelet⋯⋯不知道它們各自做什麼，更不知道它們怎麼協作。

這篇文章會用最清楚的方式，帶你走過 Kubernetes 的每一個重要元件。

Kubernetes 的基本介紹，請參考 Kubernetes 完整指南。

---

架構總覽：Control Plane vs Worker Node

Kubernetes 叢集由兩種角色組成：

角色	功能	比喻
Control Plane	決策中心	公司總部
Worker Node	執行工作	分公司

Control Plane（控制平面）

Control Plane 是 Kubernetes 的大腦。

它負責：

• 接收使用者的指令
• 儲存整個叢集的狀態
• 決定 Pod 要跑在哪裡
• 監控並維持期望狀態

包含的元件：

• API Server
• etcd
• Scheduler
• Controller Manager

Worker Node（工作節點）

Worker Node 是實際執行容器的地方。

它負責：

• 執行被分配的 Pod
• 回報 Pod 狀態給 Control Plane
• 處理網路流量

包含的元件：

• kubelet
• kube-proxy
• Container Runtime

架構圖

┌─────────────────────────────────────────────────────────────┐
│                      Control Plane                          │
│  ┌──────────────┐  ┌────────┐  ┌───────────┐  ┌──────────┐ │
│  │  API Server  │  │  etcd  │  │ Scheduler │  │Controller│ │
│  │              │  │        │  │           │  │ Manager  │ │
│  └──────────────┘  └────────┘  └───────────┘  └──────────┘ │
└─────────────────────────────────────────────────────────────┘
                              │
                              │ API 通訊
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                       Worker Nodes                          │
│  ┌─────────────────────────┐  ┌─────────────────────────┐  │
│  │       Node 1            │  │       Node 2            │  │
│  │  ┌───────┐ ┌─────────┐  │  │  ┌───────┐ ┌─────────┐  │  │
│  │  │kubelet│ │kube-proxy│  │  │  │kubelet│ │kube-proxy│  │  │
│  │  └───────┘ └─────────┘  │  │  └───────┘ └─────────┘  │  │
│  │  ┌─────────────────┐    │  │  ┌─────────────────┐    │  │
│  │  │Container Runtime│    │  │  │Container Runtime│    │  │
│  │  └─────────────────┘    │  │  └─────────────────┘    │  │
│  │  ┌─────┐ ┌─────┐        │  │  ┌─────┐ ┌─────┐        │  │
│  │  │ Pod │ │ Pod │        │  │  │ Pod │ │ Pod │        │  │
│  │  └─────┘ └─────┘        │  │  └─────┘ └─────┘        │  │
│  └─────────────────────────┘  └─────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

重點理解：

所有元件之間的通訊都是透過 API Server。沒有元件會直接跟另一個元件溝通（除了 API Server 存取 etcd）。

---

Control Plane 四大元件詳解

Control Plane 有四個核心元件，每個都有明確的職責。

API Server（kube-apiserver）

一句話說明： Kubernetes 的前門，所有操作都要經過它。

職責：

功能	說明
請求入口	所有 kubectl 指令都送到這裡
驗證請求	檢查請求是否合法
授權檢查	確認使用者有權限執行
資料存取	唯一可以存取 etcd 的元件

運作方式：

使用者 → kubectl → API Server → etcd
                       ↓
              其他元件 Watch 變更

重要特性：

• RESTful API：所有操作都是標準的 HTTP 請求
• Watch 機制：其他元件可以訂閱資源變更
• 水平擴展：可以跑多個 API Server 做負載均衡

實際操作：

# 直接呼叫 API Server
kubectl get --raw /api/v1/namespaces/default/pods

# 查看 API Server 端點
kubectl cluster-info

etcd

一句話說明： Kubernetes 的資料庫，儲存整個叢集的狀態。

職責：

功能	說明
狀態儲存	所有資源的設定和狀態
分散式	多節點確保高可用
一致性	使用 Raft 協定保證資料一致

儲存什麼？

• Pod、Deployment、Service 等所有資源的定義
• ConfigMap、Secret 的內容
• 叢集的設定資訊

不儲存什麼？

• 容器日誌
• 應用程式資料
• 監控指標

為什麼重要：

etcd 掛了，整個叢集就無法運作。

備份建議：

# 備份 etcd
ETCDCTL_API=3 etcdctl snapshot save backup.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

插圖：三台伺服器組成的 etcd 叢集示意圖

場景描述： 三台伺服器組成的 etcd 叢集示意圖，每台伺服器標示為 etcd-1、etcd-2、etcd-3，中間有雙向箭頭表示 Raft 共識協定通訊，其中一台標示為 Leader，另外兩台標示為 Follower。需要顯示的中文字：主節點、從節點

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述中的關鍵元素

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪、發光特效

Slug: kubernetes-etcd-cluster-diagram

Scheduler（kube-scheduler）

一句話說明： 決定 Pod 要跑在哪個 Node 上。

職責：

功能	說明
監控未調度的 Pod	Watch 沒有指定 Node 的 Pod
評估 Node	根據條件篩選和評分
綁定 Pod	把 Pod 指派給最適合的 Node

調度流程：

新 Pod 建立（未指定 Node）
        ↓
    過濾階段
    - 資源夠不夠？
    - 有沒有污點？
    - 親和性規則？
        ↓
    評分階段
    - 資源使用率
    - Pod 分散程度
    - 自訂優先級
        ↓
    選擇最高分的 Node
        ↓
    綁定 Pod 到 Node

過濾條件（Predicates）：

條件	說明
PodFitsResources	CPU、記憶體夠不夠
PodFitsHostPorts	主機 Port 有沒有衝突
PodMatchNodeSelector	符不符合 NodeSelector
PodToleratesNodeTaints	能不能容忍 Node 的污點

評分因素（Priorities）：

因素	說明
LeastRequestedPriority	優先選資源使用率低的
BalancedResourceAllocation	CPU 和記憶體使用要平衡
SelectorSpreadPriority	同一個 Service 的 Pod 要分散

Controller Manager（kube-controller-manager）

一句話說明： 確保叢集的實際狀態符合期望狀態。

職責：

功能	說明
監控狀態	持續 Watch 資源變更
比較差異	實際狀態 vs 期望狀態
執行調整	讓實際狀態趨近期望

包含的控制器：

控制器	職責
Deployment Controller	管理 Deployment 和 ReplicaSet
ReplicaSet Controller	維持 Pod 副本數量
Node Controller	監控 Node 狀態
Service Controller	管理雲端負載均衡器
Endpoint Controller	維護 Service 和 Pod 的對應
Namespace Controller	處理 Namespace 刪除

控制迴圈概念：

while true:
    當前狀態 = 從 API Server 取得
    期望狀態 = 從資源定義取得
    if 當前狀態 != 期望狀態:
        執行調整動作
    sleep(一小段時間)

範例：Deployment Controller

你說「我要 3 個 Pod」：

1. Controller 發現目前 0 個 Pod
2. 建立一個新 Pod
3. 發現目前 1 個 Pod
4. 再建立一個
5. 發現目前 2 個 Pod
6. 再建立一個
7. 發現目前 3 個 Pod，符合期望
8. 持續監控，如果有 Pod 掛掉就補新的

---

🏗️ 需要 Kubernetes 架構設計？

從概念驗證到生產環境，我們協助企業設計符合需求的 K8s 架構。

👉 預約架構諮詢

---

Worker Node 元件解析

每個 Worker Node 上都執行著三個核心元件。

kubelet

一句話說明： Node 上的代理人，負責管理該 Node 上的所有 Pod。

職責：

功能	說明
接收指令	從 API Server 取得 Pod 規格
啟動容器	透過 Container Runtime 執行
健康檢查	執行 Liveness 和 Readiness Probe
回報狀態	定期向 API Server 回報

運作流程：

API Server
    ↓ Watch PodSpec
kubelet
    ↓ 呼叫 CRI
Container Runtime
    ↓ 建立容器
容器執行

健康檢查類型：

類型	用途	失敗時
Liveness Probe	容器是否存活	重啟容器
Readiness Probe	容器是否準備好	從 Service 移除
Startup Probe	啟動是否完成	延遲其他檢查

重要設定：

# kubelet 設定範例
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
maxPods: 110
imageGCHighThresholdPercent: 85
imageGCLowThresholdPercent: 80

kube-proxy

一句話說明： 處理網路規則，實現 Service 的負載均衡。

職責：

功能	說明
維護網路規則	iptables 或 IPVS 規則
實現 Service	ClusterIP、NodePort、LoadBalancer
負載均衡	把流量分配到後端 Pod

運作模式：

模式	說明	效能
iptables	預設模式	中等
IPVS	大規模叢集	較好
userspace	舊版模式	較差

iptables 模式運作：

外部流量 → Service IP → iptables 規則 → Pod IP

kube-proxy 會監控 Service 和 Endpoint 的變更，自動更新 iptables 規則。

Container Runtime

一句話說明： 實際執行容器的程式。

常見選擇：

Runtime	說明	使用場景
containerd	Docker 公司開源	最常用，預設選擇
CRI-O	Red Hat 開發	OpenShift 預設
Docker	已不直接支援	透過 cri-dockerd

為什麼 Kubernetes 不再直接支援 Docker？

Kubernetes 1.24 移除了 dockershim。但這不代表不能用 Docker 映像檔。

關鍵理解：

• Docker 映像檔（OCI 格式）：✅ 完全支援
• Docker 作為 Runtime：❌ 需要額外的 cri-dockerd

大多數情況下，直接用 containerd 就好。

插圖：單一 Worker Node 的內部架構圖

場景描述： 單一 Worker Node 的內部架構圖，頂部是 kubelet 方塊連接到 API Server，中間是 kube-proxy 方塊處理網路流量，底部是 Container Runtime 方塊上面跑著三個 Pod 容器，每個元件之間有箭頭標示通訊方向。需要顯示的中文字：網路流量、容器執行

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述中的關鍵元素

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪、發光特效

Slug: kubernetes-worker-node-components

---

元件之間如何溝通

理解元件之間的溝通方式，是深入理解 Kubernetes 的關鍵。

通訊原則

核心原則：所有通訊都透過 API Server。

通訊方向	說明
使用者 → API Server	kubectl 或 API 呼叫
API Server → etcd	讀寫叢集狀態
Controller → API Server	Watch 資源變更
Scheduler → API Server	取得未調度的 Pod
kubelet → API Server	回報 Node 和 Pod 狀態

為什麼這樣設計？

• 統一的存取點，方便做認證授權
• 所有操作都有紀錄
• 容易做水平擴展

請求流程解析

範例：建立一個 Deployment

kubectl apply -f deployment.yaml

完整流程：

1. kubectl 發送 POST 請求到 API Server
   POST /apis/apps/v1/namespaces/default/deployments

2. API Server 驗證和處理
   - 驗證 YAML 格式
   - 檢查使用者權限
   - 寫入 etcd

3. Deployment Controller 收到通知
   - Watch 機制偵測到新 Deployment
   - 建立對應的 ReplicaSet

4. ReplicaSet Controller 收到通知
   - 偵測到新 ReplicaSet
   - 建立指定數量的 Pod

5. Scheduler 收到通知
   - 偵測到未調度的 Pod
   - 選擇適合的 Node
   - 更新 Pod 的 NodeName

6. kubelet 收到通知
   - 偵測到被指派的 Pod
   - 呼叫 Container Runtime 啟動容器
   - 回報 Pod 狀態

Watch 機制

Watch 是 Kubernetes 的核心機制之一。

運作方式：

Controller                    API Server
    │                              │
    │── Watch /api/v1/pods ───────▶│
    │                              │
    │◀─── 初始資料列表 ────────────│
    │                              │
    │◀─── 變更事件（新增）─────────│
    │◀─── 變更事件（修改）─────────│
    │◀─── 變更事件（刪除）─────────│
    │                              │

優點：

• 即時通知，不用輪詢
• 降低 API Server 負擔
• 減少網路流量

控制迴圈（Reconciliation Loop）

每個 Controller 都運行著控制迴圈：

┌────────────────────────────────────────┐
│                                        │
│   ┌──────────┐      ┌──────────┐      │
│   │ 期望狀態 │      │ 實際狀態 │      │
│   │ (Spec)   │      │ (Status) │      │
│   └────┬─────┘      └────┬─────┘      │
│        │                  │            │
│        └───────┬──────────┘            │
│                ▼                       │
│         ┌──────────┐                   │
│         │   比較   │                   │
│         └────┬─────┘                   │
│              │                         │
│              ▼                         │
│    ┌─────────────────┐                 │
│    │ 差異？執行調整  │                 │
│    └─────────────────┘                 │
│                                        │
└────────────────────────────────────────┘

這就是「宣告式」的精髓：

你說「我要什麼」，Kubernetes 自己想辦法達成。

---

💡 K8s 架構有問題？

架構設計影響後續的維運成本和穩定性。讓專家幫你檢視。

👉 預約免費諮詢

---

高可用架構設計

生產環境需要高可用架構。

單點故障風險

元件	掛掉會怎樣
API Server	無法下指令，但現有 Pod 繼續跑
etcd	叢集完全無法運作
Scheduler	新 Pod 無法調度
Controller Manager	無法自動修復
kubelet	該 Node 的 Pod 無法管理

Multi-Master 架構

生產環境至少要有 3 個 Control Plane 節點。

架構圖：

              Load Balancer
                   │
       ┌───────────┼───────────┐
       ▼           ▼           ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Master 1 │ │ Master 2 │ │ Master 3 │
│          │ │          │ │          │
│API Server│ │API Server│ │API Server│
│Scheduler │ │Scheduler │ │Scheduler │
│Controller│ │Controller│ │Controller│
│  etcd    │ │  etcd    │ │  etcd    │
└──────────┘ └──────────┘ └──────────┘

運作方式：

元件	高可用機制
API Server	多個實例，前面放負載均衡器
etcd	Raft 共識，需要多數節點
Scheduler	Leader Election，只有一個在運作
Controller Manager	Leader Election，只有一個在運作

etcd 叢集

etcd 使用 Raft 共識協定，需要奇數個節點。

節點數	容忍故障數	建議
1	0	測試環境
3	1	生產環境最低要求
5	2	大型生產環境
7	3	超大規模

為什麼是奇數？

Raft 需要多數決。3 個節點可以容忍 1 個故障（2 > 3/2），4 個節點也只能容忍 1 個故障（3 > 4/2）。

生產環境建議

Control Plane：

項目	建議
節點數	至少 3 個
資源	4 CPU、16GB RAM 以上
磁碟	SSD，尤其是 etcd
網路	低延遲，穩定

etcd：

項目	建議
獨立部署	大規模時考慮分離
備份	定期自動備份
監控	監控延遲和磁碟使用

Worker Node：

項目	建議
數量	根據負載決定
分散部署	跨可用區
資源預留	為系統元件保留資源

更多雲端服務的架構選擇，請參考 Kubernetes 雲端服務完整比較。

---

FAQ：常見問題

Q1: Control Plane 可以跑 Pod 嗎？

預設不行，但可以設定。

Control Plane 節點預設有 Taint，阻止一般 Pod 被調度上去。

# 查看 Taint
kubectl describe node master-node | grep Taints

# 移除 Taint（不建議生產環境）
kubectl taint nodes master-node node-role.kubernetes.io/control-plane:NoSchedule-

生產環境建議讓 Control Plane 專心做管理。

Q2: etcd 資料要備份嗎？

絕對要。

etcd 存了整個叢集的狀態，沒有它什麼都恢復不了。

備份策略：

• 定期自動備份（每天至少一次）
• 備份到遠端儲存
• 定期測試還原

Q3: Scheduler 和 Controller Manager 為什麼要 Leader Election？

避免衝突。

想像如果有 3 個 Scheduler 同時運作，同一個 Pod 可能被指派到不同 Node，會造成混亂。

Leader Election 確保同一時間只有一個實例在做決策，其他是備援。

Q4: kubelet 掛了會怎樣？

該 Node 上的 Pod 會變成孤兒。

• Pod 還是會繼續跑（除非容器本身掛了）
• 但沒辦法重啟、更新、或做健康檢查
• Control Plane 會把該 Node 標記為 NotReady
• 一段時間後，Pod 會被重新調度到其他 Node

Q5: 如何確認元件狀態？

# 查看元件狀態
kubectl get componentstatuses

# 查看 Node 狀態
kubectl get nodes

# 查看系統 Pod
kubectl get pods -n kube-system

# 查看 etcd 狀態（如果有權限）
kubectl exec -n kube-system etcd-master -- etcdctl endpoint health

---

下一步

理解了 Kubernetes 架構後，你可以：

目標	行動
學習核心物件	閱讀 Kubernetes 核心物件教學
了解網路架構	閱讀 Kubernetes 網路架構指南
選擇雲端服務	閱讀 Kubernetes 雲端服務比較
動手實作	閱讀 Kubernetes 入門教學

---

🚀 需要專業的 Kubernetes 架構諮詢？

無論是新建叢集還是優化現有架構，CloudInsight 都能提供專業協助。

👉 立即預約諮詢

---

延伸閱讀

• Kubernetes 完整指南 - K8s 入門總覽
• Kubernetes 核心物件教學 - Pod、Deployment、Service 詳解
• Kubernetes 網路架構指南 - CNI、Service、Ingress
• Kubernetes 雲端服務比較 - EKS、GKE、AKS

---

參考資料

• Kubernetes 官方文件 - 架構
• Kubernetes 組件
• etcd 官方文件
• Kubernetes API Server