Geo-replicatie in Azure Container Registry

Door geo-replicatie in te schakelen voor een Azure Container Registry (ACR), worden resources voor geo-replica's aangemaakt in Azure-regio's naar keuze. Wanneer u afbeeldingen naar een register gerepliceerd op geo-niveau pusht, wordt de inhoud automatisch gesynchroniseerd met alle geografische replica's.

Met geo-replicatie:

• Eén register beheren: beheer één set referenties, roltoewijzingen, netwerkregels en registerconfiguratie voor alle geo-replica's.
• Gebruik één globaal eindpunt: Verwijs naar myregistry.azurecr.io/myimage:tag in al uw builds en implementaties. Azure routeert aanvragen naar de geo-replica met het beste netwerkprestatieprofiel voor de client. Dit is meestal de dichtstbijzijnde geo-replica. Als de client echter op gelijke afstand van meerdere geo-replica's is, of als de dichtstbijzijnde geo-replica niet beschikbaar is, kunnen verzoeken elders worden gerouteerd.
• Automatische synchronisatie: tags en digests één keer pushen; ACR repliceert inhoud en metagegevens naar alle geo-replica's.

Voor geo-replicatie is de Premium-SKU vereist.

Overwegingen voor hoge beschikbaarheid

Replicatiemodel

ACR geo-replicatie maakt gebruik van een actief-actief model.

• Alle geo-replica's zijn actief en beschrijfbaar. U kunt afbeeldingen pushen, ophalen en verwijderen uit elke geo-replica, niet alleen de geo-replica van de basisregio.
• Dit verschilt van primaire-secundaire replicatiemodellen waarbij slechts één regio schrijfbewerkingen accepteert en secundaire regio's passief zijn.

Consistentiemodel

ACR maakt gebruik van uiteindelijke consistentie.

• Nadat u een afbeelding in een geo-replica hebt gepusht of verwijderd, repliceert ACR uiteindelijk de wijziging naar alle geo-replica's op de achtergrond.
• De replicatietijd is afhankelijk van de grootte van de image. Een gepushte image of tag is mogelijk niet direct beschikbaar om te worden opgehaald in andere georeplica's als grote aantallen images of images met een grote omvang worden gepusht. Op dezelfde manier is een verwijderde afbeelding of tag mogelijk nog steeds beschikbaar voor het ophalen van andere geo-replica's totdat het verwijderen is doorgevoerd.
• De tijd die nodig is om een nieuwe geo-replica te maken, schaalt met de totale grootte van het register. Bij het maken van een nieuwe geo-replica blijven bestaande geo-replica's push-, pull- en deleteverkeer normaal verwerken. Er is geen beperkte toestand of degradatieperiode terwijl de nieuwe geo-replica op de achtergrond wordt gesynchroniseerd.
• Totdat de replicatie uiteindelijk op de achtergrond is voltooid, heeft een geo-replica mogelijk niet de meest recente inhoud of metagegevens. U kunt webhooks gebruiken om meldingen te ontvangen wanneer replicatie voor een specifieke gepushte afbeelding in elke geo-replica is voltooid.

Hoge beschikbaarheid van het datavlak

Geo-replicatie verbetert de beschikbaarheid van het datavlak door images in meerdere regio's te bewaren. Als één regio een storing heeft, blijven afbeeldingen toegankelijk vanuit andere geo-replica's: pushen, ophalen en verwijderen blijven werken via de resterende geo-replica's.

Zoneredundantie is altijd ingeschakeld voor geo-replica's: ACR verspreidt automatisch replicagegevens over meerdere beschikbaarheidszones om te beschermen tegen zonestoringen.

Statusbewuste failover

ACR bewaakt automatisch de status van elke geo-replica en routeert globaal eindpuntverkeer weg van geo-replica's die aanvragen niet betrouwbaar kunnen verwerken. Dit wordt statusbewuste failover genoemd. ACR routeert globaal eindpuntverkeer op basis van de status van de ACR-service en Azure regionale infrastructuurstatus.

