Häufig gestellte Fragen zu Azure Backup für Azure Kubernetes Service

Dieser Artikel beantwortet häufig gestellte Fragen zu Azure Backup für Azure Kubernetes Service. Weitere Informationen zur Verfügbarkeit der Azure Backup für AKS-Regionen , unterstützten Szenarien und Einschränkungen finden Sie in der Supportmatrix.

Häufig gestellte Fragen

Warum muss ich die AKS-Sicherungserweiterung in meinem AKS-Cluster installieren, um die Sicherung für meinen AKS-Cluster zu aktivieren?

Sie müssen die AKS-Sicherungserweiterung in Ihrem AKS-Cluster installieren, um die Sicherung zu ermöglichen, da sie Ihren Cluster in den systemeigenen Sicherungsdienst von Azure integriert, die zentrale Verwaltung, Automatisierung und Sicherheit für Ihre Sicherungen bereitstellt. Die Erweiterung interagiert mit Kubernetes-APIs, um sicherzustellen, dass Kubernetes-Workloads (persistente Volumes, Konfigurationen und Metadaten) ordnungsgemäß gesichert und wiederhergestellt werden.

Welche Eingaben sind für die Installation der AKS Backup Extension erforderlich? Haben diese Eingaben bestimmte Anforderungen?

Die Installation der AKS-Sicherungserweiterung erfordert ein Speicherkonto und einen BLOB-Container als Eingaben. Das Speicherkonto muss sich in derselben Region wie der AKS-Cluster befinden, und der BLOB-Container muss sich im gleichen Speicherkonto befinden. Der BLOB-Container wird verwendet, um sowohl die Sicherungsdaten als auch die zugehörigen Metadaten zu speichern. Zu den spezifischen Anforderungen für das Speicherkonto und den BLOB-Container gehören:

• Das Speicherkonto muss vom Standard general-purpose v2 Typ sein.
• Der BLOB-Container muss im Speicherkonto erstellt werden, bevor die AKS-Sicherungserweiterung installiert wird.
• Der BLOB-Container sollte vorzugsweise vor der Installation leer sein oder zumindest keine nicht mit demBack verbundenen Daten darin enthalten sein, da die Erweiterung eine eigene Ordnerstruktur innerhalb des Containers erstellt, um Sicherungsdaten und Metadaten zu speichern.
• Wenn sich der AKS-Cluster in einem privaten Netzwerk befindet, muss auf das Speicherkonto über den AKS-Cluster zugegriffen werden. Dies kann mithilfe eines privaten Endpunkts für das Speicherkonto oder durch Konfigurieren der erforderlichen Netzwerkregeln erreicht werden, um den Zugriff vom AKS-Cluster auf das Speicherkonto zu ermöglichen.

Welche Anforderungen müssen von den NodePools des AKS-Clusters erfüllt werden, um die Sicherungserweiterung darin zu installieren?

Die Pods, die mit der AKS Backup Extension verbunden sind, werden auf den Knotenpools des AKS-Clusters bereitgestellt. Um diese Pods erfolgreich bereitzustellen und zu verhindern, dass sie Ihre Anwendungsressourcen beeinträchtigen, stellen Sie Folgendes sicher:

• Der AKS-Cluster muss über den Agenten-Knotenpool mit dem Betriebssystem Linux, einschließlich Azure Linux und Ubuntu verfügen.
• Der Agentknotenpool muss über Azure Virtual Machine Scale Sets SKUs verfügen, die auf einer nicht ARM64 basierten Architektur basieren.
• Der Agenten-Pool muss mit dem Taint CriticalAddOnOnly verknüpft sein. Dieser Taint wird dem Knoten-Pool automatisch hinzugefügt, wenn der AKS-Cluster über das Portal erstellt wird. Er stellt sicher, dass nur kritische Add-On Pods, wie z. B. die Pods der AKS Backup Extension, auf dem Knoten-Pool eingeplant werden. Dadurch wird verhindert, dass Ihre Anwendungsworkloads beeinträchtigt werden, und es wird sichergestellt, dass Sicherungsvorgänge von anderen Workloads im Cluster isoliert sind. Falls der Taint nicht vorhanden ist, können Sie ihn manuell hinzufügen, bevor Sie die AKS Backup Extension installieren.

Was sind die CPU- und Speicheranforderungen für die AKS Backup Extension?

Azure Backup für AKS basiert auf Pods, die im AKS-Cluster als Teil der Sicherungserweiterung unter dem Namespace dataprotection-microsoftbereitgestellt werden. Um Sicherungs- und Wiederherstellungsvorgänge auszuführen, weisen diese Pods bestimmte CPU- und Speicheranforderungen auf.

• Arbeitsspeicher: Anforderungen - 256Mi, Grenzwerte - 1280Mi
• CPU: Anforderungen - 500m, Grenzwerte - 1000m

Welche Kubernetes-Ressourcen werden beim Installieren der AKS-Sicherungserweiterung im Cluster bereitgestellt?

Wenn Sie die AKS-Sicherungserweiterung installieren, werden sicherungsbezogene Ressourcen im Cluster unter dem dataprotection-microsoft Namespace bereitgestellt. Die folgenden drei Bereitstellungen werden in diesem Namespace erstellt:

dataprotection-microsoft-controller dataprotection-microsoft-geneva-service dataprotection-microsoft-kubernetes-agent

Da die AKS Backup Extension auf der Arc Extensions for AKS Plattform erstellt wurde, werden außerdem zwei weitere Bereitstellungen im kube-system Namespace erstellt:

extension-agent extension-operator

Diese Bereitstellungen unterstützen nicht nur die Sicherungserweiterung, sondern sind auch für andere Erweiterungen wie Flux und Azure Machine Learning erforderlich.

Welche anderen Azure-Ressourcen werden während der Installation der AKS-Sicherungserweiterung im Abonnement erstellt?

Im Rahmen der Installation der Sicherungserweiterung wird auch eine Benutzeridentität in der Node-Ressourcengruppe des Clusters erstellt. Diese Identität wird von der AKS-Sicherungserweiterung verwendet, um auf die azure-Ressourcen zuzugreifen, die für Sicherungsvorgänge erforderlich sind. Der Benutzeridentität wird die Rolle Storage Blob Data Contributor für das Speicherkonto zugewiesen, um den Zugriff auf die Erweiterung zu ermöglichen. Wenn die Erweiterung aus dem AKS-Cluster deinstalliert wird, wird die Identität ebenfalls gelöscht.

