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

Сценарий

• Liveness probe: проверяет, жив ли контейнер. Это аналогично ps команде, которая проверяет наличие процесса. Если проверка liveness probe завершается неудачно, кластер перезапускает контейнер. Если проверка liveness probe проходит успешно, никаких дальнейших действий не требуется.
• Readiness probe: проверяет, готово ли приложение в контейнере принимать трафик. В некоторых сценариях приложение запущено, но ещё не готово предоставлять услуги, потому что требуется загрузить большой объём данных с диска или инициализировать внешние сервисы. В этом случае можно использовать проверку readiness probe, чтобы предотвратить перенаправление трафика к приложению. Если проверка readiness probe не проходит, кластер CCE временно удаляет контейнер из списка эндпоинтов Service, блокируя внешние запросы. Если проверка readiness probe проходит успешно, контейнер считается готовым и может принимать трафик.
• Startup probe: проверяет, запущено ли приложение в контейнере. Кластер запускает проверки liveness и readiness только после успешного прохождения startup probe, чтобы гарантировать, что проверки не влияют на запуск приложения. Такой тип проверки хорошо подходит для контейнеров, которые долго стартуют. Он эффективно препятствует ошибочному признанию контейнеров аномальными и их завершению до завершения инициализации.

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

1. Войдите в консоль управления CCE console.
2. При создании рабочей нагрузки выбирайте Health Check в Информация о контейнере.
3. Выберите и настройте подходящую проверку в соответствии с вашими требованиями. Параметры проверок liveness, readiness и startup в основном одинаковы. Для примера рассмотрим проверку liveness. Значения параметров остальных проверок такие же.

   Table 1 Параметр проверки

   Параметр

   Описание

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

   Существует четыре варианта. Выберите один в зависимости от сценария сервиса. Подробнее о конкретных параметрах каждого метода проверки см. в разделе "Specific Parameters". Подробнее о общих параметрах, таких как период проверки и задержка, см. Общие параметры. HTTP (httpGet): применяется к контейнеру, предоставляющему сервисы по HTTP/HTTPS. Кластер будет периодически инициировать HTTP/HTTPS GET‑запрос к контейнеру. Если код статуса ответа находится в диапазоне 200–399, проверка считается успешной. В противном случае проверка не проходит. Необходимо указать порт, на котором слушает контейнер. TCP (tcpSocket): применяется к контейнеру, предоставляющему сервисы по TCP (например, базы данных, кэш, пользовательские TCP‑сервисы). Кластер будет периодически устанавливать TCP‑соединение с контейнером. Если соединение успешно, проверка считается успешной. В противном случае — не проходит. Необходимо указать порт, на котором слушает контейнер. Command (exec): необходимо указать исполняемую команду в контейнере. Кластер будет периодически выполнять команду в контейнере. Если вывод команды равен 0, проверка считается успешной. В противном случае проверка не проходит. ПРЕДУПРЕЖДЕНИЕ: В средах с высокой нагрузкой не используйте проверки на основе команд, так как они потребляют ресурсы системы. При нехватке ресурсов, например при высоком использовании CPU или блокировке файловой системы, проверка может завершиться по тайм‑ауту и будет отмечена как неудачная. Если необходимо использовать такие проверки, следуйте рекомендациям: Увеличьте порог неудач и расширьте тайм‑аут, чтобы временные всплески ресурсов не приводили к тайм‑ауту проверки. Однако это снизит чувствительность сервиса, поэтому настраивайте с осторожностью. Установите соответствующие ограничения CPU для сервисных контейнеров и системных ад‑онов. Иначе голодание по времени процессорных слотов может удерживать ядровые блокировки и блокировать exec‑probe для всех pod‑ов на узле. GRPC Check (grpc): применяется к gRPC‑приложениям. Не требуется открывать HTTP‑порты или зависеть от внешних скриптов. Проверка состояния контейнера может быть реализована через стандартные gRPC‑API.

4. Настройте остальные параметры и нажмите Create Workload в правом нижнем углу. Если рабочая нагрузка находится в состоянии Running, команда запуска выполнена успешно.

Specific Parameters

• HTTP (httpGet)

  Этот вариант применяется к контейнеру, предоставляющему сервисы по HTTP/HTTPS. Кластер будет периодически отправлять HTTP/HTTPS GET‑запрос в контейнер и определять результат проверки по статус‑коду HTTP. Подробности:

  • Если код статуса ответа находится в диапазоне 200–399, проверка считается успешной.
  • Если код статуса ответа находится за пределами 200–399, проверка не проходит.

  Ниже приведены параметры, характерные для проверки на основе HTTP‑запроса. Примерные значения в Table 2 показывают, что кластер периодически отправляет "GET http://172.16.0.186:80/health-check" в контейнер для проверки его состояния.

  Table 2 Параметры, характерные для проверки на основе HTTP‑запроса

  Параметр	Пример значения	Описание
  Path	/health-check	HTTP или HTTPS путь запроса для проверки состояния. Используйте абсолютный путь, начинающийся с символа "/".
  Port	80	(Обязательно) Порт, на котором слушает контейнер, используется для его поиска в pod.
  Host Address	172.16.0.186	IP‑адрес запрашиваемого хоста. Если параметр не указан, по умолчанию используется IP‑адрес pod.
  Protocol	HTTP	Протокол, используемый для отправки запросов. Значение должно соответствовать типу сервиса, предоставляемого контейнером.

