Как настроить liveness и readiness пробы для веб‑приложения в Kubernetes — пошаговое руководство

Что подготовить перед настройкой проб

Прежде чем писать манифесты и менять деплой, убедитесь, что у вас есть доступ к кластеру и нужные артефакты: kubeconfig с правами на создание/обновление Deployment/Pod, YAML‑шаблоны приложения и возможность перезапуска процесса CI/CD. Также проверьте, что приложение имеет стабильный эндпоинт для проверки состояния (например, /healthz и /ready) или позволяет выполнить проверку через команду внутри контейнера.

Подготовьте список параметров, которые будут управлять пробами: порт и путь для HTTP, команда для exec, а также значения таймаутов и порогов (initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold, successThreshold). Решите, какие ошибки считать критическими для liveness (перезапуск) и какие — для readiness (временное исключение из сервиса).

Наконец, настройте локальную возможность тестирования: kubectl port‑forward, доступ к логам (kubectl logs) и инструмент для отправки HTTP‑запросов (curl, httpie). Если в кластере есть CI/CD или GitOps, подготовьте план, как вносить изменения — напрямую через kubectl/helm или через merge в репозиторий инфраструктуры.

Какой тип пробы выбрать: HTTP, TCP или exec

HTTP‑пробы подходят для большинства веб‑приложений: они проверяют конкретный путь и позволяют получить семантику статусов (200 — OK, 5xx — проблема). Используйте HTTP, когда приложение уже предоставляет легкий endpoint, который выполняет минимальную логику и быстро отвечает. HTTP удобен для проверки готовности сервисов, которые зависят от зависимостей (базы, кеша): readiness может делать лёгкие запросы к внутренним ресурсам.

TCP‑проба просто проверяет открытость порта. Это полезно, если приложение не имеет HTTP‑эндпоинта для проверок, но слушает TCP‑порт (например, не‑HTTP сервис). TCP быстрее и проще, но не даёт информации о внутреннем состоянии приложения — открытый порт может обозначать, что процесс жив, но сервис не готов обслуживать запросы.

Exec‑пробы выполняют команду внутри контейнера, поэтому дают максимальную гибкость: можно проверить наличие файлов, соединение к БД, результат health‑check скрипта. Недостаток — нужно, чтобы контейнер имел утилиты для выполнения проверки, и команда выполнялась быстро. Выбор зависит от уровня контроля: для сложных внутренних проверок предпочтителен exec, для внешнего состояния — HTTP.

• HTTP — проверяет путь и код ответа; подходит для веб‑приложений.
• TCP — проверяет доступность порта; простая, но поверхностная.
• exec — выполняет команду внутри контейнера; гибкая, требует инструментов.

Примеры конфигурации проб для типичных приложений

Ниже — практические шаблоны, которые можно адаптировать. Для .NET Core используйте HTTP endpoints: liveness → /health/live, readiness → /health/ready. В манифесте Deployment это выглядит как: livenessProbe: httpGet: path: /health/live port: 80 initialDelaySeconds: 30 timeoutSeconds: 5; readinessProbe аналогично с меньшим initialDelaySeconds. Такой подход использует встроенные HealthChecks в ASP.NET и минимизирует ложные рестарты.

Для Node.js/Express часто создают лёгкий роут /healthz, который выполняет простую проверку зависимостей. Если не хочется добавлять HTTP, можно использовать exec: readinessProbe: exec: command: ["/bin/sh","-c","curl -f http://localhost:3000/ready || exit 1"] — но помните, exec запускает утилиту внутри контейнера и зависит от её наличия.

Для сервисов, которые слушают TCP (например, custom‑protocol), используйте tcpSocket: readinessProbe: tcpSocket: port: 12345; initialDelaySeconds: 10. Этот вариант быстро проверяет, что процесс слушает порт, но не гарантирует корректную обработку приложений уровня выше.

Пошаговая настройка в кластере: от манифеста до деплоя

1) Добавьте в Deployment или Pod секции livenessProbe и readinessProbe. 2) Начните с консервативных значений: initialDelaySeconds — чуть больше времени запуска приложения, timeoutSeconds — небольшое значение, periodSeconds — умеренный интервал. 3) Внесите изменения в тестовую среду или отдельный namespace. Такой поэтапный подход минимизирует риск простоя.

После применения манифеста (kubectl apply -f) следите за статусом Pod: kubectl get pods -w и kubectl describe pod <имя>. Если проба приводит к рестарту, проверьте логи контейнера и параметры таймаутов. Пошаговая отладка: временно увеличьте initialDelaySeconds, уменьшите frequency или используйте exec‑проверку, чтобы локализовать проблему.

Если изменения проходят тесты, интегрируйте их в CI/CD — обновление image или манифеста должно проходить через pipeline. При использовании Helm храните значения проб в values.yaml, чтобы можно было быстро откатить настройки. Убедитесь, что rollout strategy корректно настроена и вы готовы к откату (kubectl rollout undo).

