我正在编写一个grpc服务,并在Kubernetes (https://github.com/grpc-ecosystem/grpc-health-probe)上使用https://github.com/grpc-ecosystem/grpc-health-probe健康检查。在我的服务器中,我添加了端点的不同实现(一个用于活动,另一个用于就绪)。我想知道这个探测工具二进制如何区分活性检查和准备状态检查?在yaml中应该有其他方法来定义它,而不仅仅是“bin/grpc_health_探针”、"-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
kubectl exec -it <MY_POD_NAME> -- /bin/bash
bash-4.4$ ./grpc_health_probe -addr=localhost:8801
status: SERVING发布于 2019-10-10 12:38:52
我想知道这个探测工具二进制如何区分活性检查和准备状态检查?
总之,事实并非如此。
Kubernetes定义了两个不同的检查:活性检查程序是否仍然正常工作(即没有挂起)和准备就绪检查程序是否愿意接受更多请求。
然而,gRPC只定义了一个健康检查协议,并且没有本机的“就绪检查”的概念。
如何将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: 15https://stackoverflow.com/questions/58274364
复制相似问题