Облачная платформаAdvanced

Что делать, если Pod не может загрузить образ?

Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

Определение неисправности

Когда статус рабочей нагрузки показывает "Pod not ready: Back-off pulling image "xxxxx", в Kubernetes будет зарегистрировано событие Failed to pull image или Failed to re-pull image. Подробную информацию о том, как просматривать события Kubernetes, см. Viewing Pod Events.

Устранение неполадок

Определите причину на основе событий, перечисленных в Table 1.
Table 1 События, связанные с ошибкой загрузки образа

Событие

Причина и решение

Failed to pull image "xxx": rpc error: code = Unknown desc = Error response from daemon: Get xxx: denied: You may not login yet

Вы не вошли в репозиторий образов.

Пункт проверки 1: Указан ли imagePullSecret при использовании kubectl для создания рабочей нагрузки

Failed to pull image "nginx:v1.1": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io: no such host

Адрес образа настроен неверно.

Пункт проверки 2: Корректен ли адрес образа при использовании стороннего образа

Пункт проверки 3: Используется ли неверный secret при использовании стороннего образа

Failed create pod sandbox: rpc error: code = Unknown desc = failed to create a sandbox for pod "nginx-6dc48bf8b6-l8xrw": Error response from daemon: mkdir xxxxx: no space left on device

Недостаточно места на диске.

Check Item 4: Является ли пространство диска узла недостаточным

Failed to pull image "xxx": rpc error: code = Unknown desc = error pulling image configuration: xxx x509: certificate signed by unknown authority

Неизвестный или небезопасный сертификат используется сторонним репозиторием образов, из которого загружается образ.

Check Item 5: Использует ли удалённый репозиторий образов неизвестный или небезопасный сертификат

Failed to pull image "xxx": rpc error: code = Unknown desc = context canceled

Размер образа слишком велик.

Check Item 6: Является ли размер образа слишком большим

Failed to pull image "docker.io/bitnami/nginx:1.22.0-debian-11-r3": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Check Item 7: Можно ли получить доступ к репозиторию образов

ERROR: toomanyrequests: Too Many Requests.

Или

Вы превысили лимит загрузки образов, вы можете увеличить лимит, аутентифицировавшись и обновив

Скорость ограничена, потому что количество загрузок образов достигает верхнего предела.

Пункт проверки 8: Достигает ли количество публичных загрузок образов верхнего предела

Пункт проверки 1: Указан ли imagePullSecret при использовании kubectl для создания рабочей нагрузки

Если рабочая нагрузка аномальна и отображается событие Kubernetes, указывающее, что pod не может загрузить образ, вы можете проверить, существует ли поле imagePullSecrets в файле YAML.

Элементы для проверки
  • Если образ необходимо загрузить из SWR, параметр name должен быть установлен в default-secret.
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: nginx
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nginx
      strategy:
        type: RollingUpdate
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - image: nginx 
            imagePullPolicy: Always
            name: nginx
          imagePullSecrets:
          - name: default-secret
  • Если образ необходимо загрузить из стороннего репозитория образов, параметр name должен быть установлен в имя созданного секрета.

    При использовании kubectl для создания рабочей нагрузки из стороннего образа укажите поле imagePullSecret, где name указывает имя секрета, используемого для загрузки образа.

Пункт проверки 2: Корректен ли адрес образа при использовании стороннего образа

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

Необходимо ввести адреса сторонних образов в соответствии с конкретными требованиями. Адрес образа должен быть в формате domainname/organization/imagename:tag. Если версия не указана, по умолчанию используется latest.
  • Для частного репозитория введите адрес образа в формате domainname/organization/imagename:tag.
  • Для открытого репозитория Docker введите адрес образа в формате name:version, например, nginx:latest.

Если загрузка образа не удалась из‑за указания неверного адреса образа, в событиях Kubernetes отображается информация, аналогичная следующей:

 
Failed to pull image "nginx:v1.1": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io: no such host

