Разбор аварий: CrashLoopBackOff и Pending

Статусы читаются однозначно

Pending - под создан, но не запущен. Почти всегда планировщик не нашёл узла: не хватает ресурсов, не подходят правила размещения, нет нужного тома. Ответ лежит в событиях пода прямым текстом - я получал там «0 из 1 узлов доступны: недостаточно процессора и памяти».

ImagePullBackOff - узел не смог скачать образ. Причины: опечатка в имени или теге, нет доступа к реестру, не заведён ключ для приватного реестра. У меня в событиях было буквально «Failed to pull image, код NotFound». CrashLoopBackOff - контейнер стартует и падает, кластер перезапускает его с растущей паузой.

// Ещё три частых. OOMKilled - превышен лимит памяти, код завершения 137. Error - контейнер завершился с ненулевым кодом. Completed у пода развёртывания - приложение завершилось само, хотя должно было работать; обычно это уход процесса в фон или неверная команда запуска.

Pending

узел не найден; смотреть события и запросы ресурсов

CrashLoopBackOff

контейнер падает при старте; пауза между попытками растёт

ImagePullBackOff

образ не скачался: имя, тег, доступ к реестру

Растущая пауза и почему это важно

Кластер не долбит перезапуском без остановки: после каждой неудачи он ждёт вдвое дольше. Мой замер это показывает: первый перезапуск через десять секунд, потом двадцать, сорок, восемьдесят - и так до предела примерно в пять минут.

Практическое следствие: не спешите делать выводы по первому взгляду. Под, который «висит в CrashLoopBackOff и ничего не делает», на самом деле ждёт следующей попытки. И второе: если вы исправили причину, но под всё ещё в цикле, он поднимется сам - просто не мгновенно, а на следующей попытке через несколько минут. Ускорить можно удалением пода: новый начнёт отсчёт заново.

// Логи упавшего контейнера смотрят с ключом «предыдущий»: обычная команда показывает логи ТЕКУЩЕГО контейнера, который только что запустился и ещё ничего не написал. Логи того, который упал, доступны отдельно - и именно там лежит причина.

растущая пауза

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

логи предыдущего контейнера

то, что написал упавший экземпляр; отдельный ключ команды

Порядок разбора

Порядок один и тот же, и он экономит часы. Первое - статус и число перезапусков: они уже сужают круг. Второе - подробное описание пода: там события, причина последнего завершения и код выхода. Третье - логи, причём и текущего контейнера, и предыдущего, если были перезапуски. Четвёртое - события всего отсека, отсортированные по времени: там видно, что происходило вокруг.

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

// И три вещи, которые стоит проверить до того, как искать сложное. Не изменилось ли описание (история версий это покажет). Хватает ли места на узлах. Не выселяет ли кластер поды по нехватке памяти - это видно в событиях узла и объясняет «поды почему-то перезапускаются» лучше любых логов приложения.

подробное описание пода

события, причина завершения и код выхода в одном месте

события отсека

хронология происходившего вокруг; сортируются по времени

Как отвечать: «Под в CrashLoopBackOff. Ваши действия?»

Это значит, что контейнер стартует и падает, а кластер перезапускает его с растущей паузой - я мерил, интервалы удваиваются: десять секунд, двадцать, сорок, восемьдесят, и так до пяти минут. Поэтому сначала перестаю ждать мгновенной реакции. Первым делом смотрю подробное описание пода: там причина последнего завершения и код выхода. Код 137 означает превышение лимита памяти, 1 - приложение упало само, 127 - команда не найдена в образе. Потом читаю логи ПРЕДЫДУЩЕГО контейнера, а не текущего: обычная команда покажет только что запущенный экземпляр, который ещё ничего не написал, а причина лежит в логах упавшего. Дальше проверяю очевидное: доступна ли конфигурация и секреты, которые под подключает, отвечают ли зависимости, не убивает ли контейнер собственная проба живости из-за медленного старта. И если причину уже исправил, под поднимется сам, просто не сразу - или удаляю его, чтобы отсчёт паузы начался заново.

Ответ объясняет механику паузы, даёт правильный источник логов и разбирает коды выхода. Логи предыдущего контейнера - деталь, на которой видно, кто это реально делал.

На чём валятся

• −Читают логи текущего контейнера вместо предыдущего и не видят причины падения.
• −Не смотрят события пода, где причина написана прямым текстом.
• −Ждут мгновенного подъёма после починки: пауза между попытками уже выросла до минут.
• −Ищут проблему в приложении, когда поды выселяются по нехватке памяти на узле.
• −Не проверяют список адресов за сервисом и ищут сетевые проблемы там, где не сошлись метки.