從單機到叢集：Kubernetes 在解什麼問題

先講清楚問題，才知道 K8s 那一大堆概念是在回應什麼。

場景一：機器掛了

• Compose：所有容器都在那一台機器上。機器掛 → 服務全掛，你半夜爬起來手動處理。
• 編排系統：偵測到節點失聯，自動把上面的工作負載重新排到其他健康的節點上。你早上起來看到的是一則通知，不是一場事故。

場景二：更新不能停機

• Compose：up -d 更新服務時，舊容器停掉、新容器啟動，中間有幾十秒的空窗（Java 冷啟動更久）。
• 編排系統：滾動更新——先起一個新版本、確認它真的能服務、把流量切過去、才關掉一個舊的，如此逐一替換。使用者完全無感。出問題還能一鍵回滾。

場景三：流量暴增

• Compose：手動改 --scale，而且只能在這一台機器上長，長到機器極限就沒了。
• 編排系統：依 CPU／記憶體／自訂指標自動增減副本數，不夠時甚至自動增加節點（AWS ch03 的 Auto Scaling 概念，但作用在容器層級）。

場景四：服務多到管不動

• 5 個服務用 Compose 很舒服。50 個服務、分屬 8 個團隊、跑在 20 台機器上——你需要的是一套統一的「宣告部署意圖」的方式，加上權限隔離、資源配額、統一的監控與日誌。

如果這章你只記得一件事，請記這個。

while (true) {
    期望狀態 = 讀取你提交的設定（etcd 裡的 YAML）
    實際狀態 = 觀察叢集現在的樣子
    if (實際 != 期望) {
        採取行動縮小差距
    }
}

對照 Compose 就懂了

• Compose ＝ 命令式的一次性動作：你打 up，它照做，然後就沒事了。之後容器掛掉，除非你設了 restart 策略（那也只是本機 daemon 的簡單重試），沒有人在「持續確保」狀態正確。
• K8s ＝ 持續運作的宣告式系統：你說「我要 3 個副本」，controller 就一直盯著。有一個掛了 → 現況 2 ≠ 期望 3 → 建一個新的。節點失聯 → 上面的 Pod 全部重新調度。你不需要做任何事，因為系統的職責就是消除差異。

由這一個機制，直接推導出 K8s 的所有招牌能力

• 自我修復：Pod 掛了 → 副本數不足 → 重建。
• 滾動更新：你改了映像版本 → 期望狀態變了 → controller 逐步把舊的換成新的。
• 自動擴縮：HPA 依指標改寫「期望副本數」→ 迴圈自然去達成它。
• 節點故障轉移：節點沒回報心跳 → 上面的 Pod 視為不存在 → 在別處重建。

┌──────────── 控制平面（Control Plane，叢集的大腦）────────────┐
│  kube-apiserver      所有操作的唯一入口（kubectl 打的就是它）    │
│  etcd                儲存所有狀態的資料庫（期望狀態存這裡）      │
│  kube-scheduler      決定新 Pod 該放到哪個節點                  │
│  controller-manager  跑各種控制迴圈的地方 ← 上一張卡的主角       │
└──────────────────────────┬───────────────────────────────────┘
                           │
     ┌─────────────────────┼─────────────────────┐
┌────┴──── Node 1 ────┐ ┌──┴─── Node 2 ────┐ ┌───┴── Node 3 ───┐
│ kubelet             │ │ kubelet          │ │ kubelet         │
│  └ 負責在本機把 Pod  │ │                  │ │                 │
│    跑起來、回報狀態  │ │                  │ │                 │
│ kube-proxy          │ │ kube-proxy       │ │ kube-proxy      │
│  └ 處理 Service 的   │ │                  │ │                 │
│    網路轉發         │ │                  │ │                 │
│ 容器執行環境         │ │ containerd       │ │ containerd      │
│  (containerd)       │ │                  │ │                 │
│ [Pod] [Pod] [Pod]   │ │ [Pod] [Pod]      │ │ [Pod]           │
└─────────────────────┘ └──────────────────┘ └─────────────────┘

各角色的白話職責