• Automatisch en per register: Status wordt per register geëvalueerd, niet per regio. Als een verslechtering alleen van invloed is op een subset van registers in een regio, worden alleen die registers opnieuw omgeleid. Andere registers in dezelfde regio blijven lokaal worden geleverd zonder onnodige latentiestraf.
• Timing: End-to-end-omleiding duurt in de orde van enkele minuten, snel genoeg om echte regionale degradatie te detecteren en traag genoeg om tijdelijke fouten die vanzelf verdwijnen uit te zitten. DNS TTL kan voor extra vertraging in de propagatie zorgen voordat alle clientsystemen naar de nieuwe regio overschakelen.
• Er is geen klantactie vereist: er is geen door de klant aanroepbare trigger. Statusbewuste failover wordt volledig door het platform beheerd.
• Failback is automatisch: zodra de regionale statusevaluatie van een geo-replica opnieuw is geslaagd, bijvoorbeeld wanneer regionale ACR- of Azure-infrastructuur wordt hersteld, kan het globale eindpunt het routeren van verkeer naar de geo-replica in de herstelde Azure regio hervatten.
• Niet geactiveerd door bandbreedtebeperking: Statusafhankelijke failover is gebaseerd op DNS en reageert op de status van de regionale ACR-service en de Azure-infrastructuurstatus. Het leidt verkeer niet om op basis van HTTP 429-reacties (throttling). Als een geo-replica uw aanvragen afremt, maar de infrastructuur van de regio in orde is, blijft het globale eindpunt u naar die geo-replica routeren. Om throttling te beheren, gebruikt u regionale eindpunten om workloads over meerdere geo-replica's te verdelen voor een betere capaciteitsverdeling.

Bereik van statusbewuste failover:

Statusafhankelijke failover is alleen van toepassing op bewerkingen op het globale eindpunt (myregistry.azurecr.io). Deze is niet van toepassing op:

• Regionale eindpunten : wanneer u een regionaal eindpunt (myregistry.<region>.geo.azurecr.io) gebruikt, praat u rechtstreeks met één specifieke geo-replica. Als deze regio verslechtert, wordt ACR niet automatisch omgeleid. Implementeer failover aan de clientzijde door over te schakelen naar een ander regionaal eindpunt.
• Toegewezen gegevenseindpunten : zodra een registereindpunt u omleidt naar een toegewezen gegevenseindpunt voor het downloaden van een laag, blijft u tijdens het downloaden op het gegevenseindpunt van die regio. De regio wordt vooraf bepaald door het registerendpoint dat de aanroep voor de bloblocatie heeft afgehandeld.

Snelheidsbeperking tijdens failover:

Beperkingslimieten voor API-bewerkingen zijn per replica. Tijdens een statusafhankelijke failover kan verkeer dat over meerdere geo-replica's was verspreid, zich in sterke mate verplaatsen naar de geo-replica's die in de routeringspool van het globale eindpunt overblijven. Capaciteitsplan voor ten minste twee of drie geo-replica's, zodat verkeer zich kan verspreiden over meerdere gezonde geo-replica's tijdens een failover. Registries met slechts twee regio's kunnen gemakkelijker de throttlinglimieten per replica bereiken wanneer één regio niet beschikbaar is. U kunt dit beperken door regionale eindpunten te gebruiken om workloads over meerdere geo-replica's te verdelen en capaciteit per replica te plannen.

Een failover bevestigen:

• Azure portal: Navigeer naar het register en selecteer Resourcestatus onder de sectie Help om de degradatiesignalen aan de platformzijde te bekijken.
• Azure CLI: controleer de replicatiestatus met az acr replication list --registry myregistry --output table. Geo-replica's die problemen ondervinden, geven een andere status weer dan online.
• Azure Monitor: metrische platformgegevens worden automatisch verzameld. Schakel Diagnostische instellingen in voor resourcelogboeken om gedetailleerde telemetrie te verkrijgen.

Gedrag bij onderbreking in hoofdregio

De basisregio is de regio waarin u het register oorspronkelijk hebt gemaakt. Het host het besturingsvlak van het register, waarmee de registerconfiguratie wordt beheerd. De thuisregio is bij het maken vast en kan daarna niet meer worden gewijzigd. Als u een register naar een andere thuisregio wilt verplaatsen, raadpleegt u Azure Container Registry verplaatsen. Daarin wordt een procedure voor herimplementatie beschreven (waarbij een nieuw register wordt gemaakt), niet een wijziging ter plaatse.

Als de thuisregio niet meer beschikbaar is, is het effect beperkt tot besturingsvlakbewerkingen (beheerbewerkingen). Alle gegevensvlakbewerkingen blijven werken via de resterende geo-replica's.

Wat blijft werken tijdens een storing in de thuisregio:

