Что такое liveness, readiness и startup probe, и когда использовать каждый?

Question

IT Interview Practice · Accepted Answer

Probe позволяют kubelet проверять здоровье контейнера и действовать по результату. Их три: **liveness** (жив ли он или его надо перезапустить?), **readiness** (готов ли он принимать трафик?) и **startup** (закончил ли он запуск?). Каждый отвечает на свой вопрос.

## Три probe вкратце

```text
LIVENESS   → "Приложение зависло/в дедлоке?"    СБОЙ → kubelet ПЕРЕЗАПУСКАЕТ контейнер
READINESS  → "Может ли оно обслуживать трафик сейчас?" СБОЙ → Pod убирается из endpoints Service
                                                       (НЕ перезапускается)
STARTUP    → "Закончился ли медленный запуск?"  выполняется ПЕРВЫМ; пока он идёт, liveness и
                                                readiness придержаны
```

## Readiness против liveness — ключевое различие

```text
Readiness управляет ТРАФИКОМ:
  → Pod, проваливший readiness, ВЫВОДИТСЯ из load-balancer Service,
    но продолжает работать (например, прогревает кэш или зависимость недоступна)
Liveness управляет ЖИЗНЬЮ:
  → Pod, проваливший liveness, УБИВАЕТСЯ и перезапускается (сломан без надежды на восстановление)
Использование liveness там, где имелся в виду readiness, вызывает бессмысленные циклы перезапуска.
```

## Определения probe

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      ports: [{ containerPort: 8080 }]

startupProbe:            # даёт медленному стартеру время до включения остальных
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = до 5 мин на запуск
        periodSeconds: 10

readinessProbe:          # управление трафиком
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # перезапуск при нездоровье
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Механизмы probe

```text
httpGet    → GET по пути; 2xx/3xx = успех       (чаще всего для веб-приложений)
tcpSocket  → можем ли открыть TCP-соединение?    (для не-HTTP сервисов)
exec       → запустить команду; exit 0 = успех   (произвольные проверки)
grpc       → нативная gRPC health check
Ключевые ручки: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## Зачем существуют startup probe

```text
Медленно стартующие приложения (прогрев JVM, большие миграции) раньше вынуждали ставить огромный
initialDelaySeconds на liveness — что делало реальные падения медленно обнаруживаемыми.
startupProbe решает это: он защищает медленный запуск, и ТОЛЬКО после его успеха
liveness/readiness начинают работать со своими обычными (жёсткими) таймингами.
```

```bash
kubectl describe pod app     # смотреть сбои probe и причины перезапуска в событиях
kubectl get pod app          # столбец READY отражает readiness; RESTARTS отражает liveness
```

## Почему это важно

Health probe — это то, как Kubernetes обеспечивает самовосстановление и безопасную маршрутизацию трафика, поэтому понимание трёх типов и того, когда использовать каждый, — существенное знание о надёжности. Ключевое различие — на котором спотыкаются многие инженеры — между **readiness** и **liveness**: readiness управляет **трафиком** (проваливший Pod выводится из load-balancer Service, но продолжает работать, что идеально, когда он прогревается или зависимость временно недоступна), тогда как liveness управляет **жизнью** (проваливший Pod убивается и перезапускается, когда он в дедлоке без надежды на восстановление). Путаница между ними — использование liveness probe там, где подразумевался readiness, — вызывает бессмысленные циклы перезапуска и простои, поэтому знание того, на какой вопрос отвечает каждый probe, напрямую практично. **Startup** probe решает реальную историческую боль: медленно загружающиеся приложения когда-то вынуждали ставить огромный `initialDelaySeconds` на liveness (что задерживало обнаружение настоящих падений), тогда как startup probe защищает окно загрузки и позволяет liveness/readiness работать с жёсткими, обычными таймингами лишь после успешного старта. Понимание механизмов probe (`httpGet`, `tcpSocket`, `exec`, `grpc`) и ручек настройки (`initialDelaySeconds`, `periodSeconds`, `failureThreshold` и т.д.) позволяет настраивать проверки здоровья корректно, а не наугад. Поскольку probe напрямую определяют, попадают ли пользователи на здоровые Pod и восстанавливаются ли сломанные Pod автоматически, правильная их настройка фундаментальна для запуска надёжных, production-нагрузок на Kubernetes.

Три probe вкратце

Readiness против liveness — ключевое различие

Определения probe

Механизмы probe

Зачем существуют startup probe

Почему это важно

Похожие вопросы