[infra] Kubernetes 入門：從 Docker Compose 到容器編排

Docker Compose 是一台主機上的容器管理。但當你的服務需要跑在多台機器上、需要自動擴縮、需要零停機部署的時候，Compose 就不夠用了。Kubernetes 解決的就是這個問題。

先講結論

K8s 是容器編排系統，不是 Docker Compose 的升級版——它是一個完全不同等級的東西。核心概念由外到內：Cluster → Node → Namespace → Deployment → Pod → Container。如果你的團隊只有一兩個服務、流量不大、不需要自動擴縮，Compose 就夠了，不要為了「潮」而上 K8s。

---

Docker Compose 的天花板在哪

Compose 很好用，但它有幾個硬限制：

• 容器掛了要人工介入重啟（或者靠 restart: unless-stopped，但這不是真正的 self-healing）
• 無法跨多台機器分配容器
• 更新版本要停機重建
• 一台主機掛了，上面所有服務一起掛

K8s 把這些問題都解了：Pod 掛了自動重建、多 Node 容錯、Rolling Update 零停機、HPA 自動擴縮。代價是——你需要學一套全新的概念跟工具鏈。

---

核心概念：六個詞搞懂 K8s

Pod —— 最小部署單位。通常一個 Pod 跑一個 container。Pod 是短暫的，隨時可能被殺掉重建，不要把它當 VM 用。

Deployment —— 定義「我要幾個 Pod、用什麼 image、什麼配置」。K8s 會確保實際狀態永遠符合你定義的期望狀態。

Service —— Pod 的 IP 會變，Service 提供穩定的入口。其他服務透過 Service name 來呼叫，不需要知道 Pod IP。

Ingress —— HTTP 路由層。把外部流量根據 hostname 或 path 分配到不同的 Service。

Namespace —— 邏輯隔離。可以用 Namespace 區分 dev / staging / prod 環境。

Node —— 叢集裡的一台機器。K8s 的 scheduler 負責決定 Pod 放在哪個 Node 上。

---

最小可用的 YAML

一個 Deployment + 一個 Service，就能把服務跑起來：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-api
  template:
    metadata:
      labels:
        app: demo-api
    spec:
      containers:
        - name: api
          image: myrepo/demo-api:1.0.0
          ports:
            - containerPort: 8080
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-secret
                  key: url
          resources:
            requests:
              cpu: "200m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
---
apiVersion: v1
kind: Service
metadata:
  name: demo-api-svc
spec:
  selector:
    app: demo-api
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP

Deployment 維持 2 個 Pod。其中一個掛了，K8s 會自動再建一個。Service 讓其他服務可以用 demo-api-svc 這個名字呼叫，不用管 Pod IP。

resources 一定要設。 沒有設 requests/limits 的 Pod 就像一個不設預算的部門——它會搶光 Node 上所有資源，把別人的 Pod 一起拖下水。

---

從 Compose 過渡的思維轉換

Compose 概念	K8s 對應	差異
service	Deployment + Pod	K8s 會自動維持副本數
ports	Service	K8s 用 Service 做服務發現
volumes	PV / PVC	K8s 的持久化儲存更複雜但更靈活
depends_on	readiness / liveness probe	K8s 不用依賴順序，用健康檢查

最大的思維轉換是：Compose 管「啟動順序」，K8s 管「期望狀態」。你告訴 K8s 「我要 3 個 Pod 跑這個 image」，它會一直確保這個狀態成立，不管中間發生什麼。

---

什麼時候該上 K8s？

適合的情況：

• 多個服務、多個環境、頻繁部署
• 需要自動擴縮跟高可用
• 團隊有人懂 K8s 或願意投資學習

不適合的情況：

• 只有一兩個服務，流量很小
• 團隊沒有 K8s 經驗，也沒時間學
• 只有一台主機

先把 Compose 穩定化，再考慮 K8s。 如果你連 Compose 的 healthcheck、logging、network 都沒做好，上 K8s 只是把問題搬到一個更複雜的地方。

---

延伸閱讀

• Infrastructure as Code
• Elasticsearch 深入
• Docker Compose 實戰模板

---

K8s 最大的陷阱不是學不會，而是學會之後想把所有東西都搬上去。你的個人 blog 不需要 K8s。但 resume 上寫有用過 K8s 確實有幫助就是了。