Georeplikation in Azure Container Registry

Durch aktivieren der Georeplikation für eine Azure Container Registry (ACR) werden Georeplikatressourcen in Azure-Regionen Ihrer Wahl erstellt. Wenn Sie Bilder in eine georeplizierte Registrierung übertragen, werden Inhalte automatisch mit allen Georeplikaten synchronisiert.

Mit Georeplikation:

• Verwalten sie eine Registrierung: Verwalten Sie eine einzelne Gruppe von Anmeldeinformationen, Rollenzuweisungen, Netzwerkregeln und Registrierungskonfigurationen für alle Georeplikate.
• Verwenden Sie einen globalen Endpunkt: Verweisen Sie myregistry.azurecr.io/myimage:tag in allen Builds und Bereitstellungen. Azure leitet Anforderungen an das Georeplikat mit dem besten Netzwerkleistungsprofil für den Client weiter, bei dem es sich in der Regel um das nächstgelegene Georeplikat handelt. Wenn der Client jedoch von mehreren Georeplikaten gleich weit entfernt ist oder das nächstgelegene Georeplikat nicht verfügbar ist, werden Anfragen möglicherweise an anderer Stelle weitergeleitet.
• Automatische Synchronisierung: Tags und Digests einmalig pushen; ACR repliziert Inhalte und Metadaten an alle Georeplikate.

Für die Georeplikation ist die Premium-SKU erforderlich.

Überlegungen zu Hochverfügbarkeit

Replikationsmodel

ACR-Georeplikation verwendet ein active-active Modell.

• Alle Georeplikate sind aktiv und schreibbar – Sie können Bilder aus jedem Georeplikat übertragen, ziehen und löschen, nicht nur das Georeplikat der Heimatregion.
• Dies unterscheidet sich von primären sekundären Replikationsmodellen, bei denen nur eine Region Schreibvorgänge akzeptiert und sekundäre Regionen passiv sind.

Konsistenzmodell

ACR verwendet Eventual Consistency.

• Nachdem Sie ein Bild in einem beliebigen Georeplikat übertragen oder gelöscht haben, repliziert ACR schließlich die Änderung auf alle Georeplikate im Hintergrund.
• Die Replikationszeit hängt von der Bildgröße ab. Ein per Push übertragenes Image oder Tag ist in anderen Georeplikaten möglicherweise nicht sofort per Pull verfügbar, wenn große Mengen an Images oder sehr große Images per Push übertragen werden. Ebenso kann ein gelöschtes Image oder Tag in anderen Georeplikaten möglicherweise noch zum Pullen verfügbar sein, bis die Löschung vollständig übernommen wurde.
• Die Zeit, die zum Erstellen eines neuen Geo-Replikats benötigt wird, skaliert mit der Gesamtgröße der Registrierung. Beim Erstellen eines neuen Geo-Replikats verarbeiten vorhandene Geo-Replikate weiterhin Push-, Pull- und Löschvorgänge normal. Es gibt keinen eingeschränkten Zustand und kein Beeinträchtigungsfenster, während das neue Georeplikat im Hintergrund den aktuellen Stand aufholt.
• Bis die Replikation schließlich im Hintergrund abgeschlossen ist, verfügt ein Georeplikat möglicherweise nicht über die neuesten Inhalte oder Metadaten. Sie können Webhooks verwenden, um Benachrichtigungen zu empfangen, wenn die Replikation für ein bestimmtes Pushimage in jedem Georeplikat abgeschlossen ist.

Hohe Verfügbarkeit der Datenebene

Die Georeplikation verbessert die Verfügbarkeit von Datenebenen, indem Bilder in mehreren Regionen beibehalten werden. Wenn eine Region von einem Ausfall betroffen ist, bleiben Images über andere Georeplikate erreichbar – Push-, Pull- und Löschvorgänge funktionieren weiterhin über die verbleibenden Georeplikate.

Zonenredundanz ist immer für Georeplikate aktiviert– ACR verteilt Replikatdaten automatisch über mehrere Verfügbarkeitszonen, um vor tieralen Ausfällen zu schützen.

Zustandsabhängiges Failover

ACR überwacht automatisch die Integrität jedes Georeplikats und umroutet den globalen Endpunktdatenverkehr von Georeplikaten, die Anforderungen nicht zuverlässig bedienen können. Dies wird als zustandsabhängiges Failover bezeichnet. ACR leitet den Datenverkehr des globalen Endpunkts basierend auf der Integrität des ACR-Diensts und der Integrität der regionalen Azure-Infrastruktur weiter.

