Что произойдет, если Pod в Kubernetes не пройдет liveness-пробу?

Если контейнер в Pod'е последовательно проваливает liveness-пробу, kubelet на узле убивает этот контейнер и перезапускает его согласно политике перезапуска Pod'а (restartPolicy).

Механизм работы:

1. Пробу настраивают в манифесте. Например, HTTP-проверка эндпоинта /health каждые 10 секунд.

   livenessProbe:
     httpGet:
       path: /health
       port: 8080
     initialDelaySeconds: 30  # Даем приложению время на старт
     periodSeconds: 10        # Проверяем каждые 10 сек
     failureThreshold: 3      # После 3х неудач подряд - контейнер неживой

2. Если проба fails, kubelet ждет следующей попытки (periodSeconds).
3. После failureThreshold (по умолчанию 3) последовательных неудач kubelet считает контейнер "неживым" (dead).
4. Kubelet останавливает контейнер (отправляет SIGTERM, затем SIGKILL) и создает его заново, используя тот же образ.

Важные нюансы из практики:

• Pod остается, перезапускается только контейнер. Имя Pod, IP-адрес (если не изменился узел) и привязанные тома (PersistentVolumes) сохраняются.
• CrashLoopBackOff: Если контейнер постоянно падает при старте (или сразу проваливает liveness-пробу), Kubernetes вводит экспоненциальную задержку перезапуска (10s, 20s, 40s...), чтобы не нагружать систему. Это состояние называется CrashLoopBackOff.
• Liveness vs Readiness: Liveness отвечает за "жив ли контейнер", readiness — за "готов ли он принимать трафик". Провал readiness-пробы удаляет Pod из эндпоинтов Service, но не перезапускает его.

Пример из нашего мониторинга: У приложения была утечка памяти, которая приводила к зависанию HTTP-сервера. Liveness-проба начинала фейлиться, kubelet перезапускал контейнер, временно решая проблему. Это давало нам время на анализ дампа памяти и исправление кода, пока не был настроен HPA на основе памяти.