Решение

Измените адрес образа, отредактировав файл YAML, или войдите в консоль CCE и замените образ на вкладке Upgrade на странице сведений о рабочей нагрузке.

Пункт проверки 3: Используется ли неверный secret при использовании стороннего образа

Обычно к стороннему репозиторию образов можно получить доступ только после аутентификации (с использованием вашей учётной записи и пароля). CCE использует режим аутентификации secret для загрузки образов, поэтому необходимо создать secret для репозитория образов перед загрузкой образов из репозитория.

Решение

Если ваш secret неверен, загрузка образов завершится неудачей. В этом случае создайте новый secret.

Пункт проверки 4: Недостаточно ли места на диске узла

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

 
Failed create pod sandbox: rpc error: code = Unknown desc = failed to create a sandbox for pod "nginx-6dc48bf8b6-l8xrw": Error response from daemon: mkdir xxxxx: no space left on device

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

 
lvs

Решение 1: Очистка образов

Выполните следующие действия для очистки неиспользуемых образов:

  • containerd nodes
    1. Получите локальные образы на узле.
      crictl images -v
    2. Удалите ненужные образы по ID образа.
      crictl rmi {Image ID}
  • Docker nodes
    1. Получите локальные образы на узле.
      docker images
    2. Удалите ненужные образы по ID образа.
      docker rmi {image-ID}
Note

Не удаляйте системные образы, такие как образ cce-pause. В противном случае создание pod может завершиться неудачей.

Решение 2: Расширение ёмкости диска