• Automatisch und pro Registrierungsstelle: Der Status wird je Registrierungsstelle und nicht je Region bewertet. Wenn eine Verschlechterung nur eine Teilmenge von Registern in einer Region betrifft, werden nur diese Register umgeleitet – andere Register in derselben Region werden weiterhin lokal ohne unnötige Latenzstrafe bedient.
• Zeitverhalten: Die End-to-End-Umleitung liegt in der Größenordnung von Minuten – schnell genug, um tatsächliche regionale Beeinträchtigungen zu erkennen, und langsam genug, um vorübergehende Fehler abzuwarten, die sich von selbst beheben. DNS-TTL kann eine Verzögerung bei der Verbreitung verursachen, bevor alle Clients auf die neue Region umschalten.
• Es ist keine Kundenaktion erforderlich: Es gibt keinen aufrufbaren Trigger. Das zustandsbasierte Failover wird vollständig von der Plattform verwaltet.
• Failback ist automatisch: Sobald die regionale Integritätsauswertung eines Georeplikats erneut bestanden hat, z. B. wenn regionale ACR oder Azure Infrastruktur wiederhergestellt wird, kann der globale Endpunkt den Routingdatenverkehr an das Georeplikat in der wiederhergestellten Azure Region fortsetzen.
• Nicht durch Drosselung ausgelöst: Der zustandsbasierte Failover basiert auf DNS und reagiert auf den Integritätszustand des regionalen ACR-Diensts sowie der Azure-Infrastruktur. Es leitet den Datenverkehr nicht anhand von HTTP 429-Antworten (Drosselung) um. Wenn ein Georeplikat Ihre Anfragen drosselt, die Infrastruktur der Region aber funktionsfähig ist, leitet der globale Endpunkt Sie weiterhin an dieses Georeplikat weiter. Zur Verwaltung der Drosselung verwenden Sie regionale Endpunkte, um Workloads über mehrere Georeplikate hinweg für eine bessere Kapazitätsverteilung zu verteilen.

Umfang des zustandsbasierten Failovers:

Zustandsbasiertes Failover gilt nur für Vorgänge gegen den globalen Endpunkt (myregistry.azurecr.io). Sie gilt nicht für:

• Regionale Endpunkte – Wenn Sie einen regionalen Endpunkt (myregistry.<region>.geo.azurecr.io) verwenden, sprechen Sie direkt mit einem bestimmten Georeplikat. Wenn diese Region beeinträchtigt wird, wird ACR nicht automatisch umgeleitet. Implementieren Sie clientseitiges Failover, indem Sie zu einem anderen regionalen Endpunkt wechseln.
• Dedizierte Datenendpunkte – Sobald ein Registrierungsendpunkt Sie zu einem dedizierten Datenendpunkt für einen Layerdownload umleitet, bleiben Sie während des Downloads auf dem Datenendpunkt dieser Region. Die Region wird im Voraus durch den Registrierungsendpunkt festgelegt, der den Blob-Location-Aufruf beantwortet hat.

Drosselung beim Failover:

Drosselungsgrenzwerte für API-Vorgänge gelten pro Replikat. Während eines zustandsbasierten Failovers kann sich der Datenverkehr, der über mehrere Georeplikate verteilt war, stark auf die im Routingpool des globalen Endpunkts verbleibenden Georeplikate verlagern. Planen Sie Kapazität für mindestens zwei oder drei Georeplikate ein, damit der Datenverkehr während eines Failovers auf mehrere funktionsfähige Georeplikate verteilt werden kann. Registrierungen mit nur zwei Regionen können die Einschränkungsgrenzwerte pro Replikat einfacher erreichen, wenn eine Region nicht verfügbar ist. Um dies zu vermeiden, verwenden Sie regionale Endpunkte, um Arbeitslasten auf mehrere Georeplikate zu verteilen und die Kapazität pro Replikat zu planen.

So bestätigen Sie ein Failover:

• Azure-Portal: Navigieren Sie zu Ihrer Containerregistrierung, und wählen Sie im Abschnitt HilfeResource Health aus, um plattformseitige Signale zu Beeinträchtigungen anzuzeigen.
• Azure CLI: Überprüfen Sie den Replikationsstatus mit az acr replication list --registry myregistry --output table. Georeplikate, bei denen Probleme auftreten, zeigen einen anderen Status als online.
• Azure Monitor: Plattformmetriken werden automatisch erfasst. Aktivieren Sie Diagnoseeinstellungen für Ressourcenprotokolle, um detaillierte Telemetrie zu erhalten.

