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 模块，该模块公开两个端口 - 一个服务于健康检查服务，另一个 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://127.0.0.1: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://127.0.0.1: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。

• ←上一篇
下一篇→