Kubernetes 1.24：gRPC 容器探測功能進入 beta 階段

_更新：自發布本文以來，該功能已在 v1.27 中升級為正式版 (GA)，並且不再需要啟用任何功能閘道。

在 Kubernetes 1.24 中，gRPC 探針功能已進入 Beta 階段，並且預設為可用。現在您可以為您的 gRPC 應用程式配置啟動、存活和就緒探針，而無需公開任何 HTTP 端點，也不需要可執行檔。Kubernetes 可以透過 gRPC 原生連線到您的工作負載並查詢其狀態。

歷史背景

讓管理您工作負載的系統檢查應用程式是否健康、是否已正常啟動，以及應用程式是否認為自己可以接受流量，這很有用。在新增 gRPC 支援之前，Kubernetes 已經允許您根據從容器映像內部執行可執行檔、發出 HTTP 請求或檢查 TCP 連線是否成功來檢查健康狀況。

對於大多數應用程式來說，這些檢查就足夠了。如果您的應用程式為健康（或就緒）檢查提供 gRPC 端點，則可以輕鬆地重新調整 exec 探針的用途，以將其用於 gRPC 健康檢查。在部落格文章〈在 Kubernetes 上進行 gRPC 伺服器健康檢查〉中，Ahmet Alp Balkan 描述了您可以如何做到這一點——這種機制至今仍然有效。

有一個常用工具可以啟用此功能，該工具於 2018 年 8 月 21 日建立，並於 2018 年 9 月 19 日發布第一個版本。

這種用於 gRPC 應用程式健康檢查的方法非常受歡迎。在 GitHub 上進行基本搜尋（在撰寫本文時）發現有 3,626 個 Dockerfile 包含 grpc_health_probe，以及 6,621 個 yaml 檔案。這很好地表明了該工具的普及程度以及對原生支援此功能的需求。

Kubernetes v1.23 引入了原生支援使用 gRPC 查詢工作負載狀態的 Alpha 品質實作。由於它是一個 Alpha 功能，因此在 v1.23 版本中預設為停用。

使用此功能

我們以與其他探針類似的方式建置了 gRPC 健康檢查，並且相信如果您熟悉 Kubernetes 中的其他探針類型，它將很容易使用。原生支援的健康探針比涉及 grpc_health_probe 可執行檔的變通方法有許多優勢。

透過原生 gRPC 支援，您無需下載並在映像中攜帶額外的 10MB 可執行檔。Exec 探針通常比 gRPC 呼叫慢，因為它們需要實例化一個新進程來執行可執行檔。這也使得在 Pod 以最大資源運作且實例化新進程遇到問題的邊緣情況下，檢查變得不太明智。

不過，有一些限制。由於為探針配置用戶端憑證很困難，因此不支援需要用戶端驗證的服務。內建探針也不會檢查伺服器憑證，並忽略相關問題。

內建檢查也無法配置為忽略某些類型的錯誤（grpc_health_probe 為不同的錯誤傳回不同的退出代碼），並且無法「鏈式」以在單個探針中對多個服務執行健康檢查。

但是所有這些限制對於 gRPC 來說都是相當標準的，並且有簡單的變通方法可以解決這些問題。

親自試試看

叢集級別設定

您今天就可以試用此功能。若要試用原生 gRPC 探針，您可以自行啟動一個已啟用 GRPCContainerProbe 功能閘道的 Kubernetes 叢集，有許多工具可用。

由於功能閘道 GRPCContainerProbe 在 1.24 中預設為啟用，因此許多供應商將開箱即用地提供此功能。因此，您只需在您選擇的平台上建立一個 1.24 叢集即可。某些供應商允許在 1.23 叢集上啟用 Alpha 功能。

例如，在撰寫本文時，您可以在 GKE 上啟動測試叢集以進行快速測試。其他供應商也可能具有類似的功能，特別是如果您在 Kubernetes 1.24 版本發布很久之後才閱讀此部落格文章。

在 GKE 上使用以下命令（請注意，版本為 1.23 且指定了 enable-kubernetes-alpha）。

gcloud container clusters create test-grpc \
    --enable-kubernetes-alpha \
    --no-enable-autorepair \
    --no-enable-autoupgrade \
    --release-channel=rapid \
    --cluster-version=1.23

您還需要配置 kubectl 才能存取叢集

gcloud container clusters get-credentials test-grpc

試用此功能

讓我們建立 Pod 來測試 gRPC 探針如何運作。在此測試中，我們將使用 agnhost 映像。這是一個 k8s 維護的映像，可用於各種工作負載測試。例如，它有一個有用的 grpc-health-checking 模組，該模組公開了兩個端口 - 一個端口用於提供健康檢查服務，另一個端口用於回應 make-serving 和 make-not-serving 命令的 http 端口。

這是一個範例 Pod 定義。它啟動 grpc-health-checking 模組，公開端口 5000 和 8080，並配置 gRPC 就緒探針

---
apiVersion: v1
kind: Pod
metadata:
  name: test-grpc
spec:
  containers:
  - name: agnhost
    # image changed since publication (previously used registry "k8s.gcr.io")
    image: registry.k8s.io/e2e-test-images/agnhost:2.35
    command: ["/agnhost", "grpc-health-checking"]
    ports:
    - containerPort: 5000
    - containerPort: 8080
    readinessProbe:
      grpc:
        port: 5000

在名為 test.yaml 的 manifest 檔案中，您可以建立 Pod 並檢查其狀態。Pod 將處於就緒狀態，如輸出片段所示。

kubectl apply -f test.yaml
kubectl describe test-grpc

輸出將包含類似以下內容

Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True

現在讓我們將健康檢查端點狀態變更為 NOT_SERVING。為了呼叫 Pod 的 http 端口，讓我們建立端口轉發

kubectl port-forward test-grpc 8080:8080

您可以使用 curl 呼叫命令...

curl http://localhost:8080/make-not-serving

... 並且在幾秒鐘內，端口狀態將切換為未就緒。

kubectl describe pod test-grpc

輸出現在將具有

Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True

...

  Warning  Unhealthy  2s (x6 over 42s)  kubelet            Readiness probe failed: service unhealthy (responded with "NOT_SERVING")

一旦切換回，大約一秒鐘後，Pod 將恢復為就緒狀態

curl http://localhost:8080/make-serving
kubectl describe test-grpc

輸出表明 Pod 已恢復為 Ready 狀態

Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True

Kubernetes 上新的內建 gRPC 健康探測使得透過 gRPC 實作健康檢查比依賴使用單獨的 exec 探針的舊方法容易得多。在該功能升級為正式版 (GA) 之前，請仔細閱讀官方文件以了解更多資訊並提供回饋。

總結

Kubernetes 是一個受歡迎的工作負載協調平台，我們根據回饋和需求新增功能。諸如 gRPC 探針支援之類的功能是一項小的改進，它將使許多應用程式開發人員的生活更輕鬆，並使應用程式更具彈性。今天就試試看並提供回饋，趕在該功能進入正式版 (GA) 之前。

• ←上一篇
下一篇→