Warum Velero nicht zusammen mit der AKS Backup Erweiterung im Cluster verwendet werden sollte?

Velero ist eine Drittanbieter-Backup-Lösung für Kubernetes, die mit der AKS Backup Extension in Konflikt stehen kann. Es wird empfohlen, nur die AKS-Sicherungserweiterung für Sicherungsvorgänge in einem Cluster zu verwenden, aber nicht beide gleichzeitig. AKS Backup Extension stellt auch Velero CRDs im Cluster bereit. Wenn das eigenständige Velero zusammen mit der AKS Backup Extension im AKS-Cluster installiert wird und die von den beiden Installationen verwendeten Versionen zu irgendeinem Zeitpunkt voneinander abweichen, kann dies zu Fehlern aufgrund von Vertragskonflikten führen. Darüber hinaus können benutzerdefinierte Velero-Konfigurationen, die von Ihnen erstellt wurden, wie beispielsweise eine VolumeSnapshotClass für die CSI-basierte Snapshot-Erstellung mit Velero, das AKS Backup-Setup für die Snapshot-Erstellung beeinträchtigen. Velero-Anmerkungen, die velero.io enthalten und auf verschiedene Ressourcen im Cluster angewendet werden, können ebenfalls das Verhalten der AKS-Sicherung beeinträchtigen.

Was ist eine Momentaufnahme-Ressourcengruppe?

Azure Backup für AKS bietet Sicherung der Betriebsebene für AKS-Cluster. Daher werden die Momentaufnahmen von Azure-Disk-basierten Persistent Volumes, die während der geplanten und On-Demand-Sicherungsvorgänge erstellt werden, in einer Ressourcengruppe in Ihrem Abonnement gespeichert. Azure Backup bietet eine sofortige Wiederherstellung, da die inkrementellen Momentaufnahmen in Ihrem Abonnement gespeichert sind. Diese Ressourcengruppe wird als Momentaufnahme-Ressourcengruppe bezeichnet. Es ist obligatorisch, während der Sicherungskonfiguration eine Momentaufnahmeressourcengruppe bereitzustellen, und sobald sie zugeordnet wurde, kann sie nicht mehr geändert werden.

Was ist eine Stagingressourcengruppe und ein Speicherkonto?

Wenn Sicherungen aus dem Vault Tier wiederhergestellt werden sollen, sind eine Staging Ressourcengruppe und ein Storage-Konto erforderlich. Bei einer solchen Wiederherstellung werden die Sicherungsdaten im Vault zunächst in den Staging-Ort hydriert und dann mit der im Cluster installierten Erweiterung im Ziel-AKS-Cluster wiederhergestellt. Die Staging-Ressourcengruppe wird verwendet, um die gesicherten Datenträger vorübergehend wiederherzustellen. Das Staging Storage-Konto wird verwendet, um die in den Sicherungsdaten gespeicherten Kubernetes-Ressourcen im Vault Tier zu speichern. Die Sicherungen, die einmal im Staging Storage erstellt wurden, müssen manuell bereinigt werden.

Welche Typen persistenter Volumes werden von Azure Backup für AKS unterstützt?

Azure Backup für AKS basiert auf CSI-treiberbasierten Momentaufnahmen für seine Sicherungs- und Wiederherstellungsvorgänge. Die folgenden persistenten Volumetypen werden unterstützt:

Azure Disk-basierte persistente Volumes: Zugeordnet über den CSI-Treiber mit den folgenden SKUs:

• Premium-SSD
• Standard-SSD
• Standard-Festplatte
• Premium-SSD v2
• Ultra Disks

Hinweis

Während Snapshot- und Wiederherstellungsvorgänge für alle Datenträger-SKUs unterstützt werden, können Vorgänge für Premium SSD v2 und Ultra Disks länger dauern, da der Prozess das Kopieren von Daten vom Volume in eine Momentaufnahme und zurück umfasst. Der Snapshot kann verfügbar erscheinen und das Volume kann gemountet werden, bevor der zugrunde liegende Datenkopiervorgang vollständig abgeschlossen ist, was zu einer Verzögerung führt, bevor die wiederhergestellten Daten sichtbar werden.

In Bezug auf Azure-Datenträger mit Netzwerkzugriffseinstellungen:

• Die Betriebsebene unterstützt sowohl öffentliche als auch private Zugriffsdatenträger beliebiger Größe.
• Die Tresorebene unterstützt nur Datenträger mit öffentlichem Zugriff mit einer maximalen Größe von bis zu 1 TB.

Azure Files-basierte persistente Volumes: Über den CSI-Treiber (file.csi.azure.com) mit den folgenden Merkmalen bereitgestellt:

• Nur SMB-Protokoll (NFS wird nicht unterstützt)
• Sowohl Standard- als auch Premium-Dateifreigaben
• Nur öffentliche Netzwerkendpunkte (private Endpunkte werden nicht unterstützt)
• Maximal 25.000 Dateien pro Dateifreigabe
• Nur Sicherung der Betriebsebene (Vault-Ebene wird nicht unterstützt)
• Aufbewahrung bis zu 30 Tage

Andere Azure-Speicheroptionen wie Azure Blob, Azure Container Storage, Azure NetApp Files, Azure Managed Lustre und Speicherlösungen von Drittanbietern werden derzeit nicht unterstützt. Erfahren Sie mehr über die Unterstützung und Einschränkungen von Azure Files.

Wenn ein AKS-Cluster über persistente Volumes von nicht unterstützten Typen verfügt, was geschieht während des Sicherungsvorgangs?

Wenn ein AKS-Cluster persistente Volumes von nicht unterstützten Typen enthält, werden diese Volumes während des Sicherungsvorgangs übersprungen. Die gesamte Sicherung wird dennoch erfolgreich sein, aber die nicht unterstützten Volumes werden nicht in die Sicherung einbezogen.

Welche Sicherungsspeicherebenen sind in Azure Backup für AKS verfügbar?

Azure Backup für AKS unterstützt zwei Arten von Sicherungsspeicherebenen:

