Не удалось извлечь образы из Реестр контейнеров Azure в кластер Служба Azure Kubernetes

Примечание.

Статья была полезной? Ваши входные данные важны для нас. Нажмите кнопку "Отзывы" на этой странице, чтобы сообщить нам, насколько хорошо эта статья работала для вас или как мы можем улучшить ее.

При использовании Microsoft Реестр контейнеров Azure вместе с Служба Azure Kubernetes (AKS) необходимо установить механизм проверки подлинности. Вы можете настроить интеграцию AKS с реестром контейнеров с помощью нескольких простых команд Azure CLI или Azure PowerShell. Эта интеграция назначает роль AcrPull для удостоверения kubelet, связанного с кластером AKS, для извлечения образов из реестра контейнеров.

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

Подготовка к работе

В этой статье предполагается, что у вас есть существующий кластер AKS и существующий реестр контейнеров. См. следующие краткие руководства.

• Если вам нужен кластер AKS, разверните его с помощью Azure CLI или портал Azure.

• Если вам нужен Реестр контейнеров Azure (ACR), создайте его с помощью Azure CLI или портал Azure.

Для установки и настройки также требуется Azure CLI версии 2.0.59 или более поздней версии. Выполните команду az version , чтобы определить версию. Если необходимо установить или обновить, см. статью "Установка Azure CLI".

Симптомы и начальное устранение неполадок

Состояние pod Kubernetes — ImagePullBackOff или ErrImagePull. Чтобы получить подробные сведения об ошибке, выполните следующую команду и проверьте события из выходных данных.

kubectl describe pod <podname> -n <namespace>

Рекомендуется начать устранение неполадок, проверив работоспособности реестра контейнеров и проверив, доступен ли реестр контейнеров из кластера AKS.

Чтобы проверить работоспособность реестра контейнеров, выполните следующую команду:

az acr check-health --name <myregistry> --ignore-errors --yes

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

Примечание.

Если вы получаете ошибки, связанные с Helm или нотариями, это не означает, что проблема влияет на реестр контейнеров или AKS. Он указывает только, что Helm или Нотари не установлен, или что Azure CLI несовместима с текущей установленной версией Helm или Notary и т. д.

Чтобы проверить, доступен ли реестр контейнеров из кластера AKS, выполните следующую команду az aks check-acr :

az aks check-acr --resource-group <MyResourceGroup> --name <MyManagedCluster> --acr <myacr>.azurecr.io

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

Причина 1: 401 Несанкционированная ошибка

Для кластера AKS требуется удостоверение. Это удостоверение может быть либо управляемым удостоверением, либо субъектом-службой. Если кластер AKS использует управляемое удостоверение, удостоверение kubelet используется для проверки подлинности с помощью ACR. Если кластер AKS используется в качестве удостоверения субъекта-службы, сам субъект-служба используется для проверки подлинности с помощью ACR. Независимо от того, что такое удостоверение, требуется правильная авторизация, используемая для извлечения образа из реестра контейнеров. В противном случае может появиться следующая ошибка "401 Несанкционированный".

