Что произойдет, если под не пройдет liveness пробу

Анализ последствий провала liveness-пробы в Kubernetes

Когда liveness-проба (проверка жизнеспособности) для Pod в Kubernetes завершается неудачно, система интерпретирует это как сигнал о том, что контейнер внутри Pod перестал корректно функционировать, даже если процесс ещё работает. Это критическое событие, которое запускает автоматический процесс восстановления.

Что именно происходит?

1. Kubernetes отмечает Pod как "нездоровый". Состояние контейнера в описании Pod (kubectl describe pod <pod-name>) изменится, отражая неудачные проверки.

2. Kubelet на узле инициирует перезапуск контейнера. Это ключевое действие. Согласно политике перезапуска (restartPolicy, обычно Always для Pod'ов с liveness-пробой), контейнер будет убит и создан заново.

   apiVersion: v1
   kind: Pod
   metadata:
     name: liveness-example
   spec:
     containers:
     - name: liveness
       image: busybox
       args:
       - /bin/sh
       - -c
       - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
       livenessProbe:
         exec:
           command:
           - cat
           - /tmp/healthy
         initialDelaySeconds: As long as the file /tmp/healthy exists, the probe succeeds.
       restartPolicy: Always # Именно эта политика определяет поведение при провале пробы
   

3. Последовательность событий при перезапуске:

    *   Подается сигнал `SIGTERM` основному процессу контейнера для graceful shutdown.
    *   Выдерживается `terminationGracePeriodSeconds` (по умолчанию 30 секунд).
    *   Если процесс не завершился, посылается `SIGKILL`.
    *   Запускается новый экземпляр контейнера с чистого листа (с точки зрения процессов и файловой системы контейнера, томов `emptyDir`).

1. Увеличение счетчика рестартов. Это важный диагностический показатель.

   kubectl get pod <pod-name>
   # В колонке RESTARTS будет увеличиваться счетчик
   

Каковы бизнес-последствия и риски?

• Кратковременная недоступность сервиса: На время перезапуска (запуск нового контейнера, инициализация приложения) Pod не будет обслуживать трафик. Для предотвращения этого необходим readinessProbe и несколько реплик сервиса.
• Потеря состояния в памяти: Любое состояние, хранимое в памяти процесса (сессии пользователей, кэш, несохраненные данные), будет безвозвратно утеряно.
• Маскировка коренной проблемы: Частые рестарты могут временно "скрывать" симптом, но не устраняют причину (утечка памяти, deadlock, зависание на внешней зависимости). Это приводит к "дергающемуся" Pod'у.
• Увеличение нагрузки на узел и registry: Постоянная пересборка контейнера потребляет ресурсы узла и может создавать нагрузку на registry образов.

Рекомендации по проектированию и отладке

1. Liveness-проба должна быть "жесткой". Она должна проверять критическую внутреннюю функцию приложения (например, возможность подключиться к собственной БД, рассчитать простой ответ), а не внешние зависимости. Проверка внешних сервисов — задача readinessProbe.
2. Всегда настраивайте initialDelaySeconds и periodSeconds адекватно. Дайте приложению время полностью инициализироваться перед первой проверкой.

   livenessProbe:
     httpGet:
       path: /healthz
       port: 8080
     initialDelaySeconds: 45 # Ждем полного старта приложения
     periodSeconds: 10       # Проверяем каждые 10 секунд
     failureThreshold: 3     # Даем 3 попытки перед объявлением "мертвым"
   

3. Используйте логи и метрики для анализа. При частых рестартах исследуйте:

    *   Логи контейнера **до момента рестарта** (`kubectl logs <pod-name> --previous`).
    *   Метрики потребления памяти/CPU.
    *   События Pod'а (`kubectl describe pod <pod-name>`).

1. Рассмотрите комбинацию с readiness-пробой. ReadinessProbe отключит Pod из балансировщика нагрузки при проблемах, но не перезапустит его, позволяя провести диагностику. Liveness — это последний рубеж, когда перезапуск является единственным вариантом.

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