Контрольные точки перед запуском проверки проб

Прежде чем включать пробу в production, пройдите обязательные проверки: 1) приложение стабильно стартует в контейнере, 2) endpoint проверок отвечает по локальному curl, 3) проверка выполняется быстро (время ответа меньше timeoutSeconds). Эти проверки устраняют частые причины ложных срабатываний проб.

Проверьте ресурсную доступность: CPU и память не должны на старте быть на грани. Если старт приложения периодически занимает больше времени, увеличьте initialDelaySeconds. Также убедитесь, что зависимости приложения (БД, очередь) доступны хотя бы в режиме чтения/подключения, если readiness зависит от них.

Проверьте логи системы и kube‑events: kubectl describe pod покажет причины срабатывания livenessProbe (например, BackOff или CrashLoopBackOff). Если обнаружите частые рестарты, детализируйте логи приложения и рассматривайте возможность добавить более мягкие thresholds или health‑endpoint, возвращающий более детальный статус.

• Endpoint health отвечает быстро и стабильно
• initialDelaySeconds покрывает старт‑время приложения
• Логи контейнера не содержат критичных ошибок на старте

Методы тестирования проб: локально и в кластере

Тестирование локально: используйте docker run или kind/minikube для быстрого воспроизведения окружения. Запустите контейнер и выполните curl localhost:/healthz или команду, используемую в exec. Это позволяет отладить сам endpoint без влияния Kubernetes. Для HTTP‑проб проверяйте статусы 200/503, для exec — коды возврата.

Тестирование в кластере: примените манифест в тестовый namespace и наблюдайте за поведением. Команды: kubectl get pods, kubectl describe pod, kubectl logs. Для имитации отказа вручную можете заставить endpoint возвращать 500 или временно закрыть внешний ресурс; затем смотрите, как kubelet обрабатывает состояние: удаляет ли под из Endpoints (readiness) или рестартует контейнер (liveness).

Дополнительно используйте kubectl port‑forward для локального обращения к сервису и инструменты тестирования нагрузки, чтобы убедиться, что периодичность проверок не создаёт лишней нагрузки. Для автоматизации тестов проб можно написать e2e тесты, которые эмулируют частичный отказ зависимостей и проверяют, что поведение соответствует ожиданиям.

Как приложение и кластер реагируют на провалы проб

Когда readiness проба падает, kube‑controller исключает Pod из Endpoints сервиса: трафик перестаёт идти на этот под, но сам контейнер не перезапускается. Это позволяет Kubernetes направлять запросы только на готовые реплики и постепенно исключать «неготовые» инстансы при обновлениях или деградации.

Если liveness проба падает (несколько последовательных неудач в соответствии с failureThreshold), kubelet считает контейнер неработоспособным и перезапускает его. Это полезно при ситуациях, когда процесс завис или находится в неконсистентном состоянии и требуется перезапуск для восстановления. Неправильно сконфигурированные liveness‑пробы могут приводить к циклическим рестартам, поэтому важна корректная настройка таймингов.

Учтите взаимодействие с readiness и liveness: например, при долгом старте приложения сначала выставьте readiness в false (по умолчанию) и включите liveness с большим initialDelaySeconds. Это предотвратит ранние перезапуски до того, как приложение успеет инициализироваться.

Мониторинг и оповещения по состоянию проб

Добавьте метрики и дашборды, которые отслеживают успех/провал проб и количество рестартов Pod. Интеграция с Prometheus и kube‑state‑metrics позволяет видеть тренды: растёт ли число падений чтения/живости, сколько подов находится в CrashLoopBackOff, и какие сервисы чаще теряют готовность. Эти данные помогают принять решение о корректировке порогов или оптимизации приложения.

Настройте alert‑правила: оповещения по увеличению частоты рестартов, длительной недоступности readiness для сервиса или падению общего числа READY‑реплик ниже порога. Оповещения должны быть информативными и указывать namespace, Deployment и последние логи, чтобы ускорить диагностику.

Регулярно просматривайте метрики после внесения изменений: изменение initialDelaySeconds или timeoutSeconds может снизить количество ложных срабатываний, но увеличить время обнаружения реального сбоя. Мониторинг поможет сбалансировать чувствительность проб и устойчивость сервиса.

Последние шаги перед продакшен‑запуском и проверка после релиза

Перед переводом изменений в production выполните staged rollout: обновите небольшую долю реплик, проверьте метрики и логи, затем увеличивайте rollout. Используйте kubectl rollout status или мониторинг в CI/CD для автоматической валидации. Если обнаружите критические проблемы — откатывайте через kubectl rollout undo или откат в CI/CD.

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

Документируйте итоговые параметры проб в репозитории infra/helm‑values и оставьте комментарии почему выбраны именно эти значения. Это поможет коллегам быстрее ориентироваться при последующих изменениях и минимизирует риск регресса при обновлениях.

Частые вопросы