AM
DevOps 9 мин чтения

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

Пошаговое руководство по устранению состояния CrashLoopBackOff в Kubernetes: проверка логов, resource limits, readiness probe и common ошибки.

KubernetespodCrashLoopBackOffkubectlконтейнер

Симптомы

  • Pod в статусе CrashLoopBackOff
  • kubectl describe pod показывает Restart Count > 0
  • Pod запускается и сразу падает
  • Container never ready
  • Back-off restarting failed container

Возможные причины

  • Приложение внутри пода падает с ошибкой
  • Недостаточно ресурсов (memory/cpu limits)
  • Liveness/Readiness probe не проходит
  • Неверный image или entrypoint
  • Секреты (Secrets) или ConfigMap недоступны
  • Ошибки в YAML-манифесте

Пошаговое решение

1

Проверьте статус пода

Выполните kubectl get pods для просмотра статуса. Под в CrashLoopBackOff будет иметь Restart Count больше 0. Выполните kubectl describe pod имя-пода — в секции Last State будет показана причина последнего падения (Reason: Error/Crash/Error/ImagePullBackOff). Проверьте Events в конце вывода — там будут ошибки планировщика.

Команда 
kubectl get pods
2

Просмотрите логи пода

Выполните kubectl logs имя-пода для просмотра текущих логов. Если под уже перезапустился: kubectl logs --previous имя-пода покажет логи предыдущего запуска. Логи содержат стектрейс или сообщение об ошибке. Также попробуйте kubectl logs -f имя-пода для вывода в реальном времени. Если контейнер падает слишком быстро, логи могут быть пустыми.

Команда 
kubectl logs --previous my-pod
3

Проверьте resource limits

Pod может падать из-за нехватки ресурсов. В секцииresources контейнера укажите requests и limits. Если memory limit слишком низкий, Kubernetes убьёт контейнер (OOMKilled). Проверьте: kubectl describe pod | grep -A 5 "Limits". Рекомендуется: resources: requests: memory: 256Mi, cpu: 250m; limits: memory: 512Mi, cpu: 500m. Увеличьте лимиты и пересоздайте под.

Команда 
kubectl describe pod my-pod | grep -A 5 "Limits"
4

Проверьте probes

Liveness probe определяет, жив ли контейнер. Если probe не проходит, Kubernetes перезапускает контейнер. Readiness probe определяет, готов ли контейнер принимать трафик. Проверьте: kubectl describe pod | grep -A 10 "Liveness". Убедитесь, что probe указывает правильный порт и path. Увеличьте initialDelaySeconds и timeoutSeconds. Временно отключите probe для диагностики.

Команда 
kubectl describe pod my-pod | grep -A 10 "Liveness"
5

Проверьте image и entrypoint

Убедитесь, что образ существует и доступен: kubectl describe pod | grep Image. Если образ не найден, проверьте имя registry и тег. Проверьте entrypoint/cmd в YAML. Если контейнер использует shell-команду, убедитесь, что скрипт существует в образе. Для диагностики перезапишитеcommand: command: ["/bin/sh"] и args: ["-c", "sleep 3600"] — это предотвратит падение.

Команда 
kubectl describe pod my-pod | grep Image
6

Проверьте Secrets и ConfigMap

Если под зависит от Secrets или ConfigMap, убедитесь, что они существуют и смонтированы.kubectl get secrets и kubectl get configmap. Если секрет не найден, под не сможет запуститься. Проверьте, что имена Secrets в deployment совпадают с реальными. Также проверьте, что значения не содержат Base64-ошибок (kubectl get secret my-secret -o yaml).

Команда 
kubectl get secrets
7

Запустите под отладки

Создайте отладочный под с тем же образом: kubectl run debug --image=образ --rm -it --restart=Never -- /bin/sh. Это позволит войти внутрь контейнера и запустить приложение вручную. Проверьте переменные окружения: env. Запустите приложение:./start.sh. Это покажет ошибку без перезапусков Kubernetes. Также попробуйте kubectl exec -it my-pod -- /bin/sh если под хоть немного работает.

Команда 
kubectl run debug --image=my-image --rm -it --restart=Never -- /bin/sh
8

Пересоздайте под

После исправления ошибки пересоздайте под: kubectl delete pod имя-пода. Deployment автоматически создаст новый под. Если используете bare pod, создайте его заново: kubectl apply -f pod.yaml. Проверьте статус нового пода: kubectl get pods -w (watch mode). Убедитесь, что Restart Count не растёт и статус Changed to Running.

Команда 
kubectl delete pod my-pod

CrashLoopBackOff — состояние, при котором Kubernetes перезапускает под, который падает при старте. Это не конкретная ошибка, а симптом: контейнер завершается с ненулевым кодом, Kubernetes повторяет попытку, увеличивая интервал между ними (back-off).

Почему под падает

Причины делятся на несколько категорий: (1) ошибка в коде приложения, (2) неверный образ или тег, (3) нехватка ресурсов (RAM/CPU), (4)probe не проходит, (5) отсутствуют Secrets/ConfigMap, (6) сетевые проблемы (БД недоступна). Первая задача — посмотреть логи: kubectl logs —previous.

Проверка сетевой связности

Начните с базовых проверок: ping 8.8.8.8 (проверка интернета), ping localhost (проверка сетевого стека), ip addr show (проверка IP-адресов). Если ping localhost не работает, проблема в сетевой подсистеме. Если ping 8.8.8.8 работает, но DNS нет — проблема в DNS-настройках.

Настройка DNS

Проверьте /etc/resolv.conf: cat /etc/resolv.conf. Убедитесь, что есть строка nameserver. Попробуйте: sudo echo “nameserver 8.8.8.8” > /etc/resolv.conf. Для постоянных настроек используйте systemd-resolved: sudo systemd-resolve —set-dns=8.8.8.8 —interface=имя-интерфейса. Проверьте: resolvectl status.

Проверка файрвола

Fайрвол может блокировать сетевой трафик. Проверьте: sudo iptables -L -n (legacy), sudo nft list ruleset (nftables) или sudo ufw status (Ubuntu). Временно отключите для диагностики: sudo ufw disable. Если проблема решена — настройте правила файрвола для разрешения нужного трафика.

Перезапуск сети

Перезапустите сетевые службы: sudo systemctl restart NetworkManager (или systemd-networkd). Для полного сброса: sudo ip link set имя-интерфейса down, sudo ip link set имя-интерфейса up. Проверьте журналы: journalctl -u NetworkManager -xe. Часто перезапуск решает временные сбои.

Проверка кабеля и интерфейса

Убедитесь, что сетевой кабель подключён: ip link show. Статус UP означает, что интерфейс активен. NO-CARRIER — кабель не подключён. Проверьте, что драйвер загружен: lspci | grep -i ethernet. Если интерфейс не виден, возможно, проблема в аппаратном обеспечении или драйвере.

Источники

  1. kubernetes.io — проверено 02.06.2026
  2. stackoverflow.com — проверено 02.06.2026
  3. kubernetes.io — проверено 02.06.2026
  4. learnk8s.io — проверено 02.06.2026