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

Источник

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

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

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

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

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

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

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

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

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

Пробы Kubernetes

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

ПРЕДУПРЕЖДЕНИЕ: в версии 1.16 часть API Kubernetes были помечены как устаревшие. Используйте это руководство по миграции, чтобы проверить совместимость.

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

• 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 и сообщает о потенциальных проблемах с конфигурациями.

В этих двух Telegram-каналах вас ждут новости нашего Kubernetes aaS и анонсы мероприятий @Kubernetes meetup.

Что почитать еще:

• 90 инструментов для работы с Kubernetes.
• Как устроен Kubernetes aaS на платформе MCS.
• Пять промахов при развертывании первого приложения на Kubernetes.