PrepBro
← Назад к вопросам

Что такое liveness и readiness probes в Kubernetes? Чем они отличаются?

1.8 Middle🔥 202 комментариев
#Kubernetes

Комментарии (2)

🐱
deepseek-v3.2PrepBro AI6 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Liveness и Readiness Probes в Kubernetes

Liveness и Readiness Probes — это механизмы проверки состояния (health checks) контейнеров в Kubernetes, которые помогают оркестратору принимать интеллектуальные решения о маршрутизации трафика и перезапуске подов. Они являются фундаментальными для обеспечения отказоустойчивости и высокой доступности приложений.

Основное предназначение

Обе пробы периодически выполняются kubelet'ом (агент на ноде) для каждого контейнера в поде. Различие лежит в их семантике и последствиях:

  • Liveness Probe (Проба жизнеспособности) отвечает на вопрос: "Жив ли контейнер?". Если проба fails (не удалась), kubelet убивает контейнер, и он следует политике перезапуска (restartPolicy). Это нужно для восстановления "зависшего" приложения, которое не может прогрессировать.
  • Readiness Probe (Проба готовности) отвечает на вопрос: "Готов ли контейнер принимать трафик?". Если проба fails, Endpoint Controller удаляет IP-адрес этого пода из всех сервисов (Service), на которые он завязан. Трафик перестает на него направляться. Это позволяет приложению спокойно завершить тяжелую начальную инициализацию или временно "отдохнуть" без получения запросов.

Ключевые отличия

АспектLiveness ProbeReadiness Probe
ЦельОпределить, нужно ли перезапустить контейнер.Определить, может ли контейнер получать трафик от сервисов.
Действие при failureКонтейнер перезапускается.IP пода удаляется из эндпоинтов сервиса.
Влияние на трафикКосвенное: после перезапуска контейнер снова пройдет проверку readiness, и только потом получит трафик.Прямое: трафик немедленно прекращает маршрутизироваться на под.
Типичные сценарииПриложение "зависло", deadlock, не отвечает на запросы, но процесс работает.Приложение загружает большой кэш, конфигурирует соединения с БД, выполняет миграции.

Типы проб и пример конфигурации

Обе пробы поддерживают три типа проверок:

  1. HTTP GET: Проверка HTTP-кода ответа (2xx, 3xx — успех).
  2. TCP Socket: Установление TCP-соединения.
  3. Exec: Выполнение команды внутри контейнера (код возврата 0 — успех).

Вот пример манифеста пода с обеими пробами:

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp
    image: myapp:latest
    livenessProbe:
      httpGet:
        path: /health/live
        port: 8080
      initialDelaySeconds: 30  # Ждем 30 сек перед первой проверкой
      periodSeconds: 10        # Проверяем каждые 10 сек
      failureThreshold: 3      # 3 неудачи подряд -> контейнер dead
    readinessProbe:
      httpGet:
        path: /health/ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
      successThreshold: 1     # 1 успешная проверка -> контейнер ready
      failureThreshold: 3

Рекомендации по использованию

  • Всегда настраивайте readinessProbe. Без нее под получит трафик сразу после старта контейнера, что может привести к ошибкам 5xx.
  • Используйте livenessProbe осторожно. Неправильная конфигурация (например, initialDelaySeconds: 0 для медленно стартующего приложения) может привести к бесконечной петле перезапусков. Для stateful-приложений (БД, очереди) часто лучше полагаться на внешние системы мониторинга, а не на автоматический перезапущ.
  • Эндпоинты проб должны быть легковесными и не зависеть от внешних сервисов (БД, кэша), иначе сбой зависимости убьет все ваши поды.
  • Настройте timeoutSeconds, periodSeconds, failureThreshold в соответствии с реальным временем отклика вашего приложения.

Таким образом, правильное комбинирование liveness и readiness probes позволяет Kubernetes автоматически поддерживать работоспособность кластера, обеспечивая zero-downtime деплойments и устойчивость к внутренним сбоям приложения.