CrashLoopBackOff в Kubernetes: как найти причину перезапусков

Сохраните данные неудачной попытки

Подставьте настоящие namespace, имя Pod и имя контейнера. В Pod может быть несколько контейнеров, поэтому указывайте -c явно. Предыдущие логи особенно полезны, пока новая попытка ещё не дошла до места сбоя. Они могут отсутствовать, если предыдущий экземпляр не сохранился.

Запишите Last State, Reason, Exit Code, счётчик перезапусков и время событий. Проверьте Deployment и версию релиза. Не удаляйте Pod в начале диагностики: замена может уничтожить нужные данные. Задержка повторного запуска зависит от версии и настроек kubelet; фиксированное время ожидания само по себе не объясняет причину.

NS=demo
POD=api-7d8c9f-example
CONTAINER=api
kubectl get pod "$POD" -n "$NS" -o wide
kubectl describe pod "$POD" -n "$NS"
kubectl logs "$POD" -n "$NS" -c "$CONTAINER" --previous --tail=100
kubectl logs "$POD" -n "$NS" -c "$CONTAINER" --tail=100
kubectl get events -n "$NS" --field-selector "involvedObject.name=$POD" --sort-by=.metadata.creationTimestamp

• Kubernetes: debug running Pods
• Kubernetes: Pod lifecycle and container restart backoff

Выберите направление по фактам

Представьте новый релиз API: в логах снова появляется booting, затем процесс исчезает без собственного исключения. Это ещё не доказывает ошибку приложения. Сопоставьте завершение с событиями kubelet. Liveness probe может остановить процесс, который продолжает инициализацию; отсутствие настройки может заставить приложение завершиться самостоятельно.

Код 137 соответствует принятому обозначению завершения через SIGKILL, но сам по себе не доказывает превышение лимита памяти. Ищите OOMKilled и данные о ресурсах. ImagePullBackOff и Pending из-за невозможности назначить Pod на узел требуют другого разбора: приложение могло ещё не запуститься.

• Kubernetes: Pod lifecycle and container restart backoff
• Kubernetes: memory requests, limits and OOM diagnosis

Пример: инициализация занимает 45 секунд

Наш API около 45 секунд загружает индекс и только потом открывает health endpoints. Liveness probe запускается сразу, проверяет процесс каждые 10 секунд и перезапускает после трёх ошибок. События показывают провал probe и Killing, а логи каждый раз обрываются на загрузке. Поэтому инициализация не успевает закончиться.

Добавьте этот фрагмент в описание контейнера API, предварительно реализовав три endpoint. /startedz подтверждает завершение инициализации, /livez — работоспособность самого процесса, /readyz — возможность принимать запросы. Параметры startupProbe дают примерно 90 секунд на запуск. Это бюджет для примера, а не универсальное значение.

startupProbe:
  httpGet:
    path: /startedz
    port: 8080
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 18
livenessProbe:
  httpGet:
    path: /livez
    port: 8080
  periodSeconds: 10
  timeoutSeconds: 2
  failureThreshold: 3
readinessProbe:
  httpGet:
    path: /readyz
    port: 8080
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 2

• Kubernetes: liveness, readiness and startup probes

Не смешивайте три вида probe

При наличии startupProbe проверки liveness и readiness ждут её первого успеха. Повторные ошибки startup или liveness могут привести к перезапуску. Ошибка readiness убирает готовность для обычного трафика Service, но сама контейнер не перезапускает. Смягчение readiness не исправит цикл, вызванный liveness.

Не заставляйте liveness падать при каждой краткой недоступности базы. Это может одновременно перезапустить все API-реплики и затянуть восстановление. Временную невозможность обслуживать запросы при необходимости отражайте в readiness. Liveness должна проверять состояние, которое перезапуск способен улучшить. Делайте проверки дешёвыми и задавайте понятные таймауты.

• Kubernetes: liveness, readiness and startup probes
• Готовность зависимостей и переподключение в Docker Compose

Ошибки запуска и OOM проверяйте отдельно

При немедленном завершении с ненулевым кодом проверяйте команду образа, обязательные переменные, подключённые файлы, права и ошибки зависимостей. Сравните спецификацию с рабочей версией. Если команда успешно заканчивается в Deployment с обычной политикой Always, контейнер тоже будет перезапускаться. Для одноразовой задачи обычно подходит Job.

При OOMKilled изучите пики памяти, параллелизм и лимит. Текущие метрики могут не показать короткий всплеск перед завершением. Увеличение лимита иногда помогает временно, если на узле хватает ресурсов, но затем нужно искать утечку или слишком большой вход. Memory request влияет на размещение Pod и не заменяет лимит.

• Kubernetes: Pod lifecycle and container restart backoff
• Kubernetes: memory requests, limits and OOM diagnosis

Подтвердите восстановление всего релиза

Примените исправленную конфигурацию обычным способом развёртывания. Следите за всеми новыми Pod: готовностью, перезапусками и событиями. Проверьте настоящий запрос к API и наблюдайте дольше прежнего интервала сбоя. Фаза Running сама по себе не подтверждает готовность и стабильность сервиса.

В примере с медленным стартом ожидаемый результат — одна завершённая инициализация, успешная startupProbe и стабильный счётчик перезапусков после неё. Сохраните причину и результат проверки в разборе инцидента. Если релиз остаётся неработоспособным, рассмотрите откат по правилам проекта, сохранив логи.

• Вопросы о Kubernetes и DevOps

Коротко

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