• API Server ＝ 總機：所有人（你、controller、kubelet）都只跟它講話，它負責認證、驗證、寫入 etcd。K8s 沒有元件之間直接互相呼叫——全部透過 API Server，這讓系統極度模組化。
• etcd ＝ 唯一的事實來源：整個叢集的狀態都在這裡。etcd 掛了叢集就失憶，所以正式環境一定要備份它。
• Scheduler ＝ 排位人員：看到「有個 Pod 還沒地方去」，依資源需求、親和性規則、節點狀況挑一台。
• Controller Manager ＝ 一群盡責的管家：Deployment controller、ReplicaSet controller、Node controller… 各自跑自己的調和迴圈。
• kubelet ＝ 節點上的工頭：接到「你這台要跑這些 Pod」，就呼叫容器執行環境把它們跑起來，並持續回報健康狀況。
• kube-proxy ＝ 節點上的交通警察：維護轉發規則，讓「連到 Service」的流量正確送到後端的 Pod。

Pod ＝ 最小的部署單位（不是容器！）

• 一個 Pod 可以裝一個或多個容器，它們共用同一個 network namespace 和儲存 volume。
• 共用 network namespace 的意思（回扣 ch02）：同一個 Pod 裡的容器可以用 localhost 互相連線、共用同一組 port 空間（所以不能撞埠）。
• 典型用法是「主容器 + 輔助容器（sidecar）」：主容器跑你的 Spring Boot，旁邊掛一個日誌收集器或服務網格代理。
• 90% 的情況你的 Pod 只有一個容器——那就把 Pod 想成「容器的包裝紙」即可。
• Pod 是可拋棄的：它會死、會被重建，而且重建後 IP 會變。這正是需要 Service 的原因。

Deployment ＝ 你實際上會寫的東西

你幾乎不會直接建立 Pod，而是宣告一個 Deployment：「我要 3 個這樣的 Pod，用這個映像，更新時請逐步替換。」

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3                     # ← 期望狀態：我要 3 個
  selector:
    matchLabels: { app: myapp }
  template:                       # ← 每個 Pod 長什麼樣
    metadata:
      labels: { app: myapp }
    spec:
      containers:
        - name: app
          image: myregistry.io/myapp:1.4.2    # 明確版本，不用 latest（ch04）
          ports:
            - containerPort: 8080
          env:
            - name: SPRING_PROFILES_ACTIVE
              value: prod
            - name: SPRING_DATASOURCE_PASSWORD
              valueFrom:
                secretKeyRef: { name: db-secret, key: password }   # 秘密注入（ch10）
          resources:
            requests: { memory: 512Mi, cpu: 250m }
            limits:   { memory: 1Gi,   cpu: 1000m }
          securityContext:                     # ch10 的安全實務
            runAsNonRoot: true
            readOnlyRootFilesystem: true
            capabilities: { drop: [ALL] }

Service ＝ 穩定的入口（解決 Pod IP 會變的問題）

apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector: { app: myapp }      # 找到所有帶這個標籤的 Pod
  ports:
    - port: 80
      targetPort: 8080

• Service 有一個固定不變的名稱與虛擬 IP，會把流量負載平衡到符合標籤的所有 Pod 上。
• 其他服務用 http://myapp 就連得到——跟 Compose 用服務名稱互連是同一個心智模型（ch07），只是背後從單機的 DNS 換成了叢集 DNS ＋ kube-proxy 的轉發規則。
• 三種類型：ClusterIP（只在叢集內，預設）、NodePort（每個節點開一個埠）、LoadBalancer（雲端商配一顆負載平衡器）。對外的 HTTP 流量通常再上一層用 Ingress 統一處理路由與 TLS。

ch05 講過 Docker 的 HEALTHCHECK。K8s 把它拆成三個用途不同的探測，設錯會導致服務詭異地反覆重啟或流量被丟到還沒準備好的實例上。

① Liveness Probe ——「你還活著嗎？」

• 失敗的後果：殺掉容器並重建。
• 用途：偵測死鎖、無限迴圈這類「process 還在但已經廢了」的狀態。
• ⚠️ 最常見的錯誤：把它指向會依賴資料庫的端點。資料庫短暫抖動 → liveness 失敗 → 你的應用被殺掉重啟 → 重啟後資料庫還是有問題 → 無限重啟迴圈，而且問題根本不在你的應用。Liveness 應該只檢查「這個 process 本身還能運作嗎」。

