Kubernetes 探針

功能描述

三個探針對應的 SPI 接口

• livenessProbe: org.apache.dubbo.qos.probe.LivenessProbe
• readinessProbe: org.apache.dubbo.qos.probe.ReadinessProbe
• startupProbe: org.apache.dubbo.qos.probe.StartupProbe

接口會自動獲取當前應用程序所有 SPI 的實現，如果對應接口的 SPI 實現都準備成功，則接口返回成功。

有關 Dubbo3 SPI 更多擴展的介紹，請參閱

使用場景

• kubelet 使用 liveness probe 來判斷您的應用程式是否正在執行，是否處於活動狀態。一般來說，如果您的程式當掉，Kubernetes 會立即知道程式已終止，然後重新啟動程式。我們設置 liveness probe 的目的是為了捕捉當前應用程式是否沒有終止或當機。如果發生這些情況，則重新啟動處於此狀態的容器，以便應用程式在存在錯誤的情況下仍然可以繼續運行。
• kubelet 使用 readiness probe 來判斷容器是否已準備好接收流量。它是否已準備就緒並可以開始工作。只有當 Pod 中的容器都處於就緒狀態時，kubelet 才會將 Pod 視為就緒狀態，因為一個 Pod 下可能有多個容器。如果 Pod 未就緒，我們會將其從 Service 的 Endpoints 列表中移除，這樣我們的流量就不會被路由到該 Pod。

如何使用

存活檢查

對於 livenessProbe 存活檢查，由於 Dubbo3 框架本身無法取得應用程式的存活狀態，因此此介面沒有默認實現，默認返回成功。開發者可以根據 SPI 定義擴展此 SPI 介面，從應用程式層面判斷是否存活。

關於 liveness 存活探針 擴展範例

就緒檢查

對於 readinessProbe 就緒檢查，Dubbo3 目前默認提供兩個檢查維度。一是判斷 Dubbo3 服務本身是否已啟動或停止，二是檢查所有服務是否已註冊介面。如果所有服務都已從註冊中心下線（您可以通過 QOS 操作進行操作）將返回 Not Ready。

關於 readiness 就緒探針 擴展範例

啟動檢查

對於 startupProbe 啟動檢查，Dubbo3 目前默認提供一個檢查維度，即在所有啟動流程（接口暴露、註冊中心寫入等）完成後返回就緒狀態。

關於 startup 啟動探針 擴展範例

參考範例

livenessProbe:
  httpGet:
    path: /live
    port: 22222
  initialDelaySeconds: 5
  periodSeconds: 5
readinessProbe:
  httpGet:
    path: /ready
    port: 22222
  initialDelaySeconds: 5
  periodSeconds: 5
startupProbe:
  httpGet:
    path: /startup
    port: 22222
  failureThreshold: 30
  periodSeconds: 10

QOS 當計算節點檢測到内存壓力時，kuberentes 會按照 BestEffort -> Burstable -> Guaranteed 的順序逐漸驅逐 Pod。

目前，三種探針都有對應的介面，路徑即為 QOS 中的 command。請根據 QOS 配置修改端口信息（默認端口為 22222）。其他參數請參考 Kubernetes 官方文档。