Понимаем пробы Kubernetes: типы, настройка и лучшие практики

Перевод статьи о настройке проб готовности, работоспособности и запуска для обнаружения и работы с нездоровыми подами.

Зачем нужны проверки Kubernetes

Одна из проблем, связанных с архитектурой распределенных систем и микросервисов — это автоматическое обнаружение неисправных приложений, перенаправление запросов в другие доступные системы и восстановление поврежденных компонентов. Проверки работоспособности — один из способов решения этой проблемы и обеспечения надежности. В Kubernetes проверки работоспособности настраиваются с помощью проб для определения состояния каждого пода.

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

Пробы Kubernetes

Kubernetes поддерживает пробы готовности и работоспособности для версий ≤ 1.15. Пробы запуска были добавлены в 1.16 в качестве альфа-функции и перешли в бета-версию в 1.18.

Многие разработчики полагают, что этой базовой настройки достаточно, особенно когда приложение внутри пода настроено с помощью менеджеров процессов, например PM2 для Node.js.

В этой статье автор рассматривает различные типы проб, а также передовые методы и инструменты для обнаружения развертываний с потенциальными проблемами конфигурации.

Пробы Kubernetes

Kubernetes поддерживает пробы готовности и работоспособности для версий ≤ 1.15. Пробы запуска были добавлены в 1.16 в качестве альфа-функции и перешли в бета-версию в 1.18.

Все пробы имеют следующие параметры:

• initialDelaySeconds: количество секунд ожидания перед запуском проверки работоспособности или готовности;
• periodSeconds: как часто проверять пробу;
• timeoutSeconds: количество секунд до отметки тайм-аута пробы (проверка работоспособности дала сбой);
• successThreshold: минимальное количество последовательных успешных проверок, чтобы проба была помечена как пройденная;
• failureThreshold: количество повторных попыток до пометки пробы как неудачной. Для проб живучести это приведет к перезапуску пода. Для проб готовности это приведет к тому, что контейнер будет помечен как неготовый.

Пробы готовности

Пробы готовности используют, чтобы сообщить kubelet, когда приложение готово принять новый трафик. Если приложению требуется некоторое время для инициализации состояния после запуска процесса, настройте пробу готовности, чтобы Kubernetes подождал перед отправкой нового трафика. Основным вариантом использования проб готовности является направление трафика к деплойментам за сервисами.

Важно помнить, что пробы готовности работают в течение всего жизненного цикла пода. Это означает, что они будут запускаться не только при запуске, но и повторно на протяжении всего времени работы пода.

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

Пробы работоспособности

Пробы работоспособности используют для перезапуска неработоспособных контейнеров. Kubelet периодически вызывает пробу работоспособности, определяет здоровье пода и убивает его, если он не проходит проверку работоспособности.

Проба может помочь приложению выйти из тупиковой ситуации. Без проверок работоспособности Kubernetes считает заблокированный под работоспособным, поскольку основной процесс продолжает работать с точки зрения Kubernetes. Настроив пробу работоспособности, kubelet может определить, что приложение находится в плохом состоянии, и перезапустит под, чтобы восстановить доступность.

Пробы запуска

Пробы запуска аналогичны пробам готовности, но выполняются только при запуске. Они оптимизированы для медленного запуска контейнеров или приложений с непредсказуемыми процессами инициализации. С помощью проб готовности мы можем настроить initialDelaySeconds, чтобы определить, как долго ждать перед проверкой готовности.

Теперь рассмотрим приложение, в котором иногда требуется загрузить большие объемы данных или выполнить ресурсоемкую операцию в начале процесса. Поскольку initialDelaySeconds является статическим числом, мы вынуждены всегда брать наихудший сценарий (или увеличивать значение failureThreshold, что может повлиять на дальнейшее поведение) и ждать в течение длительного времени, даже если этому приложению не требуется выполнять длительную инициализацию.

Вместо этого с помощью проб запуска мы можем настроить failureThreshold и periodSeconds, чтобы лучше обрабатывать эту неопределенность. Например, установка failureThreshold в 15 и periodSeconds в 5 означает, что приложение получит 15 x 5 = 75 секунд на запуск до того, как будет диагностирован сбой.

Настройка проб

