Как отлаживать ошибки Kubernetes «ImagePullBackOff»

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

Как работает подбор изображений

Kubernetes необходимо получить образ, когда вы создаете новое развертывание или обновляете существующее с другой ссылкой на тег. Ответственность за получение изображений лежит на процессе Kubelet на каждом рабочем узле. Каждое изображение, на которое ссылается манифест пода, должно быть доступно для всех узлов в кластере, чтобы любой из них мог выполнить запрос планирования контейнера.

Загрузка может завершиться неудачно, если путь к изображению неверен, вы неправильно аутентифицированы или сеть выходит из строя. Когда это происходит, Kubernetes «отступает» и планирует еще одну попытку загрузки. Задержка перед следующим извлечением увеличивается экспоненциально каждый раз, когда попытка терпит неудачу, вплоть до предела в пять минут.

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

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

Проверьте основы

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

Вы можете проверить внутреннее состояние Kubernetes с помощью команды describe pod в Kubectl. Это дает вам больше информации, чем get pod и инструментальная панель Kubernetes.

kubectl describe pod my-pod --namespace my-namespace

Изменения в жизненном цикле пода отображаются под заголовком «События». Первое событие будет Запланировано; за ним должно следовать событие Pulling для первой попытки извлечения. После этого вы увидите событие Failed или BackOff, если получение не удалось. Они будут повторяться позже в списке, если Kubernetes все еще находится в цикле отсрочки и повторной попытки.

Чтение Message, связанного с этими событиями, часто указывает на основную причину проблемы. Сообщение manifest for image:tag not found означает, что изображение допустимо, но вы указали недопустимый тег. Если вы видите, что не существует или нет доступа по запросу, проверьте правильность путей реестра и образа. Когда вы уверены, что они правы, проблема будет связана с неправильной аутентификацией.

Управление входами в реестр

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

Поле Pod называется imagePullSecrets. Он должен указать секрет Kubernetes, который предоставляет токен входа в реестр. Этот секрет должен хранить значение JSON, совместимое с Docker.

apiVersion: v1
kind: Secret
type: kubernetes.io/dockerconfigjson
metadata:
  name: image-pull-secret
data:
  .dockerconfigjson: {{ "{"auths": {"registry.example.com": {"username": "demo-user", "password": "my-password"}}}" | b64enc }}

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: registry.example.com/my-image:latest
  imagePullSecrets:
    - name: image-pull-secret