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

Сценарий

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

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

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

   Таблица 1 Параметр зонда

   Параметр

   Описание

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

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

4. Настройте другие параметры и нажмите Создать рабочую нагрузку в правом нижнем углу. Если нагрузка находится в Запущено состоянии команда запуска успешно выполнена.

Конкретные параметры

• HTTP

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

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

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

  Таблица 2 Параметры, специфичные для проверки на основе HTTP‑запроса

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

• TCP

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

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

  Таблица 3 Параметры, специфические для проверки по TCP‑порту

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

• Команда

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

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

  Caution

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

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

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

• gRPC Check

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

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

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

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

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

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

Пример YAML

1. Используйте kubectl для доступа к кластеру. Подробности см Доступ к кластеру с помощью 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 Запущен в выводе команды pod был создан.

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