Когда readiness probe не проходит, контейнер может быть запущен, но Service не направляет в Pod трафик. Причину нужно искать в конкретном ответе проверки: неверный порт, путь, схема, медленный старт или реальная неготовность приложения.

Начните с kubectl describe pod и событий probe. Затем выполните тот же запрос изнутри Pod и с соседнего Pod, используя точные path, port и scheme из манифеста.

Что сделать в первую очередь

  • Сохраните сообщение probe failed и код ответа.
  • Проверьте имя порта, containerPort и фактический listen address.
  • Уточните, не относится ли долгий старт к startupProbe.
  • Сравните текущий манифест с последним рабочим релизом.

Почему возникает проблема

Симптом обычно появляется не из-за одной настройки. Сначала разделите путь данных на этапы и найдите место, где фактическое поведение расходится с ожидаемым.

  • Приложение слушает localhost, а kubelet обращается по Pod IP.
  • Path или port изменились, но probe осталась старой.
  • TimeoutSeconds меньше обычного времени ответа.
  • Readiness зависит от временно недоступной внешней системы и никогда не стабилизируется.

Пошаговая диагностика

  • Посмотрите endpoints Service и убедитесь, что Pod отсутствует именно из-за readiness.
  • Выполните curl или аналогичный запрос внутри контейнера.
  • Проверьте журналы приложения в момент каждой проверки.
  • Измерьте время старта, прогрева кеша и подключения к базе.
  • Проверьте NetworkPolicy, service mesh и TLS-схему при наличии sidecar.

Как исправить

Исправляйте подтвержденную первопричину и сохраняйте возможность отката. После каждого изменения повторяйте один и тот же контрольный сценарий, чтобы не спутать результат нескольких правок.

  • Исправьте path, scheme и ссылку на реальный именованный порт.
  • Слушайте на интерфейсе, доступном kubelet, если это соответствует модели безопасности.
  • Добавьте startupProbe для долгой инициализации.
  • Настройте timeout, period и failureThreshold по измеренным данным.
  • Оставьте в readiness только зависимости, без которых трафик действительно нельзя обслужить.

Как проверить результат

  • Pod становится Ready за ожидаемое время и появляется в endpoints.
  • Краткий сбой зависимости корректно выводит Pod из пула и возвращает после восстановления.
  • Rolling update завершается без недоступных реплик.

Как не допустить повторения

  • Тестируйте probes в CI на собранном образе.
  • Мониторьте время до Ready и частоту переходов состояния.
  • Версионируйте манифест и приложение одним релизом.

Частые вопросы

Чем readiness отличается от liveness?

Readiness управляет приемом трафика, а liveness решает, нужно ли перезапустить контейнер.

Нужно ли увеличивать initialDelaySeconds?

Только по измерениям. Для долгого старта обычно точнее startupProbe.

Когда стоит обратиться за помощью

Для разбора достаточно describe Pod, манифеста probe и обезличенного журнала старта. Секреты Kubernetes публиковать нельзя.

Итог

Readiness должна точно отвечать на вопрос, способен ли Pod принять трафик сейчас. Я могу исправить probes, зависимости и стратегию rolling update без случайных перезапусков.