第5課: Probes、Logging 與 Debugging

1. 三種 Probe 類型

Probe	用途	失敗時行為
Liveness	檢測容器是否正常運行	重啟容器
Readiness	檢測容器是否準備好接收流量	從 Service endpoints 移除（不重啟）
Startup	檢測應用程式是否完成啟動	重啟容器（成功前 liveness/readiness 被停用）

Probe 時間線:

  容器啟動 ──► Startup Probe（檢查中...）──► 成功 ──► Liveness + Readiness 開始
                                              │
                                              ▼
                               達到 failureThreshold ──► 重啟容器

2. Probe 方法與設定

# httpGet — 發送 HTTP GET 請求
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15    # 首次檢查前的等待時間
  periodSeconds: 10          # 檢查間隔
  timeoutSeconds: 3          # 逾時時間
  failureThreshold: 3        # 連續失敗幾次判定為失敗
  successThreshold: 1        # 連續成功幾次判定為成功

# tcpSocket — 嘗試建立 TCP 連線
readinessProbe:
  tcpSocket:
    port: 3306

# exec — 在容器內執行指令（exit 0 = 成功）
livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy

設定欄位	預設值	說明
initialDelaySeconds	0	容器啟動後首次 Probe 前的等待秒數
periodSeconds	10	Probe 執行間隔（秒）
timeoutSeconds	1	Probe 逾時秒數
failureThreshold	3	判定失敗的連續失敗次數
successThreshold	1	判定成功的連續成功次數（readiness 可設 >1）

考試重點: 啟動較慢的應用程式（如 Java/Spring Boot）應使用 startupProbe。Startup Probe 成功前，Liveness Probe 不會執行，避免應用程式在初始化期間被誤判為異常而重啟。CKAD 常考三種 Probe 的正確使用場景。

3. kubectl logs

# 查看 Pod 日誌
kubectl logs mypod

# 查看特定容器的日誌（multi-container Pod）
kubectl logs mypod -c sidecar

# 即時追蹤日誌
kubectl logs mypod -f

# 最近 1 小時的日誌
kubectl logs mypod --since=1h

# 最近 100 行日誌
kubectl logs mypod --tail=100

# 前一個容器實例的日誌（重啟後）
kubectl logs mypod --previous

4. 除錯指令

# 在容器內執行指令
kubectl exec -it mypod -- sh
kubectl exec mypod -- cat /etc/config/app.conf

# Port forward（從本機直接存取 Pod）
kubectl port-forward mypod 8080:80
kubectl port-forward svc/myservice 8080:80

# Ephemeral debug container（注入到運行中的 Pod）
kubectl debug mypod -it --image=busybox --target=app

# 從 Pod 複製檔案
kubectl cp mypod:/var/log/app.log ./app.log
kubectl cp ./config.yaml mypod:/etc/config/

5. 常見 Pod 狀態

狀態	原因	排查方式
CrashLoopBackOff	容器反覆崩潰	kubectl logs --previous 查看日誌
ImagePullBackOff	映像檔拉取失敗	確認映像檔名稱、標籤、registry 權限
Pending	無法排程	檢查節點資源、taints/tolerations、PVC
OOMKilled	超出記憶體限制	增加 resources.limits.memory
Error	容器以非零退出碼結束	查看日誌和指令

6. 速查表

任務	指令
查看崩潰 Pod 的原因	kubectl logs pod --previous
進入 Pod 互動式調查	kubectl exec -it pod -- sh
從本機存取 Pod	kubectl port-forward pod 8080:80
注入除錯容器	kubectl debug pod -it --image=busybox
查看 Pod 詳情和事件	kubectl describe pod name

7. 練習題

Q1: 應用程式啟動需要 60 秒。livenessProbe 在啟動期間重啟容器，導致 CrashLoopBackOff。最佳解決方案是什麼？

• A) 將 livenessProbe 的 initialDelaySeconds 增加到 120
• B) 移除 livenessProbe
• C) 新增具有足夠 failureThreshold 的 startupProbe ✓
• D) 用 readinessProbe 替代

解析: startupProbe 是啟動較慢應用程式的推薦方案。startupProbe 成功前，livenessProbe 和 readinessProbe 會被停用。比增加 initialDelaySeconds 更可靠——因為啟動時間會因負載和環境而變化。

Q2: 容器持續重啟。查看前一個容器實例日誌的指令是什麼？

• A) kubectl logs mypod --all
• B) kubectl logs mypod --previous ✓
• C) kubectl describe pod mypod
• D) kubectl get events

解析: --previous 旗標會顯示前一個容器實例的日誌。當容器重啟後，當前日誌可能不包含崩潰資訊。describe 和 events 也有用，但應用層級的錯誤通常記錄在 --previous 日誌中。

Q3: readinessProbe 失敗時會發生什麼？

• A) 容器被重啟
• B) 整個 Pod 被刪除
• C) Pod 從對應 Service 的 endpoints 中被移除 ✓
• D) Pod 回到 Pending 狀態

解析: readinessProbe 失敗不會導致容器重啟（與 livenessProbe 不同）。而是將 Pod 從 Service 的 endpoints 列表中移除，新的流量不再發送給它。readinessProbe 再次成功後，Pod 會回到 endpoints 列表中。