今日目標

• 理解為什麼在生產環境中幾乎「不會單獨建立 Pod」。
• 掌握 Deployment、ReplicaSet 與 Pod 之間的三層架構關係。
• 理解 Label Selector（標籤選擇器）如何綁定與管理資源。
• 親手撰寫 Deployment YAML 檔並實測 K8s 的「自癒（Self-healing）」機制。

為什麼你幾乎不該單獨建立 Pod？

在 Day 07 中，我們親手撰寫了第一個 Pod YAML 檔。但如果你在生產環境中只用 Pod，會遇到一個致命問題：Pod 是拋棄式且脆弱的（Ephemeral）。

• 如果 Pod 內部的程式 Crash，Pod 可能會停止運作。
• 如果 Pod 所在的 Worker Node 實體損壞或重開機，這個 Pod 就會永遠消失，不會自動在其他機器上復活。
• 如果流量暴增，你必須手動再複製好幾個 Pod YAML 檔並依序 apply。

在 Kubernetes 的設計哲學中，獨立建立的 Pod 就像「孤兒」，沒有任何控制器在背後監護它。為了實現高可用（High Availability）與自動修復（Self-healing），我們需要引入更高層級的控制器——Deployment。

俄羅斯套娃：Deployment、ReplicaSet 與 Pod 的關係

Kubernetes 採用了非常優雅的階層式設計，這三者的關係可以用「俄羅斯套娃」或「公司組織架構」來理解：

1. Deployment（高階專案經理）：

   • 負責定義應用的期望狀態、版本更新策略（如滾動更新 Rolling Update）與版本回退（Rollback）。
   • Deployment 本身不直接管理個別 Pod，而是透過管理 ReplicaSet 來達成目標。

2. ReplicaSet（現場工頭）：

   • 唯一且純粹的任務：維持 Pod 的副本數量（Replicas）。
   • 如果指定要 3 個副本，當前只有 2 個，它就負責建立 1 個；如果多了 1 個，它就負責刪除 1 個。

3. Pod（基層工人）：

   • 真正包裹容器、執行應用程式業務邏輯的地方。

關鍵黏著劑：Label 與 Label Selector

ReplicaSet 是如何知道「哪些 Pod 歸它管」的？答案就是 Labels（標籤） 與 Selector（選擇器）。

• Pod metadata.labels：給 Pod 貼上標籤（例如 app: nginx-app）。
• Deployment spec.selector.matchLabels：告訴 Controller「只要身上有 app: nginx-app 標籤的 Pod，全部歸我監控與管理」。

實戰演練：撰寫與部署第一個 Deployment

步驟 1：建立 nginx-deployment.yaml

在工作目錄建立檔案，內容如下：

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

解析：spec.template 底下的內容，本質上就是我們在 Day 07 寫的 Pod 定義！Deployment 就是拿這份 template 作為模具，一口氣開出 3 個副本。

步驟 2：套用配置

執行指令部署 Deployment：

kubectl apply -f nginx-deployment.yaml

輸出預期：

deployment.apps/nginx-deployment created

步驟 3：觀察三層物件的建立

依序查看 Deployment、ReplicaSet 與 Pods：

# 查看 Deployment
kubectl get deployments

# 查看 ReplicaSet (簡寫 rs)
kubectl get rs

# 查看 Pods
kubectl get pods -l app=nginx-app

你會發現 K8s 自動幫我們建立了 1 個 Deployment、1 個 ReplicaSet，以及 3 個命名帶有隨機後綴的 Pod。

步驟 4：實測 Self-healing（自癒機制）

現在我們手動刪除其中一個 Pod，看看會發生什麼事：

# 隨機挑選其中一個 Pod 刪除
kubectl delete pod <POD-NAME>

刪除後立刻再次執行：

kubectl get pods -l app=nginx-app

你會發現被刪除的 Pod 正在被終止，但 ReplicaSet 已經在一秒內自動為你生成了一個全新的 Pod！ 這就是 Kubernetes 最強大的自癒保證——永遠維持期望的副本數量。

本日小結

今天我們搞懂了 Deployment、ReplicaSet 與 Pod 的三層管理體系，也透過親手刪除 Pod 驗證了 K8s 的自動修復能力。

既然 Deployment 可以穩定維持多個 Pod，那麼當軟體有新版本要釋出時，Deployment 又是如何在不停機的情況下幫我們完成升級的？

明天 Day 09，我們將深入探索核心維運場景：「零停機更新：Rolling Update 滾動升級與 Rollback 退回舊版」！