• Installatiekopieën pushen, pullen en verwijderen — Clients kunnen installatiekopieën pushen, pullen en verwijderen vanaf elke beschikbare geo-replica met behulp van het globale eindpunt (myregistry.azurecr.io) of elk beschikbaar regionaal eindpunt (myregistry.<region>.geo.azurecr.io). ACR stuurt globale eindpuntaanvragen automatisch naar een goede geo-replica.
• Authenticatie — Alle authenticatiemethoden blijven functioneren, waaronder Microsoft Entra ID, service-principals, beheerde identiteiten en tokens met opslagplaatsbereik. Klanten kunnen zich authenticeren bij elke beschikbare geo-replica zonder hun inloggegevens, tokens of register-URL's te hoeven wijzigen.
• Webhooklevering : webhooks die zijn geconfigureerd voor beschikbare geo-replica's blijven geactiveerd. Één push resulteert in webhook-gebeurtenissen van de ontvangende geo-replica en in gebeurtenissen van elke geo-replica zodra de replicatie is voltooid. Webhook-consumenten moeten zodanig worden ontworpen dat ze meerdere gebeurtenissen per gepushte containerimage kunnen verwerken en deze zo nodig kunnen dedupliceren.
• Regionale eindpunten : als regionale eindpunten zijn ingeschakeld, blijven ze onafhankelijk werken. Clients kunnen rechtstreeks communiceren met specifieke geo-replica's met behulp van regionale eindpunt-URL's.

Wat is er niet beschikbaar tijdens een storing in de thuisregio:

• Globale eindpuntroutering naar de geo-replica van de basisregio : de statusdetectie van ACR stopt automatisch het routeren van globaal eindpuntverkeer naar de geo-replica van de thuisregio en leidt deze om naar gezonde geo-replica's.
• Regionaal eindpunt voor de thuisregio : het regionale eindpunt () van de thuisregio (myregistry.<home-region>.geo.azurecr.io) is niet beschikbaar terwijl de thuisregio uitvalt. Regionale eindpunten voor andere geo-replica's blijven onafhankelijk werken.
• Wijzigingen in registerconfiguratie : u kunt registereigenschappen, zoals netwerkregels, replicatie-instellingen of configuraties van beschikbaarheidszones, pas wijzigen als de basisregio wordt hersteld.
• ACR Tasks : taken zijn gebonden aan de basisregio en worden niet uitgevoerd terwijl deze niet beschikbaar is.

Overwegingen voor servicelagen en limieten

Azure Container Registry servicelagen en -limieten zijn onafhankelijk van toepassing op elke geo-replica.

Bepaalde servicelaaglimieten hebben de volgende speciale overweging:

• Opslaglimieten: opslaglimieten voor uw servicelaag worden gedeeld in alle geo-replica's. Als u bijvoorbeeld een image van 1 GiB pusht en deze wordt gerepliceerd naar 5 geografische replica's, wordt slechts 1 GiB meegeteld voor de maximale opslaglimieten van uw prijscategorie.
• API-frequentielimieten: beperkingslimieten voor API-bewerkingen, zoals het aantal lees- en schrijfbewerkingen per minuut, zijn geografisch replicaspecifiek. Gebruik regionale eindpunten om workloads over meerdere geo-replica's te verdelen voor een betere capaciteitsdistributie en om te voorkomen dat al het verkeer op één geo-replica wordt geconcentreerd.

Zie ACR-servicelagen voor meer informatie over servicelagen en limieten.

Prijsoverwegingen

• Facturering voor opslag: Opslag wordt gefactureerd per geo-replica. Een image van 1 GiB die naar 5 geo-replica's is gerepliceerd, wordt bijvoorbeeld gefactureerd als 5 GiB opslag (1 GiB × 5 geo-replica's).
• Gegevensoverdracht: Geo-replicatie kan kosten verlagen door pushes en pulls in de regio in te schakelen, waardoor kosten voor gegevensoverdracht tussen regio's worden voorkomen tijdens deze push- of pull-bewerkingen. Kosten voor gegevensoverdracht tussen regio's zijn echter nog steeds van toepassing wanneer ACR gepushte inhoud repliceert naar andere geo-replica's als onderdeel van uiteindelijke consistentie.

Zie ACR-prijzen voor meer informatie.

Geo-replica's toevoegen of verwijderen

Benodigde machtigingen

Voor het beheren van geo-replica's heeft uw identiteit de volgende machtigingen nodig:

Azure Portal

