Настройка проверки состояния контейнера

Сценарий

• Зонд живости (livenessProbe): проверяет, жив ли контейнер. Он похож на ps команда, проверяющая, существует ли процесс. Если проверка живости контейнера не проходит, кластер перезапускает контейнер. Если проверка живости проходит успешно, никаких действий не выполняется.
• Зонд готовности (readinessProbe): проверяет, готов ли контейнер обрабатывать запросы пользователей. Если контейнер определяется как не готовый, трафик сервиса не будет направлен к контейнеру. Для некоторых приложений может потребоваться длительное время для запуска, прежде чем они смогут предоставлять услуги. Это происходит потому, что им необходимо загрузить данные с диска или ждать запуска внешнего модуля. В этом случае, хотя процесс приложения запущен, приложение не может предоставлять услуги. Для решения этой проблемы используется данный health check probe. Если проверка готовности контейнера не проходит, кластер маскирует все запросы, отправленные к контейнеру. Если проверка готовности контейнера проходит успешно, к контейнеру можно получить доступ.
• Проба запуска (startupProbe): проверяет, когда контейнеризованное приложение запущено. Если такой зонд настроен, он отключает проверки liveness и readiness до тех пор, пока не пройдет успешно, гарантируя, что эти зонд не будут мешать запуску приложения. Это может использоваться для применения проверок liveness к медленно запускающимся контейнерам, избегая их завершения kubelet до завершения запуска.

Метод проверки

• HTTP запрос

  Этот режим проверки состояния применяется к контейнерам, предоставляющим услуги HTTP/HTTPS. Кластер периодически инициирует запрос HTTP/HTTPS GET к таким контейнерам. Если код возврата ответа HTTP/HTTPS находится в диапазоне 200–399, проверка считается успешной. В противном случае проверка считается неудачной. В этом режиме проверки состояния необходимо указать порт прослушивания контейнера и путь HTTP/HTTPS запроса.

  Например, для контейнера, предоставляющего услуги HTTP, путь проверки HTTP /health-check, порт 80, а адрес хоста необязателен (по умолчанию используется IP‑адрес контейнера). Здесь в качестве примера используется 172.16.0.186, и мы можем получить такой запрос: GET http://172.16.0.186:80/health-check. Кластер периодически инициирует этот запрос к контейнеру. Вы также можете добавить один или несколько заголовков к HTTP‑запросу. Например, задайте имя заголовка запроса Custom-Header и соответствующее значение пример.

• TCP порт

  Для контейнера, предоставляющего услуги TCP‑связи, кластер периодически устанавливает TCP‑соединение с контейнером. Если соединение успешно, проба считается успешной. В противном случае проба не удалась. В этом режиме проверки состояния необходимо указать порт прослушивания контейнера.

  Например, если у вас есть контейнер Nginx с портом сервиса 80, после указания TCP‑порта 80 для прослушивания контейнера кластер будет периодически инициировать TCP‑соединение с портом 80 контейнера. Если соединение успешно, проба считается успешной. В противном случае проба не удалась.

• CLI

  CLI — это эффективный инструмент для проверки состояния. При использовании CLI необходимо указать исполняемую команду в контейнере. Кластер периодически выполняет команду в контейнере. Если выход команды равен 0, проверка состояния считается успешной. В противном случае проверка состояния не удалась.

  Режим CLI можно использовать вместо проверки состояния, основанной на HTTP‑запросах и TCP‑портах.

  • Для TCP‑порта вы можете использовать скрипт программы для подключения к порту контейнера. Если соединение успешно, скрипт возвращает 0. В противном случае скрипт возвращает –1.
  • Для HTTP‑запроса вы можете использовать скриптовую команду для запуска wget команду для обнаружения контейнера.

    wget http://127.0.0.1:80/health-check

    Проверьте код возврата ответа. Если код возврата находится в диапазоне 200–399, скрипт возвращает 0. В противном случае скрипт возвращает –1.

    Notice

    • Поместите программу, которую нужно выполнить, в образ контейнера, чтобы её можно было исполнить.
    • Если команда, которую нужно выполнить, представляет собой shell‑скрипт, не указывайте скрипт напрямую как команду, а добавьте парсер скриптов. Например, если скрипт находится /data/scripts/health_check.sh, вы должны указать sh/data/scripts/health_check.sh для выполнения команды.
• gRPC‑проверка

  gRPC‑проверки могут настраивать startup, liveness и readiness проб для вашего gRPC‑приложения без раскрытия какого‑либо HTTP‑эндпоинта, и вам не нужен исполняемый файл. Kubernetes может подключаться к вашей рабочей нагрузке через gRPC и получать её статус.

  Notice

  • Проверка gRPC поддерживается только в кластерах CCE версии v1.25 и выше.
  • Чтобы использовать gRPC для проверки, ваше приложение должно поддерживать протокол проверки работоспособности gRPC.
  • Как и в случае HTTP и TCP‑проб, если порт неверен или приложение не поддерживает протокол проверки работоспособности, проверка завершается неудачей.

Общие параметры

YAML Пример

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: <image_address>
    args:
    - /server
    livenessProbe:                 # Liveness probe
      httpGet:                     # Checking an HTTP request is used as an example.
        path: /healthz             # The HTTP check path is /healthz.
        port: 80                   # The check port number is 80.
        httpHeaders:               # (Optional) The request header name is Custom-Header and the value is Awesome.
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3
    readinessProbe:                # Readiness probe
      exec:                        # Checking an execution command is used as an example.
        command:                   # Command to be executed
          - cat
          - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
    startupProbe:                  # Startup probe
      httpGet:                     # Checking an HTTP request is used as an example.
        path: /healthz             # The HTTP check path is /healthz.
        port: 80                   # The check port number is 80.
      failureThreshold: 30
      periodSeconds: 10