我正在编写一个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
我刚刚进行测试,发现当我执行kubernetes pod时,“ GrpcModuleReadinessCheck”(我最后添加的健康类)实现正在生效
kubectl exec -it <MY_POD_NAME> -- /bin/bash
bash-4.4$ ./grpc_health_probe -addr=localhost:8801
status: SERVING
答案 0 :(得分:0)
我想知道此探针实用程序二进制文件如何区分活动检查和准备检查吗?
简而言之,不是。
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