1. Ga naar uw register in Azure Portal.
2. Onder Services, selecteer geo-replicaties.
3. Op de kaart:
   • Blauwe zeshoek: Thuisregio (waar u het register hebt gemaakt)
   • Groene zeshoeken: Beschikbare regio's
   • Grijze zeshoeken: Niet beschikbare regio's
4. Selecteer een groene zeshoek en selecteer Maken vervolgens.

Azure CLI

# Create a replica
az acr replication create --registry myregistry --location eastus

# List replicas
az acr replication list --registry myregistry --output table

# Delete a replica
az acr replication delete --registry myregistry --name eastus

Zie az acr replication voor meer opdrachten.

Globaal eindpunt van een geo-gerepliceerd register

Nadat u geo-replicatie hebt geconfigureerd, kunt u inhoud in uw register pushen, ophalen of verwijderen via het globale eindpunt van het register (myregistry.azurecr.io).

Hoe globale eindpunten werken

Wanneer u via het globale eindpunt pusht, pullt of verwijdert, leidt ACR de aanvraag naar de geo-replica met het beste netwerkprestatieprofiel voor de client.

• De geo-replica met het beste netwerkprestatieprofiel van de client is meestal de dichtstbijzijnde geo-replica.
• Als de client echter op gelijke afstand van meerdere geo-replica's is, of als de dichtstbijzijnde geo-replica niet beschikbaar is, kunnen verzoeken elders worden gerouteerd.
• ACR beheert deze routering. U bepaalt niet welke geo-replica een specifieke aanvraag verwerkt.

Het globale eindpunt gebruiken

Verifiëren:

az acr login --name myregistry

Een afbeelding taggen en pushen:

docker tag myapp:v1 myregistry.azurecr.io/myapp:v1
docker push myregistry.azurecr.io/myapp:v1

Een afbeelding ophalen:

docker pull myregistry.azurecr.io/myapp:v1

Een afbeelding importeren:

az acr import \
  --name myregistry \
  --source mcr.microsoft.com/hello-world:latest \
  --image hello-world:latest

Kubernetes-implementatiemanifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myregistry.azurecr.io/myapp:v1

Een geo-replica tijdelijk uitsluiten van globale eindpuntroutering

U kunt een geo-replica uitsluiten van globale eindpuntroutering door de --global-endpoint-routing instelling voor een specifieke geo-replica uit te schakelen. Dit is handig voor onderhoud of probleemoplossing, of wanneer u weet dat een specifieke geo-replica of Azure regio degradatie ondervindt. U kunt zelfs globale eindpuntroutering uitschakelen voor de geo-replica van de thuisregio. De basisregio wordt alleen gebruikt voor besturingsvlakbewerkingen en het gegevensvlakverkeer kan veilig worden uitgesloten van globale routering. Zie Gedrag bij uitval van de basisregio voor meer informatie over waar de basisregio invloed op heeft.

• Wanneer de --global-endpoint-routing instelling voor een specifieke geo-replica is ingesteld op false, stopt ACR de routering van aanvragen naar die specifieke geo-replica voor aanvragen die naar het globale eindpunt gaan.
• Gegevens worden in twee richtingen gesynchroniseerd met een geo-replica, zelfs als globale eindpuntroutering is uitgeschakeld voor die specifieke geo-replica. Elke image die vanuit welke regio dan ook naar het register wordt gepusht terwijl de geo-replica is uitgesloten van globale routering, wordt er nog steeds naartoe gerepliceerd. Wanneer u de geo-replica opnieuw inschakelt, is deze direct klaar om verkeer te verwerken zonder inhaalvenster.
• Als zodanig blijven het opslagquotum en de kosten oplopen voor die geo-replica.
• Als regionale eindpunten zijn ingeschakeld, blijft de regionale eindpunt-URL (myregistry.<region-name>.geo.azurecr.io) van de geo-replica werken, zelfs als globale eindpuntroutering is uitgeschakeld. --global-endpoint-routing bepaalt alleen de deelname van de geo-replica aan globale eindpuntroutering.

# Exclude a geo-replica from global endpoint routing
az acr replication update --registry myregistry --name eastus \
  --global-endpoint-routing false

# Re-enable a geo-replica in global endpoint routing
az acr replication update --registry myregistry --name eastus \
  --global-endpoint-routing true

Regionale eindpunten van een geo-gerepliceerd register (preview)

Regionale eindpunten bieden u toegewezen URL's voor elke replica, zodat u precies kunt opgeven welke regionale geo-replica uw push-, pull- of verwijderaanvraag afhandelt:

