【從一台 Server 到分散式架構】第 22 篇：很多小廚房誰來排班？——Kubernetes 在解決什麼

Docker 上線之後，小明他們的部署流程乾淨多了。

但某個週一早上，系統工程師阿強拉著小明看了一份清單：

「現在我們有 12 個服務，每個服務在正式環境跑 3 個副本，一共是 36 個 Container，分散在 8 台機器上。昨晚有 3 個 Container 掛掉，我是半夜手動 SSH 進去重啟的。這樣下去不行。」

小明問：「那怎麼辦？」

阿強：「我們需要一個系統，讓我不用手動管理這些容器——它掛掉就自己重啟、機器不夠就自動加容器、機器太閒就自動縮減。我們需要 Kubernetes。」

生活化的比喻：連鎖餐廳的總部排班系統

想像一家連鎖餐廳，全台有 50 間分店。

你不可能自己管理每間分店「今天要幾個廚師、幾個服務員」，更不可能每次有廚師請假就親自飛過去補人。

你需要一個總部排班系統：

你告訴系統：「每間分店週末要有 5 個廚師、5 個服務員」
系統自動去排班，確保每間分店符合這個規格
哪個廚師請假了，系統自動補人
某間分店突然大爆滿，系統自動多調一些人過去
某間分店週間很閒，系統自動縮減人力

Kubernetes 就是這個總部排班系統，只是管理的是容器，不是人。

Kubernetes 在解決什麼？

沒有 K8s，管理多台機器上的多個容器，你要手動：

決定每個容器跑在哪台機器（考慮機器的剩餘資源）
容器掛掉時手動重啟
流量變大時手動多啟幾個副本
滾動更新時手動一台一台換版本（避免全斷）
管理服務之間的網路路由（這個服務怎麼找到那個服務）

這些事情一台機器時沒問題，幾十台機器時就是噩夢。

Kubernetes 讓你「宣告式地」描述你要什麼，然後它去維持：

# 我要訂單服務，永遠保持 3 個副本在跑
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3        # 我要 3 個副本
  selector:
    matchLabels:
      app: order-service
  template:
    spec:
      containers:
      - name: order-service
        image: course-platform/order-service:v2.1
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"

你不說「去那台機器跑」，你說「我要 3 個副本」。K8s 決定在哪裡跑，並確保隨時都有 3 個副本在運作。

K8s 的核心概念

Pod：最小部署單位

K8s 不直接管理容器，它管理的是 Pod。

Pod 是一個或多個容器的集合，這些容器共享同一個網路空間和儲存。大多數情況，一個 Pod 裡只有一個容器。

你可以把 Pod 想成「一個工作位置」：裡面有一個（或幾個緊密協作的）容器。

Node：跑 Pod 的機器

Node 就是實體或虛擬機器，Pod 跑在 Node 上。

K8s 叢集有兩種 Node：

Control Plane（控制節點）：K8s 的大腦，決策要在哪裡跑什麼
Worker Node（工作節點）：實際跑 Pod 的機器

Deployment：管理 Pod 副本

Deployment 是你用來宣告「我要幾個副本、用什麼 Image」的資源。K8s 會確保這個數量的 Pod 一直在跑。

Service：讓服務可以被找到

容器 IP 是動態的——Pod 重啟後 IP 會變。Service 是 K8s 裡的「穩定門牌」：不管背後的 Pod IP 怎麼變，其他服務透過 Service name 就能找到它。

K8s 幫你做的三件最重要的事

1) 自癒（Self-Healing）

Pod 掛掉了？K8s 自動重啟。

Node 掛掉了？K8s 把上面的 Pod 調度到其他 Node 去跑。

你不需要半夜爬起來重啟服務。

2) 自動擴縮（Auto Scaling）

K8s 的 Horizontal Pod Autoscaler（HPA） 可以根據 CPU 使用率、記憶體、或自訂指標，自動增減 Pod 數量：

# 當 CPU 用量超過 70%，自動加副本；最多到 10 個
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  scaleTargetRef:
    name: order-service
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        averageUtilization: 70

課程平台的搶購活動一開始，K8s 自動擴出更多副本；活動結束，自動縮回來，不浪費資源。

3) 滾動更新（Rolling Update）

更新版本時，K8s 預設採滾動更新：先啟動新版本的 Pod，確認健康後，再關掉舊版本的 Pod，一批一批替換，確保全程不斷服。

舊版(3個) → 啟動1個新版 → 關掉1個舊版 → 啟動1個新版 → 關掉1個舊版 → 完成

K8s 不是萬靈丹：它本身很複雜

小明學到這裡，很興奮地說：「這個太強了，我們要馬上上！」

小傑潑了一桶冷水：

「K8s 強，但複雜度也很高。你需要學的概念很多——Pod、Deployment、Service、Ingress、ConfigMap、Secret、PVC……光是設定就要花一段時間。而且 K8s 本身也需要維運，控制節點要高可用、升級要小心。」

什麼時候值得上 K8s？

服務數量多（十個以上），手動管理成本高
需要自動擴縮（有流量波動）
部署頻率高（每天多次部署）
有足夠的工程師去學習和維護它

如果你只有三、四個服務，用 Docker Compose 加上簡單的 CI/CD 也許就夠了。不要為了「用了很厲害」而用 K8s，要為了「它解決了我的真實問題」而用。

對小明他們現在的規模，是時候了。

小結與預告

這篇小明學到的重點是：

K8s 是容器的排班系統：你宣告「我要什麼」，它確保現實狀態持續符合宣告。
三個核心能力：自癒（Pod 掛掉自動重啟）、自動擴縮（根據負載增減副本）、滾動更新（不斷服地更新版本）。
核心概念：Pod（最小部署單位）、Node（機器）、Deployment（副本管理）、Service（穩定入口）。
K8s 是有成本的：學習曲線陡、維運複雜，要在複雜度高到值得時才引入。

小明他們的系統，已經從「一台 Server」長成了：多服務、容器化、有 K8s 編排、有監控、有 log、有追蹤。

接下來，產品的方向要加入一個新功能：「AI 學習助理」。用戶輸入問題，AI 根據課程內容回答。

下一篇，我們來談如何把 LLM 接進現有系統——LLM、RAG 與向量庫。

Menu