在 Kubernetes 中，livenessProbe 和 readinessProbe 是確保應用高可用性的關鍵機制，但配置不當可能導致應用頻繁重啟或流量中斷。以下是配置這兩個探針的最佳實踐：

1. 核心區別與作用

探針類型	目的	失敗后果
livenessProbe	檢測應用是否 存活（如死鎖、內存泄漏）。	重啟容器（kubectl restart）
readinessProbe	檢測應用是否 準備好接收流量（如依賴服務未就緒、緩存未加載）。	從 Service 的 Endpoints 移除 Pod

2. 最佳實踐指南

(1) 明確區分兩個探針的用途

• livenessProbe：
  • 保守檢查：僅檢測應用是否處于不可恢復的故障狀態（如主線程崩潰）。一般服務沒掛掉就認為是正常的。
  • 避免敏感條件：例如，不要用業務邏輯失敗（如數據庫連接超時）觸發重啟，除非明確需要。
• readinessProbe：
  • 嚴格檢查：確保所有依賴（如數據庫、通過 feign 調用的外部組件、中間件）就緒后才接收流量。
  • 動態調整：在運行時若依賴服務不可用（如 Redis 宕機），應通過 readinessProbe 主動拒絕流量。

(2) 設置合理的檢查端點

• 為 livenessProbe 和 readinessProbe 使用不同的 HTTP 路徑：

  livenessProbe:httpGet:path: /health/liveness   # 輕量級存活檢查（僅進程存活）port: 8080
  readinessProbe:httpGet:path: /health/readiness  # 包含依賴檢查（如數據庫連接）port: 8080
  

(3) 配置合理的參數

livenessProbe:httpGet:path: /actuator/health/livenessport: 8080initialDelaySeconds: 10   # 應用啟動后等待 10 秒再開始探測periodSeconds: 5          # 每 5 秒檢查一次timeoutSeconds: 3         # 超時時間設為 3 秒failureThreshold: 3       # 連續失敗 3 次后判定為故障readinessProbe:httpGet:path: /actuator/health/readinessport: 8080initialDelaySeconds: 5    # 比 livenessProbe 更早開始檢查periodSeconds: 5timeoutSeconds: 3failureThreshold: 1       # 1 次失敗即標記為未就緒

關鍵參數說明：

• initialDelaySeconds：必須設置，避免應用未完成初始化就被判定為失敗（如 JVM 啟動慢）。
• failureThreshold：
  • livenessProbe 可設置較高（如 3），避免偶發故障觸發重啟。
  • readinessProbe 可設置較低（如 1），快速從負載均衡中剔除異常 Pod。
• periodSeconds 和 timeoutSeconds：根據應用響應時間調整，避免超時誤判。

(4) 結合 startupProbe 處理慢啟動應用

對于啟動時間較長的應用（如 Java 服務），使用 startupProbe 延遲 livenessProbe 和 readinessProbe 的啟動：

startupProbe:httpGet:path: /actuator/health/startupport: 8080failureThreshold: 30  # 允許最多 30 次檢查失敗periodSeconds: 5      # 每 5 秒檢查一次# 總等待時間 = failureThreshold * periodSeconds = 150 秒

如果想了解 k8s 為什么要專門提出 startupProb 來解決慢服務啟動的問題，而不是直接把 livenessPro 中初始化的時間設置的長一點。可以參考下面的文章《為什么需要啟動探針（StartupProb）？》。

(5) 選擇適當的探測類型

• HTTP GET：適合 Web 服務，通過狀態碼（2xx/3xx 表示成功）判斷。

• Exec：執行命令，返回 0 表示成功（適合非 HTTP 服務）：

  readinessProbe:exec:command:- /app/check-dependency.sh  # 自定義腳本檢查依賴
  

• TCP Socket：僅檢查端口是否開放（適用非 HTTP 協議）。

(6) 避免依賴下游服務

• readinessProbe 不要深度檢查外部依賴（如數據庫、API）：
  • 若外部服務宕機，所有 Pod 都會被標記為未就緒，導致全面故障。
  • 改為在應用內部實現熔斷機制（如 Hystrix），部分功能降級。

(7) 日志與監控

• 記錄探針檢查結果：在 /health 端點返回詳細信息（如版本、依賴狀態）。
• 監控探針失敗：通過 Prometheus 監控 kubelet_probe_errors_total，及時報警。

3. 示例配置

Spring Boot 應用

apiVersion: apps/v1
kind: Deployment
spec:template:spec:containers:- name: applivenessProbe:httpGet:path: /actuator/health/livenessport: 8080initialDelaySeconds: 30periodSeconds: 10failureThreshold: 3readinessProbe:httpGet:path: /actuator/health/readinessport: 8080initialDelaySeconds: 5periodSeconds: 5failureThreshold: 1startupProbe:httpGet:path: /actuator/health/startupport: 8080failureThreshold: 30periodSeconds: 5