• myregistry. eastus.geo.azurecr.io
• myregistry. westeurope.geo.azurecr.io

Gebruik regionale eindpunten wanneer u het volgende nodig hebt:

Regionale eindpunten bestaan naast globale eindpunten

Als u regionale eindpunten inschakelt, wordt het globale eindpunt niet uitgeschakeld of vervangen. U kunt beide tegelijk gebruiken:

• Gebruik het globale eindpunt (myregistry.azurecr.io) als u de voorkeur geeft aan automatische routering die wordt beheerd door Azure in geo-replica's.
• Gebruik regionale eindpunten (myregistry.<region-name>.geo.azurecr.io) als u een nauwkeuriger routeringsbeheer aan de clientzijde wilt, waarbij Azure beheerde routering van het globale eindpunt volledig wordt overgeslagen.

Hoe regionale eindpunten werken

Regionale eindpunten fungeren als inlogservers voor specifieke geo-replica's. Wanneer u een regionaal eindpunt verifieert en ermee communiceert in plaats van het globale eindpunt van het register, gaan al uw registerbewerkingen (verificatie, artefactuploads/downloads, opslagplaatsbewerkingen en metagegevensacties) rechtstreeks naar die specifieke regionale replica, waarbij Azure beheerde routering volledig wordt overgeslagen.

Downloads van laag-blobs (de daadwerkelijke lagen van containerimages) volgen nog steeds de bestaande configuratie van uw register:

• Registers zonder privé-eindpunten of toegewezen gegevenseindpunten: wanneer u afbeeldingslagen downloadt van een specifieke geo-replica, worden laag-blob-downloads omgeleid naar Azure opslagaccounts (*.blob.core.windows.net).
• Registers met privé-eindpunten of toegewezen gegevenseindpunten ingeschakeld: wanneer u afbeeldingslagen downloadt van een specifieke geo-replica, worden laag-blob-downloads omgeleid naar het toegewezen gegevenseindpunt van de bijbehorende regio (myregistry.<region-name>.data.azurecr.io).

In het volgende diagram ziet u de stroom voor regionale eindpuntaanvragen:

Vereisten voor regionale eindpunten

• Premium-SKU : regionale eindpunten zijn exclusief beschikbaar in premium-laagregisters.
• Azure CLI — versie 2.86.0 of hoger. Alle opdrachten voor regionale eindpunten (--regional-endpoints, az acr show-endpoints, az acr login --endpoint) zijn standaard beschikbaar in Azure CLI 2.86.0+.

az extension remove --name acrregionalendpoint

az extension list --query "[?name=='acrregionalendpoint']" -o table

Regionale eindpunten inschakelen

U kunt regionale eindpunten inschakelen wanneer u een nieuw register maakt of een bestaand register bijwerkt.

Maak een nieuw register waarvoor regionale eindpunten zijn ingeschakeld:

az acr create \
  -n myregistry \
  -g myrg \
  -l regionname \
  --sku Premium \
  --regional-endpoints enabled

Regionale eindpunten inschakelen in een bestaand register:

az acr update \
  -n myregistry \
  -g myrg \
  --regional-endpoints enabled

Regionale eindpunten zijn ingeschakeld op registerniveau en zijn van toepassing op elke geo-replica. U kunt geen regionale eindpunten inschakelen voor afzonderlijke replica's. Wanneer u regionale eindpunten inschakelt, maakt Azure Container Registry automatisch URL's voor aanmeldingsservers voor elk van uw geo-replica's.

Werken met regionale eindpunten

Regionale eindpunten verifiëren en gebruiken

Regionale eindpunten ondersteunen dezelfde verificatiemethoden als het globale eindpunt: Microsoft Entra ID, service-principals, beheerde identiteiten en beheerdersreferenties.

Meld u aan bij een specifiek regionaal eindpunt:

az acr login --name myregistry --endpoint eastus

Een afbeelding taggen en pushen naar een regionaal eindpunt. Afbeeldingen en tags die via het regionale eindpunt naar een geo-replica worden gepusht, worden nog steeds doorgegeven aan alle andere geo-replica's onder uiteindelijke consistentie.

docker tag myapp:v1 myregistry.eastus.geo.azurecr.io/myapp:v1
docker push myregistry.eastus.geo.azurecr.io/myapp:v1

Een image ophalen vanaf een regionaal endpoint:

docker pull myregistry.eastus.geo.azurecr.io/myapp:v1

