Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure Kubernetes Service (AKS) -Sicherung ist ein einfacher, cloudeigener Prozess, mit dem Sie containerisierte Anwendungen und Daten sichern und wiederherstellen können, die in Ihrem AKS-Cluster ausgeführt werden. Sie können geplante Sicherungen für Clusterstatus- und Anwendungsdaten konfigurieren, die auf persistenten Kubernetes-Volumes in auf CSI-Treibern (Container Storage Interface) basierenden Azure Disk Storage-Instanzen gespeichert sind.
Die Lösung bietet Ihnen präzise Kontrolle. Sie können einen bestimmten Namespace oder einen gesamten Cluster sichern oder wiederherstellen, indem Sie Sicherungen lokal in einem Blobcontainer und als Momentaufnahmen von Datenträgern speichern. Sie können die AKS-Sicherung für End-to-End-Szenarien verwenden, einschließlich betriebsbereiter Wiederherstellung, Klonen von Entwickler- oder Testumgebungen und Clusterupgradeszenarien.
Die AKS-Sicherung ist in das Backup Center in Azure integriert, um eine einzelne Ansicht bereitzustellen, die Ihnen dabei helfen kann, Sicherungen im großen Maßstab zu steuern, zu überwachen, zu betreiben und zu analysieren. Ihre Sicherungen sind auch im Azure-Portal unter "Einstellungen " im Dienstmenü für eine AKS-Instanz verfügbar.
Wie funktioniert die AKS-Sicherung?
Sie können die AKS-Sicherung verwenden, um Ihre AKS-Workloads und persistenten Volumes zu sichern, die in AKS-Clustern bereitgestellt werden. Die Lösung erfordert die Installation der Backup-Erweiterung im AKS-Cluster. Der Backup-Tresor kommuniziert mit der Erweiterung, Erweiterung, um Sicherungs- und Wiederherstellungsvorgänge abzuschließen. Die Verwendung der Sicherungserweiterung ist obligatorisch. Die Erweiterung muss innerhalb des AKS-Clusters installiert werden, um die Sicherung und Wiederherstellung für den Cluster zu aktivieren. Wenn Sie die AKS-Sicherung konfigurieren, fügen Sie Werte für ein Speicherkonto und einen Blobcontainer hinzu, in dem Sicherungen gespeichert werden.
Zusammen mit der Backup-Erweiterung wird eine Benutzeridentität (die als Erweiterungsidentität bezeichnet wird) in der verwalteten Ressourcengruppe des AKS-Clusters erstellt. Der Erweiterungsidentität wird die Rolle „Speicherkontomitwirkender“ für das Speicherkonto zugewiesen, in dem Sicherungen in einem Blobcontainer gespeichert werden.
Um öffentliche, private und autorisierte IP-basierte Cluster zu unterstützen, erfordert die AKS-Sicherung, dass Sie das Feature "Vertrauenswürdiger Zugriff" zwischen dem AKS-Cluster und dem Sicherungstresor aktivieren. Durch den vertrauenswürdigen Zugriff kann der Backup-Tresor aufgrund spezifischer Berechtigungen, die ihm für Sicherungsvorgänge zugewiesen wurden, auf den AKS-Cluster zugreifen. Weitere Informationen zum vertrauenswürdigen Zugriff von AKS finden Sie unter Aktivieren von Azure-Ressourcen für den Zugriff auf AKS-Cluster mithilfe des vertrauenswürdigen Zugriffs.
Mit der AKS-Sicherung können Sie Sicherungen sowohl auf Betriebsebene als auch auf Tresorebene speichern. Die Betriebsebene ist ein lokaler Datenspeicher (Sicherungen werden in Ihrem Mandanten als Momentaufnahmen gespeichert). Sie können jetzt einen Wiederherstellungspunkt pro Tag verschieben und ihn mithilfe der AKS-Sicherung als Blobs (außerhalb Ihres Mandanten) auf Tresorebene speichern. Sicherungen, die auf der Tresorebene gespeichert sind, können auch verwendet werden, um Daten in einer sekundären Region (Azure-gekoppelte Region) wiederherzustellen.
Nachdem Sie die Sicherungserweiterung installiert und den vertrauenswürdigen Zugriff aktiviert haben, können Sie geplante Sicherungen für die Cluster entsprechend Ihrer Sicherungsrichtlinie konfigurieren. Sie können die Sicherungen auch auf dem ursprünglichen Cluster oder in einem anderen Cluster im selben Abonnement und derselben Region wiederherstellen. Beim Einrichten des spezifischen Vorgangs können Sie einen bestimmten Namespace oder einen gesamten Cluster als Sicherungs- und Wiederherstellungskonfiguration auswählen.
Die AKS-Sicherung ermöglicht Sicherungsvorgänge für Ihre AKS-Datenquellen, die im Cluster bereitgestellt werden. Es ermöglicht außerdem Sicherungsvorgänge für die daten, die im persistenten Volume für den Cluster gespeichert sind. Anschließend werden die Sicherungen in einem Blob-Container gespeichert. Die datenträgerbasierten persistenten Volumes werden als Momentaufnahmen von Datenträgern in einer Ressourcengruppe für Momentaufnahmen gesichert. Die Kombination von Momentaufnahmen und Clusterzustand in einem Blob bildet einen Wiederherstellungspunkt, der in Ihrem Mandanten unter dem Namen „Betriebsebene“ gespeichert wird. Sie können auch Sicherungen (erste erfolgreiche Sicherung in einem Tag, einer Woche, einem Monat oder einem Jahr) in der Betriebsebene in Blobs konvertieren und sie dann einmal pro Tag in einen Tresor (außerhalb Ihres Mandanten) verschieben.
Hinweis
Derzeit unterstützt Azure Backup nur persistente Volumes in CSI-Treiber-basierter Azure Disk Storage. Während der Sicherungen werden andere Typen von persistenten Volumes, z. B. Azure Files-Freigabe und Blobs, von der Lösung übersprungen. Wenn Sie Aufbewahrungsregeln für die Tresorebene festgelegt haben, können Sicherungen zudem nur in den Tresor verschoben werden, wenn die persistenten Volumes kleiner oder gleich 1 TB sind.
Konfigurieren der Sicherung
Um die Sicherung für AKS-Cluster zu konfigurieren, erstellen Sie zunächst einen Backup-Tresor. Der Tresor bietet eine konsolidierte Ansicht der Sicherungen, die für unterschiedliche Datenquellen konfiguriert werden. AKS-Sicherung unterstützt Sicherungen sowohl für die Betriebsebene als auch für die Tresorebene.
Die Redundanzeinstellung des Sicherungstresorspeichers (lokal redundanter Speicher oder georedundanter Speicher) gilt nur für Sicherungen, die auf der Tresorebene gespeichert sind. Wenn Sie Sicherungen für die Notfallwiederherstellung verwenden möchten, legen Sie die Speicherredundanz als GRS mit aktivierter regionsübergreifender Wiederherstellung fest.
Hinweis
Der Sicherungsspeicher und der AKS-Cluster, den Sie sichern oder wiederherstellen möchten, müssen sich in derselben Region und im selben Abonnement befinden.
Die AKS-Sicherung löst automatisch einen geplanten Sicherungsauftrag aus. Der Auftrag kopiert die Clusterressourcen in einen Blobcontainer und erstellt eine inkrementelle Momentaufnahme der datenträgerbasierten persistenten Volumes gemäß der Sicherungshäufigkeit. Die Sicherungen werden entsprechend der in der Sicherungsrichtlinie festgelegten Aufbewahrungsdauer in der Betriebsebene und der Tresorebene aufbewahrt. Die Sicherungen werden gelöscht, wenn die Dauer abgelaufen ist.
Sie können die AKS-Sicherung verwenden, um mehrere Sicherungsinstanzen für einen einzelnen AKS-Cluster zu erstellen, indem Sie verschiedene Sicherungskonfigurationen pro Sicherungsinstanz verwenden. Es wird jedoch empfohlen, jede Sicherungsinstanz eines AKS-Clusters auf eine der folgenden beiden Arten zu erstellen:
- In einem anderen Backup-Tresor
- Beim Verwenden einer separaten Sicherungsrichtlinie im selben Backup-Tresor
Verwalten von Sicherungen
Wenn die Sicherungskonfiguration für einen AKS-Cluster abgeschlossen ist, wird eine Sicherungsinstanz im Backup-Tresor erstellt. Sie können die Sicherungsinstanz für den Cluster im Abschnitt Backup für eine AKS-Instanz im Azure-Portal anzeigen. Sie können sämtliche sicherungsbezogenen Vorgänge für die Instanz, beispielsweise das Initiieren von Wiederherstellungen, das Überwachen, das Beenden des Schutzes und vieles mehr, über die entsprechende Sicherungsinstanz durchführen.
Die AKS-Sicherung ist auch direkt in das Backup Center integriert, damit Sie den Schutz für alle AKS-Cluster und andere sicherungsgestützte Workloads zentral verwalten können. Das Backup Center bietet eine einzige Ansicht für alle Ihre Sicherungsanforderungen, z. B. Überwachung von Aufträgen und status von Sicherungen und Wiederherstellungen. Das Backup Center hilft Ihnen dabei, Compliance und Governance sicherzustellen, die Sicherungsnutzung zu analysieren und wichtige Vorgänge auszuführen, um Daten zu sichern und wiederherzustellen.
Die AKS-Sicherung verwendet die verwaltete Identität für den Zugriff auf andere Azure-Ressourcen. Um die Sicherung eines AKS-Clusters zu konfigurieren und aus einer früheren Sicherung wiederherzustellen, benötigt die verwaltete Identität des Backup-Tresors eine Reihe von Berechtigungen für den AKS-Cluster. Außerdem ist eine Reihe von Berechtigungen für die Momentaufnahmeressourcengruppe erforderlich, in der Momentaufnahmen erstellt und verwaltet werden. Derzeit erfordert der AKS-Cluster eine Reihe von Berechtigungen für die Snapshot-Ressourcengruppe.
Außerdem erstellt die Backup-Erweiterung eine Benutzeridentität und weist eine Reihe von Berechtigungen für den Zugriff auf das Speicherkonto zu, in dem Sicherungen in einem Blob gespeichert werden. Sie können berechtigungen für die verwaltete Identität erteilen, indem Sie die rollenbasierte Zugriffssteuerung von Azure verwenden. Die verwaltete Identität ist ein spezieller Dienstprinzipaltyp, der nur zusammen mit Azure-Ressourcen verwendet werden kann. Weitere Informationen zu verwalteten Identitäten.
Wiederherstellen aus einem Backup
Sie können Daten von jedem Zeitpunkt wiederherstellen, für den ein Wiederherstellungspunkt vorhanden ist. Ein Wiederherstellungspunkt wird erstellt, wenn sich eine Sicherungsinstanz in einem geschützten Zustand befindet. Sie kann verwendet werden, um Daten wiederherzustellen, bis die Sicherungsrichtlinie die Daten aufbewahrt.
Azure Backup bietet Ihnen die Möglichkeit, alle gesicherten Elemente wiederherzustellen oder präzise Steuerelemente zu verwenden, um bestimmte Elemente aus den Sicherungen mithilfe von Namespaces und anderen Filteroptionen auszuwählen. Außerdem können Sie die Wiederherstellung auf dem ursprünglichen AKS-Cluster (dem gesicherten Cluster) oder auf einem alternativen AKS-Cluster ausführen. Sie können Sicherungen, die in der Betriebs- und Tresorebene gespeichert sind, in einem Cluster im selben oder in einem anderen Abonnement wiederherstellen. Nur in der Tresorebene gespeicherte Sicherungen können für eine Wiederherstellung in einem Cluster in einer anderen Region (gekoppelte Azure-Region) verwendet werden.
Um eine in der Tresorebene gespeicherte Sicherung wiederherzustellen, müssen Sie einen Stagingspeicherort bereitstellen, an dem die Sicherungsdaten aktualisiert werden. Dieser Stagingspeicherort umfasst eine Ressourcengruppe und ein darin enthaltenes Speicherkonto innerhalb derselben Region und desselben Abonnements wie der Zielcluster für die Wiederherstellung. Während der Wiederherstellung werden bestimmte Ressourcen (Blobcontainer, Datenträger und Momentaufnahmen von Datenträgern) als Teil der Hydration erstellt. Sie werden gelöscht, nachdem der Wiederherstellungsvorgang abgeschlossen ist.
Azure Backup für AKS unterstützt derzeit die folgenden beiden Optionen für ein Szenario, in dem ein Ressourcenkonflikt auftritt. Ein Ressourcenkonflikt tritt auf, wenn eine gesicherte Ressource denselben Namen wie die Ressource im Ziel-AKS-Cluster hat. Sie können eine dieser Optionen auswählen, wenn Sie die Wiederherstellungskonfiguration definieren.
Überspringen: Diese Option ist standardmäßig aktiviert. Wenn Sie beispielsweise ein Persistent Volume Claim (PVC) namens
pvc-azuredisk
sichern und es in einem Zielcluster wiederherstellen, in dem sich bereits ein PVC mit demselben Namen befindet, überspringt die Sicherungserweiterung die Wiederherstellung des gesicherten PVC. In solchen Szenarien wird empfohlen, die Ressource aus dem Cluster zu löschen. Führen Sie dann den Wiederherstellungsvorgang aus, damit die gesicherten Elemente nur im Cluster verfügbar sind und nicht übersprungen werden.Patch: Mit dieser Option kann die veränderbare Variable in der gesicherten Ressource auf der Ressource im Zielcluster gepatcht werden. Wenn Sie die Anzahl der Replikate im Zielcluster aktualisieren möchten, können Sie sich für das Patchen als Vorgang entscheiden.
Hinweis
Die AKS-Sicherung löscht derzeit keine Ressourcen im Zielcluster, sofern sie bereits vorhanden sind, und erstellt sie nicht erneut. Wenn Sie versuchen, persistente Volumes am ursprünglichen Speicherort wiederherzustellen, löschen Sie die vorhandenen persistenten Volumes, und führen Sie dann den Wiederherstellungsvorgang aus.
Verwenden benutzerdefinierter Hooks für Sicherung und Wiederherstellung
Sie können benutzerdefinierte Hooks verwenden, um anwendungskonsistente Snapshots von Volumes auszuführen, die für Datenbanken verwendet werden, die als containerisierte Workloads bereitgestellt werden.
Was sind benutzerdefinierte Hooks?
Mit der AKS-Sicherung können Sie benutzerdefinierte Hooks als Teil des Sicherungs- und Wiederherstellungsvorgangs ausführen. Hooks sind zum Ausführen eines oder mehrerer Befehle in einem Pod unter einem Container während des Sicherungsvorgangs oder nach der Wiederherstellung konfiguriert.
Sie definieren diese Hooks als benutzerdefinierte Ressource und stellen sie im AKS-Cluster bereit, der gesichert oder wiederhergestellt werden soll. Wenn die benutzerdefinierte Ressource im AKS-Cluster im erforderlichen Namespace bereitgestellt wird, geben Sie die Details als Eingabe für den Flow zum Konfigurieren der Sicherung und Wiederherstellung an. Die Backup-Erweiterung führt die Hooks wie in einer YAML-Datei definiert aus.
Hinweis
Hooks werden nicht in einer Shell auf den Containern ausgeführt.
Die Sicherung in AKS verfügt über zwei Arten von Hooks:
- Hooks für die Sicherung
- Hooks für die Wiederherstellung
Hooks für die Sicherung
Wenn Sie einen Sicherungshaken verwenden, können Sie die Befehle so konfigurieren, dass der Hook vor einer benutzerdefinierten Aktionsverarbeitung (PreHooks
) ausgeführt wird. Sie können den Hook auch ausführen, nachdem alle benutzerdefinierten Aktionen abgeschlossen sind und alle durch benutzerdefinierte Aktionen angegebenen zusätzlichen Elemente gesichert wurden (PostHooks
).
Hier sehen Sie beispielsweise die YAML-Vorlage für eine benutzerdefinierte Ressource, die mithilfe von Sicherungs-Hooks bereitgestellt werden soll:
apiVersion: clusterbackup.dataprotection.microsoft.com/v1alpha1
kind: BackupHook
metadata:
# BackupHook CR Name and Namespace
name: bkphookname0
namespace: default
spec:
# BackupHook is a list of hooks to execute before and after backing up a resource.
backupHook:
# BackupHook Name. This is the name of the hook that will be executed during backup.
# compulsory
- name: hook1
# Namespaces where this hook will be executed.
includedNamespaces:
- hrweb
excludedNamespaces:
labelSelector:
# PreHooks is a list of BackupResourceHooks to execute prior to backing up an item.
preHooks:
- exec:
# Container is the container in the pod where the command should be executed.
container: webcontainer
# Command is the command and arguments to execute.
command:
- /bin/uname
- -a
# OnError specifies how Velero should behave if it encounters an error executing this hook
onError: Continue
# Timeout is the amount of time to wait for the hook to complete before considering it failed.
timeout: 10s
- exec:
command:
- /bin/bash
- -c
- echo hello > hello.txt && echo goodbye > goodbye.txt
container: webcontainer
onError: Continue
# PostHooks is a list of BackupResourceHooks to execute after backing up an item.
postHooks:
- exec:
container: webcontainer
command:
- /bin/uname
- -a
onError: Continue
timeout: 10s
Hooks für die Wiederherstellung
Im Skript für Wiederherstellungshooks werden benutzerdefinierte Befehle oder Skripts geschrieben, die in den Containern eines wiederhergestellten AKS-Pods ausgeführt werden.
Dies ist die YAML-Vorlage für eine benutzerdefinierte Ressource, die über Wiederherstellungs-Hooks bereitgestellt wird:
apiVersion: clusterbackup.dataprotection.microsoft.com/v1alpha1
kind: RestoreHook
metadata:
name: restorehookname0
namespace: default
spec:
# RestoreHook is a list of hooks to execute after restoring a resource.
restoreHook:
# Name is the name of this hook.
- name: myhook-1
# Restored Namespaces where this hook will be executed.
includedNamespaces:
excludedNamespaces:
labelSelector:
# PostHooks is a list of RestoreResourceHooks to execute during and after restoring a resource.
postHooks:
- exec:
# Container is the container in the pod where the command should be executed.
container: webcontainer
# Command is the command and arguments to execute from within a container after a pod has been restored.
command:
- /bin/bash
- -c
- echo hello > hello.txt && echo goodbye > goodbye.txt
# OnError specifies how Velero should behave if it encounters an error executing this hook
# default value is Continue
onError: Continue
# Timeout is the amount of time to wait for the hook to complete before considering it failed.
execTimeout: 30s
# WaitTimeout defines the maximum amount of time Velero should wait for the container to be ready before attempting to run the command.
waitTimeout: 5m
Erfahren Sie, wie Sie Hooks während der AKS-Datensicherung verwenden.
Während der Wiederherstellung wartet die Sicherungserweiterung, bis der Container angezeigt wird, und führt dann exec-Befehle für sie aus, die in den Wiederherstellungshaken definiert sind.
Wenn Sie die Wiederherstellung im selben Namespace ausführen, der gesichert wurde, wird der Wiederherstellungs-Hook nicht ausgeführt. Es wird nur nach einem neu erstellten Container gesucht. Dieses Ergebnis tritt unabhängig davon auf, ob Sie die Skip- oder Patch-Richtlinie verwenden.
Ändern der Ressource beim Wiederherstellen von Sicherungen im AKS-Cluster
Sie können die Ressourcenänderungsfunktion verwenden, um gesicherte Kubernetes-Ressourcen während der Wiederherstellung zu ändern, indem Sie JSON-Patches als von configmap
bereitgestellt im AKS-Cluster angeben.
Erstellen und Anwenden einer ConfigMap mit Ressourcenmodifizierern während der Wiederherstellung
Führen Sie die folgenden Schritte aus, um Ressourcenänderungen zu erstellen und anzuwenden:
Erstellen Sie einen Ressourcenmodifizierer
configmap
.Sie müssen einen
configmap
in Ihrem bevorzugten Namespace aus einer YAML-Datei erstellen, die Ressourcenmodifizierer definiert hat.Beispiel für das Erstellen eines Befehls:
version: v1 resourceModifierRules: - conditions: groupResource: persistentvolumeclaims resourceNameRegex: "^mysql.*$" namespaces: - bar - foo labelSelector: matchLabels: foo: bar patches: - operation: replace path: "/spec/storageClassName" value: "premium" - operation: remove path: "/metadata/labels/test"
- In der vorherigen
configmap
wird der JSON-Patch auf alle Kopien des persistenten Volumes in dernamespaces
-Leiste undfoo
mit einem Namen angewendet, der mitmysql
beginnt undmatch label foo: bar
enthält. Der JSON-Patch ersetzt diestorageClassName
Bezeichnung durchpremium
und entfernt die Bezeichnungtest
aus den Kopien des persistenten Volumes. - Hier ist der
namespace
ursprüngliche Namespace der gesicherten Ressource und nicht der neue Namespace, in den die Ressource wiederhergestellt werden soll. - Sie können mehrere JSON-Patches für eine bestimmte Ressource angeben. Die Patches werden gemäß der in der
configmap
angegebenen Reihenfolge angewendet. Der nächste Patch wird in der Reihenfolge angewendet. Wenn mehrere Patches für denselben Pfad angegeben werden, setzt der letzte Patch die vorherigen Patches außer Kraft. - Sie können mehrere
resourceModifierRules
in derconfigmap
angeben. Die Regeln werden gemäß der in derconfigmap
Angegebenen Reihenfolge angewendet.
- In der vorherigen
Erstellen eines Verweises auf den Ressourcenmodifizierer in der Wiederherstellungskonfiguration
Geben Sie bei der Durchführung eines Wiederherstellungsvorgangs die
ConfigMap name
und dennamespace
an, in der sie als Teil der Wiederherstellungskonfiguration bereitgestellt wird. Diese Details müssen unter Regeln für den Ressourcenmodifizierer angegeben werden.
Von Ressourcenmodifizierer unterstützte Vorgänge
Add (Hinzufügen)
Sie können den Add-Vorgang verwenden, um dem JSON-Code der Ressource einen neuen Block hinzuzufügen. Im folgenden Beispiel fügt der Vorgang der Spezifikation mit einer Bereitstellung neue Containerdetails hinzu.
version: v1 resourceModifierRules: - conditions: groupResource: deployments.apps resourceNameRegex: "^test-.*$" namespaces: - bar - foo patches: # Dealing with complex values by escaping the yaml - operation: add path: "/spec/template/spec/containers/0" value: "{\"name\": \"nginx\", \"image\": \"nginx:1.14.2\", \"ports\": [{\"containerPort\": 80}]}"
Entfernen
Sie können den Remove-Vorgang verwenden, um einen Schlüssel aus dem Ressourcen-JSON zu entfernen. Im folgenden Beispiel entfernt die Operation das Etikett mit
test
als Schlüssel.version: v1 resourceModifierRules: - conditions: groupResource: persistentvolumeclaims resourceNameRegex: "^mysql.*$" namespaces: - bar - foo labelSelector: matchLabels: foo: bar patches: - operation: remove path: "/metadata/labels/test"
Ersetzen
Sie können den Vorgang Ersetzen verwenden, um einen Wert für den Pfad durch einen alternativen zu ersetzen. Im folgenden Beispiel ersetzt der Vorgang das
storageClassName
im PVC mitpremium
.version: v1 resourceModifierRules: - conditions: groupResource: persistentvolumeclaims resourceNameRegex: "^mysql.*$" namespaces: - bar - foo labelSelector: matchLabels: foo: bar patches: - operation: replace path: "/spec/storageClassName" value: "premium"
Kopieren
Sie können den Vorgang Kopieren verwenden, um einen Wert aus einem Pfad aus den definierten Ressourcen in einen anderen Pfad zu kopieren.
version: v1 resourceModifierRules: - conditions: groupResource: deployments.apps resourceNameRegex: "^test-.*$" namespaces: - bar - foo patches: - operation: copy from: "/spec/template/spec/containers/0" path: "/spec/template/spec/containers/1"
Test
Sie können den Test-Vorgang verwenden, um zu überprüfen, ob ein bestimmter Wert in der Ressource vorhanden ist. Wenn der Wert vorhanden ist, wird der Patch angewendet. Wenn der Wert nicht vorhanden ist, wird der Patch nicht angewendet. Im folgenden Beispiel überprüft der Vorgang, ob die PVCs
premium
alsStorageClassName
haben, und ersetzt diesen Wert durchstandard
, wenn dies zutrifft.version: v1 resourceModifierRules: - conditions: groupResource: persistentvolumeclaims resourceNameRegex: ".*" namespaces: - bar - foo patches: - operation: test path: "/spec/storageClassName" value: "premium" - operation: replace path: "/spec/storageClassName" value: "standard"
JSON-Patch
Diese
configmap
wendet den JSON-Patch standardmäßig auf alle Bereitstellungen in den Namespaces an undnginx
mit dem Namen, der mitnginxdep
beginnt. Der JSON-Patch aktualisiert die Anzahl der Replikate auf12
bei allen derartigen Bereitstellungen.version: v1 resourceModifierRules: - conditions: groupResource: deployments.apps resourceNameRegex: "^nginxdep.*$" namespaces: - default - nginx patches: - operation: replace path: "/spec/replicas" value: "12"
JSON-Zusammenführungspatch
Dadurch wird der JSON-Merge-Patch
configmap
auf alle Bereitstellungen in den Namespaces Standard undnginx
mit Namen angewendet, der mitnginxdep
beginnt. Der JSON-Zusammenführungspatch fügt die Bezeichnungapp
mit dem Wertnginx1
hinzu oder aktualisiert sie.version: v1 resourceModifierRules: - conditions: groupResource: deployments.apps resourceNameRegex: "^nginxdep.*$" namespaces: - default - nginx mergePatches: - patchData: | { "metadata" : { "labels" : { "app" : "nginx1" } } }
Strategischer Zusammenführungspatch
Dadurch wird der strategische Zusammenführungspatch
configmap
auf alle Pods im Namespace „default“ angewendet, deren Name mitnginx
beginnt. Der strategische Zusammenführungspatch aktualisiert das Image des Containersnginx
aufmcr.microsoft.com/cbl-mariner/base/nginx:1.22
.version: v1 resourceModifierRules: - conditions: groupResource: pods resourceNameRegex: "^nginx.*$" namespaces: - default strategicPatches: - patchData: | { "spec": { "containers": [ { "name": "nginx", "image": "mcr.microsoft.com/cbl-mariner/base/nginx:1.22" } ] } }
Welche Datensicherungsebene unterstützt das AKS Backup?
Azure Backup für AKS unterstützt zwei Speicherebenen als Sicherungsdatenspeicher:
Betriebsebene: Die im AKS-Cluster installierte Backup-Erweiterung erstellt zunächst eine Sicherung, indem sie Volumemomentaufnahmen über den CSI-Treiber erstellt. Anschließend wird der Clusterstatus in einem Blobcontainer in Ihrer eigenen Instanz gespeichert. Diese Stufe unterstützt ein niedrigeres Wiederherstellungspunktziel (RPO) mit der Mindestdauer von vier Stunden zwischen zwei Sicherungen. Darüber hinaus unterstützt die Betriebsstufe für Azure-datenträgerbasierte Volumes schnellere Wiederherstellungen.
Tresorebene: Zum Speichern von Sicherungsdaten für eine längere Dauer mit niedrigeren Kosten als Momentaufnahmen unterstützt die AKS-Sicherung Tresorstandarddatenspeicher. Gemäß den in der Sicherungsrichtlinie festgelegten Aufbewahrungsregeln wird die erste erfolgreiche Sicherung (eines Tages, einer Woche, eines Monats oder eines Jahres) in einen Blob-Container außerhalb Ihres Mandanten verschoben. Dieser Datenspeicher ermöglicht nicht nur eine längere Aufbewahrung, sondern bietet auch Schutz vor Ransomware. Sie können Sicherungen, die im Backup-Tresor gespeichert sind, auch in eine andere Region (Azure-Partnerregion) für die Wiederherstellung verschieben, indem Sie Georedundanz und Regionsübergreifende Wiederherstellung im Sicherungstresor aktivieren.
Hinweis
Sie können die Sicherungsdaten über Backup Policy in einem Tresor-Standarddatenspeicher speichern, indem Sie Aufbewahrungsregeln definieren. Nur ein geplanter Wiederherstellungspunkt pro Tag wird auf die Tresorebene verschoben. Allerdings können Sie eine beliebige Anzahl von On-Demand-Sicherungen gemäß der ausgewählten Regel in den Tresor verschieben.
Grundlegendes zu Preisen
Es entstehen Gebühren für:
Gebühr für geschützte Instanzen: Azure Backup für AKS berechnet eine Gebühr für geschützte Instanzen pro Namespace und Monat. Wenn Sie die Sicherung für einen AKS-Cluster konfigurieren, wird eine geschützte Instanz erstellt. Jede Instanz verfügt über eine bestimmte Anzahl von Namespaces, die wie in der Sicherungskonfiguration definiert gesichert werden. Weitere Informationen zu den AKS-Sicherungspreisen finden Sie unter "Preise für Azure-Sicherung " und wählen Den Azure Kubernetes-Dienst als Workload aus.
Gebühr für Momentaufnahmen: Azure Backup für AKS schützt ein datenträgerbasiertes Persistentes Volumen durch Erstellen von Momentaufnahmen, die in der Ressourcengruppe in Ihrem Azure-Abonnement gespeichert sind. Diese Momentaufnahmen verursachen Speichergebühren. Da die Momentaufnahmen nicht in den Backup-Tresor kopiert werden, fallen keine Kosten für den Sicherungsspeicher an. Weitere Informationen zu Snapshot-Preisen finden Sie unter Preise für verwaltete Datenträger.
Sicherungsspeichergebühr: Azure Backup für AKS unterstützt auch das Speichern von Sicherungen auf der Tresorebene. Sie können Sicherungen in der Tresorebene speichern, indem Sie in der Sicherungsrichtlinie Aufbewahrungsregeln für den Tresorstandard festlegen, wobei pro Tag ein Wiederherstellungspunkt in den Tresor verschoben werden kann. Wiederherstellungspunkte, die auf der Tresorebene gespeichert sind, werden separat berechnet (als Sicherungsspeichergebühr bezeichnet), basierend auf der Gesamtzahl der gespeicherten Daten (in Gigabyte) und dem aktivierten Redundanztyp im Sicherungstresor.