Как grpc-health-probe (проверка состояния gRPC на Kubernetes) различает тесты живучести и готовности - PullRequest
Новая
       36

Как grpc-health-probe (проверка состояния gRPC на Kubernetes) различает тесты живучести и готовности

0 голосов
/ 07 октября 2019

Я пишу один сервис grpc и использую проверку работоспособности gRPC в Kubernetes (https://github.com/grpc-ecosystem/grpc-health-probe).). На моем сервере я добавил другую реализацию (одну для живучести, а другую для готовности) конечных точек. Мне интересно, как работает эта утилита зондадвоичные различия между проверкой живучести и проверкой готовности? Должен быть какой-то другой способ определить его в yaml, а не только ["bin / grpc_health_probe", "-addr =: 8801"] 

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

В развертывании в Kubernetesyaml, я использую следующие конфигурации 

    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

1 Ответ

0 голосов
/ 10 октября 2019

Мне интересно, как эта двоичная утилита пробника различает проверку живучести и проверку готовности?

Короче говоря, нет.

Kubernetes определяет две разные проверки: liveness для проверки правильности работы программы (т. Е. Не зависания) и готовность для проверки готовности программы принимать больше запросов.

Однако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: 15
...