Verhalten bei Ausfall der Heimatregion

Die Heimatregion ist die Region, in der Sie die Registrierung ursprünglich erstellt haben. Sie hostt die Kontrollebene der Registrierung, die die Registrierungskonfiguration verwaltet. Die Heimatregion wird bei der Erstellung festgelegt und kann danach nicht mehr geändert werden. Informationen zum Verschieben einer Registrierung in eine andere Heimregion finden Sie unter Relocate Azure Container Registry, das eine erneute Bereitstellungsprozedur (Erstellen einer neuen Registrierung) und keine direkte Änderung beschreibt.

Wenn die Heimregion nicht verfügbar ist, ist der Effekt auf die Steuerungsebene (Verwaltung) beschränkt. Alle Datenebenenvorgänge werden weiterhin über die verbleibenden Georeplikate durchgeführt.

Was während eines Ausfalls einer Heimatregion weiterhin funktioniert:

• Images übertragen, abrufen und löschen – Clients können Images über den globalen Endpunkt (myregistry.azurecr.io) oder jeden verfügbaren regionalen Endpunkt (myregistry.<region>.geo.azurecr.io) von jeder verfügbaren Georeplikation übertragen, abrufen und löschen. ACR leitet globale Endpunktanforderungen automatisch an ein gesundes Georeplikat weiter.
• Authentifizierung — Alle Authentifizierungsmethoden funktionieren weiterhin, einschließlich Microsoft Entra ID, Service Principals, verwalteter Identitäten und repositorybezogener Token. Clients können sich bei jedem verfügbaren Georeplikat authentifizieren, ohne Anmeldeinformationen, Token oder Registrierungs-URLs ändern zu müssen.
• Webhook-Übermittlung – Webhooks, die für verfügbare Georeplikate konfiguriert sind, werden weiterhin ausgelöst. Ein einzelner Push führt zu Webhook-Ereignissen vom empfangenden Georeplikat sowie zu Ereignissen von jedem Georeplikat, sobald die Replikation abgeschlossen ist. Webhook-Verbraucher sollten so konzipiert sein, dass sie mehrere Ereignisse pro gepushtem Image verarbeiten und diese bei Bedarf deduplizieren.
• Regionale Endpunkte – Wenn regionale Endpunkte aktiviert sind, arbeiten sie weiterhin unabhängig voneinander. Clients können direkt mit bestimmten Georeplikaten über regionale Endpunkt-URLs sprechen.

Was während eines Ausfalls einer Heimatregion nicht verfügbar ist:

• Globales Endpunkt-Routing zum Georeplikat der primären Region – Die Zustandsprüfung von ACR stoppt automatisch die Weiterleitung des Datenverkehrs des globalen Endpunkts an das Georeplikat der primären Region und leitet ihn an fehlerfreie Georeplikate um.
• Regionaler Endpunkt für die Heimregion – Der regionale Endpunkt der Heimatregion (myregistry.<home-region>.geo.azurecr.io) ist nicht verfügbar, während die Heimregion nicht verfügbar ist. Regionale Endpunkte für andere Georeplikate funktionieren weiterhin unabhängig.
• Registrierungskonfigurationsänderungen – Sie können Registrierungseigenschaften wie Netzwerkregeln, Replikationseinstellungen oder Verfügbarkeitszonenkonfigurationen erst ändern, wenn die Heimregion wiederhergestellt wird.
• ACR-Aufgaben – Aufgaben sind an die Heimatregion gebunden und werden nicht ausgeführt, während sie nicht verfügbar ist.

Überlegungen zu Dienstebenen und Grenzwerten

Azure Container Registry Dienstebenen und Grenzwerte gelten für jedes Georeplikat unabhängig voneinander.

Bestimmte Dienstebenenbeschränkungen weisen folgende besondere Berücksichtigung auf:

• Speicherlimits: Speicherlimits für Ihre Dienstebene gelten gemeinsam für alle Georeplikate. Wenn Sie beispielsweise ein 1-GiB-Image pushen und es auf 5 Georeplikate repliziert wird, wird nur 1 GiB auf das maximale Speicherlimit Ihres Tarifs angerechnet.
• API-Häufigkeitsgrenzwerte: Einschränkungsgrenzwerte für API-Vorgänge, z. B. die Anzahl der Lese- und Schreibvorgänge pro Minute, sind georeplikatspezifisch. Verwenden Sie regionale Endpunkte , um Workloads über mehrere Georeplikate hinweg zu verteilen, um eine bessere Kapazitätsverteilung zu ermöglichen und zu vermeiden, dass sich der gesamte Datenverkehr auf ein einzelnes Georeplikat konzentriert.

