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

Влияние неуспешной readiness probe на работу Pod в Kubernetes

Когда Pod не проходит readiness probe, это означает, что контейнер внутри Pod ещё не готов принимать трафик. Это критический механизм Kubernetes для управления доступностью сервисов.

Что происходит с Pod

• Pod остаётся в состоянии Running: Сам Pod продолжает работать, его статус не меняется на Failed или Terminating.
• Pod исключается из Endpoints объектов: Kubernetes автоматически удаляет IP адрес этого Pod из соответствующих Endpoints для Service и Ingress, к которым он принадлежит.
• Трафик не направляется на Pod: Все новые запросы к Service будут распределяться только между Pods, успешно прошедшими readiness probe. Этот Pod временно становится "невидимым" для клиентов.

Пример настройки readiness probe в манифесте Pod

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: web
    image: nginx:latest
    readinessProbe:
      httpGet:
        path: /health
        port: 80
      initialDelaySeconds: 10  # Ждать 10 секунд перед первой проверкой
      periodSeconds: 5         # Проверять каждые 5 секунд
      timeoutSeconds: 3       # Время ожидания ответа
      successThreshold: 1     # 1 успешная проверка = готов
      failureThreshold: 3     # 3 неудачи = не готов

Механизм работы в кластере

1. kubelet на узле регулярно выполняет проверку readiness probe для каждого контейнера в Pod.
2. Если проверка завершается неудачно (failureThreshold превышен), kubelet сообщает об этом в контрольную плоскость Kubernetes.
3. Endpoint Controller в контроллере управления обновляет объект Endpoints, удаляя IP проблемного Pod.

# Проверить состояние Endpoints для Service
kubectl describe endpoints my-service

# В выводе будут только IP адресы Pods с успешной readiness
Name:         my-service
Subsets:
  Addresses:          10.244.1.5:80,10.244.2.3:80  # Только готовые Pods
  NotReadyAddresses:  10.244.1.7:80                # Pod не прошёл probe

Практические последствия и решения

• Graceful startup: Позволяет приложению завершить инициализацию (загрузка конфигурации, подключение к БД) без получения трафика.
• Защита от временных проблем: Если приложение временно не может обрабатывать запросы (например, потеря соединения с БД), оно автоматически исключается из балансировки.
• Проблемы и мониторинг:
  • Pod может оставаться "не готовым" бесконечно, требуя вмешательства оператора.
  • Необходимо настроить алерт на Pods с длительным состоянием NotReady.

Важные различия с liveness probe:

• Liveness probe определяет, нужно ли перезапустить контейнер. При неудаче - Pod будет убит и пересоздан.
• Readiness probe определяет, можно ли направлять трафик. При неудаче - Pod остаётся работать, но трафик не получает.

# Увидеть статус readiness в описании Pod
kubectl describe pod my-app

# В секции Containers будет:
Containers:
  web:
    State:          Running
    Ready:          False   # Readiness probe failed
    Restart Count:  0

Рекомендации для DevOps

1. Настройте правильные endpoints для проверки: Используйте отдельный endpoint /health или /ready, который проверяет именно готовность к работе (подключенные зависимости), не смешивая с проверкой жизнеспособности (/live).
2. Учитывайте initialDelaySeconds: Установите достаточное время для инициализации приложения перед первой проверкой.
3. Мониторинг: Включите в панели мониторинга метрики для Pods в состоянии NotReady.
4. Автоматическое восстановление: Если проблема readiness временная (например, зависание на операции), liveness probe может перезапустить контейнер для восстановления.

Таким образом, неуспешная readiness probe защищает систему от отправки трафика на неготовые или проблемные экземпляры приложений, обеспечивая стабильность сервиса и graceful handling трафика в кластере Kubernetes.