Liveness, Readiness и Startup probes: безопасные шаблоны

⚙️ Теория

🧩 Зачем нужны probes

Kubernetes использует probes, чтобы отличать:

процесс "жив", но еще не готов обслуживать трафик;
процесс завис и его нужно перезапустить;
приложение стартует долго и его нельзя убивать слишком рано.

Типы:

livenessProbe: проверка "жив ли контейнер";
readinessProbe: проверка "готов ли контейнер принимать трафик";
startupProbe: защита долгого старта от ранних рестартов.

🔍 Семантика каждого типа

livenessProbe:

при регулярных fail kubelet перезапускает контейнер.

readinessProbe:

при fail pod убирается из Service endpoints;
контейнер может продолжать работать без рестарта.

startupProbe:

пока startupProbe не стала Success, kubelet не выполняет livenessProbe и readinessProbe;
нужна для JVM/миграций/прогрева кэша и других длинных стартов.

⚠️ Типичные ошибки

использовать liveness как бизнес-health endpoint;
слишком агрессивные timeoutSeconds/failureThreshold;
один и тот же endpoint для readiness и liveness без учета зависимости от внешних систем;
отсутствие startupProbe у медленно стартующих приложений.

❓ Что нужно уметь объяснить

Почему readiness важнее liveness в большинстве инцидентов?

Потому что readiness управляет попаданием трафика в pod. Неверный readiness быстро создает 5xx/latency, даже если контейнер формально "жив".

Когда liveness вреден?

Когда приложение деградировало из-за внешней зависимости (БД/очередь), и liveness начинает перезапускать pod по кругу вместо стабилизации.

Зачем startupProbe отдельным типом?

Чтобы долгий bootstrap не воспринимался как "падение" и не приводил к restart-loop.

🧪 Практика

1. Базовый безопасный шаблон

livenessProbe:
  httpGet:
    path: /health/live
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 2
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 3

startupProbe:
  httpGet:
    path: /health/startup
    port: 8080
  periodSeconds: 5
  failureThreshold: 30

2. Проверка поведения в кластере

kubectl describe pod <pod-name>
kubectl get events --sort-by=.lastTimestamp
kubectl get endpoints <service-name> -o yaml

3. Guardrails

readiness должен проверять способность обслужить запрос, а не только факт процесса;
liveness делать проще и стабильнее readiness;
startupProbe включать для всех сервисов со стартом > 20-30 секунд;
параметры проб подбирать из метрик реального старта/нагрузки.

🧾 Вывод

Правильные probes снижают blast radius и предотвращают self-inflicted outages. Базовый принцип: readiness управляет трафиком, liveness лечит зависания, startup защищает долгий старт.

📚 Ссылки

✅ Проверка источников

Kubernetes Documentation