Поделиться через

Pod завис в режиме CrashLoopBackOff

Если у pod статус CrashLoopBackOff, то, вероятно, произошел сбой или неожиданное завершение, и журнал содержит код выхода, который не равен нулю. Ниже приведены несколько возможных причин, по которым модуль pod застрял в CrashLoopBackOff режиме:

  1. Сбой приложения: приложение внутри контейнера завершается вскоре после запуска, часто из-за неправильной настройки, отсутствия зависимостей или неправильных переменных среды.
  2. Неверные ограничения ресурсов: если модуль pod превышает ограничения ресурсов ЦП или памяти, Kubernetes может убить контейнер. Эта проблема может возникнуть, если запросы или лимиты ресурсов установлены слишком низко.
  3. Отсутствуют или неправильно настроены ConfigMaps/Secret: если приложение использует файлы конфигурации или переменные среды, хранящиеся в ConfigMaps или Секретах, но они отсутствуют или неправильно настроены, приложение может завершиться сбоем.
  4. Проблемы с извлечением изображения: если с изображением возникла проблема (например, поврежден или имеет неправильный тег), контейнер может не запускаться должным образом и завершаться сбоем.
  5. Не работают контейнеры инициализации: Если под имеет контейнеры инициализации, и если один или несколько не работают должным образом, под будет перезапущен.
  6. Сбои пробы активности и готовности: если пробы активности или готовности неправильно настроены, Kubernetes может обнаружить контейнер как неработоспособный и перезапустить его.
  7. Зависимости приложений не готовы: приложение может зависеть от служб, которые еще не готовы, например баз данных, очередей сообщений или других API.
  8. Проблемы с сетью: неправильно настроенные сети могут препятствовать взаимодействию приложения с необходимыми службами, что приводит к сбою.
  9. Недопустимые команды или аргументы: контейнер может быть запущен с недопустимым ENTRYPOINT, командой или аргументом, что приводит к сбою.

Дополнительные сведения о состоянии контейнера см. в разделе "Жизненный цикл pod — состояния контейнера".

Рассмотрим следующие параметры и связанные команды kubectl .

Вариант Команда kubectl
Отладка самого модуля pod kubectl describe pod <pod-name>
Отладка контроллеров репликации kubectl describe replicationcontroller <controller-name>
Чтение сообщения о завершении kubectl get pod <pod-name> --output=yaml
Проверка журналов kubectl logs <pod-name>

Примечание.

Модуль pod также может иметь CrashLoopBackOff состояние, если оно завершило развертывание, но оно настроено для перезапуска, даже если код выхода равен нулю. Например, если вы развертываете образ "занято" без указания аргументов, образ запускается, запускается, завершается, а затем перезапускается в цикле:

$ kubectl run nginx --image nginx
pod/nginx created

$ kubectl run busybox --image busybox
pod/busybox created

$ kubectl get pods --watch
NAME     READY  STATUS             RESTARTS  AGE
busybox  0/1    ContainerCreating  0         3s
nginx    1/1    Running            0         11s
busybox  0/1    Completed          0         3s
busybox  0/1    Completed          1         4s
busybox  0/1    CrashLoopBackOff   1         5s

$ kubectl describe pod busybox
Name:         busybox
Namespace:    default
Priority:     0
Node:         aks-nodepool<number>-<resource-group-hash-number>-vmss<number>/<ip-address-1>
Start Time:   Wed, 16 Aug 2023 09:56:19 +0000
Labels:       run=busybox
Annotations:  <none>
Status:       Running
IP:           <ip-address-2>
IPs:
  IP:  <ip-address-2>
Containers:
  busybox:
    Container ID:   containerd://<64-digit-hexadecimal-value-1>
    Image:          busybox
    Image ID:       docker.io/library/busybox@sha256:<64-digit-hexadecimal-value-2>
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 16 Aug 2023 09:56:37 +0000
      Finished:     Wed, 16 Aug 2023 09:56:37 +0000
    Ready:          False
    Restart Count:  2

Если вы не распознаете проблему после создания дополнительных модулей pod на узле, запустите модуль pod на одном узле, чтобы определить, сколько ресурсов на самом деле использует модуль pod.

Заявление об отказе от ответственности за сведения о продуктах сторонних производителей

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

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.