• Betriebsebene: Diese Stufe wird für die kurzfristige Aufbewahrung von Sicherungen verwendet. Es speichert inkrementelle Snapshots von persistenten Volumes innerhalb Ihres Abonnements als Sicherungskopie. Diese Stufe eignet sich ideal für schnelle Wiederherstellungen und Betriebswiederherstellungsszenarien.
• Archivstufe: Diese Stufe wird für die Langzeitaufbewahrung von Sicherungen verwendet. Es speichert Sicherungsdaten, die auf betriebsbereiter Ebene gespeichert sind, konvertieren sie in Block-Blobs und speichern sie dann in Speicherkonten (als Tresor bezeichnet) in einem gesicherten Azure-Mandanten, der von Microsoft verwaltet wird. Diese Stufe eignet sich ideal für Compliance- und behördliche Anforderungen, da Sie Sicherungen für längere Zeiträume in niedriger Speicherebene aufbewahren können.

Sie können die Sicherungsspeicherebene definieren, wenn Sie eine Sicherungsrichtlinie erstellen. Die Standardregel besteht darin, die Betriebsstufe für die Sicherung zu verwenden. Sie können weitere Regeln hinzufügen, um Daten in der Tresorebene zusammen mit der Operativen Ebene zu sichern.

Wie häufig werden Backups in der Betriebs- und Tresorebene durchgeführt?

Die Sicherungshäufigkeit wird in der Sicherungsrichtlinie definiert.

• Im Operational Tier können Sicherungen so häufig wie alle 4 Stunden durchgeführt werden.
• Auf der Vault-Tier kann nur eine Sicherung pro Tag gespeichert werden.

Sie können Regeln konfigurieren, um die erste erfolgreiche Sicherung des Tages, der Woche, des Monats oder des Jahres in den Vault Tier zu verschieben. Diese Einstellungen können basierend auf Ihren Zielen für Wiederherstellungspunkte (RECOVERY Point Objectives, RPOs) und Aufbewahrungsanforderungen angepasst werden.

Mit welcher maximalen Verzögerung kann ich bei Azure Backup für AKS bei der Startzeit des Backups gegenüber der geplanten Zeit rechnen?

Geplante Sicherungen werden innerhalb eines 2-Stunden-Fensters ab der geplanten Zeit gemäß der Sicherungsrichtlinie ausgeführt. Sie können daher bei der AKS-Backup mit einer maximalen Verzögerung von 2 Stunden beim Beginn des Backups im Vergleich zur geplanten Sicherungszeit rechnen.

Wie schnell werden Sicherungen, die im Operational Tier erstellt wurden und für eine Übertragung in den Vault geeignet sind, in den Vault Tier verschoben?

Sobald eine Sicherung im Operational Tier erstellt wurde und wenn sie den in der Sicherungsrichtlinie definierten Regeln entspricht, kommt sie sofort für den Vault in Frage. Danach wird die Übertragung in den Vault Tier innerhalb der nächsten 4 Stunden eingeleitet.

Wie bestimmt Azure Backup, welche Wiederherstellungspunkte in einer Sicherungsrichtlinie wöchentlich, monatlich oder jährlich aufbewahrt werden?

Eine Sicherungsrichtlinie, die die Aufbewahrung nach dem Prinzip "erste erfolgreiche Sicherung der Woche/des Monats/des Jahres" festlegt, wählt die erste erfolgreiche Sicherung jeder Woche, jedes Monats oder Jahres aus und behält sie gemäß der angegebenen Aufbewahrungsdauer bei. Die Definition von "first" ist systemdefiniert , z. B.:

• Woche: Sonntag gilt als Beginn der Woche
• Monat: Der erste Tag des Monats
• Jahr: 1. Januar

Dieses Verhalten basiert nicht auf dem Datum, an dem die Richtlinie erstellt oder aktiviert wurde.

Kann ich einen AKS-Cluster mithilfe der Azure Backup-Lösung mehrmals gemäß meiner Anwendungsdefinition sichern?

Ein AKS-Cluster kann mehrere Anwendungen gleichzeitig hosten, die jeweils auf unterschiedliche Namespaces festgelegt sind. Azure Backup ermöglicht es Ihnen, einen AKS-Cluster mehrmals gemäß verschiedenen Anwendungskonfigurationen zu sichern, entweder in verschiedenen Sicherungstresorn oder unter Verwendung unterschiedlicher Sicherungsrichtlinien innerhalb desselben Sicherungstresors.

Wie kann ich meine Sicherungen für den AKS-Cluster geografisch redundant machen und für die Wiederherstellung verfügbar machen, wenn ein regionaler Ausfall vorliegt?

Azure Backup für AKS unterstützt georedundante Sicherungen, sodass Sie Ihre Daten in einer anderen Azure-Region wiederherstellen können, wenn ein regionaler Ausfall vorhanden ist. Die Sicherungsdaten werden redundant gemacht, indem sie in eine Azure-gekoppelte Region repliziert werden.

Um Ihre Sicherungen geografisch redundant zu machen, besteht der erste Schritt darin, sie in einem Sicherungstresor zu konfigurieren, der Geo-Redundanz und regionsübergreifende Wiederherstellung aktiviert hat.

Konfigurieren Sie als Nächstes die Sicherungsinstanz mit einer Sicherungsrichtlinie, die Aufbewahrungsregeln für die Tresorebene enthält.

Bei diesen Einstellungen wird eine Sicherung, sobald sie auf die Tresorebene verschoben wurde, automatisch in die gekoppelte sekundäre Azure-Region repliziert.

Im Falle eines regionalen Ausfalls können Sie die Sicherung aus der sekundären Region entweder über das Azure-Portal oder die Azure CLI wiederherstellen.

Welches RPO wird vom Azure Backup für AKS unterstützt, wenn in der sekundären Region Sicherungsdaten verfügbar sind?

Sobald eine Sicherung in den Vault Tier verschoben wurde, kann es bis zu 12 Stunden dauern, bis sie in der sekundären Region repliziert ist. Daher beträgt das maximale RPO für einen Wiederherstellungspunkt, der in den von Azure Backup für AKS unterstützten sekundären Regionen verfügbar ist, Stunden, wenn Sicherungsdaten in der sekundären Region vorhanden sind. Dies bedeutet, dass Sie im Falle eines regionalen Ausfalls Ihre Sicherungsdaten aus der sekundären Region mit einem maximalen Datenverlust von 24 Stunden wiederherstellen können.

Warum müssen Rollenzuweisungen erfolgen, um Sicherungen zu konfigurieren, geplante und bedarfsgesteuerte Sicherungen zu erstellen und Wiederherstellungsvorgänge durchzuführen?

