Kan geen installatiekopieën ophalen van Azure Container Registry naar een Azure Kubernetes Service-cluster
Notitie
Was dit artikel nuttig? Uw input is belangrijk voor ons. Gebruik de knop Feedback op deze pagina om ons te laten weten hoe goed dit artikel voor u heeft gewerkt of hoe we het kunnen verbeteren.
Wanneer u Microsoft Azure Container Registry samen met Azure Kubernetes Service (AKS) gebruikt, moet er een verificatiemechanisme tot stand worden gebracht. U kunt de integratie van AKS naar Container Registry instellen met behulp van een paar eenvoudige Azure CLI- of Azure PowerShell-opdrachten. Met deze integratie wordt de AcrPull-rol toegewezen voor de kubelet-identiteit die is gekoppeld aan het AKS-cluster om installatiekopieën op te halen uit een containerregister.
In sommige gevallen mislukt het ophalen van installatiekopieën uit een containerregister naar een AKS-cluster. Dit artikel bevat richtlijnen voor het oplossen van de meest voorkomende fouten die optreden bij het ophalen van installatiekopieën uit een containerregister naar een AKS-cluster.
Voordat u begint
In dit artikel wordt ervan uitgegaan dat u een bestaand AKS-cluster en een bestaand containerregister hebt. Bekijk de volgende quickstarts:
Als u een AKS-cluster nodig hebt, implementeert u er een met behulp van de Azure CLI of Azure Portal.
Als u een Azure Container Registry (ACR) nodig hebt, maakt u er een met behulp van de Azure CLI of Azure Portal.
U hebt ook Azure CLI versie 2.0.59 of een nieuwere versie nodig om te worden geïnstalleerd en geconfigureerd. Voer az version uit om de versie te bepalen. Als u Azure CLI moet installeren of upgraden, raadpleegt u Azure CLI installeren.
Symptomen en eerste probleemoplossing
De status van de Kubernetes-pod is ImagePullBackOff of ErrImagePull. Voer de volgende opdracht uit en controleer gebeurtenissen uit de uitvoer om gedetailleerde foutinformatie op te halen.
kubectl describe pod <podname> -n <namespace>
Het is raadzaam om te beginnen met het oplossen van problemen door de status van het containerregister te controleren en te controleren of het containerregister toegankelijk is vanuit het AKS-cluster.
Voer de volgende opdracht uit om de status van het containerregister te controleren:
az acr check-health --name <myregistry> --ignore-errors --yes
Als er een probleem wordt gedetecteerd, bevat het een foutcode en beschrijving. Zie de naslaginformatie over statuscontrolefouten voor meer informatie over de fouten en mogelijke oplossingen.
Notitie
Als u helm-gerelateerde of notary-gerelateerde fouten krijgt, betekent dit niet dat een probleem van invloed is op Container Registry of AKS. Er wordt alleen aangegeven dat Helm of Notary niet is geïnstalleerd of dat Azure CLI niet compatibel is met de huidige geïnstalleerde versie van Helm of Notary, enzovoort.
Voer de volgende az aks check-acr-opdracht uit om te controleren of het containerregister toegankelijk is vanuit het AKS-cluster:
az aks check-acr --resource-group <MyResourceGroup> --name <MyManagedCluster> --acr <myacr>.azurecr.io
De volgende secties helpen u bij het oplossen van de meest voorkomende fouten die worden weergegeven in Gebeurtenissen in de uitvoer van de kubectl describe pod opdracht.
Oorzaak 1: Fout 401 Niet geautoriseerd
Voor een AKS-cluster is een identiteit vereist. Deze identiteit kan een beheerde identiteit of een service-principal zijn. Als het AKS-cluster een beheerde identiteit gebruikt, wordt de kubelet-identiteit gebruikt voor verificatie met ACR. Als het AKS-cluster als een identiteit een service-principal gebruikt, wordt de service-principal zelf gebruikt voor verificatie met ACR. Ongeacht wat de identiteit is, is de juiste autorisatie die wordt gebruikt voor het ophalen van een installatiekopie uit een containerregister nodig. Anders krijgt u mogelijk de volgende fout '401 Niet geautoriseerd':
Kan installatiekopie '<acrname.azurecr.io/< repository:tag>' niet ophalen: [rpc-fout: code = Onbekend desc = kan de afbeelding '<acrname.azurecr.io/>>< repository:tag>' niet ophalen en uitpakken: kan verwijzing '<acrname.azurecr.io/<> repository:tag>' niet oplossen: kan oauth-token niet ophalen: onverwachte status: 401 Niet geautoriseerd
Verschillende oplossingen kunnen u helpen deze fout op te lossen, afhankelijk van de volgende beperkingen:
Oplossingen 2, 3 en 5 zijn alleen van toepassing op AKS-clusters die gebruikmaken van een service-principal.
Oplossingen 1, 2, 3 en 4 zijn van toepassing op de Azure-methode voor het maken van de roltoewijzing op Container Registry-niveau voor de identiteit van AKS.
Oplossingen 5 en 6 zijn van toepassing op de Kubernetes-methode voor het ophalen van een Kubernetes-geheim.
Oplossing 1: Zorg ervoor dat de AcrPull-roltoewijzing is gemaakt voor identiteit
De integratie tussen AKS en Container Registry maakt een AcrPull-roltoewijzing op containerregisterniveau voor de kubelet-identiteit van het AKS-cluster. Zorg ervoor dat de roltoewijzing is gemaakt.
Gebruik een van de volgende methoden om te controleren of de AcrPull-roltoewijzing is gemaakt:
Voer de volgende opdracht uit:
az role assignment list --scope /subscriptions/<subscriptionID>/resourceGroups/<resourcegroupname>/providers/Microsoft.ContainerRegistry/registries/<acrname> -o tableControleer de Azure-portal door Roltoewijzingen voor Azure Container Registry-toegangsbeheer (IAM)> te selecteren.> Zie Azure-roltoewijzingen weergeven met behulp van Azure Portal voor meer informatie.
Naast de AcrPull-rol kunnen sommige ingebouwde rollen en aangepaste rollen ook de actie Microsoft.ContainerRegistry/registries/pull/read bevatten. Controleer deze rollen als u een van deze rollen hebt.
Als de AcrPull-roltoewijzing niet is gemaakt, maakt u deze door containerregisterintegratie voor het AKS-cluster te configureren met de volgende opdracht:
az aks update -n <myAKSCluster> -g <myResourceGroup> --attach-acr <acr-resource-id>
Oplossing 2: zorg ervoor dat de service-principal niet is verlopen
Zorg ervoor dat het geheim van de service-principal die is gekoppeld aan het AKS-cluster niet is verlopen. Voer de volgende opdrachten uit om de vervaldatum van uw service-principal te controleren:
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
Zie De vervaldatum van uw service-principal controleren voor meer informatie.
Als het geheim is verlopen, werkt u de referenties voor het AKS-cluster bij.
Oplossing 3: Zorg ervoor dat de AcrPull-rol is toegewezen aan de juiste service-principal
In sommige gevallen verwijst de toewijzing van de containerregisterrol nog steeds naar de oude service-principal. Als de service-principal van het AKS-cluster bijvoorbeeld wordt vervangen door een nieuwe. Voer de volgende stappen uit om ervoor te zorgen dat de roltoewijzing van het containerregister verwijst naar de juiste service-principal:
Voer de volgende opdracht uit om de service-principal te controleren die wordt gebruikt door het AKS-cluster:
az aks show --resource-group <myResourceGroup> \ --name <myAKSCluster> \ --query servicePrincipalProfile.clientId \ --output tsvVoer de volgende opdracht uit om de service-principal te controleren waarnaar wordt verwezen door de roltoewijzing van het containerregister:
az role assignment list --scope /subscriptions/<subscriptionID>/resourceGroups/<resourcegroupname>/providers/Microsoft.ContainerRegistry/registries/<acrname> -o tableVergelijk de twee service-principals. Als ze niet overeenkomen, integreert u het AKS-cluster opnieuw met het containerregister.
Oplossing 4: Zorg ervoor dat naar de kubelet-identiteit wordt verwezen in de AKS VMSS
Wanneer een beheerde identiteit wordt gebruikt voor verificatie met de ACR, wordt de beheerde identiteit de kubelet-identiteit genoemd. Standaard wordt de kubelet-identiteit toegewezen op het niveau van AKS VMSS. Als de kubelet-identiteit wordt verwijderd uit de AKS VMSS, kunnen de AKS-knooppunten geen installatiekopieën ophalen uit de ACR.
Voer de volgende opdracht uit om de kubelet-identiteit van uw AKS-cluster te vinden:
az aks show --resource-group <MyResourceGroup> --name <MyManagedCluster> --query identityProfile.kubeletidentity
Vervolgens kunt u de identiteiten van de AKS VMSS weergeven door de VMSS te openen vanuit de knooppuntresourcegroep en de id-gebruiker te selecteren die is toegewezen in Azure Portal of door de volgende opdracht uit te voeren:>
az vmss identity show --resource-group <NodeResourceGroup> --name <AksVmssName>
Als de kubelet-identiteit van uw AKS-cluster niet is toegewezen aan de AKS VMSS, wijst u deze weer toe.
Notitie
Het wijzigen van de AKS VMSS met behulp van de IaaS-API's of de Azure-portal wordt niet ondersteund en er kan geen AKS-bewerking de kubelet-identiteit verwijderen uit de AKS VMSS. Dit betekent dat iets onverwachts is verwijderd, bijvoorbeeld een handmatige verwijdering uitgevoerd door een teamlid. Als u dergelijke verwijdering of wijziging wilt voorkomen, kunt u overwegen de NRGLockdown-functie te gebruiken.
Omdat wijzigingen in de AKS VMSS niet worden ondersteund, worden ze niet doorgegeven op AKS-niveau. Als u de kubelet-identiteit opnieuw wilt toewijzen aan de AKS VMSS, is een afstemmingsbewerking nodig. Voer hiervoor de volgende opdracht uit:
az aks update --resource-group <MyResourceGroup> --name <MyManagedCluster>
Oplossing 5: Controleer of de service-principal juist is en of het geheim geldig is
Als u een installatiekopie ophaalt met behulp van een pull-geheim voor afbeeldingen en dat Kubernetes-geheim is gemaakt met behulp van de waarden van een service-principal, controleert u of de bijbehorende service-principal juist is en het geheim nog steeds geldig is. Volg vervolgens deze stappen:
Voer de volgende kubectl get - en base64-opdracht uit om de waarden van het Kubernetes-geheim te bekijken:
kubectl get secret <secret-name> --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decodeControleer de vervaldatum door de volgende opdracht az ad sp credential list uit te voeren. De gebruikersnaam is de waarde van de service-principal.
az ad sp credential list --id "<username>" --query "[].endDate" --output tsvStel indien nodig het geheim van die service-principal opnieuw in door de volgende opdracht az ad sp credential reset uit te voeren:
az ad sp credential reset --name "$SP_ID" --query password --output tsvWerk het Kubernetes-geheim dienovereenkomstig bij of maak het opnieuw.
Oplossing 6: Zorg ervoor dat het Kubernetes-geheim de juiste waarden heeft van het beheerdersaccount van het containerregister
Als u een installatiekopie ophaalt met behulp van een pull-geheim voor installatiekopieën en dat Kubernetes-geheim is gemaakt met behulp van waarden van het containerregisterbeheerdersaccount, moet u ervoor zorgen dat de waarden in het Kubernetes-geheim hetzelfde zijn als de waarden van het containerregisterbeheerdersaccount. Volg vervolgens deze stappen:
Voer de volgende kubectl get - en base64-opdracht uit om de waarden van het Kubernetes-geheim te bekijken:
kubectl get secret <secret-name> --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decodeZoek en selecteer containerregisters in Azure Portal.
Selecteer uw containerregister in de lijst met containerregisters.
Selecteer Toegangssleutels in het navigatiedeelvenster voor het containerregister.
Vergelijk op de pagina Toegangssleutels voor het containerregister de waarden van het containerregister met de waarden in het Kubernetes-geheim.
Als de waarden niet overeenkomen, werkt u het Kubernetes-geheim bij of maakt u het opnieuw.
Notitie
Als er een bewerking wachtwoord opnieuw genereren is opgetreden, wordt een bewerking met de naam Aanmeldingsreferenties voor containerregister opnieuw genereren weergegeven op de pagina Activiteitenlogboek van het containerregister. Het activiteitenlogboek heeft een bewaarperiode van 90 dagen.
Oorzaak 2: Fout bij afbeelding niet gevonden
Kan installatiekopie '<acrname.azurecr.io/<> repository:tag>' niet ophalen: [rpc-fout: code = NotFound desc = kan de afbeelding '<acrname.azurecr.io/> repository:tag>' niet ophalen en uitpakken: kan verwijzing acrname.azurecr.io/<>< repository:tag> niet oplossen:< acrname.azurecr.io/><< repository:tag>: niet gevonden
Oplossing: Controleer of de naam van de installatiekopieën juist is
Als u deze fout ziet, controleert u of de naam van de installatiekopieën volledig juist is. Controleer de registernaam, de aanmeldingsserver van het register, de naam van de opslagplaats en de tag. Een veelvoorkomende fout is dat de aanmeldingsserver is opgegeven als 'azureacr.io' in plaats van 'azurecr.io'.
Als de naam van de installatiekopie niet volledig juist is, kan de fout 401 Niet-geautoriseerd ook optreden omdat AKS altijd anonieme pull-pogingen probeert, ongeacht of het containerregister anonieme pull-toegang heeft ingeschakeld.
Oorzaak 3: Fout 403 Verboden
Kan afbeelding '<acrname.azurecr.io/< repository:tag>' niet ophalen: rpc-fout: code = Onbekend desc = kan installatiekopie "<acrname.azurecr.io/>>< repository:tag>" niet ophalen en uitpakken: kan verwijzing '<acrname.azurecr.io/<> repository:tag>' niet oplossen: kan anonieme token niet ophalen: onverwachte status: 403 Verboden
Oplossing 1: Zorg ervoor dat de koppeling van het virtuele AKS-netwerk is ingesteld in de Privé-DNS zone van het containerregister
Als de netwerkinterface van het privé-eindpunt van het containerregister en het AKS-cluster zich in verschillende virtuele netwerken bevinden, moet u ervoor zorgen dat de virtuele netwerkkoppeling voor het virtuele netwerk van het AKS-cluster is ingesteld in de Privé-DNS zone van het containerregister. (Deze koppeling heeft standaard de naam 'privatelink.azurecr.io'.) Als de koppeling van het virtuele netwerk zich niet in de Privé-DNS zone van het containerregister bevindt, voegt u deze toe op een van de volgende manieren:
Selecteer in Azure Portal de privé-DNS-zone 'privatelink.azurecr.io', selecteer Virtuele netwerkkoppelingen>toevoegen in het deelvenster Instellingen en selecteer vervolgens een naam en het virtuele netwerk van het AKS-cluster. Selecteer OK.
Notitie
Het is optioneel om de functie Automatische registratie inschakelen te selecteren.
Maak een virtuele netwerkkoppeling naar de opgegeven Privé-DNS zone met behulp van Azure CLI.
Oplossing 2: Voeg het openbare IP-adres van AKS Load Balancer toe aan het toegestane IP-adresbereik van het containerregister
Als het AKS-cluster openbaar verbinding maakt met het containerregister (NIET via een privékoppeling of eindpunt) en de toegang tot het openbare netwerk van het containerregister beperkt is tot geselecteerde netwerken, voegt u het openbare IP-adres van AKS Load Balancer toe aan het toegestane IP-adresbereik van het containerregister:
Controleer of de openbare netwerktoegang is beperkt tot geselecteerde netwerken.
Navigeer in Azure Portal naar het containerregister. Selecteer Netwerken onder Instellingen. Op het tabblad Openbare toegang is openbare netwerktoegang ingesteld op Geselecteerde netwerken of Uitgeschakeld.
Verkrijg het openbare IP-adres van de AKS Load Balancer op een van de volgende manieren:
Navigeer in Azure Portal naar het AKS-cluster. Selecteer onder Instellingen eigenschappen, selecteer een van de virtuele-machineschaalsets in de infrastructuurresourcegroep en controleer het openbare IP-adres van de AKS Load Balancer.
Voer de volgende opdracht uit:
az network public-ip show --resource-group <infrastructure-resource-group> --name <public-IP-name> --query ipAddress -o tsv
Toegang vanaf het openbare IP-adres van de AKS Load Balancer toestaan op een van de volgende manieren:
Voer de opdracht als volgt uit
az acr network-rule add:az acr network-rule add --name acrname --ip-address <AKS-load-balancer-public-IP-address>Zie Netwerkregel toevoegen aan register voor meer informatie.
Navigeer in Azure Portal naar het containerregister. Selecteer Netwerken onder Instellingen. Voeg op het tabblad Openbare toegang onder Firewall het openbare IP-adres van de AKS Load Balancer toe aan het adresbereik en selecteer Opslaan. Zie Access vanuit het geselecteerde openbare netwerk - portal voor meer informatie.
Notitie
Als openbare netwerktoegang is ingesteld op Uitgeschakeld, schakelt u deze eerst over naar Geselecteerde netwerken .
Oorzaak 4: 'time-outfout voor i/o'
Kan afbeelding '<acrname.azurecr.io/>< repository:tag>' niet ophalen: rpc-fout: code = Onbekend desc = kan afbeelding '<acrname.azurecr.io/>< repository:tag' niet ophalen en uitpakken: kan verwijzing '<acrname>.'> niet oplossen azurecr.io/< repository:tag>": kan aanvraag niet uitvoeren: Hoofd "https://< acrname.azurecr.io/v2/<> repository>/manifests/v1": dial tcp <acrprivateipaddress>:443: i/o timeout
Notitie
De fout 'i/o time-out' treedt alleen op wanneer u privé verbinding maakt met een containerregister met behulp van Azure Private Link.
Oplossing 1: Zorg ervoor dat peering van virtuele netwerken wordt gebruikt
Als de netwerkinterface van het privé-eindpunt van het containerregister en het AKS-cluster zich in verschillende virtuele netwerken bevinden, moet u ervoor zorgen dat peering van virtuele netwerken wordt gebruikt voor beide virtuele netwerken. U kunt peering van virtuele netwerken controleren door de Azure CLI-opdracht az network vnet peering list --resource-group <MyResourceGroup> --vnet-name <MyVirtualNetwork> --output table of in Azure Portal uit te voeren door de VNET's-peerings> te selecteren onder het deelvenster Instellingen. Zie az network vnet peering list voor meer informatie over het weergeven van alle peerings van een opgegeven virtueel netwerk.
Als de peering van het virtuele netwerk wordt gebruikt voor beide virtuele netwerken, controleert u of de status Verbonden is. Als de status Verbinding verbreken is, verwijdert u de peering uit beide virtuele netwerken en maakt u deze opnieuw. Als de status Verbonden is, raadpleegt u de probleemoplossingsgids: De peeringstatus is Verbonden.
Voor verdere probleemoplossing maakt u verbinding met een van de AKS-knooppunten of -pods en test u vervolgens de verbinding met het containerregister op TCP-niveau met behulp van het hulpprogramma Telnet of Netcat. Controleer het IP-adres met de nslookup <acrname>.azurecr.io opdracht en voer de telnet <ip-address-of-the-container-registry> 443 opdracht uit.
Zie Verbinding maken met SSH met AKS-clusterknooppunten (Azure Kubernetes Service) voor onderhoud of probleemoplossing voor meer informatie over het maken van verbinding met AKS-knooppunten.
Oplossing 2: Azure Firewall Service gebruiken
Als de netwerkinterface van het privé-eindpunt van het containerregister en het AKS-cluster zich in verschillende virtuele netwerken bevinden, kunt u naast peering van virtuele netwerken Azure Firewall Service gebruiken om een sternetwerktopologie in Azure in te stellen. Wanneer u de firewallregel instelt, moet u netwerkregels gebruiken om expliciet de uitgaande verbinding met de privé-eindpuntadressen van het containerregister toe te staan.
Oorzaak 5: Geen overeenkomst voor platform in manifest
Het hostbesturingssysteem (knooppuntbesturingssysteem) is niet compatibel met de installatiekopie die wordt gebruikt voor de pod of container. Als u bijvoorbeeld een pod plant om een Linux-container uit te voeren op een Windows-knooppunt of een Windows-container op een Linux-knooppunt, treedt de volgende fout op:
Kan de installatiekopie '<acrname.azurecr.io/>< repository:tag>' niet ophalen:
[
rpc-fout:
code = NotFound
desc = kan de installatiekopie "<acrname.azurecr.io/>< repository:tag>" niet ophalen en uitpakken: geen overeenkomst voor platform in manifest: niet gevonden,
]
Deze fout kan optreden voor een installatiekopie die wordt opgehaald uit elke bron, zolang de installatiekopie niet compatibel is met het host-besturingssysteem. De fout is niet beperkt tot installatiekopieën die worden opgehaald uit het containerregister.
Oplossing: Configureer het veld nodeSelector correct in uw pod of implementatie
Geef het juiste nodeSelector veld op in de configuratie-instellingen van uw pod of implementatie. De juiste waarde voor de instelling van kubernetes.io/os dit veld zorgt ervoor dat de pod wordt gepland op het juiste type knooppunt. In de volgende tabel ziet u hoe u de kubernetes.io/os instelling instelt in YAML:
| Containertype | YAML-instelling |
|---|---|
| Linux-container | "kubernetes.io/os": linux |
| Windows-container | "kubernetes.io/os": windows |
In de volgende YAML-code wordt bijvoorbeeld een pod beschreven die moet worden gepland op een Linux-knooppunt:
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
Meer informatie
Als de richtlijnen voor probleemoplossing in dit artikel u niet helpen het probleem op te lossen, kunt u het volgende overwegen:
Controleer de netwerkbeveiligingsgroepen en routetabellen die zijn gekoppeld aan subnetten als u een van deze items hebt.
Als een virtueel apparaat, zoals een firewall, het verkeer tussen subnetten beheert, controleert u de firewall en firewalltoegangsregels.
Disclaimerinformatie van derden
De producten van derden die in dit artikel worden vermeld, worden vervaardigd door bedrijven die onafhankelijk zijn van Microsoft. Microsoft verleent dan ook geen enkele garantie, impliciet noch anderszins, omtrent de prestaties of de betrouwbaarheid van deze producten.
Contacteer ons voor hulp
Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.