Weitere Informationen zu Dienstebenen und -grenzwerten finden Sie unter ACR-Dienstebenen.

Preisinformationen

• Speicherabrechnung: Der Speicher wird pro Georeplikat in Rechnung gestellt. Beispielsweise wird ein 1 GiB-Image, das auf 5 Georeplikate repliziert wurde, als 5 GiB-Speicher in Rechnung gestellt (1 GiB × 5 Geo-Replikate).
• Datenübertragung: Die Georeplikation kann die Kosten senken, indem Push- und Pull-Vorgänge von Images innerhalb einer Region ermöglicht werden, sodass bei diesen Vorgängen keine regionsübergreifenden Datenübertragungsgebühren anfallen. Es fallen jedoch weiterhin Gebühren für die regionenübergreifende Datenübertragung an, wenn ACR im Rahmen der eventuellen Konsistenz gepushte Inhalte auf andere Georeplikate repliziert.

Weitere Informationen finden Sie unter ACR-Preise.

Hinzufügen oder Löschen von Georeplikaten

Erforderliche Berechtigungen

Um Georeplikate zu verwalten, benötigt Ihre Identität die folgenden Berechtigungen:

Azure-Portal

1. Wechseln Sie im Azure-Portal zu Ihrer Registrierung.
2. Wählen Sie unter "Dienste" die Option "Georeplikationen" aus.
3. Auf der Karte:
   • Blaues Sechseck: Heimatbereich (wo Sie die Registrierung erstellt haben)
   • Grüne Sechsecke: Verfügbare Regionen
   • Graue Sechsecke: Nicht verfügbare Regionen
4. Wählen Sie ein grünes Sechseck und dann "Erstellen" aus.

