深入理解 Kubernetes 架構：從控制平面到工作節點完整拆解

Kubernetes（簡稱 K8s）是目前最主流的容器編排平台，由 Google 發起、現由 CNCF 基金會維護。它能幫助我們自動化部署、擴縮和管理容器化的應用程式，在現代 DevOps 與雲端原生的生態中扮演著核心角色。

早期我們習慣把所有功能塞進一個單體應用裡，擴展和更新都很頭痛。隨著容器技術興起，微服務架構逐漸成為主流，但容器一多，管理起來就是噩夢。K8s 正是為了解決這個問題而誕生的，它帶來了自動擴展、自我修復、滾動更新等能力，讓應用能穩定地跑在生產環境裡，同時也支援跨雲部署，靈活度非常高。

這篇文章我會從整體架構出發，帶你逐一認識 K8s 的每個核心元件，搞懂它們各自負責什麼、彼此怎麼協作。

K8s 的基礎觀念

在往下走之前，先把幾個基本概念理清楚：

觀念	說明
容器（Container）	輕量級虛擬化技術，把應用和相依套件打包在一起，啟動快、資源利用率高
容器編排（Orchestration）	當容器數量暴增時，靠人力管理不切實際，需要自動化工具來處理部署、擴縮、監控
K8s 叢集（Cluster）	由控制平面節點（管理叢集狀態）和工作節點（實際跑容器）組成的一組機器

整體架構概覽

Kubernetes 整體架構圖（圖片來源：DevOpsCube）

K8s 的架構可以拆成兩大塊：

控制平面（Control Plane）：叢集的大腦，包含 API Server、etcd、Scheduler、Controller Manager、Cloud Controller Manager。負責管理叢集狀態、調度 Pod、監控健康狀況。
工作節點（Worker Nodes）：實際跑應用容器的機器，每個節點上都有 kubelet、kube-proxy 和容器執行環境（Container Runtime）。

接下來我會詳細拆解每個元件。

控制平面元件

Kube-API Server

API Server 是整個 K8s 叢集的入口，所有操作（不管是 kubectl 指令還是其他元件的內部溝通）都得經過它。

它的核心職責：

功能	說明
驗證與授權	確認請求者身份，根據 RBAC 等策略決定是否放行
叢集狀態中心	所有狀態資訊的存取都透過它來統一管理
通訊樞紐	其他控制平面元件和工作節點都透過 API Server 來溝通

運作流程：收到請求 → 身份驗證 → 授權檢查 → 資料驗證 → 寫入 etcd → 通知其他元件。

Etcd

etcd 是一個分散式鍵值儲存系統，K8s 把所有叢集資料（Pod、Service、ConfigMap、Secret 等）都存在這裡。它就像是 K8s 的資料庫。

特性	說明
資料儲存	保存所有叢集狀態資料
高可用與一致性	分散式架構確保資料在故障時仍可靠
高效讀寫	支援高頻的鍵值對操作

API Server 透過 etcd API 進行讀寫，其他元件則可以監聽 etcd 的變化來做出對應反應。

Kube-Scheduler

Scheduler 負責決定新建立的 Pod 應該跑在哪個節點上，它會根據資源狀況和調度策略來選擇最合適的節點。

能力	說明
資源調度	根據節點剩餘資源和 Pod 需求來配對
策略彈性	支援親和性、反親和性、資源優先等多種策略
負載均衡	合理分配負載，避免單一節點過載

Kube-Controller-Manager

Controller Manager 管理著一堆背景控制器（Node Controller、Replication Controller、Endpoint Controller 等），它們負責監聽叢集狀態變化並自動執行修復。

簡單來說，它就是確保「實際狀態」跟「期望狀態」一致的守護者。比方說你宣告要 3 個副本，有一個掛了，Controller Manager 就會自動補一個回來。

Cloud Controller Manager

這個元件把 K8s 和底層雲端平台（AWS、GCP、Azure 等）串接起來，處理雲端資源的管理，例如節點建立、負載平衡器配置、雲端儲存掛載等。

如果你的叢集跑在地端（on-premise），這個元件就不需要。

工作節點元件

Kubelet 與工作節點元件交互圖（圖片來源：DevOpsCube）

Kubelet

Kubelet 跑在每個工作節點上，是節點的代理程式。它負責：

