grpc-java - grpc-health-probe(Kubernetes 上的 gRPC 健康检查)如何区分 liveness 和 readiness 探针

Question

我正在编写一个 grpc 服务并在 Kubernetes (https://github.com/grpc-ecosystem/grpc-health-probe) 上使用 gRPC 健康检查。在我的服务器中，我添加了不同的端点实现(一个用于活跃性，另一个用于准备就绪)。我想知道这个探测实用程序二进制文件如何区分事件检查和准备检查？应该有其他方式在yaml中定义它，而不仅仅是
["bin/grpc_health_probe", "-addr=:8801"]

server = ServerBuilder.forPort(port)
  .addService(new GrpcModuleHealthCheck())
  .addService(new GrpcModuleReadinessCheck())
  .addService(ProtoReflectionService.newInstance())
  .build.start

在 kubernetes 部署 yaml 中，我使用以下配置

    livenessProbe:
      failureThreshold: 3
      exec:
        command: ["bin/grpc_health_probe", "-addr=:8801"]
      initialDelaySeconds: 240
      periodSeconds: 20
      successThreshold: 1
      timeoutSeconds: 15
    readinessProbe:
      failureThreshold: 3
      exec:
        command: ["bin/grpc_health_probe", "-addr=:8801"]
      initialDelaySeconds: 20
      periodSeconds: 20
      successThreshold: 1
      timeoutSeconds: 15

我刚刚测试并发现“GrpcModuleReadinessCheck”(我最后添加的健康类)实现在我刚刚执行我的 kubernetes pod 时生效

kubectl exec -it <MY_POD_NAME> -- /bin/bash

bash-4.4$ ./grpc_health_probe -addr=localhost:8801
status: SERVING

Answer 1

I am wondering how this probe utility binary differentiates between liveness check vs readiness check?

简而言之，它没有。

Kubernetes 定义了两种不同的检查: liveness检查程序是否仍然正常工作(即没有挂起)和 readiness检查程序是否愿意接受更多请求。

但是，gRPC 只定义了一个 health checking protocol并且没有“准备检查”的原生概念。

如何将 gRPC 响应映射到 Kubernetes 检查取决于您。一个合理的方法是解释 SERVING响应为服务处于事件状态并准备好接受更多请求， NOT SERVING响应为服务处于事件状态但不接受请求，以及 UNKNOWN或由于服务不活跃而无法响应。

这是实现该功能的探针配置:

    livenessProbe:
      failureThreshold: 3
      exec:
        # considers both SERVING and NOT SERVING to be a success
        command: ["/bin/sh", "-c", "bin/grpc_health_probe -addr=:8801 2>&1 | grep -q SERVING"]
      initialDelaySeconds: 240
      periodSeconds: 20
      successThreshold: 1
      timeoutSeconds: 15
    readinessProbe:
      failureThreshold: 3
      exec:
        # fails on any response except SERVING
        command: ["bin/grpc_health_probe", "-addr=:8801"]
      initialDelaySeconds: 20
      periodSeconds: 20
      successThreshold: 1
      timeoutSeconds: 15