Чтобы расширить ёмкость диска, выполните следующие операции:
  1. Расширьте ёмкость диска с данными в консоли EVS.

    Расширяется только ёмкость хранилища дисков EVS. Для расширения ёмкости логических томов и файловых систем необходимо выполнить следующие операции.

  2. Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера. В панели навигации выберите Nodes. В правой панели нажмите вкладку Nodes, найдите строку, содержащую узел, и выберите More > Sync Server Data в столбце Operation.
  3. Войдите в узел.
  4. Выполните lsblk, чтобы просмотреть информацию о блочных устройствах узла.

    Диск с данными делится в зависимости от контейнерного хранилища Rootfs:

    Overlayfs: Независимый thin pool не выделяется. Данные образа хранятся в dockersys.

    1. Проверьте ёмкость диска и разделов устройства.
      # lsblk
      NAME                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
      sda                   8:0    0   50G  0 disk 
      └─sda1                8:1    0   50G  0 part /
       sdb                    8:16   0  150G  0 disk      # The data disk has been expanded to 150 GiB, but 50 GiB space is free.
      ├─ vgpaas-dockersys   253:0    0   90G  0 lvm  /var/lib/containerd
      └─vgpaas-kubernetes 253:1    0   10G  0 lvm  /mnt/paas/kubernetes/kubelet
    2. Расширьте ёмкость диска.

      Добавьте новую ёмкость диска в логический том dockersys, используемый средой выполнения контейнеров.
      1. Расширьте ёмкость PV, чтобы LVM мог определить новую ёмкость EVS. /dev/sdb указывает физический том, в котором находится dockersys.
        pvresize /dev/sdb

        Отображается информация, аналогичная следующей:

         
        Physical volume "/dev/sdb" changed
        1 physical volume(s) resized or updated / 0 physical volume(s) not resized
      2. Расширьте 100% свободного объёма до логического тома. vgpaas/dockersys указывает логический том, используемый средой выполнения контейнеров.
        lvextend -l+100%FREE -n vgpaas/dockersys

        Отображается информация, аналогичная следующей:

         
        Size of logical volume vgpaas/dockersys changed from <90.00 GiB (23039 extents) to 140.00 GiB (35840 extents).
        Logical volume vgpaas/dockersys successfully resized.
      3. Отрегулируйте ёмкость файловой системы. /dev/vgpaas/dockersys указывает путь к файловой системе, используемой средой выполнения контейнеров.
        resize2fs /dev/vgpaas/dockersys

        Отображается информация, аналогичная следующей:

         
        Filesystem at /dev/vgpaas/dockersys is mounted on /var/lib/containerd; on-line resizing required
        old_desc_blocks = 12, new_desc_blocks = 18
        The filesystem on /dev/vgpaas/dockersys is now 36700160 blocks long.
    3. Проверьте, расширена ли ёмкость.
      # lsblk
      NAME                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
      sda                   8:0    0   50G  0 disk 
      └─sda1                8:1    0   50G  0 part /
       sdb                    8:16   0  150G  0 disk
      ├─ vgpaas-dockersys   253:0    0   140G  0 lvm  /var/lib/containerd
      └─vgpaas-kubernetes 253:1    0   10G  0 lvm  /mnt/paas/kubernetes/kubelet

    Devicemapper: Для хранения данных образов выделяется тонкий пул.

    1. Проверьте ёмкость диска и разделов устройства.
      # lsblk
      NAME                                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
      vda                                   8:0    0   50G  0 disk 
      └─vda1                                8:1    0   50G  0 part /
       vdb                                    8:16   0  200G  0 disk 
      ├─ vgpaas-dockersys                   253:0    0   18G  0 lvm  /var/lib/docker    
      ├─vgpaas-thinpool_tmeta             253:1    0    3G  0 lvm                   
      │ └─ vgpaas-thinpool                  253:3    0   67G  0 lvm                   # Space used by thin pool
      │   ...
      ├─vgpaas-thinpool_tdata             253:2    0   67G  0 lvm  
      │ └─vgpaas-thinpool                 253:3    0   67G  0 lvm  
      │   ...
      └─vgpaas-kubernetes                 253:4    0   10G  0 lvm  /mnt/paas/kubernetes/kubelet
    2. Расширьте ёмкость диска.

      Option 1: Добавьте новую ёмкость диска в тонкий пул.

      1. Расширьте ёмкость PV, чтобы LVM мог обнаружить новую ёмкость EVS. /dev/vdb указывает физический том, в котором находится тонкий пул.
        pvresize /dev/vdb

        Отображается информация, аналогичная следующей:

         
        Physical volume "/dev/vdb" changed
        1 physical volume(s) resized or updated / 0 physical volume(s) not resized
      2. Расширьте 100% свободного объёма до логического тома. vgpaas/thinpool указывает логический том, используемый средой выполнения контейнеров.
        lvextend -l+100%FREE -n vgpaas/thinpool

        Отображается информация, аналогичная следующей:

         
        Size of logical volume vgpaas/thinpool changed from <67.00 GiB (23039 extents) to <167.00 GiB (48639 extents).
        Logical volume vgpaas/thinpool successfully resized.
      3. Не регулируйте ёмкость файловой системы, поскольку тонкий пул не смонтирован ни на одно устройство.
      4. Запустите lsblk, чтобы проверить ёмкость диска и разделов устройства и убедиться, расширена ли ёмкость. Если новая ёмкость диска добавлена в тонкий пул, ёмкость считается расширенной.
        # lsblk
        NAME                                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
        vda                                   8:0    0   50G  0 disk 
        └─vda1                                8:1    0   50G  0 part /
         vdb                                    8:16   0  200G  0 disk 
        ├─vgpaas-dockersys                  253:0    0   18G  0 lvm  /var/lib/docker    
        ├─vgpaas-thinpool_tmeta             253:1    0    3G  0 lvm                   
        │ └─ vgpaas-thinpool                  253:3    0   167G  0 lvm             # Thin pool space after capacity expansion
        │   ...
        ├─vgpaas-thinpool_tdata             253:2    0   67G  0 lvm  
        │ └─vgpaas-thinpool                 253:3    0   67G  0 lvm  
        │   ...
        └─vgpaas-kubernetes                 253:4    0   10G  0 lvm  /mnt/paas/kubernetes/kubelet

      Option 2: Добавьте новую ёмкость диска к Docker system disk.

      1. Увеличьте ёмкость PV, чтобы LVM мог обнаружить новую ёмкость EVS. /dev/vdb указывает физический том, где находится dockersys.
        pvresize /dev/vdb

        Отображается информация, аналогичная следующей:

         
        Physical volume "/dev/vdb" changed
        1 physical volume(s) resized or updated / 0 physical volume(s) not resized
      2. Увеличьте свободную ёмкость на 100 % до логического тома. vgpaas/dockersys указывает логический том, используемый container runtime.
        lvextend -l+100%FREE -n vgpaas/dockersys

        Отображается информация, аналогичная следующей:

         
        Size of logical volume vgpaas/dockersys changed from <18.00 GiB (4607 extents) to <118.00 GiB (30208 extents).
        Logical volume vgpaas/dockersys successfully resized.
      3. Отрегулируйте ёмкость файловой системы. /dev/vgpaas/dockersys указывает путь к файловой системе container runtime.
        resize2fs /dev/vgpaas/dockersys

        Отображается информация, аналогичная следующей:

         
        Filesystem at /dev/vgpaas/dockersys is mounted on /var/lib/docker; on-line resizing required
        old_desc_blocks = 3, new_desc_blocks = 15
        The filesystem on /dev/vgpaas/dockersys is now 30932992 blocks long.
      4. Запустите команду lsblk, чтобы проверить ёмкость диска и разделов устройства и убедиться, что ёмкость была расширена. Если новая ёмкость диска была добавлена к dockersys, ёмкость расширена.
        # lsblk
        NAME                                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
        vda                                   8:0    0   50G  0 disk 
        └─vda1                                8:1    0   50G  0 part /
         vdb                                    8:16   0  200G  0 disk 
        ├─ vgpaas-dockersys                   253:0    0   118G  0 lvm  /var/lib/docker     # dockersys after capacity expansion
        ├─vgpaas-thinpool_tmeta             253:1    0    3G  0 lvm                   
        │ └─vgpaas-thinpool                 253:3    0   67G  0 lvm             
        │   ...
        ├─vgpaas-thinpool_tdata             253:2    0   67G  0 lvm  
        │ └─vgpaas-thinpool                 253:3    0   67G  0 lvm  
        │   ...
        └─vgpaas-kubernetes                 253:4    0   10G  0 lvm  /mnt/paas/kubernetes/kubelet