Теперь, когда мы понимаем различные типы проб, мы можем изучить три различных способа настройки каждой пробы.

HTTP

Kubelet отправляет HTTP GET запрос на указанный URL и проверяет ответ 2xx или 3xx. Вы можете использовать существующую конечную точку (endpoint) HTTP или настроить облегченный HTTP-сервер для проверки (например, сервер Express с конечной точкой /healthz).

Пробы HTTP принимают дополнительные параметры:

• host: имя хоста для подключения (по умолчанию это IP-адрес пода);
• scheme: HTTP по умолчанию или HTTPS;
• path: путь на HTTP/S сервере;
• httpHeaders: настраиваемые заголовки, если вам нужны значения заголовков для аутентификации, настройки CORS и так далее;
• port: имя или номер порта для доступа к серверу.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080

TCP

Если вам просто нужно проверить, можно ли установить TCP-соединение, используйте TCP-пробу. Под помечается как работоспособный, если может установить TCP-соединение. Использование TCP-проб может быть полезно для gRPC или FTP-сервера, где HTTP-вызовы не подходят.

readinessProbe:
  tcpSocket:
    port: 21

Команда

Также можно настроить пробу для запуска команды оболочки. Проверка проходит, если команда возвращается с кодом выхода 0. В противном случае под помечается как неисправный.

Этот тип проверки может быть полезен, если нежелательно открывать HTTP-сервер/порт или проще проверить шаги инициализации с помощью команд. Например, проверить, был ли создан файл конфигурации или запустить команду CLI.

readinessProbe:
  exec:
    command: ["/bin/sh", "-ec", "vault status -tls-skip-verify"]

Лучшие практики проб Kubernetes

Точные параметры проб зависят от вашего приложения, но вот несколько общих рекомендаций для начала:

1. Для более старых (≤ 1.15) кластеров Kubernetes используйте пробу готовности с начальной задержкой для обработки фазы запуска контейнера. Для этого используйте время 99% перцентиля. Но сделайте эту проверку легкой, поскольку проба готовности будет выполняться на протяжении всего жизненного цикла модуля. Мы не хотим, чтобы проба истекала по тайм-ауту, потому что проверка готовности занимает много времени.
2. Для более новых (≥ 1.16) кластеров Kubernetes используйте пробу запуска для приложений с непредсказуемым или переменным временем запуска. Проба запуска может использовать ту же конечную точку (например, /healthz), что и пробы готовности и работоспособности. Но установите значение failureThreshold выше, чем у других проб, чтобы учесть более длительное время запуска. Для проверок работоспособности и готовности стоит установить более разумное время до отказа.
3. Пробы готовности и работоспособности могут иметь одну и ту же конечную точку, если пробы готовности не используются для других целей сигнализации. Если есть только один под, например, при вертикальном автомасштабировании подов, настройте тест готовности для определения поведения при запуске и используйте тест работоспособности для определения работоспособности. В этом случае маркировка пода как нездорового означает простой в работе.
4. Проверки готовности могут использоваться различными способами, чтобы сигнализировать о деградации системы.Например, если приложение теряет соединение с базой данных, можно использовать пробы готовности, чтобы временно заблокировать новые запросы и позволить системе повторно подключиться. Пробы также можно использовать для балансировки нагрузки на другие поды, помечая занятые поды как неготовые.

Короче говоря, четко определенные пробы обычно повышают устойчивость и доступность. Обязательно следите за временем запуска и поведением системы, чтобы настроить параметры проб по мере изменения приложений.

Инструменты

Учитывая важность проб Kubernetes, вы можете использовать инструменты анализа ресурсов Kubernetes для обнаружения отсутствующих проб. Эти инструменты можно запускать в существующих кластерах или встроить в процесс CI/CD для автоматического отказа от деплоя рабочих нагрузок без правильно настроенных ресурсов:

• polaris — утилита анализа ресурсов с красивой панелью инструментов, которую также можно использовать в качестве проверочного веб-хука или инструмента командной строки;
• kube-score — инструмент статического анализа кода, который работает с файлами Helm, Kustomize и стандартными файлами YAML;
• popeye — служебный инструмент (умеет только читать), который сканирует кластеры Kubernetes и сообщает о потенциальных проблемах с конфигурациями.