程式設計的邊界，往往不在寫程式本身，而在「程式能不能穩穩跑起來」。如果你已經跟著我們的 Docker 實戰指南把應用程式打包成容器，恭喜你踏出了第一步；但當容器變成十個、一百個，誰來決定它們跑在哪台機器？誰在當機時自動重啟？誰在流量暴漲時自動加開副本？答案就是 Kubernetes（簡稱 K8s）。
這篇文章用最直白的方式，帶你從「會用 Docker」跨到「會用 K8s 編排」，重點不在背名詞，而在理解它解決了什麼痛點。
一、Kubernetes 到底是什麼？一個「容器指揮家」
把 Kubernetes 想成一間餐廳的店長。Docker 容器是廚師，每個廚師會做菜（跑服務）；店長不會做菜，但他決定「今天開幾個廚師」、「哪個廚師累倒了立刻換人」、「客人湧進來就加開窗口」。Kubernetes 就是這位店長，它運行在一群機器（節點 Node）之上，統一調度所有容器（在 K8s 裡叫 Pod）。
重點：Kubernetes 不替代 Docker，而是管理 Docker 生產出來的容器。它負責部署、擴縮容、自愈與服務發現。
二、三個核心物件：Pod、Deployment、Service
初學者只要先搞懂這三個，就能跑起第一個應用：
- Pod：K8s 最小的部署單位，裡面跑一個或多個共享網路的容器，通常一個 Pod 就是一個微服務實例。
- Deployment：告訴 K8s「我想要幾個 Pod 副本」，它會確保實際數量與你聲明的保持一致，Pod 掛了自動補。
- Service：給一組 Pod 一個穩定的訪問入口（虛擬 IP），不管後面 Pod 怎麼換，外部存取位置不變。
三、步驟 1：準備一個容器映像
假設你有一個 Node.js 後端，先確保它已經能打包成映像（可參考 Docker 指南）。這裡我們用一個現成的範例映像 ghcr.io/your-team/api:1.0.0 作為演示。
四、步驟 2：撰寫 Deployment 清單
K8s 萬物皆「宣告式 YAML」。下面這份清單描述「我要 3 個副本的 API 服務」：
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-deployment
labels:
app: api
spec:
replicas: 3
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api
spec:
containers:
- name: api
image: ghcr.io/your-team/api:1.0.0
ports:
- containerPort: 3000
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "256Mi"重點：requests 是「最低保障」，limits 是「上限保護」。設了 limits，單一容器才不會把整台節點的資源吃光，這正是生產環境的防呆機制。
五、步驟 3：用 Service 暴露服務
apiVersion: v1
kind: Service
metadata:
name: api-service
spec:
selector:
app: api
ports:
- port: 80
targetPort: 3000
type: ClusterIP這份 Service 把流量導向帶有 app: api 標籤的 Pod。type: ClusterIP 表示只在集群內部可達；若要對外，可改用 LoadBalancer 或配合 Ingress。
六、步驟 4：部署與觀察
# 套用清單
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
# 觀察 Pod 狀態
kubectl get pods -l app=api
# 擴縮容：一行指令從 3 個變 10 個
kubectl scale deployment api-deployment --replicas=10當你執行 kubectl get pods，會看到 3 個 Pod 陸續變成 Running。這就是 K8s 的自愈與調度在作用：它自動挑選有空位的節點把容器排上去。
七、步驟 5：滾動更新與回滾
K8s 的殺手鐧是「滾動更新」——發新版本時，它先起新 Pod、等新 Pod 健康才關舊 Pod，服務零中斷。
# 更新映像版本，自動滾動
kubectl set image deployment/api-deployment api=ghcr.io/your-team/api:2.0.0
# 出包了？一秒回滾上一版
kubectl rollout undo deployment/api-deployment重點：rollout undo 是你的安全網。每次部署都會留紀錄，回滾不需要重新打包，直接切回舊副本。
八、前端開發者為什麼該懂 K8s？
你或許想：「我只寫前端，後端有 SRE 管。」但其實懂一點 K8s 大有好處：
- 本地用 kind 或 minikube 起一個迷你集群，就能完整模擬「前端 + 網關 + 多個後端」的聯調環境，不再被「我本地是好的」困擾。
- 讀得懂 Deployment / Ingress YAML，和運維溝通不再雞同鴨講，提 PR 時能自己寫部署清單。
- 理解 Pod 與 Service，能解釋「為什麼測試環境偶爾連不上後端」——多半是 Service selector 標籤沒對上。
九、下一步可以學什麼
當你熟練基礎物件，可以往 Ingress（統一入口與路由）、ConfigMap / Secret（配置與機密分離）、HPA（根據 CPU 自動擴縮容）邁進。它們都是同一套「宣告式」思維的延伸。
互動話題：你第一次碰 Kubernetes 時，被哪個概念卡最久？是 Pod 與容器的關係，還是 Service 的網路模型？歡迎留言分享你的踩坑故事！