Не удалось извлечь изображение acrname.azurecr.io/ repository:tag>: [rpc error: code = Unknown desc = fail to pull and unpack image "<acrname.azurecr.io/<< repository:tag>": не удалось разрешить ссылку "<acrname.azurecr.io/>>< repository:tag>": не удалось авторизовать: не удалось получить маркер oauth: непредвиденное состояние: 401 Неавторизованный<>

Некоторые решения помогут устранить эту ошибку в соответствии со следующими ограничениями:

• Решения 2, 3 и 5 применимы только к кластерам AKS, используюющим субъект-службу.

• Решения 1, 2, 3 и 4 применимы для метода Azure создания назначения ролей на уровне реестра контейнеров для удостоверения AKS.

• Решения 5 и 6 применимы для метода Kubernetes извлечения секрета Kubernetes.

Решение 1. Убедитесь, что для удостоверения создано назначение роли AcrPull

Интеграция между AKS и Реестром контейнеров создает назначение роли AcrPull на уровне реестра контейнеров для удостоверения kubelet кластера AKS. Убедитесь, что назначение роли создано.

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

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

  az role assignment list --scope /subscriptions/<subscriptionID>/resourceGroups/<resourcegroupname>/providers/Microsoft.ContainerRegistry/registries/<acrname> -o table
  

• Проверьте портал Azure, выбрав >Реестр контейнеров Azure Access control (IAM)>Role assignments. Дополнительные сведения см. в разделе "Список назначений ролей Azure" с помощью портал Azure.

Помимо роли AcrPull, некоторые встроенные роли и пользовательские роли также могут содержать действие Microsoft.ContainerRegistry/registries/pull/read. Проверьте эти роли, если у вас есть какие-либо из них.

Если назначение роли AcrPull не создано, создайте его , настроив интеграцию реестра контейнеров для кластера AKS с помощью следующей команды:

az aks update -n <myAKSCluster> -g <myResourceGroup> --attach-acr <acr-resource-id>

Решение 2. Убедитесь, что субъект-служба не истекает

Убедитесь, что срок действия секрета субъекта-службы, связанного с кластером AKS, не истек. Чтобы проверить дату окончания срока действия субъекта-службы, выполните следующие команды:

SP_ID=$(az aks show --resource-group <myResourceGroup> --name <myAKSCluster> \
    --query servicePrincipalProfile.clientId -o tsv)

az ad app credential list --id "SP_ID" --query "[].endDateTime" --output tsv

Дополнительные сведения см. в разделе "Проверка срока действия субъекта-службы".

Если срок действия секрета истек, обновите учетные данные для кластера AKS.

Решение 3. Убедитесь, что роль AcrPull назначена правильному субъекту-службе

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

1. Чтобы проверить субъект-службу, используемый кластером AKS, выполните следующую команду:

   az aks show --resource-group <myResourceGroup> \
       --name <myAKSCluster> \
       --query servicePrincipalProfile.clientId \
       --output tsv
   

2. Чтобы проверить субъект-службу, на который ссылается назначение роли реестра контейнеров, выполните следующую команду:

   az role assignment list --scope /subscriptions/<subscriptionID>/resourceGroups/<resourcegroupname>/providers/Microsoft.ContainerRegistry/registries/<acrname> -o table
   

3. Сравните два субъекта-службы. Если они не соответствуют, снова интегрируйте кластер AKS с реестром контейнеров.

Решение 4. Убедитесь, что удостоверение kubelet ссылается в AKS VMSS

Если управляемое удостоверение используется для проверки подлинности с помощью ACR, управляемое удостоверение называется удостоверением kubelet. По умолчанию удостоверение kubelet назначается на уровне AKS VMSS. Если удостоверение kubelet удалено из AKS VMSS, узлы AKS не могут извлекать образы из ACR.

Чтобы найти удостоверение kubelet кластера AKS, выполните следующую команду:

az aks show --resource-group <MyResourceGroup> --name <MyManagedCluster> --query identityProfile.kubeletidentity

Затем вы можете получить список удостоверений AKS VMSS, открыв vmSS из группы ресурсов узла и выбрав "Пользователь удостоверения>", назначенный в портал Azure или выполнив следующую команду:

az vmss identity show --resource-group <NodeResourceGroup> --name <AksVmssName>

Если удостоверение kubelet кластера AKS не назначено виртуальной машине AKS, назначьте его обратно.

Примечание.

Изменение VMSS AKS с помощью API IaaS или из портал Azure не поддерживается, и никакие операции AKS не могут удалить удостоверение kubelet из AKS VMSS. Это означает, что что-то неожиданное удалено, например, удаление вручную, выполняемое членом команды. Чтобы предотвратить такое удаление или изменение, можно использовать функцию NRGLockdown.

Так как изменения в AKS VMSS не поддерживаются, они не распространяются на уровне AKS. Чтобы переназначить удостоверение kubelet виртуальной машине AKSS, требуется операция выверки. Для этого выполните следующую команду:

az aks update --resource-group <MyResourceGroup> --name <MyManagedCluster>

Решение 5. Убедитесь, что субъект-служба правильно и секрет действителен

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

1. Выполните следующую команду kubectl get и base64 , чтобы просмотреть значения секрета Kubernetes:

   kubectl get secret <secret-name> --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode
   

2. Проверьте дату окончания срока действия, выполнив следующую команду az ad sp credential list . Имя пользователя — это значение субъекта-службы.

   az ad sp credential list --id "<username>" --query "[].endDate" --output tsv
   

3. При необходимости сбросьте секрет этого субъекта-службы, выполнив следующую команду az ad sp credential reset :

   az ad sp credential reset --name "$SP_ID" --query password --output tsv
   

4. Обновите или повторно создайте секрет Kubernetes соответствующим образом.

Решение 6. Убедитесь, что секрет Kubernetes имеет правильные значения учетной записи администратора реестра контейнеров.

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

1. Выполните следующую команду kubectl get и base64 , чтобы просмотреть значения секрета Kubernetes:

   kubectl get secret <secret-name> --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode
   

2. В портал Azure найдите и выберите реестры контейнеров.

3. В списке реестров контейнеров выберите реестр контейнеров.

4. В области навигации для реестра контейнеров выберите ключи доступа.

5. На странице "Ключи доступа" для реестра контейнеров сравнивайте значения реестра контейнеров со значениями секрета Kubernetes.

6. Если значения не совпадают, обновите или повторно создайте секрет Kubernetes соответствующим образом.

Примечание.

Если произошла операция повторного восстановления паролей, на странице журнала действий реестра контейнеров реестра контейнеров в реестре контейнеров отобразится операция с именем "Повторное создание учетных данных для входа в реестр контейнеров". Журнал действий имеет 90-дневный срок хранения.

Причина 2. Ошибка изображения не найдена

Не удалось извлечь изображение acrname.azurecr.io/ repository:tag>: [rpc error: code = NotFound desc = не удалось извлечь и распаковать изображение "<acrname.azurecr.io/< repository:tag": не удалось разрешить ссылку "<acrname.azurecr.io/< repository:tag": acrname.azurecr.io/<><>> repository:>tag>>: <не найден<>

Решение. Убедитесь, что имя образа правильно

Если вы видите эту ошибку, убедитесь, что имя изображения полностью правильно. Необходимо проверить имя реестра, сервер входа реестра, имя репозитория и тег. Распространенная ошибка заключается в том, что сервер входа указан как "azureacr.io" вместо "azurecr.io".

Если имя образа не является полностью правильным, ошибка 401 несанкционированного доступа также может возникать, так как AKS всегда пытается выполнить анонимное извлечение независимо от того, включен ли анонимный доступ на вытягивание реестра контейнеров.

Причина 3. Ошибка запрета 403

Не удалось извлечь изображение acrname.azurecr.io/ repository:tag>: rpc error: code = Unknown desc = failed to pull and unpack image "<acrname.azurecr.io/>< repository:tag>": не удалось разрешить ссылку "<acrname.azurecr.io/><< repository:tag>": не удалось авторизовать: не удалось получить анонимный маркер: непредвиденное состояние: 403 Запрещено<>

Решение 1. Убедитесь, что в зоне Частная зона DNS реестра контейнеров установлен канал виртуальной сети AKS.

Если сетевой интерфейс частной конечной точки реестра контейнеров и кластера AKS находятся в разных виртуальных сетях, убедитесь, что связь виртуальной сети для виртуальной сети кластера AKS задана в зоне Частная зона DNS реестра контейнеров. (Эта ссылка называется "privatelink.azurecr.io" по умолчанию.) Если ссылка виртуальной сети не входит в зону Частная зона DNS реестра контейнеров, добавьте ее одним из следующих способов:

• В портал Azure выберите частную зону DNS "privatelink.azurecr.io", выберите ссылки>"Виртуальная сеть" на панели "Параметры", а затем выберите имя и виртуальную сеть кластера AKS. Нажмите ОК.

  Примечание.

  Необязательно выбрать функцию "Включить автоматическую регистрацию".

• Создайте ссылку виртуальной сети на указанную зону Частная зона DNS с помощью Azure CLI.

Решение 2. Добавление общедоступного IP-адреса AKS Load Balancer в допустимый диапазон IP-адресов реестра контейнеров

Если кластер AKS подключается публично к реестру контейнеров (НЕ через приватную ссылку или конечную точку) и доступ к общедоступной сети реестра контейнеров ограничен выбранными сетями, добавьте общедоступный IP-адрес AKS Load Balancer в допустимый диапазон IP-адресов реестра контейнеров:

1. Убедитесь, что доступ к общедоступной сети ограничен выбранными сетями.

   В портал Azure перейдите в реестр контейнеров. В разделе Параметры выберите Сеть. На вкладке "Общедоступный доступ" для общедоступного сетевого доступа задано значение "Выбранные сети" или "Отключено".

2. Получите общедоступный IP-адрес Load Balancer AKS, используя один из следующих способов:

   • В портал Azure перейдите к кластеру AKS. В разделе "Параметры" выберите "Свойства", выберите один из масштабируемых наборов виртуальных машин в группе ресурсов инфраструктуры и проверьте общедоступный IP-адрес подсистемы балансировки нагрузки AKS.

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

     az network public-ip show --resource-group <infrastructure-resource-group> --name <public-IP-name> --query ipAddress -o tsv
     

3. Разрешить доступ из общедоступного IP-адреса Load Balancer AKS с помощью одного из следующих способов:

   • Выполните az acr network-rule add следующую команду:

     az acr network-rule add --name acrname --ip-address <AKS-load-balancer-public-IP-address>
     

     Дополнительные сведения см. в разделе "Добавление сетевого правила в реестр".

   • В портал Azure перейдите в реестр контейнеров. В разделе Параметры выберите Сеть. На вкладке "Общедоступный доступ" в разделе "Брандмауэр" добавьте общедоступный IP-адрес AKS Load Balancer в диапазон адресов и нажмите кнопку "Сохранить". Дополнительные сведения см. в разделе Access из выбранной общедоступной сети — портал.

     Примечание.

     Если для общедоступного сетевого доступа установлено значение "Отключено", сначала переключитесь на выбранные сети .

     

Причина 4: "Ошибка времени ожидания ввода-вывода"

Не удалось извлечь изображение acrname.azurecr.io/ repository:tag>: rpc error: code = Unknown desc = Fail to pull and unpack image "acrname.azurecr.io/<< repository:tag>": не удалось разрешить ссылку "<<acrname>>.". azurecr.io/< repository:tag>": не удалось выполнить запрос: "https://< acrname.azurecr.io/v2/<> repository>/manifests/v1": dial tcp <acrprivateipaddress>:443: время ожидания ввода-вывода<>

Примечание.

Ошибка "Время ожидания ввода-вывода" возникает только при частном подключении к реестру контейнеров с помощью Приватный канал Azure.

Решение 1. Убедитесь, что используется пиринг между виртуальными сетями

Если сетевой интерфейс частной конечной точки реестра контейнеров и кластера AKS находятся в разных виртуальных сетях, убедитесь, что пиринг между виртуальными сетями используется для обеих виртуальных сетей. Чтобы проверить пиринг между виртуальными сетями, выполните команду az network vnet peering list --resource-group <MyResourceGroup> --vnet-name <MyVirtualNetwork> --output table Azure CLI или в портал Azure, выбрав пиринги виртуальных сетей>на панели параметров. Дополнительные сведения о перечислении всех пирингов указанной виртуальной сети см. в списке az network vnet peering.

Если пиринг между виртуальными сетями используется для обеих виртуальных сетей, убедитесь, что состояние "Подключено". Если состояние отключено, удалите пиринг из обеих виртуальных сетей, а затем повторно создайте его. Если состояние подключено, см. руководство по устранению неполадок: состояние пиринга — "Подключено".

Для дальнейшего устранения неполадок подключитесь к одному из узлов ИЛИ модулей pod AKS, а затем проверьте подключение к реестру контейнеров на уровне TCP с помощью служебной программы Telnet или Netcat. Проверьте IP-адрес с nslookup <acrname>.azurecr.io помощью команды и выполните telnet <ip-address-of-the-container-registry> 443 команду.

Дополнительные сведения о подключении к узлам AKS см. в статье "Подключение с помощью SSH к узлам кластера Служба Azure Kubernetes (AKS) для обслуживания или устранения неполадок.

Решение 2. Использование службы Брандмауэр Azure

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

Причина 5. Отсутствие совпадения для платформы в манифесте

Операционная система узла (ОС узла) несовместима с образом, используемым для модуля pod или контейнера. Например, если вы запланируйте модуль pod для запуска контейнера Linux на узле Windows или контейнера Windows на узле Linux, возникает следующая ошибка:

Не удалось извлечь изображение acrname.azurecr.io/><< repository:tag>:
[
  Ошибка rpc:
  code = NotFound
  desc = не удалось извлечь и распаковывать изображение "<acrname.azurecr.io/>< repository:tag>": не соответствует платформе в манифесте: не найдено,
]

Эта ошибка может возникать для образа, извлеченного из любого источника, если изображение несовместимо с операционной системой узла. Ошибка не ограничивается изображениями, извлекающимися из реестра контейнеров.

Решение. Правильно настройте поле nodeSelector в модуле pod или развертывании.

Укажите правильное nodeSelector поле в параметрах конфигурации модуля pod или развертывания. Правильное значение для параметра этого поля kubernetes.io/os гарантирует, что модуль pod будет запланирован на правильный тип узла. В следующей kubernetes.io/os таблице показано, как задать параметр в YAML:

Тип контейнера	Параметр YAML
Контейнер Linux	"kubernetes.io/os": linux
Контейнер Windows	"kubernetes.io/os": windows

Например, следующий код YAML описывает модуль pod, который должен быть запланирован на узле Linux:

apiVersion: v1
kind: Pod
metadata:
  name: aspnetapp
  labels:
    app: aspnetapp
spec:
  containers:
  - image: "mcr.microsoft.com/dotnet/core/samples:aspnetapp"
    name: aspnetapp-image
    ports:
    - containerPort: 80
      protocol: TCP
  nodeSelector:
    "kubernetes.io/os": linux

Дополнительная информация

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

• Проверьте группы безопасности сети и таблицы маршрутов, связанные с подсетями, если у вас есть любой из этих элементов.

• Если виртуальное устройство, например брандмауэр, управляет трафиком между подсетями, проверьте правила доступа брандмауэра и брандмауэра.

Заявление об отказе от ответственности за сведения о продуктах сторонних производителей

В этой статье упомянуты программные продукты независимых производителей. Корпорация Microsoft не дает никаких гарантий, подразумеваемых и прочих, относительно производительности и надежности этих продуктов.

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.