職責	說明
Pod 管理	根據 API Server 的指示啟動、停止 Pod
狀態回報	定期向 API Server 報告節點與 Pod 狀態
設定管理	根據取得的配置來管理容器運行環境

Kubelet 透過 CRI（Container Runtime Interface）與容器執行環境溝通，呼叫 containerd 等來實際管理容器。

Kube-Proxy

Kube-Proxy 負責每個節點上的網路規則維護，處理 Pod 間的網路通訊和負載平衡。

功能	說明
服務發現	維護服務 IP 到 Pod 的對應關係
負載平衡	透過 iptables 或 IPVS 分發流量
網路路由	確保節點內外的通訊正確路由

Container Runtime

容器執行環境是真正跑容器的引擎，常見的有 containerd 和 CRI-O。它負責拉取映像檔、啟動容器、資源隔離（透過 cgroup 和 namespace）等底層工作。

K8s 網路模型

Pod 與 Service 網路

K8s 的網路模型有幾個核心原則：

類型	重點
Pod 網路	每個 Pod 有唯一 IP，叢集內可直接存取，不需 NAT
Service 網路	透過 Cluster IP 暴露一組 Pod，搭配 DNS 做服務發現
CNI 外掛	支援 Flannel、Calico、Weave 等多種網路實作

Network Policy

網路策略讓你可以定義 Pod 之間的通訊規則，控制誰可以跟誰溝通，實現微分段（micro-segmentation）的安全隔離。

範例：只允許帶有 app: frontend 標籤的 Pod 存取 nginx：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-nginx
spec:
  podSelector:
    matchLabels:
      app: nginx
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 80

K8s 儲存架構

Volume（卷）

Volume 跟 Pod 的生命週期綁定，用來在容器之間共享資料。常見類型：

類型	用途
emptyDir	暫存資料，Pod 刪除即消失
hostPath	掛載宿主機目錄
nfs	多 Pod 共享網路檔案系統
configMap / secret	注入設定或敏感資料
persistentVolumeClaim	綁定持久化儲存

PV 與 PVC

PV（Persistent Volume）是叢集級的儲存資源，生命週期獨立於 Pod。PVC（Persistent Volume Claim）則是使用者的儲存請求，K8s 會自動配對適合的 PV。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

StorageClass

StorageClass 提供動態供應 PV 的機制。管理員定義好不同等級的儲存（SSD、HDD 等），使用者建立 PVC 時指定 StorageClass，K8s 就會自動建立對應的 PV。

K8s 安全機制

認證（Authentication）

機制	說明
X.509 憑證	常用於叢集管理員
Service Account	Pod 內部元件的認證，K8s 自動管理
OIDC / OAuth	整合外部身分提供者
靜態 Token	僅適合開發測試環境

授權（Authorization）

最常用的是 RBAC（基於角色的存取控制），透過 Role + RoleBinding 來定義誰可以對哪些資源做什麼操作：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Secret 管理

K8s 透過 Secret 物件來管理密碼、Token、憑證等敏感資料。建議搭配 etcd 加密和外部密鑰管理工具（如 Vault）來提升安全性。

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: ********
  password: ********

調度策略

Scheduler 在選擇節點時會考慮多種因素：

策略	說明
資源請求與限制	根據 Pod 所需的 CPU / Memory 篩選節點
Node Selector	透過標籤把 Pod 指定到特定節點
Affinity / Anti-Affinity	定義 Pod 之間的親和或互斥關係
Taints & Tolerations	用污點阻擋 Pod，用容忍度放行

範例 -- 使用節點親和性：

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd

應用管理資源

K8s 提供多種控制器來管理不同類型的應用：

控制器	適用場景
Deployment	無狀態應用，支援滾動更新與回滾
StatefulSet	有狀態應用（資料庫、快取），每個 Pod 有穩定的網路標識和獨立儲存
DaemonSet	需要在每個節點上跑的應用（日誌收集、監控 agent）
Job	一次性批次任務
CronJob	定期排程任務

Deployment 範例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

StatefulSet 範例

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 1Gi

總結

K8s 的架構雖然元件眾多，但每個元件的職責都很明確：控制平面負責「決策」，工作節點負責「執行」。理解這些元件如何協作，是有效使用和維運 K8s 叢集的基礎。在實際應用中，結合自身的業務需求和基礎設施環境，靈活運用這些功能，才能真正發揮 K8s 在 CI/CD 和雲端原生場景中的價值。