在上一篇中，我們談到了 資源限制與 QoS (Quality of Service)，學會了如何透過 Requests 與 Limits 控制 Pod 的資源使用。但就算資源配置再完美，應用程式依然可能「掛掉」。
例如：

• 程式進入死循環
• 外部依賴（像資料庫）暫時連不上
• 啟動過程過慢導致被誤判為壞掉

這時，Kubernetes 的 健康檢查 (Health Check) 與 自動修復 (Self-healing) 機制就派上用場了 🚑。

為什麼需要Health Check？

Kubernetes 的強大之處，不只在於能讓應用程式「跑起來」，而是能在它「壞掉時自動修好」。

透過 Health Check (Probe)，Kubernetes 能自動偵測出哪些容器：

• 活著但功能異常（例如：CPU 滿載無法回應）
• 啟動太慢、尚未可用
• 初始化過程尚未完成

然後根據情況進行不同的動作：

• LivenessProbe：決定是否需要重啟容器
• ReadinessProbe：決定是否可以接收流量
• StartupProbe：防止啟動時過早被重啟

Probe 三兄弟：Liveness、Readiness、Startup

1️⃣ LivenessProbe — 「還活著嗎？」

用途：判斷容器是否卡死或失去功能。
若連續檢查失敗，Kubelet 會自動重啟容器。

常見例子

livenessProbe:
  httpGet:
    path: /healthz
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

這代表：

• 5 秒後開始檢查
• 每 10 秒檢查一次
• 若連續 3 次失敗 → 自動重啟容器

常見用法

• HTTP 檢查 /healthz
• Command 檢查：curl localhost:8080/healthz
• TCP 檢查：確認特定 port 是否可連線

2️⃣ ReadinessProbe — 「能服務嗎？」

用途：判斷容器是否準備好接受流量。
若失敗 → 該 Pod 會被從 Service 的 endpoint list 中移除，不再接流量。

常見例子

readinessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 3
  periodSeconds: 5

與 LivenessProbe 不同，ReadinessProbe 不會重啟容器。
這非常適合用在：

• 系統啟動後需要時間載入模型或初始化連線池
• 外部依賴（DB、Redis）暫時不可用

Tip：
ReadinessProbe 是實現「零中斷部署」的重要基礎。

StartupProbe — 「啟動好了嗎？」

有些應用程式（例如 Java、AI 模型服務）啟動時間很長，若沒有 StartupProbe，Liveness 可能會太早判斷失敗而重啟。

常見例子

startupProbe:
  httpGet:
    path: /
    port: 80
  failureThreshold: 30
  periodSeconds: 10

這表示：

• 每 10 秒檢查一次
• 最多等 5 分鐘（30 * 10 秒）
• 直到成功前，不會執行 Liveness 或 Readiness 檢查

自動修復機制如何運作？

整體流程如下：

• [ Liveness Probe 失敗 ] → Kubelet 殺掉容器 → 重啟
• [ Readiness Probe 失敗 ] → Service 移除 Pod → 暫不接流量
• [ Startup Probe 成功 ] → 啟用其他 Probe

進一步搭配：

• ReplicaSet：若 Pod 完全壞掉會自動補回
• Deployment：持續維持期望狀態
• HPA/VPA（下一篇）：根據健康與負載自動調整 Pod 數量

Kubernetes 就像一個保母，持續檢查每個小孩（Pod）是否醒著、有沒有吃飯、能不能去上課 🧸。

實作範例：Nginx 健康檢查與自動修復

Step 1. 建立範例 Pod

apiVersion: v1
kind: Pod
metadata:
  name: nginx-probe-demo
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    ports:
    - containerPort: 80
    livenessProbe:
      httpGet:
        path: /healthz
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10
      failureThreshold: 3
    readinessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 3
      periodSeconds: 5
    startupProbe:
      httpGet:
        path: /
        port: 80
      failureThreshold: 30
      periodSeconds: 10

建立：

kubectl apply -f nginx-probe-demo.yaml

Step 2. 檢查 Probe 狀態

kubectl describe pod nginx-probe-demo

你會看到類似：

Liveness:  http-get http://:80/healthz delay=5s timeout=1s period=10s #success=1 #failure=3
Readiness: http-get http://:80/ delay=3s timeout=1s period=5s #success=1 #failure=3
Startup:   http-get http://:80/ delay=0s timeout=1s period=10s #success=1 #failure=30

Step 3. 模擬容器「掛掉」

1. 進入容器：

kubectl exec -it nginx-probe-demo -- /bin/bash

2. 刪掉 /usr/share/nginx/html/healthz

rm /usr/share/nginx/html/healthz

3. 觀察 Pod 狀態：

kubectl get pods -w

你會看到：

nginx-probe-demo   1/1   Running
nginx-probe-demo   0/1   CrashLoopBackOff
nginx-probe-demo   1/1   Running

✅ LivenessProbe 偵測失敗 → 自動重啟 → 應用恢復正常。

實務建議與最佳實踐

類型	用途	建議設定
LivenessProbe	偵測程式卡死	periodSeconds: 10–30
ReadinessProbe	控制流量	適度延遲初次檢查
StartupProbe	慢啟動服務	設定高 failureThreshold

Tips

• Liveness 檢查內部狀態，不需太頻繁
• Readiness 可檢查外部依賴（DB、Redis）
• 對於模型伺服器或大型框架，務必使用 StartupProbe
• 使用 kubectl describe pod 追蹤 Probe 狀態
• 可搭配 Prometheus Exporter 監控 Probe 失敗次數

結語：邁向真正的自我修復

Probe 是 自我修復 (Self-healing) 的起點。
透過正確設計健康檢查，你的系統可以在沒有人介入的情況下自動恢復運作。

在下一篇 Day 24，我們將進一步探討如何讓 Kubernetes 不只「能修好自己」，還能「根據負載自動伸縮」——也就是 HPA (水平自動伸縮) 與 VPA (垂直自動伸縮)，讓整個系統具備智慧化的自我調節能力。