Regiospecifieke eindpunten gebruiken met authenticatie via een door AKS beheerde identiteit

AKS-imagepulls die zich bij ACR verifiëren met behulp van een beheerde identiteit, ondersteunen regionale eindpunten op AKS-knooppuntinstallatiekopie 202607.29 of later. Controleer de huidige image van elke knooppuntgroep:

az aks nodepool show \
  --resource-group <resource-group> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --query nodeImageVersion \
  --output tsv

Als u automatisch een compatibele node-image-VHD wilt ontvangen nadat deze beschikbaar is in uw regio en cloud, gebruikt u het NodeImagekanaal voor automatische upgrade van het besturingssysteem van knooppunten. AKS Automatic gebruikt NodeImage; selecteer voor AKS Standard NodeImage.

az aks update \
  --resource-group <resource-group> \
  --name <cluster-name> \
  --node-os-upgrade-channel NodeImage

Voor AKS-knooppunten met een oudere image gebruikt u een Kubernetes-image pull secret wanneer u images ophaalt vanaf regionale eindpunten, of verwijst u in plaats daarvan naar het globale eindpunt (<registry-name>.azurecr.io).

Regionale eindpunten gebruiken die zijn ingesloten in implementatiemanifesten

U kunt regionale eindpunten rechtstreeks in Kubernetes-implementatiemanifesten opgeven als u workloads wilt vastmaken aan specifieke regio's. Dit zorgt ervoor dat clusters in bepaalde regio's altijd gebruikmaken van hun replica op dezelfde locatie, wat voorspelbare routering en lagere latentie oplevert.

Clusterimplementatie US - oost:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-eastus
spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myregistry.eastus.geo.azurecr.io/myapp:v1

Implementatie van het cluster in West-Europa:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-westeurope
spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myregistry.westeurope.geo.azurecr.io/myapp:v1

Door verschillende regionale eindpunten in de manifesten van elk cluster te gebruiken, kunt u ervoor kiezen om ervoor te zorgen dat elk cluster wordt opgehaald uit de lokale replica in plaats van te vertrouwen op Azure beheerde routering.

Zie Authenticate with Azure Container Registry from Azure Kubernetes Service voor meer informatie over het verifiëren van Azure Kubernetes Service (AKS) met ACR.

Regionale eindpunten gebruiken met DNS-routering zonder implementatiemanifesten te wijzigen

Als u geen verschillende distributiemanifesten per regio wilt onderhouden, kunt u alle manifesten die verwijzen naar het globale eindpunt (myregistry.azurecr.io) behouden en softwaregedefinieerde netwerken of een regionale traffic manager gebruiken om het globale eindpunt om te zetten naar het juiste regionale eindpunt op basis van het verkeer van de oorspronkelijke regio. Dit bereikt dezelfde colocatiedoelen als regionale eindpunten (voorspelbare routering en verminderde latentie) zonder regiospecifieke URL's in te sluiten in uw implementatiemanifesten.

Zie Authenticate with Azure Container Registry from Azure Kubernetes Service voor meer informatie over het verifiëren van Azure Kubernetes Service (AKS) met ACR.

Importeren uit specifieke geo-replica's met behulp van regionale eindpunten

Azure Container Registry ondersteunt het importeren van images uit verschillende bronregisters van diverse cloudproviders. Als de importbron een ACR is, kunt u alleen importeren uit de basisregio van de bron-ACR. De regionale eindpunten van de bron-ACR worden niet ondersteund als importbronnen. Geef het globale eindpunt van de bron-ACR op bij het importeren uit een bron-ACR. Daarnaast schrijft een importbewerking altijd content naar de thuisregio van de downstream-ACR. Zie Azure Container Registry eindpuntreferentie.

Netwerkoverwegingen voor regionale eindpunten

Firewall-regels

Als u ACR-firewallregels of aangepaste firewalls met regionale eindpunten gebruikt, configureert u uw firewallregels om toegang te verlenen tot:

Privé-eindpunten

Wanneer een privé-eindpunt wordt gemaakt voor een register in een virtueel netwerk, maakt de privé-eindpuntresource verschillende privé-IP-adressen van een virtueel netwerk beschikbaar die betrekking hebben op alle eindpunten van het register: het globale eindpunt, elk regionaal eindpunt (als regionale eindpunten zijn ingeschakeld) en elk toegewezen gegevenseindpunt (automatisch ingeschakeld wanneer een privé-eindpunt is geconfigureerd).