• TCP (tcpSocket)

  Этот вариант применяется к контейнеру, предоставляющему сервисы по TCP (например, базы данных, кэши, пользовательские TCP‑сервисы). Кластер будет периодически устанавливать TCP‑соединение с контейнером для проверки состояния. Если соединение успешно, проверка считается успешной. В противном случае — не проходит. Необходимо указать порт, на котором слушает контейнер.

  Ниже приведены параметры, характерные для проверки на основе TCP‑порта. Предположим, что у контейнера Nginx порт прослушивания — 80. Если для контейнера настроена TCP‑проверка и указать порт проверки "80", кластер будет периодически устанавливать TCP‑соединение с этим портом. Если соединение успешно, проверка считается успешной. В противном случае — не проходит.Table 3 Параметры, характерные для проверки на основе TCP‑порта

  ПараметрПример значения

  Описание	Port	80
  (Обязательно) Порт, на котором слушает контейнер, используется для его поиска в pod.	Command

• (exec)

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

  Для проверок на основе TCP‑порта и HTTP‑запросов также можно указать команды для достижения аналогичного эффекта. Например, значения в Table 4 позволяют реализовать проверку, аналогичную HTTP‑запросу.

  Caution

  В средах с высокой нагрузкой не используйте проверки на основе команд, так как они потребляют ресурсы системы. При нехватке ресурсов, например при высоком использовании CPU или блокировке файловой системы, проверка может завершиться по тайм‑ауту и будет отмечена как неудачная. Если необходимо использовать такие проверки, следуйте рекомендациям:

  • Увеличьте порог неудач и расширьте тайм‑аут, чтобы временные всплески ресурсов не приводили к тайм‑ауту проверки. Однако это снизит чувствительность сервиса, поэтому настраивайте с осторожностью.
  • Установите соответствующие ограничения CPU для сервисных контейнеров и системных ад‑онов. Иначе голодание по времени процессорных слотов может удерживать ядровые блокировки и блокировать exec‑probe для всех pod‑ов на узле.

  Table 4 Параметры, характерные для проверки на основе команд

  Параметр	Пример значения	Описание
  Command	/bin/sh -c curl -sf http://172.16.0.186:80/health-check || exit 1	Команда, выполняемая в контейнере для проверки его состояния. ПРИМЕЧАНИЕ: Прежде чем использовать этот метод, необходимо включить программу или утилиту в образ контейнера. Кластер будет напрямую выполнять команду в контейнере, поэтому файловые системы хост‑машины или других контейнеров недоступны. Если программа или утилита (например, curl, nc, или пользовательский скрипт), от которой зависит команда, не включена в образ, будет выведено сообщение "Command not found". Если команда представляет собой shell‑скрипт, необходимо указать парсер скрипта. Кластер не выполняет проверки в интерактивной терминальной среде, поэтому скрипт нельзя запустить напрямую как команду. Нужно использовать редактор скриптов для его вызова. Например, если скрипт находится по пути /data/scripts/health_check.sh , выполните sh /data/scripts/health_check.sh.

• gRPC Check (grpc)

  Этот вариант применяется к gRPC‑приложениям. Не требуется открывать HTTP‑порты или зависеть от внешних скриптов. Проверка состояния контейнера может быть реализована через стандартные gRPC‑API. Проверка gRPC может использоваться только при выполнении следующих условий:

  • Кластеры CCE версии v1.25 и новее.
  • Ваше приложение поддерживает gRPC health check protocol.
  • Порт указан корректно. Как и при проверках HTTP и TCP, если порт неверен, приложение не поддерживает протокол проверки или имеется другая ошибка конфигурации, проверка не проходит.

  Table 5 Параметры, характерные для проверки gRPC

  Параметр	Пример значения	Описание
  Port	80	(Обязательно) Порт, на котором слушает контейнер, используется для его поиска в pod.

Common Parameters

...
livenessProbe:
  tcpSocket:
    port: 80
  initialDelaySeconds: 0
    timeoutSeconds: 1
    periodSeconds: 10
    successThreshold: 1
    failureThreshold: 3
...

Example YAML

1. Используйте kubectl для доступа к кластеру. Подробнее см. Accessing a Cluster Using kubectl.
2. Создайте YAML‑файл для конфигурации pod. В примере имя файла "health_check.yaml". При необходимости можете изменить его.vim health_check.yaml

   Example file content:
   
   

   apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-http spec: containers: - name: liveness image:

   <image_address>
       args:
       - /server
       livenessProbe:                 # Liveness probe
         httpGet:                     # An HTTP request is used to check the containers.
           path: /healthz             # The HTTP check path is /healthz/healthz.
           port: 80                   # The health check port is 8080.
           httpHeaders:               # (Optional) The request header name is Custom-HeaderCustom-Header and the value is AwesomeAwesome.
           - name: Custom-Header
             value: Awesome
         initialDelaySeconds: 3
         periodSeconds: 3
       readinessProbe:                # Readiness probe
         exec:                        # A command is used to check the containers.
           command:                   # Command to be executed
             - cat
             - /tmp/healthy
         initialDelaySeconds: 5
         periodSeconds: 5
       startupProbe:                  # Startup probe
         httpGet:                     # An HTTP request is used to check the containers.
           path: /healthz             # The HTTP check path is /healthz/healthz.
           port: 80                   # The health check port is 8080.
         failureThreshold: 30
         periodSeconds: 10
   
   

3. Create the pod.

   kubectl create -f health_check.yaml
   
   

   If information similar to the following is displayed, the pod is being created:

   pod/liveness-http created
   
   

4. Check the pod status.

   kubectl get deployment
   
   

   If the pod status is Running in the command output, the pod has been created.

   NAME               READY      STATUS       RESTARTS    AGE
   liveness-http      1/1        Running      1           4m59s