Kubernetes 1.24：gRPC 容器探针进入 beta 阶段

_更新：自本文发布以来，该功能已在 v1.27 中升级到 GA，并且不需要启用任何 feature gates。

在 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 上进行基本搜索时，可以找到包含 grpc_health_probe 的3,626 个 Dockerfile 和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 feature gate 的 Kubernetes 集群，有许多工具可用。

由于 feature gate 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 的 manifest 文件中，您可以创建 Pod 并检查其状态。根据输出片段所示，Pod 将处于 ready 状态。

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

... 几秒钟后，端口状态将切换为 not ready。

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 将恢复到 ready 状态

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 之前提供反馈。

• ←上一篇
• 下一篇→