Что будет, если упал Health Check в Deployment

Влияние сбоя Health Check на Deployment в Kubernetes

Когда Health Check (проверка здоровья) в Deployment Kubernetes падает, система автоматически начинает процесс восстановления работоспособности пода (Pod), чтобы обеспечить доступность приложения. Этот механизм является ключевым для самоисцеления кластера.

Типы Health Check и их реакция на сбой

В Kubernetes существуют два основных типа проверок здоровья:

• Liveness Probe (Проба жизнеспособности): Определяет, жив ли контейнер. Если проба падает, kubelet убивает контейнер, и он подвергается процессу restart согласно политике restartPolicy Pod (обычно Always).
• Readiness Probe (Проба готовности): Определяет, готов ли контейнер принимать трафик. Если проба падает, Pod удаляется из списка готовых эндпоинтов всех соответствующих Services. Это означает, что новый трафик не будет направлен на этот Pod, пока проба не станет успешной.

Последовательность событий при падении Health Check

Рассмотрим сценарий для Deployment с 3 репликами (replicas: 3), где у одного Pod падает Readiness Probe.

1. Обнаружение сбоя: kubelet на узле, где запущен Pod, выполняет проверку согласно заданным параметрам (например, failureThreshold: 3). После последовательных неудач проба считается павшей.
2. Изоляция Pod: Pod получает статус NotReady. Контроллер эндпоинтов Service (Endpoints Controller) немедленно удаляет IP этого Pod из объекта Endpoints (или EndpointSlice), связанного с Service.
3. Влияние на трафик: kube-proxy на всех узлах обновляет свои правила (например, iptables) и исключает IP-адрес неготового Pod из цепочек балансировки нагрузки. Новые запросы к Service будут распределены только между остальными готовыми Pods.
4. Попытка восстановления (для Liveness Probe): Если падает Liveness Probe, kubelet завершает контейнер и создает новый внутри того же Pod. Pod сохраняет свой IP и идентичность, но контейнер рестартует. При повторных неудачах может увеличиваться задержка перед рестартом (backOff timer).
5. Автоматическое масштабирование (не происходит): Важно отметить, что сам Deployment не создает новую реплику для замены Pod с павшей пробой готовности. Число реплик остается 3: один Pod в статусе NotReady, два в статусе Ready. Новая реплика будет создана только если Pod полностью терминируется (например, при падении Liveness Probe и последующем сбое контейнера, или при ручном удалении).

Пример статуса Pod и Endpoints

После падения Readiness Probe статус Pod в выводе kubectl get pods будет выглядеть так:

NAME                          READY   STATUS    RESTARTS   AGE
myapp-deploy-5f8c9           0/1     Running   0          2m
myapp-deploy-a1b2c           1/1     Running   0          5m
myapp-deploy-d3e4f           1/1     Running   0          5m

Здесь READY: 0/1 указывает, что основной контейнер Pod не готов.

Состояние Endpoints для соответствующего Service:

kubectl describe svc myapp-service

В секции Endpoints будут указаны только IP-адреса двух готовых Pods.

Практические рекомендации и наблюдение

• Мониторинг: Настройте алерты на события Kubernetes (например, через инструменты типа Prometheus с Alertmanager) на увеличение количества Pods с статусом NotReady или частые рестарты контейнеров.
• Логирование: Убедитесь, что логи контейнеров доступны для анализа причин сбоя проб (проблемы в приложении, зависимых сервисах, ресурсах).
• Настройка параметров проб: Тщательно подбирайте параметры initialDelaySeconds, periodSeconds, timeoutSeconds и failureThreshold, чтобы избежать ложных сбоев из-за медленного старта приложения или временных проблем.
• Graceful Shutdown: Если Pod становится неготовым, приложение внутри него должно корректно обрабатывать существующие соединения (например, запросы, которые уже были направлены на него до исключения из Endpoints).

Таким образом, падение Health Check приводит к автоматической изоляции проблемного Pod от входящего трафика (для Readiness Probe) или его рестарту (для Liveness Probe), что минимизирует влияние на пользователей и позволяет системе сохранять общую доступность сервиса.