Azure Container Registry에서 Azure Kubernetes Service 클러스터로 이미지를 끌어당기는 경우 오류 문제 해결

AKS(Azure Kubernetes Service)와 함께 Microsoft Azure Container Registry를 사용하는 경우 인증 메커니즘을 설정해야 합니다. 몇 가지 간단한 Azure CLI 또는 Azure PowerShell 명령을 사용하여 AKS를 Container Registry 통합으로 설정할 수 있습니다. 이 통합은 컨테이너 레지스트리에서 이미지를 끌어오기 위해 AKS 클러스터와 연결된 kubelet ID에 대해 Container Registry 리포지토리 읽기 권한자 역할 (ABAC(특성 기반 액세스 제어) 사용 레지스트리의 경우) 또는 AcrPull 역할 (ABAC 사용이 아닌 레지스트리의 경우)을 할당합니다. ACR 레지스트리가 ABAC 사용인지 여부에 따라 할당하는 데 필요한 ACR 역할에 대한 자세한 내용은 리포지토리 권한에 대한 Microsoft Entra ABAC(특성 기반 액세스 제어) 를 참조하세요.

경우에 따라 컨테이너 레지스트리에서 AKS 클러스터로 이미지를 끌어오려고 하면 실패합니다. 이 문서에서는 컨테이너 레지스트리에서 AKS 클러스터로 이미지를 끌어올 때 발생하는 가장 일반적인 오류를 해결하기 위한 지침을 제공합니다.

시작하기 전에

이 문서에서는 기존 AKS 클러스터와 기존 컨테이너 레지스트리가 있다고 가정합니다. 다음 빠른 시작을 참조하세요.

• AKS 클러스터가 필요한 경우 Azure CLI 또는 Azure Portal을 사용하여 배포합니다.

• ACR(Azure Container Registry)이 필요한 경우 Azure CLI 또는 Azure Portal을 사용하여 만듭니다.

또한 Azure CLI 버전 2.0.59 이상을 설치하고 구성해야 합니다. az 버전을 실행하여 버전을 확인합니다. 설치 또는 업그레이드해야 하는 경우 Azure CLI 설치를 참조하세요.

증상 및 초기 문제 해결

Kubernetes Pod의 상태는 ImagePullBackOff 또는 ErrImagePull입니다. 자세한 오류 정보를 얻으려면 다음 명령을 실행하고 출력에서 이벤트를 확인합니다.

kubectl describe pod <podname> -n <namespace>

컨테이너 레지스트리의 상태를 확인하고 AKS 클러스터에서 컨테이너 레지스트리에 액세스할 수 있는지 확인하여 문제 해결을 시작하는 것이 좋습니다.

컨테이너 레지스트리의 상태를 확인하려면 다음 명령을 실행합니다.

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

문제가 감지되면 오류 코드 및 설명을 제공합니다. 오류 및 가능한 해결 방법에 대한 자세한 내용은 상태 검사 오류 참조를 참조하세요.

AKS 클러스터에서 컨테이너 레지스트리에 액세스할 수 있는지 확인하려면 다음 az aks check-acr 명령을 실행합니다.

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

다음 섹션에서는 명령 출력 의 이벤트에kubectl describe pod가장 일반적인 오류를 해결하는 데 도움이 됩니다.

원인 1: 401 Unauthorized 오류

원인 1a: 401 Unauthorized 잘못된 권한 부여로 인한 오류

AKS 클러스터에는 ID가 필요합니다. 이 ID는 관리 ID 또는 서비스 주체일 수 있습니다. AKS 클러스터에서 관리 ID를 사용하는 경우 kubelet ID는 ACR로 인증하는 데 사용됩니다. AKS 클러스터가 서비스 주체를 ID로 사용하는 경우 서비스 주체 자체는 ACR로 인증하는 데 사용됩니다. ID가 무엇이든 간에 컨테이너 레지스트리에서 이미지를 끌어오는 데 사용되는 적절한 권한 부여가 필요합니다. 그렇지 않으면 다음 401 Unauthorized 오류가 발생할 수 있습니다.

