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

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

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

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

Когда статус рабочей нагрузки показывает "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 События, связанные с ошибкой загрузки image

Event

Cause and Solution

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

You have not logged in to the image repository.

Пункт проверки 1: указано ли imagePullSecret при использовании kubectl для создания Workload

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

Адрес image указан неверно.

Пункт проверки 2: правильный ли адрес Image при использовании Third-Party Image

Пункт проверки 3: используется ли неверный Secret при использовании Third-Party Image

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

The disk space is insufficient.

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

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

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

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

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

The image size is too large.

Пункт проверки 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)

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

ERROR: toomanyrequests: Too Many Requests.

Или

вы reached your pull rate limit, вы можете увеличить лимит, аутентифицировавшись и обновив

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

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

Элемент проверки 1: Указан ли imagePullSecret при использовании kubectl для создания workload

Если workload находится в ненормальном состоянии и отображается событие 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 для создания workload из стороннего образа укажите поле imagePullSecret, где name указывает имя секрета, используемого для загрузки образа.

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

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

Необходимо вводить адреса сторонних образов в соответствии с конкретными требованиями. Адрес образа должен быть в формате 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 на странице сведений о workload.

Пункт проверки 3: Используется ли неверный Secret при использовании Third-Party Image

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

Решение

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

Пункт проверки 4: Недостаточно ли Node Disk Space

Если в событиях 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
    1. Получите локальные образы на узле.
      crictl images -v
    2. Удалите ненужные образы по ID образа.
      crictl rmi {Image ID}
  • Узлы, использующие Docker
    1. Получите локальные образы на узле.
      docker images
    2. Удалите ненужные образы по ID образа.
      docker rmi {image-ID}
Note

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

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

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

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

  2. Log in to the CCE console and click the cluster name to access the cluster console. In the navigation pane, choose Nodes. In the right pane, click the Nodes tab, locate the row containing the node, and choose More > Sync Server Data in the Operation column.
  3. Войдите в узел.
  4. Выполните lsblk, чтобы просмотреть информацию о блочных устройствах узла.

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

    Overlayfs: No independent thin pool is allocated. Image data is stored in 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

    Device Mapper: Тонкий пул выделен для хранения данных образов.

    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. Расширьте ёмкость диска.

      Вариант 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

      Вариант 2: Добавьте новую ёмкость диска к диску dockersys.

      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 указывает логический том, используемый средой выполнения контейнеров.
        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 указывает путь к файловой системе среды выполнения контейнеров.
        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

Пункт проверки 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: Слишком большой размер образа

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

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

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

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

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

Решение
  • (Recommended) Решение 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: Достигло ли количество публичных загрузок образов верхнего предела

Симптом

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

 
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