Kubernetes 1.24：gRPC 容器探針進入 Beta 階段

_更新：自本文釋出以來，該功能已在 v1.27 中升級為 GA（正式釋出），無需啟用任何特性門控。_

在 Kubernetes 1.24 中，gRPC 探針功能進入 Beta 階段並預設可用。現在，你可以為你的 gRPC 應用配置啟動（startup）、存活（liveness）和就緒（readiness）探針，而無需暴露任何 HTTP 端點，也不需要額外的可執行檔案。Kubernetes 可以透過 gRPC 原生連線到你的工作負載並查詢其狀態。

歷史回顧

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

對於大多數應用來說，這些檢查已經足夠了。如果你的應用為健康（或就緒）檢查提供了一個 gRPC 端點，那麼很容易將 exec 探針 repurposed 用於 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 引入了一個 Alpha 質量的原生支援，用於透過 gRPC 查詢工作負載狀態。由於它是一個 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 模組，該模組暴露兩個埠——一個用於提供健康檢查服務，另一個是 HTTP 埠，用於響應 make-serving 和 make-not-serving 命令。

這是一個 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 的清單檔案中，你可以建立 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 https://: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 https://: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 之前提供你的反饋。

• ←上一篇
• 下一篇→