Azure Backup für AKS verwendet den Ansatz mit den geringsten Berechtigungen, um die AKS-Cluster in Ihren Abonnements zu ermitteln, zu schützen und wiederherzustellen. Um dies zu erreichen, verwendet Azure Backup die verwaltete Identität des Sicherungstresors, um auf andere Azure-Ressourcen zuzugreifen. Sie können berechtigungen für die verwaltete Identität, das zugewiesene System oder den benutzer gewähren, indem Sie die rollenbasierte Zugriffssteuerung (Azure RBAC) verwenden. Eine verwaltete Identität ist ein spezieller Dienstprinzipal, der nur zusammen mit Azure-Ressourcen verwendet werden kann. Standardmäßig hat der Backup Vault keine Berechtigung, auf den zu sichernden AKS-Cluster zuzugreifen, periodische Snapshots zu erstellen, Snapshots nach der Aufbewahrungsperiode zu löschen und ein Backup wiederherzustellen. Durch das explizite Gewähren von Rollenzuweisungen für die verwaltete Identität des Sicherungstresors haben Sie die volle Kontrolle über die Verwaltung der Berechtigungen für die Ressourcen in den Abonnements.

Welche Berechtigungen werden von Azure Backup während des Sicherungs- und Wiederherstellungsvorgangs verwendet?

Im Folgenden finden Sie die Aktionen, die in der Rolle Mitwirkender auf dem AKS-Cluster, der gesichert oder wiederhergestellt werden soll, zugewiesen sind:

1. Microsoft.Compute/snapshots/read
2. Microsoft.Compute/snapshots/write
3. Microsoft.Compute/Schnappschüsse/löschen

Im Folgenden finden Sie die Aktionen, die in der Rolle Mitwirkender bei Storage Blob Data verwendet werden, die der Erweiterungsidentität des AKS-Clusters zugewiesen ist, der gesichert oder auf den wiederhergestellt werden soll, über das Storage-Konto:

1. Microsoft.Storage/storageAccounts/blobServices/containers/read
2. Microsoft.Storage/storageAccounts/blobServices/containers/write
3. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
4. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
5. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete
6. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action

Im Folgenden finden Sie die Aktionen, die in der Rolle Leser verwendet werden, die dem Backup Vault über den AKS-Cluster zugewiesen ist:

1. */Lesen

Nachfolgend finden Sie die Aktionen, die in der Rolle Leser verwendet werden, die dem Backup Vault über die Snapshot-Ressourcengruppe zugewiesen ist:

1. Microsoft.Authorization/*/read
2. Microsoft.Resources/subscriptions/resourceGroups/read

Nachfolgend finden Sie die Aktionen, die in der Rolle Datenträger Snapshot Mitwirkender verwendet werden, die dem Backup Vault über die Snapshot Ressourcengruppe zugewiesen wurde, falls Sicherungen im Vault Tier gespeichert werden sollen:

1. Microsoft.Compute/Schnappschüsse/löschen
2. Microsoft.Compute/snapshots/write
3. Microsoft.Compute/snapshots/read
4. Microsoft.Compute/snapshots/beginGetAccess/action
5. Microsoft.Compute/snapshots/endGetAccess/action
6. Microsoft.Compute/disks/beginGetAccess/action

Im Folgenden finden Sie die Aktionen, die in der Rolle Daten-Operator für Managed Disks verwendet werden, die dem Backup Vault über die Snapshot-Ressourcengruppe zugewiesen wurde, wenn Sicherungen im Vault-Tier gespeichert werden sollen:

1. Microsoft.Compute/disks/download/action
2. Microsoft.Compute/snapshots/download/action

Die folgenden Aktionen werden in der Rolle Storage Blob Daten Leser verwendet, die dem Backup Vault über das Storage-Konto zugewiesen ist, wenn Sicherungen im Vault Tier gespeichert werden sollen:

1. Microsoft.Storage/storageAccounts/blobServices/containers/read
2. Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action
3. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read

Nachfolgend finden Sie die Aktionen, die in der Rolle Mitwirkender verwendet werden, die dem Backup Vault über die Staging-Ressourcengruppe zugewiesen ist, wenn Sicherungen von Vault Tier wiederhergestellt werden sollen:

1. Microsoft.Resources/subscriptions/resourceGroups/read
2. Microsoft.Authorization/*/read
3. Microsoft.Compute/snapshots/*
4. Microsoft.Compute/disks/*

Im Folgenden finden Sie die Aktionen, die in der Rolle Storage Konto Mitwirkender verwendet werden, die dem Backup Vault über das Staging Storage-Konto zugewiesen wurde, wenn Sicherungen aus Vault Tier wiederhergestellt werden sollen:

1. Microsoft.Authorization/*/read
2. Microsoft.Storage/storageAccounts/*

Nachfolgend finden Sie die Aktionen, die in der Rolle Storage Blob Daten Besitzer verwendet werden, die dem Backup Vault über das Staging Storage-Konto zugewiesen wurde, wenn Sicherungen aus dem Vault Tier wiederhergestellt werden sollen:

1. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/*

Werden Momentaufnahmen für alle persistenten Volumes (PVs) in einer Sicherungskonfiguration genau zur gleichen Zeit erstellt oder gibt es eine Verzögerung?

Azure Backup für AKS unterstützt derzeit nicht das Erstellen von Momentaufnahmen aller PVs in genau derselben Millisekunden. Während die Momentaufnahmevorgänge parallel initiiert werden, kann es aufgrund der Infrastruktur und der API-Zeitsteuerung zu geringfügigen Verzögerungen zwischen einzelnen PV-Momentaufnahmen kommen. Um Konsistenz über mehrere PVs hinweg zu erzielen, unterstützt Azure Backup anwendungskonsistente Sicherungen mithilfe von Hooks. Hooks ermöglichen Benutzern, Schreiboperationen der Anwendung anzuhalten, bevor eine Momentaufnahme erstellt wird, und diese danach fortzusetzen. Dieser Ansatz verbessert die Konsistenz und imitiert die Absturzkonsistenz, obwohl sie möglicherweise nicht mit echten gleichzeitigen Momentaufnahmen oder koordinierter Konsistenz auf Datenbankebene gleichwertig ist.

Was geschieht, wenn ich die Option "Überspringen" für Kubernetes-Ressourcen einschließlich PVCs während einer AKS-Wiederherstellung auswähl?

Das Auswählen von "Überspringen" bedeutet, dass der Wiederherstellungsvorgang nicht versucht, kubernetes-Ressourcen neu zu erstellen. Wenn übereinstimmende Ressourcen bereits im Zielcluster vorhanden sind, werden sie wie sie sind wiederverwendet. Wenn sie nicht vorhanden sind, versucht Azure Backup, sie dynamisch neu zu erstellen. Stellen Sie bei PVs sicher, dass kompatible StorageClass-Definitionen und -Berechtigungen in der Zielumgebung vorhanden sind.

Warum versucht der wiederhergestellte Cluster, PVCs aus dem ursprünglichen Quellcluster einzubinden?

Dies geschieht in der Regel, wenn der wiederhergestellte Cluster auf persistente Volumes (PVs) verweist, die weiterhin auf die ursprüngliche Quellressourcengruppe verweisen. AKS trennt Clusterressourcen in zwei Ressourcengruppen: eine für die Steuerungsebene und eine für infrastruktur (z. B. Datenträger). Wenn die Zuordnung von PVC zu PV während der Wiederherstellung nicht korrekt aktualisiert wurde, könnten die wiederhergestellten Workloads versuchen, Quell-PVs anzuhängen, was zu Fehlern führen kann. Stellen Sie sicher, dass der Wiederherstellungsprozess PVCs korrekt auf neue oder bestehende PVs in der Ressourcengruppe des Ziel-Clusters neu zuordnet.

Nächste Schritte

• Azure Backup für AKS-Unterstützungsmatrix

Dieser Artikel beantwortet häufig gestellte Fragen zu Azure Backup für Azure Kubernetes Service. Weitere Informationen zur Verfügbarkeit der Azure Backup für AKS-Regionen , unterstützten Szenarien und Einschränkungen finden Sie in der Supportmatrix.

Häufig gestellte Fragen

Sie müssen die AKS-Sicherungserweiterung in Ihrem AKS-Cluster installieren, um die Sicherung zu ermöglichen, da sie Ihren Cluster in den systemeigenen Sicherungsdienst von Azure integriert, die zentrale Verwaltung, Automatisierung und Sicherheit für Ihre Sicherungen bereitstellt. Die Erweiterung interagiert mit Kubernetes-APIs, um sicherzustellen, dass Kubernetes-Workloads (persistente Volumes, Konfigurationen und Metadaten) ordnungsgemäß gesichert und wiederhergestellt werden.

Die Installation der AKS-Sicherungserweiterung erfordert ein Speicherkonto und einen BLOB-Container als Eingaben. Das Speicherkonto muss sich in derselben Region wie der AKS-Cluster befinden, und der BLOB-Container muss sich im gleichen Speicherkonto befinden. Der BLOB-Container wird verwendet, um sowohl die Sicherungsdaten als auch die zugehörigen Metadaten zu speichern. Zu den spezifischen Anforderungen für das Speicherkonto und den BLOB-Container gehören:

• Das Speicherkonto muss vom Standard general-purpose v2 Typ sein.
• Der BLOB-Container muss im Speicherkonto erstellt werden, bevor die AKS-Sicherungserweiterung installiert wird.
• Der BLOB-Container sollte vorzugsweise vor der Installation leer sein oder zumindest keine nicht mit demBack verbundenen Daten darin enthalten sein, da die Erweiterung eine eigene Ordnerstruktur innerhalb des Containers erstellt, um Sicherungsdaten und Metadaten zu speichern.
• Wenn sich der AKS-Cluster in einem privaten Netzwerk befindet, muss auf das Speicherkonto über den AKS-Cluster zugegriffen werden. Dies kann mithilfe eines privaten Endpunkts für das Speicherkonto oder durch Konfigurieren der erforderlichen Netzwerkregeln erreicht werden, um den Zugriff vom AKS-Cluster auf das Speicherkonto zu ermöglichen.

Die Pods, die mit der AKS Backup Extension verbunden sind, werden auf den Knotenpools des AKS-Clusters bereitgestellt. Um diese Pods erfolgreich bereitzustellen und zu verhindern, dass sie Ihre Anwendungsressourcen beeinträchtigen, stellen Sie Folgendes sicher:

• Der AKS-Cluster muss über den Agenten-Knotenpool mit dem Betriebssystem Linux, einschließlich Azure Linux und Ubuntu verfügen.
• Der Agentknotenpool muss über Azure Virtual Machine Scale Sets SKUs verfügen, die auf einer nicht ARM64 basierten Architektur basieren.
• Der Agenten-Pool muss mit dem Taint CriticalAddOnOnly verknüpft sein. Dieser Taint wird dem Knoten-Pool automatisch hinzugefügt, wenn der AKS-Cluster über das Portal erstellt wird. Er stellt sicher, dass nur kritische Add-On Pods, wie z. B. die Pods der AKS Backup Extension, auf dem Knoten-Pool eingeplant werden. Dadurch wird verhindert, dass Ihre Anwendungsworkloads beeinträchtigt werden, und es wird sichergestellt, dass Sicherungsvorgänge von anderen Workloads im Cluster isoliert sind. Falls der Taint nicht vorhanden ist, können Sie ihn manuell hinzufügen, bevor Sie die AKS Backup Extension installieren.

Azure Backup für AKS basiert auf Pods, die im AKS-Cluster als Teil der Sicherungserweiterung unter dem Namespace dataprotection-microsoftbereitgestellt werden. Um Sicherungs- und Wiederherstellungsvorgänge auszuführen, weisen diese Pods bestimmte CPU- und Speicheranforderungen auf.

• Arbeitsspeicher: Anforderungen - 256Mi, Grenzwerte - 1280Mi
• CPU: Anforderungen - 500m, Grenzwerte - 1000m

Wenn Sie die AKS-Sicherungserweiterung installieren, werden sicherungsbezogene Ressourcen im Cluster unter dem dataprotection-microsoft Namespace bereitgestellt. Die folgenden drei Bereitstellungen werden in diesem Namespace erstellt:

dataprotection-microsoft-controller dataprotection-microsoft-geneva-service dataprotection-microsoft-kubernetes-agent

Da die AKS Backup Extension auf der Arc Extensions for AKS Plattform erstellt wurde, werden außerdem zwei weitere Bereitstellungen im kube-system Namespace erstellt:

extension-agent extension-operator

Diese Bereitstellungen unterstützen nicht nur die Sicherungserweiterung, sondern sind auch für andere Erweiterungen wie Flux und Azure Machine Learning erforderlich.

Im Rahmen der Installation der Sicherungserweiterung wird auch eine Benutzeridentität in der Node-Ressourcengruppe des Clusters erstellt. Diese Identität wird von der AKS-Sicherungserweiterung verwendet, um auf die azure-Ressourcen zuzugreifen, die für Sicherungsvorgänge erforderlich sind. Der Benutzeridentität wird die Rolle Storage Blob Data Contributor für das Speicherkonto zugewiesen, um den Zugriff auf die Erweiterung zu ermöglichen. Wenn die Erweiterung aus dem AKS-Cluster deinstalliert wird, wird die Identität ebenfalls gelöscht.

Velero ist eine Drittanbieter-Backup-Lösung für Kubernetes, die mit der AKS Backup Extension in Konflikt stehen kann. Es wird empfohlen, nur die AKS-Sicherungserweiterung für Sicherungsvorgänge in einem Cluster zu verwenden, aber nicht beide gleichzeitig. AKS Backup Extension stellt auch Velero CRDs im Cluster bereit. Wenn das eigenständige Velero zusammen mit der AKS Backup Extension im AKS-Cluster installiert wird und die von den beiden Installationen verwendeten Versionen zu irgendeinem Zeitpunkt voneinander abweichen, kann dies zu Fehlern aufgrund von Vertragskonflikten führen. Darüber hinaus können benutzerdefinierte Velero-Konfigurationen, die von Ihnen erstellt wurden, wie beispielsweise eine VolumeSnapshotClass für die CSI-basierte Snapshot-Erstellung mit Velero, das AKS Backup-Setup für die Snapshot-Erstellung beeinträchtigen. Velero-Anmerkungen, die velero.io enthalten und auf verschiedene Ressourcen im Cluster angewendet werden, können ebenfalls das Verhalten der AKS-Sicherung beeinträchtigen.

Azure Backup für AKS bietet Sicherung der Betriebsebene für AKS-Cluster. Daher werden die Momentaufnahmen von Azure-Disk-basierten Persistent Volumes, die während der geplanten und On-Demand-Sicherungsvorgänge erstellt werden, in einer Ressourcengruppe in Ihrem Abonnement gespeichert. Azure Backup bietet eine sofortige Wiederherstellung, da die inkrementellen Momentaufnahmen in Ihrem Abonnement gespeichert sind. Diese Ressourcengruppe wird als Momentaufnahme-Ressourcengruppe bezeichnet. Es ist obligatorisch, während der Sicherungskonfiguration eine Momentaufnahmeressourcengruppe bereitzustellen, und sobald sie zugeordnet wurde, kann sie nicht mehr geändert werden.

Wenn Sicherungen aus dem Vault Tier wiederhergestellt werden sollen, sind eine Staging Ressourcengruppe und ein Storage-Konto erforderlich. Bei einer solchen Wiederherstellung werden die Sicherungsdaten im Vault zunächst in den Staging-Ort hydriert und dann mit der im Cluster installierten Erweiterung im Ziel-AKS-Cluster wiederhergestellt. Die Staging-Ressourcengruppe wird verwendet, um die gesicherten Datenträger vorübergehend wiederherzustellen. Das Staging Storage-Konto wird verwendet, um die in den Sicherungsdaten gespeicherten Kubernetes-Ressourcen im Vault Tier zu speichern. Die Sicherungen, die einmal im Staging Storage erstellt wurden, müssen manuell bereinigt werden.

Azure Backup für AKS basiert auf CSI-treiberbasierten Momentaufnahmen für seine Sicherungs- und Wiederherstellungsvorgänge. Die folgenden persistenten Volumetypen werden unterstützt:

Azure Disk-basierte persistente Volumes: Zugeordnet über den CSI-Treiber mit den folgenden SKUs:

• Premium-SSD
• Standard-SSD
• Standard-Festplatte
• Premium-SSD v2
• Ultra Disks

Hinweis

Während Snapshot- und Wiederherstellungsvorgänge für alle Datenträger-SKUs unterstützt werden, können Vorgänge für Premium SSD v2 und Ultra Disks länger dauern, da der Prozess das Kopieren von Daten vom Volume in eine Momentaufnahme und zurück umfasst. Der Snapshot kann verfügbar erscheinen und das Volume kann gemountet werden, bevor der zugrunde liegende Datenkopiervorgang vollständig abgeschlossen ist, was zu einer Verzögerung führt, bevor die wiederhergestellten Daten sichtbar werden.

In Bezug auf Azure-Datenträger mit Netzwerkzugriffseinstellungen:

• Die Betriebsebene unterstützt sowohl öffentliche als auch private Zugriffsdatenträger beliebiger Größe.
• Die Tresorebene unterstützt nur Datenträger mit öffentlichem Zugriff mit einer maximalen Größe von bis zu 1 TB.

Azure Files-basierte persistente Volumes: Über den CSI-Treiber (file.csi.azure.com) mit den folgenden Merkmalen bereitgestellt:

• Nur SMB-Protokoll (NFS wird nicht unterstützt)
• Sowohl Standard- als auch Premium-Dateifreigaben
• Nur öffentliche Netzwerkendpunkte (private Endpunkte werden nicht unterstützt)
• Maximal 25.000 Dateien pro Dateifreigabe
• Nur Sicherung der Betriebsebene (Vault-Ebene wird nicht unterstützt)
• Aufbewahrung bis zu 30 Tage

Andere Azure-Speicheroptionen wie Azure Blob, Azure Container Storage, Azure NetApp Files, Azure Managed Lustre und Speicherlösungen von Drittanbietern werden derzeit nicht unterstützt. Erfahren Sie mehr über die Unterstützung und Einschränkungen von Azure Files.

Wenn ein AKS-Cluster persistente Volumes von nicht unterstützten Typen enthält, werden diese Volumes während des Sicherungsvorgangs übersprungen. Die gesamte Sicherung wird dennoch erfolgreich sein, aber die nicht unterstützten Volumes werden nicht in die Sicherung einbezogen.

Azure Backup für AKS unterstützt zwei Arten von Sicherungsspeicherebenen:

• Betriebsebene: Diese Stufe wird für die kurzfristige Aufbewahrung von Sicherungen verwendet. Es speichert inkrementelle Snapshots von persistenten Volumes innerhalb Ihres Abonnements als Sicherungskopie. Diese Stufe eignet sich ideal für schnelle Wiederherstellungen und Betriebswiederherstellungsszenarien.
• Archivstufe: Diese Stufe wird für die Langzeitaufbewahrung von Sicherungen verwendet. Es speichert Sicherungsdaten, die auf betriebsbereiter Ebene gespeichert sind, konvertieren sie in Block-Blobs und speichern sie dann in Speicherkonten (als Tresor bezeichnet) in einem gesicherten Azure-Mandanten, der von Microsoft verwaltet wird. Diese Stufe eignet sich ideal für Compliance- und behördliche Anforderungen, da Sie Sicherungen für längere Zeiträume in niedriger Speicherebene aufbewahren können.

Sie können die Sicherungsspeicherebene definieren, wenn Sie eine Sicherungsrichtlinie erstellen. Die Standardregel besteht darin, die Betriebsstufe für die Sicherung zu verwenden. Sie können weitere Regeln hinzufügen, um Daten in der Tresorebene zusammen mit der Operativen Ebene zu sichern.

Die Sicherungshäufigkeit wird in der Sicherungsrichtlinie definiert.

• Im Operational Tier können Sicherungen so häufig wie alle 4 Stunden durchgeführt werden.
• Auf der Vault-Tier kann nur eine Sicherung pro Tag gespeichert werden.

Sie können Regeln konfigurieren, um die erste erfolgreiche Sicherung des Tages, der Woche, des Monats oder des Jahres in den Vault Tier zu verschieben. Diese Einstellungen können basierend auf Ihren Zielen für Wiederherstellungspunkte (RECOVERY Point Objectives, RPOs) und Aufbewahrungsanforderungen angepasst werden.

Geplante Sicherungen werden innerhalb eines 2-Stunden-Fensters ab der geplanten Zeit gemäß der Sicherungsrichtlinie ausgeführt. Sie können daher bei der AKS-Backup mit einer maximalen Verzögerung von 2 Stunden beim Beginn des Backups im Vergleich zur geplanten Sicherungszeit rechnen.

Sobald eine Sicherung im Operational Tier erstellt wurde und wenn sie den in der Sicherungsrichtlinie definierten Regeln entspricht, kommt sie sofort für den Vault in Frage. Danach wird die Übertragung in den Vault Tier innerhalb der nächsten 4 Stunden eingeleitet.

Eine Sicherungsrichtlinie, die die Aufbewahrung nach dem Prinzip "erste erfolgreiche Sicherung der Woche/des Monats/des Jahres" festlegt, wählt die erste erfolgreiche Sicherung jeder Woche, jedes Monats oder Jahres aus und behält sie gemäß der angegebenen Aufbewahrungsdauer bei. Die Definition von "first" ist systemdefiniert , z. B.:

• Woche: Sonntag gilt als Beginn der Woche
• Monat: Der erste Tag des Monats
• Jahr: 1. Januar

Dieses Verhalten basiert nicht auf dem Datum, an dem die Richtlinie erstellt oder aktiviert wurde.

Ein AKS-Cluster kann mehrere Anwendungen gleichzeitig hosten, die jeweils auf unterschiedliche Namespaces festgelegt sind. Azure Backup ermöglicht es Ihnen, einen AKS-Cluster mehrmals gemäß verschiedenen Anwendungskonfigurationen zu sichern, entweder in verschiedenen Sicherungstresorn oder unter Verwendung unterschiedlicher Sicherungsrichtlinien innerhalb desselben Sicherungstresors.

Azure Backup für AKS unterstützt georedundante Sicherungen, sodass Sie Ihre Daten in einer anderen Azure-Region wiederherstellen können, wenn ein regionaler Ausfall vorhanden ist. Die Sicherungsdaten werden redundant gemacht, indem sie in eine Azure-gekoppelte Region repliziert werden.

Um Ihre Sicherungen geografisch redundant zu machen, besteht der erste Schritt darin, sie in einem Sicherungstresor zu konfigurieren, der Geo-Redundanz und regionsübergreifende Wiederherstellung aktiviert hat.

Konfigurieren Sie als Nächstes die Sicherungsinstanz mit einer Sicherungsrichtlinie, die Aufbewahrungsregeln für die Tresorebene enthält.

Bei diesen Einstellungen wird eine Sicherung, sobald sie auf die Tresorebene verschoben wurde, automatisch in die gekoppelte sekundäre Azure-Region repliziert.

Im Falle eines regionalen Ausfalls können Sie die Sicherung aus der sekundären Region entweder über das Azure-Portal oder die Azure CLI wiederherstellen.

Sobald eine Sicherung in den Vault Tier verschoben wurde, kann es bis zu 12 Stunden dauern, bis sie in der sekundären Region repliziert ist. Daher beträgt das maximale RPO für einen Wiederherstellungspunkt, der in den von Azure Backup für AKS unterstützten sekundären Regionen verfügbar ist, Stunden, wenn Sicherungsdaten in der sekundären Region vorhanden sind. Dies bedeutet, dass Sie im Falle eines regionalen Ausfalls Ihre Sicherungsdaten aus der sekundären Region mit einem maximalen Datenverlust von 24 Stunden wiederherstellen können.

Azure Backup für AKS verwendet den Ansatz mit den geringsten Berechtigungen, um die AKS-Cluster in Ihren Abonnements zu ermitteln, zu schützen und wiederherzustellen. Um dies zu erreichen, verwendet Azure Backup die verwaltete Identität des Sicherungstresors, um auf andere Azure-Ressourcen zuzugreifen. Sie können berechtigungen für die verwaltete Identität, das zugewiesene System oder den benutzer gewähren, indem Sie die rollenbasierte Zugriffssteuerung (Azure RBAC) verwenden. Eine verwaltete Identität ist ein spezieller Dienstprinzipal, der nur zusammen mit Azure-Ressourcen verwendet werden kann. Standardmäßig hat der Backup Vault keine Berechtigung, auf den zu sichernden AKS-Cluster zuzugreifen, periodische Snapshots zu erstellen, Snapshots nach der Aufbewahrungsperiode zu löschen und ein Backup wiederherzustellen. Durch das explizite Gewähren von Rollenzuweisungen für die verwaltete Identität des Sicherungstresors haben Sie die volle Kontrolle über die Verwaltung der Berechtigungen für die Ressourcen in den Abonnements.

Im Folgenden finden Sie die Aktionen, die in der Rolle Mitwirkender auf dem AKS-Cluster, der gesichert oder wiederhergestellt werden soll, zugewiesen sind:

1. Microsoft.Compute/snapshots/read
2. Microsoft.Compute/snapshots/write
3. Microsoft.Compute/Schnappschüsse/löschen

Im Folgenden finden Sie die Aktionen, die in der Rolle Mitwirkender bei Storage Blob Data verwendet werden, die der Erweiterungsidentität des AKS-Clusters zugewiesen ist, der gesichert oder auf den wiederhergestellt werden soll, über das Storage-Konto:

1. Microsoft.Storage/storageAccounts/blobServices/containers/read
2. Microsoft.Storage/storageAccounts/blobServices/containers/write
3. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
4. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
5. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete
6. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action

Im Folgenden finden Sie die Aktionen, die in der Rolle Leser verwendet werden, die dem Backup Vault über den AKS-Cluster zugewiesen ist:

1. */Lesen