Check Item 5: Использует ли Remote Image Repository неизвестный или небезопасный сертификат

Если pod пытается загрузить образ из стороннего репозитория с неизвестным или небезопасным сертификатом, загрузка образа завершится неудачей на узле. События pod содержат "Failed to pull the image" с причиной "x509: certificate signed by unknown authority".
Note

Безопасность образов EulerOS 2.9 была повышена за счёт удаления небезопасных или просроченных сертификатов из системы. Хотя некоторые сторонние образы на отдельных узлах могут не сообщать об ошибках, такой тип ошибки часто встречается в EulerOS 2.9. Чтобы устранить проблему, выполните следующие действия.

Решение
  1. Проверьте IP‑адрес и номер порта стороннего сервера образов, для которого отображается сообщение об ошибке "unknown authority".

    Вы можете увидеть IP‑адрес и номер порта стороннего сервера образов, для которого ошибка зафиксирована в событии "Failed to pull image".

    Failed to pull image "bitnami/redis-cluster:latest": rpc error: code = Unknown desc = error pulling image configuration: Get https://production.cloudflare.docker.com/registry-v2/docker/registry/v2/blobs/sha256/e8/e83853f03a2e792614e7c1e6de75d63e2d6d633b4e7c39b9d700792ee50f7b56/data?verify=1636972064-AQbl5RActnudDZV%2F3EShZwnqOe8%3D: x509: certificate signed by unknown authority

    IP‑адрес стороннего сервера образов — production.cloudflare.docker.com, а номер порта HTTPS по умолчанию — 443.

  2. Загрузите корневой сертификат стороннего сервера образов на узел, где будет загружаться сторонний образ.

    Выполните следующую команду на узле EulerOS или CentOS, заменив {server_url}:{server_port} на IP‑адрес и номер порта, полученные на предыдущем шаге, например, production.cloudflare.docker.com:443.

    Если среда выполнения контейнеров на узле — containerd, замените systemctl restart docker на systemctl restart containerd.

    openssl s_client -showcerts -connect {server_url}:{server_port} < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /etc/pki/ca-trust/source/anchors/tmp_ca.crt
    update-ca-trust
    systemctl restart docker

    Выполните следующую команду на узле Ubuntu:

    openssl s_client -showcerts -connect {server_url}:{server_port} < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /usr/local/share/ca-certificates/tmp_ca.crt
    update-ca-trust
    systemctl restart docker