Failed to pull image "\<acrname>.azurecr.io/\<repository\:tag>": [rpc error: code = Unknown desc = failed to pull and unpack image "\<acrname>.azurecr.io/\<repository\:tag>": failed to resolve reference "\<acrname>.azurecr.io/\<repository\:tag>": failed to authorize: failed to fetch oauth token: unexpected status: 401 Unauthorized

몇 가지 솔루션은 다음 제약 조건에 따라 이 오류를 해결하는 데 도움이 될 수 있습니다.

• 솔루션 2, 3 및 5는 서비스 주체를 사용하는 AKS 클러스터에만 적용됩니다.

• 솔루션 1, 2, 3 및 4는 AKS ID에 대한 Container Registry 수준에서 역할 할당을 만드는 Azure 메서드에 적용할 수 있습니다.

• 솔루션 5 및 6은 Kubernetes 비밀을 끌어오는 Kubernetes 메서드에 적용됩니다.

해결 방법 1: ID에 대해 올바른 ACR 역할 할당이 생성되었는지 확인합니다.

AKS와 컨테이너 레지스트리 간의 통합은 AKS 클러스터의 kubelet ID에 대한 컨테이너 레지스트리 수준에서 올바른 역할 할당을 만듭니다.

올바른 ACR 역할 할당이 있는지 확인하려면 다음 방법 중 하나를 사용합니다.

• 다음 명령을 실행합니다.

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

• Azure IAM(Container Registry 자세한 내용은 Azure Portal을 사용하여 Azure 역할 할당 나열을 참조 하세요.

Container Registry Repository Reader 역할(ABAC 사용 레지스트리의 경우) 및 AcrPull 역할(ABAC 사용이 아닌 레지스트리의 경우) 외에도 일부 기본 제공 역할 및 사용자 지정 역할에는 이미지 풀에 필요한 Microsoft Entra 권한이 포함될 수 있습니다. 필요에 따라 해당 역할을 확인합니다.

Container Registry Repository Reader 역할(ABAC 사용 레지스트리의 경우) 또는 AcrPull 역할(ABAC 사용이 아닌 레지스트리의 경우)이 없는 경우 역할 할당을 만들 수 있습니다.

ABAC 사용이 아닌 레지스트리의 경우 다음 명령을 사용하여 역할을 할당 AcrPull 할 수 있습니다.

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

ABAC가 사용된 레지스트리에서는 az aks --attach-acr 명령이 Container Registry Repository Reader 역할 추가를 지원하지 않습니다. Azure Portal 또는 az role assignment CLI 명령을 사용하여 AKS kubelet 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: 올바른 ACR 역할이 올바른 서비스 주체에 할당되었는지 확인

경우에 따라 컨테이너 레지스트리 역할 할당은 여전히 이전 서비스 주체를 참조합니다. 예를 들어 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 ID가 AKS Virtual Machine Scale Sets에서 참조되는지 확인합니다.

ACR을 사용하여 인증하는 데 관리 ID를 사용하는 경우 관리 ID를 kubelet ID라고 합니다. 기본적으로 kubelet ID는 AKS Virtual Machine Scale Setslevel에 할당됩니다. AKS Virtual Machine Scale Sets에서 kubelet ID가 제거된 경우 AKS 노드는 ACR에서 이미지를 끌어올 수 없습니다.

AKS 클러스터의 kubelet ID를 찾으려면 다음 명령을 실행합니다.

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

그런 다음 노드 리소스 그룹에서 Virtual Machine Scale Sets를 열고 Azure Portal에서할당된 ID 사용자를 선택하거나 다음 명령을 실행하여 AKS Virtual Machine Scale Sets의 >를 나열할 수 있습니다.

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

AKS 클러스터의 kubelet ID가 AKS Virtual Machine Scale Sets에 할당되지 않은 경우 다시 할당합니다.

AKS Virtual Machine Scale Sets에 대한 수정은 지원되지 않으므로 AKS 수준에서 전파되지 않습니다. kubelet ID를 AKS Virtual Machine Scale Sets에 다시 할당하려면 조정 작업이 필요합니다. 이렇게 하려면 다음 명령을 실행합니다.

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 Portal에서 컨테이너 레지스트리를 검색하고 선택합니다.

3. 컨테이너 레지스트리 목록에서 컨테이너 레지스트리를 선택합니다.

4. 컨테이너 레지스트리의 탐색 창에서 액세스 키를 선택합니다.

5. 컨테이너 레지스트리의 액세스 키 페이지에서 컨테이너 레지스트리 값을 Kubernetes 비밀의 값과 비교합니다.

6. 값이 일치하지 않으면 Kubernetes 비밀을 적절하게 업데이트하거나 다시 만듭니다.

원인 1b: 401 Unauthorized 호환되지 않는 아키텍처로 인한 오류

AKS 클러스터 ID에 권한이 부여된 경우에도 오류가 발생할 401 Unauthorized 수 있습니다( 원인 1a: 401 Unauthorized 잘못된 권한 부여 섹션으로 인한 오류 ). 이 문제는 ACR의 컨테이너 이미지가 컨테이너를 실행하는 노드의 아키텍처(예: ARM64 및 AMD64)와 일치하지 않는 경우에 발생할 수 있습니다. 예를 들어 AMD64 노드에 ARM64 이미지를 배포하거나 그 반대로 배포하면 이 오류가 발생할 수 있습니다.

오류 메시지는 다음과 같이 표시됩니다.

Failed to pull image "\<acrname>.azurecr.io/\<repository:\tag>": [rpc error: code = NotFound desc = failed to pull and unpack image "\<acrname>.azurecr.io/\<repository:\tag>": no match for platform in manifest: not found, failed to pull and unpack image "\<acrname>.azurecr.io/\<repository\:tag>": failed to resolve reference "\<acrname>.azurecr.io/\<repository\:tag>": failed to authorize: failed to fetch anonymous token: unexpected status from GET request to https://\<acrname>.azurecr.io/oauth2/token?scope=repository%3A\<repository>%3Apull&service=\<acrname>.azurecr.io: 401 Unauthorized]

Azure CLI를 사용하여 이 문제를 진단할 때 시스템 노드 풀이 ACR의 이미지와 다른 아키텍처를 실행하는 경우 예기치 않은 exec format 오류가 표시될 수 있습니다.

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

exec /canipull: exec format error

해결 방법: 올바른 아키텍처로 이미지 푸시 또는 다중 아키텍처 이미지 푸시

이 문제를 해결하려면 다음 방법 중 하나를 사용합니다.

• ACR에 푸시된 컨테이너 이미지가 AKS 노드의 아키텍처(예: ARM64 또는 AMD64)와 일치하는지 확인합니다.
• ARM64 및 AMD64 아키텍처를 모두 지원하는 다중 아키텍처 이미지를 만들고 푸시합니다.

원인 2: 이미지를 찾을 수 없음 오류

이미지를 찾을 수 없는 오류는 다음과 같이 표시됩니다.

Failed to pull image "\<acrname>.azurecr.io/\<repository\:tag>": [rpc error: code = NotFound desc = failed to pull and unpack image "\<acrname>.azurecr.io/\<repository\:tag>": failed to resolve reference "\<acrname>.azurecr.io/\<repository\:tag>": \<acrname>.azurecr.io/\<repository\:tag>: not found

해결 방법: 마지 이름이 올바른지 확인

이 오류가 표시되면 이미지 이름이 올바른지 확인합니다. 레지스트리 이름, 레지스트리 로그인 서버, 리포지토리 이름 및 태그를 확인합니다.

이미지 이름이 완전히 올바르지 않으면 컨테이너 레지스트리에서 익명 끌어오기 액세스를 사용하도록 설정했는지 여부에 관계없이 AKS에서 항상 익명 끌어오기를 시도하기 때문에 401 권한 없음 오류가 발생할 수도 있습니다.

원인 3: 403 forbidden 오류

403 Forbidden 오류 메시지는 다음과 같이 표시됩니다.

Failed to pull image "\<acrname>.azurecr.io/\<repository\:tag>": rpc error: code = Unknown desc = failed to pull and unpack image "\<acrname>.azurecr.io/\<repository\:tag>": failed to resolve reference "\<acrname>.azurecr.io/\<repository\:tag>": failed to authorize: failed to fetch anonymous token: unexpected status: 403 Forbidden

해결 방법 1: AKS 가상 네트워크 링크가 컨테이너 레지스트리의 프라이빗 DNS 영역에 설정되어 있는지 확인합니다.

컨테이너 레지스트리의 프라이빗 엔드포인트와 AKS 클러스터의 네트워크 인터페이스가 서로 다른 가상 네트워크에 있는 경우 AKS 클러스터의 가상 네트워크에 대한 가상 네트워크 링크 가 컨테이너 레지스트리의 프라이빗 DNS 영역에 설정되어 있는지 확인합니다. (이 링크의 이름은 기본적으로 privatelink.azurecr.io .) 가상 네트워크 링크가 컨테이너 레지스트리의 프라이빗 DNS 영역에 없는 경우 다음 방법 중 하나를 사용하여 추가합니다.

• Azure Portal 사용:

1. Azure Portal에서 프라이빗 DNS 영역 privatelink.azurecr.io 선택합니다.
2. 설정에서 가상 네트워크 링크>추가를 선택합니다.
3. AKS 클러스터의 이름 및 가상 네트워크를 선택한 다음 확인을 선택합니다.

• Azure CLI를 사용하여 지정된 프라이빗 DNS 영역에 대한 가상 네트워크 링크를 만듭니다.

해결 방법 2: AKS 부하 분산 장치의 공용 IP 주소를 컨테이너 레지스트리의 허용된 IP 주소 범위에 추가

AKS 클러스터가 프라이빗 링크 또는 엔드포인트를 통하지 않고 컨테이너 레지스트리에 공개적으로 연결되고 컨테이너 레지스트리의 공용 네트워크 액세스가 선택한 네트워크로 제한되는 경우 다음 단계를 사용하여 AKS 부하 분산 장치의 공용 IP 주소를 컨테이너 레지스트리의 허용된 IP 주소 범위에 추가합니다.

1. 공용 네트워크 액세스가 선택한 네트워크로 제한되는지 확인합니다.

   1. Azure Portal에서 컨테이너 레지스트리로 이동합니다.
   2. 설정에서 네트워킹을 선택합니다.
   3. 공용 액세스 탭에서 공용 네트워크 액세스를 선택한 네트워크 또는 사용 안 함으로 설정합니다.

2. 다음 방법 중 하나를 사용하여 AKS Load Balancer의 공용 IP 주소를 가져옵니다.

   • Azure Portal 사용

     1. Azure Portal에서 AKS 클러스터로 이동합니다.
     2. 설정에서 속성을 선택합니다.
     3. 인프라 리소스 그룹에서 Virtual Machine Scale Sets 중 하나를 선택하고 AKS 부하 분산 장치의 공용 IP 주소를 확인합니다.

   • 다음 명령을 실행합니다.

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

3. 다음 방법 중 하나를 사용하여 AKS 부하 분산 장치의 공용 IP 주소에서 액세스를 허용합니다.

   • az acr network-rule add 다음과 같이 명령을 실행합니다.

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

     자세한 내용은 레지스트리에 네트워크 규칙 추가를 참조 하세요.

   • Azure Portal 사용:

     1. Azure Portal에서 컨테이너 레지스트리로 이동합니다.
     2. 설정에서 네트워킹을 선택합니다.
     3. 공용 액세스 탭의 방화벽에서 AKS 부하 분산 장치의 공용 IP 주소를 주소 범위에 추가한 다음 저장을 선택합니다.

     자세한 내용은 선택한 공용 네트워크 - 포털에서 액세스를 참조 하세요.

     참고 항목

     공용 네트워크 액세스가 사용 안 함으로 설정된 경우 먼저 선택한 네트워크로 전환합니다.

     

원인 4: i/o timeout 오류

i/o timeout 오류 메시지는 다음과 같이 표시됩니다.

Failed to pull image "\<acrname>.azurecr.io/\<repository\:tag>": rpc error: code = Unknown desc = failed to pull and unpack image "\<acrname>.azurecr.io/\<repository\:tag>": failed to resolve reference "\<acrname>.azurecr.io/<repository\:tag>": failed to do request: Head "https://\<acrname>.azurecr.io/v2/\<repository>/manifests/v1": dial tcp \<acrprivateipaddress>:443: i/o timeout

솔루션 1: 가상 네트워크 피어링이 사용되는지 확인

컨테이너 레지스트리의 프라이빗 엔드포인트와 AKS 클러스터의 네트워크 인터페이스가 서로 다른 가상 네트워크에 있는 경우 가상 네트워크 피어링이 두 가상 네트워크에 모두 사용되는지 확인합니다. Azure CLI 명령을 az network vnet peering list --resource-group <MyResourceGroup> --vnet-name <MyVirtualNetwork> --output table 실행하거나 Azure Portal에서 설정 패널에서 > 피어링을 선택하여 가상 네트워크피어링을 확인할 수 있습니다. 지정된 가상 네트워크의 모든 피어링을 나열하는 방법에 대한 자세한 내용은 az network vnet peering list를 참조하세요.

가상 네트워크 피어링이 두 가상 네트워크에 모두 사용되는 경우 상태가 연결되었는지 확인합니다. 상태가 연결이 끊어진 경우 두 가상 네트워크에서 피어링을 삭제한 다음 다시 만듭니다. 상태가 연결된 경우 문제 해결 가이드를 참조하세요. 피어링 상태는 "연결됨"입니다.

추가 문제 해결을 위해 AKS 노드 또는 Pod 중 하나에 연결한 다음 텔넷 또는 netcat 유틸리티를 사용하여 TCP 수준에서 컨테이너 레지스트리와의 연결을 테스트합니다. nslookup <acrname>.azurecr.io 명령을 사용하여 IP 주소를 확인한 다음 telnet <ip-address-of-the-container-registry> 443 명령을 실행합니다.

AKS 노드에 연결하는 방법에 대한 자세한 내용은 유지 관리 또는 문제 해결을 위해 AKS(Azure Kubernetes Service) 클러스터 노드에 SSH를 사용하여 연결을 참조 하세요.

솔루션 2: Azure Firewall 사용

컨테이너 레지스트리의 프라이빗 엔드포인트 및 AKS 클러스터의 네트워크 인터페이스가 가상 네트워크 피어링 외에도 다른 가상 네트워크에 있는 경우 Azure Firewall을 사용하여 Azure에서 허브-스포크 네트워크 토폴로지를 설정할 수 있습니다. 방화벽 규칙을 설정할 때 네트워크 규칙을 사용하여 컨테이너 레지스트리 프라이빗 엔드포인트 IP 주소에 대한 아웃바운드 연결을 명시적으로 허용해야 합니다.

원인 5: 매니페스트의 플랫폼에 대한 일치 없음

호스트 운영 체제(노드 OS)는 Pod 또는 컨테이너에 사용되는 이미지와 호환되지 않습니다. 예를 들어 Windows 노드 또는 Linux 노드의 Windows 컨테이너에서 Linux 컨테이너를 실행하도록 Pod를 예약하는 경우 다음 오류가 발생합니다.

Failed to pull image "\<acrname>.azurecr.io/\<repository:tag>"\:\ [\ &nbsp; rpc error:\ &nbsp; code = NotFound\ &nbsp; desc = failed to pull and unpack image "\<acrname>.azurecr.io/\<repository:tag>": **no match for platform in manifest**: not found,\ ]

이 오류는 이미지가 호스트 OS와 호환되지 않는 경우 원본에서 가져온 이미지에 대해 발생합니다. 오류는 컨테이너 레지스트리에서 가져온 이미지로 제한되지 않습니다.

해결 방법: Pod 또는 배포에서 nodeSelector 필드를 올바르게 구성합니다.

Pod 또는 배포의 구성 설정에서 올바른 nodeSelector 필드를 지정합니다. 이 필드 설정에 kubernetes.io/os 대한 올바른 값을 사용하면 올바른 유형의 노드에서 Pod가 예약됩니다. 다음 표에서는 YAML에서 설정을 설정하는 kubernetes.io/os 방법을 보여줍니다.

예를 들어 다음 YAML 코드는 Linux 노드에서 예약해야 하는 Pod를 설명합니다.

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

원인 6: Kubelet이 기본 이미지 끌어오기 속도 제한을 초과합니다.

여러 작업이 동일한 이미지를 끌어오면 kubelet 기본 끌어오기 속도 제한을 초과할 수 있습니다. 이 경우 다음과 같은 오류 메시지가 표시됩니다.

Failed to pull image "acrname.azurecr.io/repo/nginx:latest": pull QPS exceeded. This occurred for pod \<podname\> at 4/22/2025, 12:48:32.000 PM UTC.

제한에 대한 자세한 내용은 registryPullQPS 구성을 참조하세요.

해결 방법: imagePullPolicy 값을 IfNotPresent로 변경

이 문제를 해결하려면 배포 YAML 파일에서 imagePullPolicy 값을 Always에서 IfNotPresent로 변경하여 불필요한 끌어오기를 방지합니다. IfNotPresent 는 이미지가 노드에 아직 없는 경우에만 레지스트리에서 끌어오도록 합니다.

배포 YAML 파일의 예는 다음과 같습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: myacr.azurecr.io/my-image:latest
        imagePullPolicy: IfNotPresent

기타 고려 사항

이 문서의 문제 해결 지침이 문제를 해결하는 데 도움이 되지 않는 경우 고려해야 할 몇 가지 다른 사항은 다음과 같습니다.

• 서브넷과 연결된 네트워크 보안 그룹 및 경로 테이블을 확인합니다(이러한 항목이 있는 경우).

• 방화벽과 같은 가상 어플라이언스가 서브넷 간의 트래픽을 제어하는 경우 방화벽 및 방화벽 액세스 규칙을 확인합니다.

타사 정보 고지 사항

이 문서에 나와 있는 다른 공급업체 제품은 Microsoft와 무관한 회사에서 제조한 것입니다. Microsoft는 이들 제품의 성능이나 안정성에 관하여 명시적이든 묵시적이든 어떠한 보증도 하지 않습니다.

도움을 요청하십시오.

질문이 있는 경우 Azure 커뮤니티 지원을 요청할 수 있습니다. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.