Nachfolgend finden Sie die Aktionen, die in der Rolle Leser verwendet werden, die dem Backup Vault über die Snapshot-Ressourcengruppe zugewiesen ist:

1. Microsoft.Authorization/*/read
2. Microsoft.Resources/subscriptions/resourceGroups/read

Nachfolgend finden Sie die Aktionen, die in der Rolle Datenträger Snapshot Mitwirkender verwendet werden, die dem Backup Vault über die Snapshot Ressourcengruppe zugewiesen wurde, falls Sicherungen im Vault Tier gespeichert werden sollen:

1. Microsoft.Compute/Schnappschüsse/löschen
2. Microsoft.Compute/snapshots/write
3. Microsoft.Compute/snapshots/read
4. Microsoft.Compute/snapshots/beginGetAccess/action
5. Microsoft.Compute/snapshots/endGetAccess/action
6. Microsoft.Compute/disks/beginGetAccess/action

Im Folgenden finden Sie die Aktionen, die in der Rolle Daten-Operator für Managed Disks verwendet werden, die dem Backup Vault über die Snapshot-Ressourcengruppe zugewiesen wurde, wenn Sicherungen im Vault-Tier gespeichert werden sollen:

1. Microsoft.Compute/disks/download/action
2. Microsoft.Compute/snapshots/download/action

Die folgenden Aktionen werden in der Rolle Storage Blob Daten Leser verwendet, die dem Backup Vault über das Storage-Konto zugewiesen ist, wenn Sicherungen im Vault Tier gespeichert werden sollen:

1. Microsoft.Storage/storageAccounts/blobServices/containers/read
2. Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action
3. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read

Nachfolgend finden Sie die Aktionen, die in der Rolle Mitwirkender verwendet werden, die dem Backup Vault über die Staging-Ressourcengruppe zugewiesen ist, wenn Sicherungen von Vault Tier wiederhergestellt werden sollen:

1. Microsoft.Resources/subscriptions/resourceGroups/read
2. Microsoft.Authorization/*/read
3. Microsoft.Compute/snapshots/*
4. Microsoft.Compute/disks/*

Im Folgenden finden Sie die Aktionen, die in der Rolle Storage Konto Mitwirkender verwendet werden, die dem Backup Vault über das Staging Storage-Konto zugewiesen wurde, wenn Sicherungen aus Vault Tier wiederhergestellt werden sollen:

1. Microsoft.Authorization/*/read
2. Microsoft.Storage/storageAccounts/*

Nachfolgend finden Sie die Aktionen, die in der Rolle Storage Blob Daten Besitzer verwendet werden, die dem Backup Vault über das Staging Storage-Konto zugewiesen wurde, wenn Sicherungen aus dem Vault Tier wiederhergestellt werden sollen:

1. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/*

Azure Backup für AKS unterstützt derzeit nicht das Erstellen von Momentaufnahmen aller PVs in genau derselben Millisekunden. Während die Momentaufnahmevorgänge parallel initiiert werden, kann es aufgrund der Infrastruktur und der API-Zeitsteuerung zu geringfügigen Verzögerungen zwischen einzelnen PV-Momentaufnahmen kommen. Um Konsistenz über mehrere PVs hinweg zu erzielen, unterstützt Azure Backup anwendungskonsistente Sicherungen mithilfe von Hooks. Hooks ermöglichen Benutzern, Schreiboperationen der Anwendung anzuhalten, bevor eine Momentaufnahme erstellt wird, und diese danach fortzusetzen. Dieser Ansatz verbessert die Konsistenz und imitiert die Absturzkonsistenz, obwohl sie möglicherweise nicht mit echten gleichzeitigen Momentaufnahmen oder koordinierter Konsistenz auf Datenbankebene gleichwertig ist.

Das Auswählen von "Überspringen" bedeutet, dass der Wiederherstellungsvorgang nicht versucht, kubernetes-Ressourcen neu zu erstellen. Wenn übereinstimmende Ressourcen bereits im Zielcluster vorhanden sind, werden sie wie sie sind wiederverwendet. Wenn sie nicht vorhanden sind, versucht Azure Backup, sie dynamisch neu zu erstellen. Stellen Sie bei PVs sicher, dass kompatible StorageClass-Definitionen und -Berechtigungen in der Zielumgebung vorhanden sind.

Dies geschieht in der Regel, wenn der wiederhergestellte Cluster auf persistente Volumes (PVs) verweist, die weiterhin auf die ursprüngliche Quellressourcengruppe verweisen. AKS trennt Clusterressourcen in zwei Ressourcengruppen: eine für die Steuerungsebene und eine für infrastruktur (z. B. Datenträger). Wenn die Zuordnung von PVC zu PV während der Wiederherstellung nicht korrekt aktualisiert wurde, könnten die wiederhergestellten Workloads versuchen, Quell-PVs anzuhängen, was zu Fehlern führen kann. Stellen Sie sicher, dass der Wiederherstellungsprozess PVCs korrekt auf neue oder bestehende PVs in der Ressourcengruppe des Ziel-Clusters neu zuordnet.

Nächste Schritte

• Azure Backup für AKS-Unterstützungsmatrix