② Readiness Probe ——「你現在能接工作嗎？」

• 失敗的後果：從 Service 的後端清單移除，不再送流量給它（但不會殺掉它）。
• 用途：暫時性的不可用——正在啟動、連線池耗盡、正在載入大量快取。
• 這才是可以檢查相依服務的地方：資料庫連不上時把自己標記成 not ready，流量會被導到其他健康的實例，等恢復後自動回到輪替。

③ Startup Probe ——「你啟動完了嗎？」

• 對 Java 應用至關重要。在它成功之前，liveness 和 readiness 都暫停不執行。
• 解決的問題：Spring Boot 冷啟動要 30~90 秒，如果只設 liveness，應用會在啟動途中被判定為死亡而遭殺害，然後永遠重啟（這是 Java 上 K8s 最經典的翻車現場）。

startupProbe:                      # 給它最多 5 分鐘啟動（30 次 × 10 秒）
  httpGet: { path: /actuator/health/liveness, port: 8080 }
  failureThreshold: 30
  periodSeconds: 10

livenessProbe:                     # 只看 process 本身，不看相依服務
  httpGet: { path: /actuator/health/liveness, port: 8080 }
  periodSeconds: 10
  failureThreshold: 3

readinessProbe:                    # 可以看相依服務（DB、Redis）
  httpGet: { path: /actuator/health/readiness, port: 8080 }
  periodSeconds: 5
  failureThreshold: 3

這組設定直接決定你的服務穩不穩、以及叢集的錢有沒有花在刀口上。

resources:
  requests:              # 「我至少需要這麼多」→ 用於「排程決策」
    memory: 512Mi
    cpu: 250m            # 250 milli-core = 0.25 顆 CPU
  limits:                # 「我最多只能用這麼多」→ 用於「執行時限制」（就是 ch02 的 cgroup）
    memory: 1Gi
    cpu: 1000m

兩者的職責完全不同

• requests ＝ 給 scheduler 看的：決定這個 Pod 能被放到哪台節點。節點的剩餘可分配量是用 requests 加總計算的，跟實際用量無關。
• limits ＝ 給 kernel 看的：就是 ch02 那個 cgroup 上限，超過就限流（CPU）或砍掉（記憶體）。

設定不當的三種災難

1. 沒設 requests → scheduler 以為這個 Pod 不吃資源，把一堆 Pod 塞進同一台節點 → 實際跑起來記憶體不夠 → 大規模 OOM。
2. CPU limit 設太低 → CPU 限流（throttling）：process 被強制暫停。對 Java 特別致命——GC 執行緒被限流會造成延遲尖峰，而且從應用日誌上完全看不出原因。
3. 記憶體 limit 設太低 → OOMKilled（ch02、ch09 的 137）。記憶體和 CPU 不同：CPU 超過是「變慢」，記憶體超過是「立刻死亡」，沒有中間地帶。

Java 應用的建議設定

• 記憶體：requests 和 limits 設成一樣（獲得 Guaranteed QoS 等級，最不容易在節點資源緊張時被驅逐）。搭配 -XX:MaxRAMPercentage=75（ch09），讓 JVM 自動適應這個上限。
• CPU：requests 一定要設（保證排程時拿得到）；limits 則常見的建議是「設寬鬆一點，或延遲服務乾脆不設」——因為 CPU 限流造成的延遲尖峰，通常比讓它偶爾多用一點 CPU 更糟。

ch13 教了 Docker 的除錯，這裡是 K8s 版本。好消息是：問題的成因幾乎完全一樣，只是名字不同。

① CrashLoopBackOff（最常見）

• 意思：容器不斷啟動又不斷崩潰，K8s 用指數退避拉長重試間隔。
• 成因：跟 ch13 的「一直 Restarting」完全一樣——設定錯誤、相依服務連不上、或 liveness probe 設錯把健康的應用殺掉。
• 查法：

  kubectl logs <pod> --previous     # ← 關鍵：看「上一次崩潰前」的日誌
  kubectl describe pod <pod>         # 看 Events 區段

  --previous 這個旗標非常重要，因為現在這個容器可能才剛啟動、日誌還是空的。

