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

Health check регулярно проверяет состояние контейнеров, когда контейнеры находятся в работе. Если проверка состояния не настроена, pod не может обнаружить исключения приложения или автоматически перезапустить приложение для его восстановления. В результате pod может находиться в состоянии Running, но приложение недоступно или работает аномально.

Kubernetes предоставляет три типа проверок состояния для мониторинга приложений в контейнерах с целью обеспечения стабильности системы и высокой доступности.

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

Для получения дополнительной информации см. Liveness, Readiness, and Startup Probes и Configure Liveness, Readiness and Startup Probes.

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

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

   Параметр

   Описание

   Check Method

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

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

• 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‑запроса

  Parameter	Example Value	Description
  Path	/health-check	Путь HTTP или HTTPS запроса для проверки работоспособности. Используйте абсолютный путь, начинающийся со слеша (/).
  Port	80	(Mandatory) Порт, на котором слушает контейнер, используемый для определения местоположения контейнера в 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‑порту

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

• Command (exec)

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

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

  Caution

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

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

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

  Parameter	Example Value	Description
  Command	/bin/sh -c curl -sf http://172.16.0.186:80/health-check || exit 1	Команда, выполняемая в контейнере для проверки его состояния. NOTE: Перед использованием этого метода необходимо упаковать программу или утилиту в образ контейнера. Кластер будет напрямую выполнять команду в контейнере, поэтому файловые системы хост‑машины или других контейнеров недоступны. Если программа или утилита (например, 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

  Parameter	Example Value	Description
  Port	80	(Обязательно) Порт, на котором слушает контейнер, используемый для определения местоположения контейнера в pod.

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

   vim health_check.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:                     # An HTTP request is used to check the containers.
           path: /healthz             # The HTTP check path is  /healthz .
           port: 80                   # The health check port 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:                        # 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 .
           port: 80                   # The health check port is  80 .
         failureThreshold: 30
         periodSeconds: 10
   
   

3. Создайте pod.

   kubectl create -f health_check.yaml
   
   

   Если отображается информация, похожая на следующую, pod создаётся:

   pod/liveness-http created
   
   

4. Проверьте статус pod.

   kubectl get deployment
   
   

   Если статус pod Running в выводе команды, pod был создан.

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