Пункт проверки 6: слишком большой размер образа

События Под содержат "Failed to pull image". Это может быть вызвано большим размером образа.

 
Failed to pull image "XXX": rpc error: code = Unknown desc = context canceled

Однако образ можно загрузить вручную, выполнив команду docker pull на узле.

Возможная причина

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

Решение
  • (Рекомендуется) Решение 1:
    1. Войдите в узел и вручную загрузите образ.
      • Узлы containerd:
        crictl pull <image-address>
      • Узлы Docker:
        docker pull <image-address>
    2. При создании рабочей нагрузки убедитесь, что imagePullPolicy установлен в IfNotPresent (конфигурация по умолчанию). В этом случае рабочая нагрузка может использовать образ, который был загружен на локальный хост.
  • (Для кластеров версии v1.25 и новее) Решение 2: Измените параметры конфигурации пула узлов. Параметры конфигурации узлов в пуле узлов DefaultPool изменить нельзя.
    1. Войдите в консоль CCE.
    2. Щелкните имя кластера, чтобы открыть консоль кластера. В панели навигации выберите Nodes. В правой панели нажмите вкладку Node Pools.
    3. Найдите строку, содержащую целевой пул узлов, и нажмите Manage.
    4. В окне, которое выдвигается справа, измените параметр image-pull-progress-timeout в разделе Docker или containerd. Этот параметр image-pull-progress-timeout определяет интервал тайм‑аута при загрузке образа.
    5. Нажмите OK.

Пункт проверки 7: Можно ли получить доступ к репозиторию образов

Симптом

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

 
Failed to pull image "docker.io/bitnami/nginx:1.22.0-debian-11-r3": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Возможная причина

Из‑за сетевых проблем невозможно получить доступ к репозиторию образов. SWR позволяет загружать образы только из официального репозитория Docker. Чтобы загружать образы из других репозиториев, необходимо иметь доступ к Интернету.

Решение
  • Привяжите публичный IP‑адрес к узлу, с которого необходимо загрузить образ.
  • Отправьте образы в SWR, а затем загрузите их из SWR на ваши узлы.

Пункт проверки 8: Достигло ли количество публичных загрузок образов верхнего предела

Симптом

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

 
ERROR: toomanyrequests: Too Many Requests.

Или

 
you have reached your pull rate limit, you may increase the limit by authenticating an upgrading: https://www.docker.com/increase-rate-limits.

Возможная причина

Docker Hub устанавливает ограничения на максимальное количество запросов на загрузку образов контейнеров. Для подробностей см. Docker Hub pull usage and limits.

Решение

Перенесите часто используемые образы в SWR, а затем загружайте их из SWR на ваши узлы.
Родительская тема: Workload Exception Troubleshooting
Предыдущая статья
Что мне делать, если планирование Pod завершилось неудачей?
Следующая статья
Что мне делать, если запуск Pod не удался?
Поддержка Юридические документы Политика конфиденциальности
© 2026 Cloud.ru