Elk eindpuntoppervlak verbruikt één privé-IP-adres van het subnet van het virtuele netwerk. Plan de grootte van uw subnet dienovereenkomstig:

• 1 IP-adres voor het globale eindpunt (myregistry.azurecr.io)
• 1 IP per geo-replica voor toegewezen gegevenseindpunten (myregistry.<region>.data.azurecr.io) - altijd ingeschakeld voor registers met ten minste één privé-eindpunt
• 1 IP per geo-replica voor regionale eindpunten (myregistry.<region>.geo.azurecr.io) - alleen als regionale eindpunten zijn ingeschakeld

Voorbeeld: Voor een register met drie geo-replica's en regionale eindpunten is 1 (globaal) + 3 (gegevens) + 3 (regionaal) = 7 privé-IP-adressen per privé-eindpuntresource vereist. Zonder regionale eindpunten vereist hetzelfde register 1 + 3 = 4 privé-IP-adressen.

Met veel geo-replica's kan het maken van privé-eindpunten mislukken als het subnet geen beschikbare IP-adressen meer heeft. Zie Privé verbinding maken met een register vanuit een virtueel netwerk met behulp van privé-eindpunten voor meer informatie.

Toegewezen gegevenseindpunten

Wanneer regionale eindpunten zijn ingeschakeld in combinatie met toegewezen gegevenseindpunten ( expliciet ingeschakeld of automatisch ingeschakeld door ten minste één privé-eindpunt te hebben geconfigureerd), worden laag-blobdownloads van regionale eindpunten automatisch omgeleid naar het toegewezen gegevenseindpunt van de geo-replica (myregistry.<region-name>.data.azurecr.io). De omleiding blijft altijd binnen dezelfde regio als het regionale eindpunt — een pull van myregistry.eastus.geo.azurecr.io wordt altijd omgeleid naar myregistry.eastus.data.azurecr.io, nooit naar een data-eindpunt in een andere regio.

Deze garantie voor dezelfde regio geldt ook wanneer u gegevens ophaalt via het globale eindpunt. ACR routeert de aanvraag naar de geo-replica met het beste netwerkprestatieprofiel voor de client, en de geo-replica die de aanvraag verwerkt geeft een 307-omleiding naar het eigen toegewezen data-eindpunt — nooit naar een andere regio.

az acr update -n <registry-name> --data-endpoint-enabled true

Zie Toegesneden gegevenseindpunten in Azure Container Registry voor meer informatie.

Referentie naar eindpunt

Zie Azure Container Registry eindpuntreferentie voor een volledig overzicht van alle typen registereindpunten, URL-indelingen en de CLI-vlaggen die deze beheren.

Probleemoplossingsproces

Push mislukt met manifestfouten

A docker push is een reeks HTTP-aanvragen: blob-uploads voor elke laag en vervolgens een manifestupload die verwijst naar die lagen per digest. Sommige Linux DNS-resolvers plaatsen reacties niet consistent in de cache. Als er verschillende geo-replica's in de nabijgelegen regio's zijn, kan DNS tijdens één push (DNS-bouncing) worden omgezet in verschillende replica's, waardoor het gepushte manifest verwijst naar lagen die naar een andere geo-replica zijn gepusht. Omdat de replicatie uiteindelijk consistent is, kan het manifest terechtkomen op een replica die nog niet over de lagen beschikt waarnaar wordt verwezen en mislukt de manifestvalidatie.

Oplossingen (in volgorde van voorkeur):

1. Gebruik regionale eindpunten om de push vast te maken aan één geo-replica end-to-end. Elke subvraag (aanmelding, blobuploads, manifestupload) gaat naar dezelfde geo-replica. Dit is de schoonste oplossing en de aanbevolen aanpak voor elke pijplijn waarbij de consistentie push/pull van belang is.
2. Een dns-cache met korte levensduur gebruiken, zoals dnsmasq beperkt tot de duur van één push. Zie opties voor DNS-naamomzetting voor Linux-VM's in Azure. De pinning mag alleen gedurende de push gelden en niet langer — gebruik geen langlevende DNS-cache voor het globale endpoint, omdat die interfereert met --global-endpoint-routing false en met statusafhankelijke failoverroutering.
3. Ontwerp de publicatiestappen zodanig dat ze idempotent zijn, zodat nieuwe pogingen na fouten halverwege het pushen veilig zijn.

Het maken van geo-replica's is vastgelopen voor registers met privé-eindpunten