② ImagePullBackOff / ErrImagePull

• 成因：映像名稱打錯、標籤不存在、私有 registry 沒設認證（imagePullSecrets）、或架構不符（ch04 的 M1 問題）。
• 查法：kubectl describe pod 的 Events 會寫出確切的失敗原因。

③ Pending（卡住不動）

• 成因：scheduler 找不到地方放它——所有節點的可分配資源都不足以滿足你的 requests、或有 taint／親和性規則擋住、或 PVC 還沒綁定。
• 查法：kubectl describe pod 會直接寫「0/5 nodes are available: insufficient memory」。

④ OOMKilled

• 跟 ch09 一模一樣：記憶體超過 limits。kubectl describe pod 的 Last State 會顯示 OOMKilled、exit code 137。
• Java 的檢查順序：有沒有設 MaxRAMPercentage？limits 是不是太小（Spring Boot 建議至少 512Mi）？是不是真的洩漏？

⑤ Running 但沒有流量進來

• 成因：readiness probe 沒通過（Pod 活著但沒被加進 Service 的後端），或 Service 的 selector 標籤跟 Pod 的 labels 對不上。
• 查法：

  kubectl get pods            # READY 欄是 0/1 就是 readiness 沒過
  kubectl get endpoints myapp # 後端清單是空的？那就是選不到 Pod

指令對照（你已經會 Docker 了，這些是同義詞）

docker ps                 → kubectl get pods
docker logs -f X          → kubectl logs -f X
docker exec -it X bash    → kubectl exec -it X -- bash
docker inspect X          → kubectl describe pod X
docker stats              → kubectl top pods
docker events             → kubectl get events --sort-by=.lastTimestamp
（無對應）                 → kubectl port-forward pod/X 8080:8080  ← 本機直連 Pod，除錯神器

你現在的位置

你已經有整個容器基礎（前 13 章）＋ K8s 的核心心智模型。這比「只會照著 YAML 抄」的人扎實得多——因為 K8s 的所有行為都建立在容器的原理上（Pod 共用 namespace、limits 就是 cgroup、映像就是 OCI image）。

建議的下一步（照順序）

1. 本機跑起一個叢集：kind（Docker 裡跑 K8s，最輕）、minikube、或 Docker Desktop 內建的 K8s。把 ch12 那套 Compose 環境翻成 Deployment ＋ Service ＋ ConfigMap ＋ Secret 手動做一遍——這個練習的學習密度最高。
2. ConfigMap 與 Secret：設定與秘密的注入方式（對應 ch09、ch10 的環境變數與 secret）。
3. 持久化儲存：PersistentVolume／PVC／StorageClass（對應 ch06 的 volume，但多了「跨節點」的複雜度）。
4. Ingress 與流量管理：對外路由、TLS 憑證（cert-manager）。
5. 套件化：Helm（樣板化與版本管理）或 Kustomize（疊加式覆蓋，概念很像 ch11 的 compose override）。
6. GitOps：ArgoCD／Flux——把 Git 當成期望狀態的唯一來源，控制迴圈負責讓叢集與 Git 保持一致。這是本章「控制迴圈」思想的最高展現，也是現在 SRE 的主流做法。
7. 可觀測性：Prometheus（指標）＋ Grafana（視覺化）＋ Loki／ELK（日誌）＋ OpenTelemetry（追蹤）。SRE 的核心技能其實在這裡——不是部署，是「知道系統現在好不好、壞了為什麼」。

託管 K8s：不要自己架控制平面

• AWS EKS、Google GKE、Azure AKS：控制平面由雲端商維護（etcd 備份、版本升級、高可用），你只管工作節點與應用。
• 自架控制平面是一項專職工作，對絕大多數團隊都不划算。
• 你在 AWS ch08 學過的 ECS／EKS／Fargate 選型，現在應該完全看得懂了：ECS 是 AWS 自家的較簡單編排、EKS 是託管的標準 K8s、Fargate 是「連工作節點都不用管」的執行模式。