Что такое Kubernetes CrashLoopBackOff? И как его исправить

CrashLoopBackOff — это состояние Kubernetes, представляющее цикл перезапуска, происходящий в Pod: контейнер в Pod запускается, но терпит крах и затем перезапускается снова и снова.

Kubernetes будет ждать все больше времени между перезапусками, чтобы дать вам шанс исправить ошибку. Таким образом, CrashLoopBackOff сама по себе не является ошибкой, но указывает на наличие ошибки, которая мешает правильному запуску Pod.

Обратите внимание, что причиной перезапуска является то, что его restartPolicy установлен в Always (по умолчанию) или OnFailure. Затем кубелет считывает эту конфигурацию и перезапускает контейнеры в Pod, вызывая цикл. Такое поведение на самом деле полезно, поскольку это дает некоторое время для завершения загрузки недостающих ресурсов, а также для обнаружения проблемы и ее отладки — подробнее об этом позже.

Это объясняет часть CrashLoop, но что насчет времени BackOff? По сути, это экспоненциальная задержка между перезагрузками (10с, 20с, 40с, …), которая ограничена пятью минутами. Когда состояние стручка отображает CrashLoopBackOff, это означает, что в настоящее время он ожидает указанное время перед повторным запуском стручка. И он, вероятно, снова потерпит неудачу, если не будет исправлен.

В этой статье вы узнаете:

  1. Что такое CrashLoopBackOff?
  2. Как обнаружить проблемы CrashLoopBackOff
  3. Общие причины CrashLoopBackOff
  4. Инструменты Kubernetes для отладки CrashLoopBackOff
  5. Как обнаружить CrashLoopBackOff с помощью Prometheus

Как обнаружить CrashLoopBackOff в вашем кластере?

Скорее всего, вы обнаружили один или несколько pods в этом состоянии, перечислив pods с помощью kubectl get pods:

$ kubectl get pods
NAME                     READY     STATUS             RESTARTS   AGE
flask-7996469c47-d7zl2   1/1       Running            1          77d
flask-7996469c47-tdr2n   1/1       Running            0          77d
nginx-5796d5bc7c-2jdr5   0/1       CrashLoopBackOff   2          1m
nginx-5796d5bc7c-xsl6p   0/1       CrashLoopBackOff   2          1m

Вход в полноэкранный режим Выйти из полноэкранного режима

Из вывода видно, что последние две капсулы:

  • Не находятся в состоянии READY (0/1).
  • Их статус отображает CrashLoopBackOff.
  • Колонка RESTARTS отображает один или несколько перезапусков.

Эти три сигнала указывают на то, что мы объяснили: капсулы терпят неудачу, и их перезапускают. Между перезапусками есть льготный период, который представлен как CrashLoopBackOff.

Вам также может «посчастливиться» найти Pod за то короткое время, пока он находится в состоянии Running или Failed.

Распространенные причины аварийного завершения работы (CrashLoopBackOff)

Важно отметить, что CrashLoopBackOff не является фактической ошибкой, которая приводит к краху капсулы. Помните, что это просто отображение цикла в колонке STATUS. Вам нужно найти основную ошибку, влияющую на контейнеры.

Некоторые из ошибок, связанных с реальным приложением, следующие:

  • Неправильная конфигурация: Например, опечатка в конфигурационном файле.
  • Ресурс недоступен: Например, PersistentVolume, который не смонтирован.
  • Неправильные аргументы командной строки: Либо отсутствуют, либо указаны неверные аргументы.
  • Ошибки и исключения: Это может быть что угодно, очень специфично для вашего приложения.

И, наконец, ошибки со стороны сети и разрешений:

  • Вы пытались привязать существующий порт.
  • Пределы памяти слишком малы, поэтому контейнер Out Of Memory убит.
  • Ошибки зондов liveness probes не сообщают о готовности Pod.
  • Файловые системы только для чтения, или отсутствие прав доступа в целом.

Повторимся, это лишь список возможных причин, но может быть и много других.

Теперь давайте посмотрим, как копнуть глубже и найти истинную причину.

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

Из предыдущего раздела вы поняли, что существует множество причин, по которым капсула оказывается в состоянии CrashLoopBackOff. Теперь, как узнать, какая из них влияет на вас? Давайте рассмотрим некоторые инструменты, которые вы можете использовать для отладки, и в каком порядке их применять.

Это может стать нашим лучшим курсом действий:

  1. Проверьте описание стручка.
  2. Проверьте журналы pod.
  3. Проверьте события.
  4. Проверьте развертывание.

1. Проверьте описание стручка — kubectl describe pod

Команда kubectl describe pod предоставляет подробную информацию о конкретном Pod и его контейнерах:

$ kubectl describe pod the-pod-name
Name:         the-pod-name
Namespace:    default
Priority:     0
…
State:          Waiting
Reason:       CrashLoopBackOff
Last State:     Terminated
Reason:       Error
…
Warning  BackOff                1m (x5 over 1m)   kubelet, ip-10-0-9-132.us-east-2.compute.internal  Back-off restarting failed container
…

Войти в полноэкранный режим Выход из полноэкранного режима