Dit probleem treedt meestal op wanneer de identiteit die een geo-replica maakt voor een register waarvoor privé-eindpunten zijn ingeschakeld, niet over voldoende machtigingen beschikt om netwerkbronnen voor privé-eindpunten te maken.

Solution:

• U kunt dit oplossen door handmatig de geo-replica te verwijderen die vastgelopen is in de inrichtingsstatus.
• Zorg er daarna voor dat de identiteit de machtiging Microsoft.Network/privateEndpoints/privateLinkServiceProxies/write heeft voordat u een geo-replica maakt.
• Controleer ook of elk subnet van het privé-eindpunt dat is verbonden met het register gratis IP-capaciteit heeft. Als een subnet in een verbonden virtueel netwerk niet voldoende gratis IP-adressen heeft, mislukt de replicatie-inrichting en wordt deze teruggedraaid. De replica wordt kort weergegeven in een Creating status en wordt vervolgens verwijderd. De resulterende fout identificeert niet welk subnet of virtueel netwerk is uitgeput. Zie Privé verbinding maken met een register via privé-eindpunten voor richtlijnen voor subnetgrootte.

Het maken van geo-replica's mislukt bij registers met een privé-eindpunt met een statisch IP-adres

Het toevoegen van een geo-replica mislukt wanneer het privé-eindpunt van het register is geconfigureerd met statische privé-IP-toewijzing.

Elke geo-replica heeft een eigen toegewezen gegevenseindpunt, dat wordt weergegeven op het privé-eindpunt als lid met de groeps-id registry en een lidnaam van registry_data_<region>. Wanneer u een nieuwe geo-replica toevoegt, vraagt ACR het privé-eindpunt om het lidmaatschap toe te voegen voor het gegevens-eindpunt van de nieuwe regio. Met een privé-eindpunt dat is geconfigureerd met dynamische IP-toewijzing wordt het IP-adres van het nieuwe lid automatisch ingericht. Een privé-eindpunt dat is geconfigureerd met statische IP-toewijzing, heeft een vaste set IP-configuraties gedefinieerd tijdens het maken en voegt het nieuwe lid niet automatisch toe, zodat het maken van replica's mislukt met een fout die vergelijkbaar is met:

Failed to replicate private endpoint. Private Endpoint <id> contains static ipconfigurations:
[... GroupId: registry, MemberName: registry_data_<existing-region> ...] and it's missing these
membernames/groupids requested by Private Link service [GroupId: registry, MemberName:
registry_data_<new-region>, IpVersion: IPv4]. Private Endpoint needs to be reconfigured with
missing memberNames.

Als u de toewijzingsmethode van het privé-eindpunt van een register wilt controleren, controleert u de PrivateIPAllocationMethod IP-configuraties op de netwerkinterface van het privé-eindpunt. Het privé-eindpunt verwijst naar een netwerkinterface met deze IP-configuraties, dus haal eerst de netwerkinterface-id op en inspecteer vervolgens de IP-configuraties:

nicId=$(az network private-endpoint show \
  --name <private-endpoint-name> \
  --resource-group <resource-group-name> \
  --query "networkInterfaces[0].id" --output tsv)

az network nic show --ids "$nicId" \
  --query "ipConfigurations[].{Name:name, PrivateIPAddress:privateIPAddress, PrivateIPAllocationMethod:privateIPAllocationMethod}" \
  --output table

Oplossingen:

• Gebruik dynamische IP-toewijzing voor het privé-eindpunt als u later geo-replica's wilt toevoegen. Met dynamische toewijzing richt ACR automatisch het lid van het gegevenseindpunt in voor elke nieuwe regio. Dit is de aanbevolen aanpak.
• Maak het privé-eindpunt pas nadat alle geo-replica's bestaan als statische IP-toewijzing is vereist. Voeg eerst elke geo-replica toe en maak vervolgens het privé-eindpunt voor statisch IP, zodat de IP-configuratie een lid bevat voor het gegevenseindpunt van elke bestaande regio. Nadat een statisch IP-privé-eindpunt op deze manier is gemaakt, kunt u geen verdere geo-replica's toevoegen zonder het privé-eindpunt opnieuw te configureren om het nieuwe lid toe te voegen.

Verwante inhoud

• ACR-SKU's en serviceniveaus
• Eindpuntreferentie
• Webhooks
• Privé-eindpunten
• Toegewezen gegevenseindpunten
• Firewalltoegangsregels configureren