Azure-Befehlszeilenschnittstelle (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

Weitere Befehle finden Sie unter az acr replication.

Globaler Endpunkt einer geo-replizierten Registrierung

Nach dem Konfigurieren der Georeplikation können Sie Inhalte in Ihrer Registrierung über den globalen Endpunkt (myregistry.azurecr.io) der Registrierung übertragen, abrufen oder löschen.

Funktionsweise globaler Endpunkte

Wenn Sie den globalen Endpunkt per Push übertragen, abrufen oder löschen, leitet ACR die Anforderung an das Georeplikat mit dem besten Netzwerkleistungsprofil für den Client weiter.

• Das Georeplikat mit dem besten Netzwerkleistungsprofil aus Sicht des Clients ist in der Regel das nächstgelegene Georeplikat.
• Wenn der Client jedoch von mehreren Georeplikaten gleich weit entfernt ist oder das nächstgelegene Georeplikat nicht verfügbar ist, werden Anfragen möglicherweise an anderer Stelle weitergeleitet.
• ACR verwaltet dieses Routing. Sie steuern nicht, welches Georeplikat eine bestimmte Anforderung verarbeitet.

Verwenden des globalen Endpunkts

Authentifizieren:

az acr login --name myregistry

Markieren und Verschieben eines Bilds:

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

Ziehen Sie ein Bild:

docker pull myregistry.azurecr.io/myapp:v1

Importieren eines Bilds:

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

Kubernetes-Bereitstellungsmanifest:

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

Vorübergehendes Ausschließen eines Georeplikats vom globalen Endpunktrouting

Sie können ein Georeplikat aus dem globalen Endpunktrouting ausschließen, indem Sie die --global-endpoint-routing Einstellung für ein bestimmtes Georeplikat deaktivieren. Dies ist nützlich für Wartung oder Problembehandlung oder wenn Sie wissen, dass ein bestimmtes Georeplikat oder Azure Region Beeinträchtigungen hat. Sie können sogar das globale Endpunktrouting für das Georeplikat der Heimatregion deaktivieren – die Heimatregion wird nur für die Steuerung von Flugzeugvorgängen verwendet, und der Datenverkehr auf der Datenebene kann sicher vom globalen Routing ausgeschlossen werden. Weitere Informationen dazu, was von der Home-Region gesteuert wird, finden Sie unter Ausfallverhalten der Home-Region.

• Wenn die --global-endpoint-routing Einstellung für ein bestimmtes Georeplikat auf false festgelegt ist, stoppt ACR das Routing von Anfragen an dieses bestimmte Georeplikat für Anfragen, die zum globalen Endpunkt wechseln.
• Daten werden bidirektional mit einem Georeplikat synchronisiert, auch wenn das globale Endpunktrouting für dieses bestimmte Georeplikat deaktiviert ist. Jedes Image, das von jeder Region aus an die Registrierung übertragen wird, während das Georeplikat vom globalen Routing ausgeschlossen wird, wird weiterhin repliziert. Wenn Sie das Geo-Replikat wieder aktivieren, ist es sofort bereit, Datenverkehr ohne Aufholphase zu verarbeiten.
• Daher werden Speicherkontingente und Kosten für dieses Georeplikat weiterhin fällig.
• Wenn regionale Endpunkte aktiviert sind, funktioniert die regionale Endpunkt-URL desmyregistry.<region-name>.geo.azurecr.io Georeplikats weiterhin, auch wenn das globale Endpunktrouting deaktiviert ist. --global-endpoint-routing steuert nur die Teilnahme des Georeplikats am globalen Endpunktrouting.

# 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 Endpunkte einer geo-replizierten Registrierung (Vorschau)

Regionale Endpunkte bieten Ihnen dedizierte URLs für jedes Replikat, sodass Sie genau angeben können, welche regionalen Georeplikate Ihre Push-, Pull- oder Löschanforderung verarbeitet:

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

Verwenden Sie bei Bedarf regionale Endpunkte:

Regionale Endpunkte koexistieren mit globalen Endpunkten

Durch das Aktivieren regionaler Endpunkte wird der globale Endpunkt nicht deaktiviert oder ersetzt. Sie können beide gleichzeitig verwenden:

• Verwenden Sie den globalen Endpunkt (myregistry.azurecr.io), wenn Sie das automatische Routing bevorzugen, das von Azure über Georeplikate hinweg verwaltet wird.
• Verwenden Sie regionale Endpunkte (myregistry.<region-name>.geo.azurecr.io), wenn Sie eine präzisere clientseitige Routingsteuerung wünschen und Azure verwaltetes Routing des globalen Endpunkts vollständig umgehen möchten.

Funktionsweise regionaler Endpunkte

Regionale Endpunkte funktionieren als Anmeldeserver für bestimmte Georeplikate. Wenn Sie sich authentifizieren und mit einem regionalen Endpunkt anstatt mit dem globalen Endpunkt der Registrierung interagieren, werden alle Registrierungsvorgänge (Authentifizierung, Artefakteuploads/Downloads, Repositoryvorgänge und Metadatenaktionen) direkt zu diesem bestimmten regionalen Replikat geleitet, wobei Azure verwaltetes Routing vollständig umgangen wird.

Downloads von Layer-Blobs (die tatsächlichen Container-Image-Layer) folgen weiterhin der vorhandenen Konfiguration Ihrer Registry:

• Registries ohne private Endpunkte oder dedizierte Datenendpunkte: Wenn Sie Bildebenen aus einem bestimmten Georeplikat herunterladen, leiten Layer-BLOB-Downloads zu Azure Speicherkonten (*.blob.core.windows.net) um.
• Registrierungen mit privaten Endpunkten oder dedizierten Datenendpunkten sind aktiviert: Wenn Sie Bildebenen aus einem bestimmten Georeplikat herunterladen, leiten Layer-BLOB-Downloads an den dedizierten Datenendpunkt der entsprechenden Region (myregistry.<region-name>.data.azurecr.io).

Das folgende Diagramm veranschaulicht den regionalen Endpunktanforderungsfluss:

Voraussetzungen für regionale Endpunkte

• Premium-SKU – Regionale Endpunkte sind ausschließlich für Premium-Tier-Registrierungen verfügbar.
• Azure CLI – Version 2.86.0 oder höher. Alle regionalen Endpunktbefehle (--regional-endpoints, az acr show-endpoints, az acr login --endpoint) sind nativ in Azure CLI 2.86.0+ verfügbar.

az extension remove --name acrregionalendpoint

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

Aktivieren regionaler Endpunkte

Sie können regionale Endpunkte aktivieren, wenn Sie eine neue Registrierung erstellen oder eine vorhandene Registrierung aktualisieren.

Erstellen Sie eine neue Registrierung mit aktivierten regionalen Endpunkten:

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

Aktivieren Sie regionale Endpunkte in einer vorhandenen Registrierung:

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

Regionale Endpunkte sind auf Registrierungsebene aktiviert und gelten für jedes Georeplikat. Sie können keine regionalen Endpunkte für einzelne Replikate aktivieren. Wenn Sie regionale Endpunkte aktivieren, erstellt Azure Container Registry automatisch Anmeldeserver-URLs für jede Ihrer Georeplikate.

Arbeiten mit regionalen Endpunkten

Authentifizieren und Verwenden regionaler Endpunkte

Regionale Endpunkte unterstützen dieselben Authentifizierungsmethoden wie der globale Endpunkt: Microsoft Entra ID, Dienstprinzipale, verwaltete Identitäten und Administratoranmeldeinformationen.

Melden Sie sich bei einem bestimmten regionalen Endpunkt an:

az acr login --name myregistry --endpoint eastus

Markieren und Übertragen eines Bilds an einen regionalen Endpunkt. Bilder und Tags, die über den regionalen Endpunkt an ein Georeplikat gepusht werden, werden auch weiterhin im Rahmen der eventual consistency an alle anderen Georeplikate repliziert.

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

Abrufen eines Bilds von einem regionalen Endpunkt:

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

Verwenden regionaler Endpunkte, die in Bereitstellungsmanifesten eingebettet sind

Sie können regionale Endpunkte direkt in Kubernetes-Bereitstellungsmanifesten angeben, wenn Sie Workloads an bestimmte Regionen anheften müssen. Dadurch wird sichergestellt, dass Cluster in bestimmten Regionen immer ihre lokale Replik verwenden, was vorhersehbares Routing und geringere Latenz ermöglicht.

Bereitstellung von USA, Osten-Clustern:

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

Bereitstellung des West Europe-Clusters:

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

Durch die Verwendung verschiedener regionaler Endpunkte in den Manifesten jedes Clusters können Sie sicherstellen, dass jeder Cluster von seinem lokalen Replikat abruft, anstatt sich auf Azure verwaltetes Routing zu verlassen.

Informationen zum Authentifizieren von Azure Kubernetes Service (AKS) mit ACR finden Sie unter Authenticate with Azure Container Registry from Azure Kubernetes Service.

Verwenden von regionalen Endpunkten mit DNS-basiertem Routing ohne Änderung von Bereitstellungsmanifesten

Wenn Sie nicht unterschiedliche Bereitstellungsmanifeste pro Region verwalten möchten, können Sie alle Manifeste beibehalten, die auf den globalen Endpunkt verweisen (myregistry.azurecr.io) und softwaredefinierte Netzwerke oder einen regionalen Datenverkehrsmanager verwenden, um den globalen Endpunkt basierend auf dem Datenverkehr der Ursprungsregion auf den entsprechenden regionalen Endpunkt aufzulösen. Dies erreicht dieselben Colocation-Ziele wie regionale Endpunkte (vorhersagbares Routing und reduzierte Latenz), ohne regionsspezifische URLs in Ihre Bereitstellungsmanifeste einzubetten.

Informationen zum Authentifizieren von Azure Kubernetes Service (AKS) mit ACR finden Sie unter Authenticate with Azure Container Registry from Azure Kubernetes Service.

Importieren aus bestimmten Georeplikaten mithilfe regionaler Endpunkte

Beim Importieren von Bildern zwischen Registrierungen können Sie regionale Endpunkte verwenden, um aus einem bestimmten Georeplikat der Quellregistrierung zu importieren. Dies ist nützlich für Szenarien, in denen Sie vorhersehbare Netzwerkpfade benötigen oder aus einem Replikat in einer bestimmten Region importieren müssen.

az acr import \
  --name mydownstreamregistry \
  --source myupstreamregistry.westeurope.geo.azurecr.io/myapp:v1 \
  --image myapp:v1

Überlegungen zum Regionalen Endpunktnetzwerk

Firewallregeln

Wenn Sie ACR-Firewallregeln oder benutzerdefinierte Firewalls mit regionalen Endpunkten verwenden, konfigurieren Sie Ihre Firewallregeln, um den Zugriff auf Folgendes zu ermöglichen:

Private Endpunkte

Wenn ein privater Endpunkt für eine Registrierung in einem virtuellen Netzwerk erstellt wird, macht die private Endpunktressource mehrere private Netzwerk-IPs verfügbar, die alle Endpunktoberflächen der Registrierung abdecken – den globalen Endpunkt, jeden regionalen Endpunkt (wenn regionale Endpunkte aktiviert sind) und jeden dedizierten Datenendpunkt (automatisch aktiviert, wenn ein privater Endpunkt konfiguriert ist).

Jede Endpunktoberfläche verwendet eine private IP-Adresse aus dem subnetz des virtuellen Netzwerks. Planen Sie ihre Subnetzgröße entsprechend:

• 1 IP für den globalen Endpunkt (myregistry.azurecr.io)
• 1 IP pro Geo-Replikat für dedizierte Datenendpunkte (myregistry.<region>.data.azurecr.io) – immer für Registrierungen mit mindestens einem privaten Endpunkt aktiviert
• 1 IP pro Georeplikat für regionale Endpunkte (myregistry.<region>.geo.azurecr.io) – nur, wenn regionale Endpunkte aktiviert sind

Beispiel: Eine Registrierung mit 3 georeplikaten und regionalen Endpunkten erfordert 1 (global) + 3 (Daten) + 3 (regional) = 7 private IP-Adressen pro private Endpunktressource. Ohne regionale Endpunkte erfordert dieselbe Registrierung 1 + 3 = 4 private IP-Adressen.

Bei vielen Georeplikaten kann die Erstellung privater Endpunkte fehlschlagen, wenn das Subnetz keine verfügbaren IPs mehr enthält. Weitere Informationen finden Sie unter "Privates Verbinden mit einer Registrierung über ein virtuelles Netzwerk mithilfe privater Endpunkte".

Dedizierte Datenendpunkte

Wenn regionale Endpunkte zusammen mit dedizierten Datenendpunkten aktiviert sind — entweder explizit oder automatisch, wenn mindestens ein privater Endpunkt konfiguriert ist — werden Layer-Blob-Downloads von regionalen Endpunkten automatisch an den dedizierten Datenendpunkt der Georeplik (myregistry.<region-name>.data.azurecr.io) umgeleitet. Die Umleitung bleibt immer innerhalb derselben Region wie der regionale Endpunkt – ein Pull von myregistry.eastus.geo.azurecr.io wird immer an myregistry.eastus.data.azurecr.io umgeleitet, niemals an einen Datenendpunkt in einer anderen Region.

Diese Garantie für dieselbe Region gilt auch beim Abrufen vom globalen Endpunkt. ACR leitet die Anforderung an das Georeplikat mit dem besten Netzwerkleistungsprofil für den Client weiter, und das bereitgestellte Georeplikat gibt eine 307-Umleitung zu seinem eigenen dedizierten Datenendpunkt aus – niemals regionenübergreifend.

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

Weitere Informationen finden Sie unter Dedizierte Datenendpunkte in Azure Container Registry.

Endpunktreferenz

Eine vollständige Referenz aller Registrierungsendpunkttypen, URL-Formate und cli-Flags, die sie steuern, finden Sie unter Azure Container Registry Endpunktreferenz.

Problembehandlung

Push schlägt mit Manifestfehlern fehl

Bei docker push handelt es sich um eine Sequenz von HTTP-Anfragen: Blob-Uploads für jede Schicht, gefolgt von einem Manifest-Upload, der mittels Digest auf diese Schichten verweist. Einige Linux-DNS-Resolver speichern keine konsistenten Antworten. Wenn mehrere Georeplikate in nahe gelegenen Regionen vorhanden sind, kann DNS während eines einzelnen Pushs (DNS-Bouncing) zu verschiedenen Replikaten aufgelöst werden, wodurch das Pushmanifest auf Ebenen verweist, die an ein anderes Georeplikat übertragen wurden. Da die Replikation nur schließlich konsistent ist, kann das Manifest bei einer Replik ankommen, die die referenzierten Layer noch nicht enthält, und die Validierung des Manifests schlägt fehl.

Lösungen (in der Reihenfolge der Voreinstellung):

1. Verwenden Sie regionale Endpunkte, um den Push durchgängig auf eine einzige Georeplik festzulegen. Jede Unteranforderung (Anmeldung, Blob-Uploads, Manifestupload) wird an dasselbe Georeplikat übertragen. Dies ist die sauberste Lösung und der empfohlene Ansatz für jede Pipeline, bei der die Push-/Pull-Konsistenz wichtig ist.
2. Verwenden Sie einen kurzlebigen DNS-Cache wie dnsmasq, der auf die Dauer eines einzelnen Pushs beschränkt ist. Informationen zu Linux-VMs in Azure finden Sie unter DNS-Namensauflösungsoptionen. Das Pinning sollte nur für die Dauer des Pushs gelten und nicht länger — verwenden Sie keinen langlebigen DNS-Cache für den globalen Endpunkt, da er --global-endpoint-routing false und das zustandsbasierte Failover-Routing beeinträchtigt.
3. Gestalten Sie die Veröffentlichungsschritte so, dass sie idempotent sind, damit Wiederholungsversuche, die durch Fehler während des Push-Vorgangs ausgelöst werden, sicher sind.

Geo-Replikaterstellung hängt bei Registrierungen mit privatem Endpunkt

Dieses Problem tritt in der Regel auf, wenn die Identität, die ein Georeplikat für eine private endpunktfähige Registrierung erstellt, nicht über ausreichende Berechtigungen zum Erstellen privater Endpunktnetzwerkressourcen verfügt.

Lösung:

• Um dies zu beheben, löschen Sie das Georeplikat, das sich im Bereitstellungszustand festgefahren hat.
• Stellen Sie anschließend sicher, dass die Identität über die Berechtigung Microsoft.Network/privateEndpoints/privateLinkServiceProxies/write verfügt, bevor Sie ein Georeplikat erstellen.
• Stellen Sie außerdem sicher, dass jedes mit der Registrierung verbundene private Endpunktsubnetz über kostenlose IP-Kapazität verfügt. Wenn ein Subnetz über ein verbundenes virtuelles Netzwerk nicht über genügend freie IPs verfügt, schlägt die Replikationsbereitstellung fehl und führt einen Rollback durch. Das Replikat wird kurz in einem Creating Zustand angezeigt und dann entfernt. Der resultierende Fehler identifiziert nicht, welches Subnetz oder virtuelles Netzwerk erschöpft ist. Anleitungen zur Subnetzgröße finden Sie unter Privates Verbinden mit einer Registrierung mithilfe privater Endpunkte.

Die Erstellung von Georeplikaten schlägt bei Registrys mit privatem Endpunkt mit statischer IP-Adresse fehl

Das Hinzufügen eines Georeplikats schlägt fehl, wenn der private Endpunkt der Registrierung mit statischer privater IP-Zuordnung konfiguriert ist.

Jedes Georeplikat verfügt über einen eigenen dedizierten Datenendpunkt, der auf dem privaten Endpunkt als Mitglied mit der Gruppen-ID registry und dem Mitgliedsnamen registry_data_<region> bereitgestellt wird. Wenn Sie ein neues Georeplikat hinzufügen, fordert ACR den privaten Endpunkt an, das Mitglied für den Datenendpunkt der neuen Region hinzuzufügen. Ein privater Endpunkt, der mit dynamischer IP-Zuordnung konfiguriert ist, stellt die IP-Adresse des neuen Mitglieds automatisch fest. Ein privater Endpunkt, der mit statischer IP-Zuweisung konfiguriert ist, verfügt über einen festen Satz von IP-Konfigurationen, die zur Erstellungszeit definiert sind und das neue Element nicht automatisch hinzufügen, sodass die Replikaterstellung mit einem Ähnlichen Fehler fehlschlägt:

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.

Um die Zuordnungsmethode des privaten Endpunkts einer Registrierung zu überprüfen, überprüfen Sie die PrivateIPAllocationMethod IP-Konfigurationen auf der Netzwerkschnittstelle des privaten Endpunkts. Der private Endpunkt verweist auf eine Netzwerkschnittstelle, die diese IP-Konfigurationen enthält. Rufen Sie also zuerst die Netzwerkschnittstellen-ID ab, und prüfen Sie dann ihre IP-Konfigurationen:

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

Lösungen :

• Verwenden Sie die dynamische IP-Zuordnung für den privaten Endpunkt, wenn Sie später georeplikate hinzufügen möchten. Mit der dynamischen Zuweisung stellt ACR das Datenendpunktmitglied für jede neue Region automatisch fest. Dies ist der empfohlene Ansatz.
• Erstellen Sie den privaten Endpunkt, nachdem alle Georeplikate vorhanden sind , wenn eine statische IP-Zuordnung erforderlich ist. Fügen Sie zuerst jedes Georeplikat hinzu, und erstellen Sie dann den privaten static-IP-Endpunkt, sodass seine IP-Konfiguration ein Mitglied für den Datenendpunkt jeder vorhandenen Region enthält. Nachdem ein privater static-IP-Endpunkt auf diese Weise erstellt wurde, können Sie keine weiteren Georeplikate hinzufügen, ohne den privaten Endpunkt neu zu konfigurieren, um das neue Mitglied hinzuzufügen.

Verwandte Inhalte

• ACR-SKUs und Dienstebenen
• Endpunktreferenz
• Webhooks
• Private Endpunkte
• Dedizierte Datenendpunkte
• Konfigurieren von Firewallzugriffsregeln