Из вывода describe можно извлечь следующую информацию:

  • Текущее состояние pod StateWaiting.
  • Причина состояния ожидания — «CrashLoopBackOff».
  • Последнее (или предыдущее) состояние было «Прервано».
  • Причина последнего завершения — «Ошибка».

Это соответствует поведению цикла, которое мы объясняли.

Используя kubectl describe pod, вы можете проверить неправильную конфигурацию в:

  • Определении pod.
  • Контейнер.
  • Образ, созданный для контейнера.
  • Ресурсы, выделенные для контейнера.
  • Неправильные или отсутствующие аргументы.
…
Warning  BackOff                1m (x5 over 1m)   kubelet, ip-10-0-9-132.us-east-2.compute.internal  Back-off restarting failed container
…

Вход в полноэкранный режим Выход из полноэкранного режима

В последних строках вы увидите список последних событий, связанных с этой капсулой, одним из которых является "Back-off restarting failed container". Это событие связано с циклом перезапуска. Здесь должна быть только одна строка, даже если произошло несколько перезапусков.

2. Проверьте журналы — kubectl logs

Вы можете просмотреть журналы для всех контейнеров стручка:

kubectl logs mypod --all-containers

Войти в полноэкранный режим Выйти из полноэкранного режима

Или даже одного контейнера в этом стручке:

kubectl logs mypod -c mycontainer

Войти в полноэкранный режим Выйти из полноэкранного режима

В случае, если в затронутой капсуле неверное значение, в журналах может отображаться полезная информация.

3. Проверьте события — kubectl get events.

Они могут быть перечислены:

kubectl get events

Войти в полноэкранный режим Выйти из полноэкранного режима

Кроме того, вы можете перечислить все события одного Pod, используя:

kubectl get events --field-selector involvedObject.name=mypod

Войти в полноэкранный режим Выйти из полноэкранного режима

Обратите внимание, что эта информация также присутствует в нижней части вывода describe pod.

4. Проверьте развертывание — kubectl describe deployment

Вы можете получить эту информацию с помощью:

kubectl describe deployment mydeployment

Войти в полноэкранный режим Выйти из полноэкранного режима

Если есть развертывание, определяющее желаемое состояние Pod, оно может содержать неправильную конфигурацию, вызывающую CrashLoopBackOff.

Собираем все вместе

В следующем примере показано, как копаться в журналах, где обнаруживается ошибка в аргументе команды.

Как обнаружить CrashLoopBackOff в Prometheus

Если вы используете Prometheus для мониторинга облака, вот несколько советов, которые помогут вам предупредить о возникновении CrashLoopBackOff.

Вы можете быстро просканировать контейнеры в вашем кластере, которые находятся в CrashLoopBackOff status, используя следующее выражение (вам понадобится Kube State Metrics):

kube_pod_container_status_waiting_reason{reason="CrashLoopBackOff"} == 1

Войти в полноэкранный режим Выход из полноэкранного режима

Также можно отследить количество перезапусков, происходящих в стручках, с помощью:

rate(kube_pod_container_status_restarts_total[5m]) > 0

Войти в полноэкранный режим Выйти из полноэкранного режима

Внимание: Не все перезагрузки, происходящие в вашем кластере, связаны со статусами CrashLoopBackOff.

После каждого периода CrashLoopBackOff должен происходить перезапуск (1), но могут быть перезапуски, не связанные с CrashLoopBackOff (2).

После этого вы можете создать правило оповещения Prometheus Alerting Rule, подобное следующему, чтобы получать уведомления, если какая-либо из ваших капсул находится в этом состоянии:

- alert: RestartsAlert
  expr: rate(kube_pod_container_status_restarts_total[5m]) > 0
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: Pod is being restarted
  description: Pod {{ $labels.pod }} in {{ $labels.namespace }} has a container {{ $labels.container }} which is being restarted

Вход в полноэкранный режим Выход из полноэкранного режима

Заключение

В этой статье мы увидели, что CrashLoopBackOff сам по себе не является ошибкой, а лишь уведомлением о повторном цикле, происходящем в капсуле.

Мы увидели описание состояний, через которые он проходит, а также то, как отследить его с помощью команд kubectl.

Также мы увидели распространенные неправильные конфигурации, которые могут вызвать это состояние, и какие инструменты можно использовать для его отладки.

Наконец, мы рассмотрели, как Prometheus может помочь нам в отслеживании и оповещении событий CrashLoopBackOff в наших капсулах.

Хотя сообщение CrashLoopBackOff не является интуитивно понятным, это полезная концепция, которая имеет смысл и которой не стоит бояться.


Отлаживайте CrashLoopBackOff быстрее с помощью Sysdig Monitor

Advisor, новый продукт для устранения неисправностей Kubernetes в Sysdig Monitor, ускоряет устранение неисправностей до 10 раз. Advisor отображает приоритетный список проблем и соответствующие данные по устранению неполадок, чтобы выявить самые крупные проблемные области и ускорить время их решения.

Попробуйте его бесплатно в течение 30 дней!

Оцените статью
devanswers.ru
Добавить комментарий