Exec зонд в GKE

Question

Я пытаюсь использовать exec-зонды для готовности и жизнеспособности в GKE. Это связано с тем, что он является частью рекомендованного Kubernetes способа проверки работоспособности на серверах gRPC. Однако когда я помещаю конфигурацию exec probe в свой yaml для развертывания и применяю ее, она не вступает в силу в GCP. Это мой контейнер yaml:

  - name: rev79-uac-sandbox
    image: gcr.io/rev79-232812/uac:latest
    imagePullPolicy: Always
    ports:
    - containerPort: 3011
    readinessProbe:
      exec:
        command: ["bin/grpc_health_probe", "-addr=:3011"]
      initialDelaySeconds: 5
    livenessProbe:
      exec:
        command: ["bin/grpc_health_probe", "-addr=:3011"]
      initialDelaySeconds: 10

Но проверки работоспособности все равно не выполняются, и когда я смотрю на конфигурацию проверки работоспособности в консоли GCP, я вижу обычную проверку работоспособности HTTP, направленную на '/'

Когда я редактирую проверку работоспособности в консоли GCP, кажется, нет никакого способа выбрать тип exec. Также я не вижу упоминаний о проверках живучести в отличие от проверок готовности, даже если это отдельные вещи Kubernetes.

Облако Google поддерживает использование exec для проверки работоспособности? Если да, то как мне это сделать? Если нет, как я могу проверить работоспособность сервера gRPC?

Answer 1

TCP-зонды полезны, когда мы используем gRPC Services вместо использования HTTP-зондов.

    - containerPort: 3011
    readinessProbe:
      tcpSocket:
        port: 3011
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 3011
      initialDelaySeconds: 15
      periodSeconds: 20

kubelet попытается открыть сокет для вашего контейнера на указанном порту.Если он может установить соединение, контейнер считается исправным, если он не может, это считается ошибкой define-a-tcp-liveness-probe

Answer 2

Сервер должен реализовать протокол зонда grpc, как указано здесь , как указано в этой статье

Answer 3

Оба ответа от Василий Ангапов и Суреш Вишной должны теоретически работать, однако на практике они не (по крайней мере, в моей практике).

ТакМое решение состояло в том, чтобы запустить другой сервер в моем бэкэнд-контейнере - HTTP-сервер, который просто выполняет проверку работоспособности всякий раз, когда получает запрос, и возвращает статус 200, если он проходит, и 503, если он не выполняется.

Мне также пришлось открыть второй порт в моем контейнере для прослушивания этого сервера.

Answer 4

Exec-зонды работают в GKE так же, как и везде. Вы можете просмотреть результат проверки живучести в "модуле описания куба". Или вы можете просто войти в pod, выполнить команду и увидеть ее код возврата.