Teilen über

Was ist die Azure Kubernetes Service-Sicherung?

  • Artikel

Die Azure Kubernetes Service (AKS)-Sicherung ist ein einfacher, cloudnativer Prozess, mit dem Sie die containerisierten 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 Volumes in einer auf CSI-Treibern basierenden Azure Disk Storage-Instanz gespeichert sind. Die Lösung bietet eine granulare Kontrolle, um einen bestimmten Namespace oder einen gesamten Cluster auszuwählen, der gesichert oder wiederhergestellt werden soll, indem Sicherungen lokal in einem Blobcontainer und als Datenträgermomentaufnahmen gespeichert werden. Sie können die AKS-Sicherung für End-to-End-Szenarien verwenden, u. a. für operative Wiederherstellung, das Klonen von Entwickler-/Testumgebungen und Upgradeszenarien für Cluster.

Die AKS-Sicherung lässt sich im Backup Center in Azure integrieren und bietet so eine zentrale Ansicht, in der Sie Sicherungen im großen Stil steuern, überwachen, betreiben und analysieren können. Ihre Sicherungen sind auch im Azure-Portal unter Einstellungen im Dienstmenü für eine AKS-Instanz verfügbar.

Hinweis

Tresorsicherung und regionsübergreifende Wiederherstellung für AKS mit Azure Backup befinden sich derzeit in der Vorschau.

Wie funktioniert die AKS-Sicherung?

Verwenden Sie die AKS-Sicherung, 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, um Vorgänge im Zusammenhang mit Sicherung und Wiederherstellung auszuführen. Die Verwendung der Backup-Erweiterung ist obligatorisch, und die Erweiterung muss innerhalb des AKS-Clusters installiert werden, um die Sicherung und Wiederherstellung für den Cluster zu ermöglichen. 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 vertrauenswürdiger Zugriff zwischen dem AKS-Cluster und dem Backup-Tresor aktiviert ist. 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.

Hinweis

Die AKS-Sicherung ermöglicht das Speichern von Sicherungen in der Betriebsebene. Die Betriebsebene ist ein lokaler Datenspeicher (in Ihrem Mandanten bestehend aus Momentaufnahmen). Sie können jetzt einen Wiederherstellungspunkt pro Tag verschieben und ihn mithilfe der AKS-Sicherung als Blobs (außerhalb Ihres Mandanten) in der Tresorebene speichern. Sie verwenden jedoch weiterhin den Azure Backup-Tresor zum Verwalten von Sicherungen.

Nachdem die Backup-Erweiterung installiert und der vertrauenswürdige Zugriff aktiviert wurde, können Sie geplante Sicherungen für die Cluster gemäß Ihrer Sicherungsrichtlinie konfigurieren. Sie können die Sicherungen auch im ursprünglichen Cluster oder in einem alternativen Cluster wiederherstellen, der sich im selben Abonnement und in derselben Region befindet. Sie können einen bestimmten Namespace oder einen gesamten Cluster als Sicherungs- und Wiederherstellungskonfiguration auswählen, während Sie den spezifischen Vorgang einrichten.

Die Sicherungslösung ermöglicht Sicherungsvorgänge für Ihre AKS-Datenquellen, die im Cluster bereitgestellt werden, und für die Daten, die auf dem persistenten Volume für den Cluster gespeichert werden. Anschließend werden die Sicherungen in einem Blobcontainer gespeichert. Die datenträgerbasierten persistenten Volumes werden als Datenträgermomentaufnahmen 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 „Operational Tier“ (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 einer auf CSI-Treibern basierenden Azure Disk Storage-Instanz. Während der Sicherungen werden andere Typen von persistenten Volumes, z. B. Azure-Dateifreigaben 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. Die AKS-Sicherung unterstützt Sicherungen sowohl auf Betriebs- als auch auf Tresorebene.

    Hinweis

    • Der Backup-Tresor und der zu sichernde oder wiederherzustellende AKS-Cluster müssen sich in derselben Region und im selben Abonnement befinden.
    • Die Speicherredundanzeinstellung (LRS/GRS) des Backup-Tresors gilt nur für Sicherungen, die auf der Tresorsebene gespeichert werden. Wenn Sie Sicherungen für die Notfallwiederherstellung verwenden möchten, legen Sie die Speicherredundanz auf GRS mit aktivierter regionsübergreifender Wiederherstellung fest.

  • 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 Sicherungsfrequenz. Die Sicherungen werden gemäß der in der Sicherungsrichtlinie definierten Aufbewahrungsdauer in der Betriebs- bzw. Tresorebene aufbewahrt und gelöscht, sobald die Dauer abgelaufen ist.

    Hinweis

    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. Jede Sicherungsinstanz eines AKS-Clusters muss jedoch in einem anderen Backup-Tresor oder mit einer anderen Sicherungsrichtlinie im selben Backup-Tresor erstellt werden.

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 im Backup Center integriert, damit Sie den Schutz für alle Ihre AKS-Cluster und andere von Sicherungen unterstützten Workloads zentral verwalten können. Das Backup Center ist eine einzelne 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. Zum Konfigurieren der Sicherung eines AKS-Clusters und zum Wiederherstellen aus einer früheren Sicherung erfordert die verwaltete Identität des Backup-Tresors eine Reihe von Berechtigungen für den AKS-Cluster und die Momentaufnahmeressourcengruppe, in der Momentaufnahmen erstellt und verwaltet werden. Derzeit erfordert der AKS-Cluster eine Reihe von Berechtigungen für die Momentaufnahmeressourcengruppe. 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 der verwalteten Identität mithilfe der rollenbasierten Zugriffssteuerung von Azure (Azure RBAC) Berechtigungen erteilen. Die verwaltete Identität ist ein spezieller Dienstprinzipaltyp, der nur zusammen mit Azure-Ressourcen verwendet werden kann. Weitere Informationen zu verwalteten Identitäten.

Wiederherstellen einer Sicherung

Sie können Daten von jedem Zeitpunkt wiederherstellen, für den ein Wiederherstellungspunkt vorhanden ist. Ein Wiederherstellungspunkt wird erstellt, wenn sich eine Sicherungsinstanz im geschützten Zustand befindet, und er kann verwendet werden, um Daten wiederherzustellen, bis sie von der Sicherungsrichtlinie beibehalten werden.

Azure Backup bietet Ihnen die Möglichkeit, alle gesicherten Elemente wiederherzustellen oder die granularen Steuerelemente zu verwenden, um bestimmte Elemente durch die Auswahl von Namespaces und anderer Filteroptionen aus der Sicherung auszuwählen. Außerdem haben Sie die Möglichkeit, die Wiederherstellung im ursprünglichen AKS-Cluster (dem Cluster, der gesichert wurde) oder im alternativen AKS-Cluster in derselben Region und im gleichen Abonnement durchzuführen. Sie können Sicherungen, die in der Betriebs- und Tresorebene gespeichert sind, in einem Cluster im gleichen und 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 hydratisiert 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 (BLOB-Container, Datenträger und Datenträgermomentaufnahmen) als Teil der Hydratisierung erstellt, die dann nach Abschluss des Wiederherstellungsvorgangs gelöscht wird.

Azure Backup für AKS unterstützt derzeit die folgenden beiden Optionen bei einem Wiederherstellungsvorgang, wenn ein Ressourcenkonflikt auftritt. (Die gesicherte Ressource hat denselben Namen wie die Ressource im AKS-Zielcluster.) Sie können eine dieser Optionen auswählen, wenn Sie die Wiederherstellungskonfiguration definieren.

  1. Überspringen: Diese Option ist standardmäßig aktiviert. Wenn Sie beispielsweise einen PVC mit dem Namen pvc-azuredisk gesichert haben und ihn in einem Zielcluster mit einem PVC mit demselben Namen wiederherstellen, überspringt die Sicherungserweiterung die Wiederherstellung des gesicherten Anspruchs auf ein persistentes Volume (Persistent Volume Claim, PVC). In solchen Szenarien wird empfohlen, die Ressource aus dem Cluster zu löschen und dann den Wiederherstellungsvorgang auszuführen, damit die gesicherten Elemente nur im Cluster verfügbar sind und nicht übersprungen werden.

  2. 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

Derzeit werden bei der AKS-Sicherung keine Ressourcen im Zielcluster gelöscht und erneut erstellt, sofern sie bereits vorhanden sind. 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 Befehle, die zum Ausführen eines oder mehrerer Befehle in einem Pod unter einem Container während des Sicherungsvorgangs oder nach der Wiederherstellung konfiguriert sind. 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

In einem Sicherungs-Hook können Sie die Befehle so konfigurieren, dass sie vor jeder benutzerdefinierten Aktionsverarbeitung (Pre-Hooks) oder nach Abschluss aller benutzerdefinierten Aktionen ausgeführt werden, und alle zusätzlichen Elemente, die durch benutzerdefinierte Aktionen angegeben werden, gesichert werden (Post-Hooks).

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 Wiederherstellungs-Hook werden benutzerdefinierte Befehle oder Skripts geschrieben, die in den Containern eines wiederhergestellten AKS-Pods ausgeführt werden.

Hier sehen Sie die YAML-Vorlage für eine benutzerdefinierte Ressource, die mithilfe von Wiederherstellungs-Hooks bereitgestellt werden soll:

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-Sicherung verwenden.

Hinweis

  • 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 Hooks für die Wiederherstellung definiert sind.
  • Falls Sie die Wiederherstellung desselben Namespace ausführen, der gesichert wurde, werden die Hooks für die Wiederherstellung nicht ausgeführt, da nur nach einem neuen Container gesucht wird, der parallel erstellt wird. Dies ist unabhängig davon, ob die Skip- oder Patch-Richtlinie aktiviert ist.

Ändern der Ressource beim Wiederherstellen von Sicherungen im AKS-Cluster

Sie können die Funktion Ressourcenänderung 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:

  1. Erstellen Sie die ConfigMap mit Ressourcenmodifizierern.

    Sie müssen eine ConfigMap in Ihrem bevorzugten Namespace aus einer YAML-Datei erstellen, die Ressourcenmodifizierer definiert hat.

    Beispiel zum Erstellen des 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"
    • Die obige ConfigMap wendet den JSON-Patch auf alle persistenten Volumekopien in der Namespaces-Leiste und foo mit einem Namen an, der mit mysql und match label foo: bar beginnt. Der JSON-Patch ersetzt storageClassName durch premium und entfernt die Bezeichnung test aus den persistenten Volumekopien.
    • Hier ist der Namespace der ursprüngliche Namespace der gesicherten Ressource und nicht der neue Namespace, in dem die Ressource wiederhergestellt werden soll.
    • Sie können mehrere JSON-Patches für eine bestimmte Ressource angeben. Die Patches werden in der Reihenfolge angewendet, die in der ConfigMap angegeben ist. Ein nachfolgender Patch wird in der jeweiligen 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 der ConfigMap angeben. Die Regeln werden in der Reihenfolge angewendet, die in der ConfigMap angegeben ist.

  2. Erstellen eines Verweises auf den Ressourcenmodifizierer in der Wiederherstellungskonfiguration

    Geben Sie beim Ausführen eines Wiederherstellungsvorgangs den ConfigMap-Namen und den Namespace, wo die Bereitstellung erfolgt, im Rahmen der Wiederherstellungskonfiguration an. Diese Details müssen unter Regeln für den Ressourcenmodifizierer angegeben werden.

    Screenshot: Ort zur Angabe der Ressourcendetails.

Vom Ressourcenmodifizierer unterstützte Vorgänge

  • Add (Hinzufügen)

    Sie können den Vorgang Hinzufügen verwenden, um der Ressourcen-JSON einen neuen Block hinzuzufügen. Im folgenden Beispiel fügt sie neue Containerdetails zur Spezifikation mit einer Bereitstellung 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}]}"

  • Remove

    Sie können den Vorgang Entfernen verwenden, um einen Schlüssel aus der Ressourcen-JSON zu entfernen. Im folgenden Beispiel entfernt der Vorgang die Bezeichnung mit Testen 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 „storageClassName“ im persistenten Volumeanspruch durch „premium“.

    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 persistenten Volumeansprüche „premium“ als „StorageClassName“ haben, und ersetzt den Wert durch „Standard“, wenn „true“.

    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 auf alle Bereitstellungen in den Namespaces „default“ und „nginx“ with the name that starts with „nginxdep“ an. Der JSON-Patch aktualisiert die Replikatanzahl für alle derartigen Bereitstellungen auf 12.

    version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^nginxdep.*$"
    namespaces:
   - default
   - nginx
  patches:
  - operation: replace
    path: "/spec/replicas"
    value: "12"

  • JSON Merge Patch

    Diese ConfigMap wendet den JSON Merge Patch auf alle Bereitstellungen in den Namespaces „default“ und „nginx“ mit dem Namen beginnend mit „nginxdep“ an. Der JSON Merge Patch fügt die Bezeichnung „app“ mit dem Wert „nginx1“ hinzu oder aktualisiert sie entsprechend.

    version: v1
resourceModifierRules:
  - conditions:
      groupResource: deployments.apps
      resourceNameRegex: "^nginxdep.*$"
      namespaces:
        - default
        - nginx
    mergePatches:
      - patchData: |
          {
            "metadata" : {
              "labels" : {
                "app" : "nginx1"
              }
            }
          }

  • Strategischer Merge Patch

    Diese ConfigMap wendet den strategischen Merge Patch auf alle Pods im Namespace „default“ mit dem Namen beginnend mit „nginx“ an. Der strategische Merge Patch aktualisiert das Image des Containers „nginx“ auf mcr.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 Sicherungsspeicherebene unterstützt die AKS-Sicherung?

Azure Backup für AKS unterstützt zwei Speicherebenen als Sicherungsdatenspeicher:

  • Betriebsebene: Die im AKS-Cluster installierte Azure Backup-Erweiterung übernimmt zunächst die Sicherung, indem sie Volume-Momentaufnahmen über CSI-Treiber erstellt und den Clusterstatus in einem BLOB-Container in Ihrem eigenen Mandanten speichert. Diese Ebene unterstützt ein niedrigeres RPO mit der Mindestdauer von vier Stunden zwischen zwei Sicherungen. Darüber hinaus unterstützt die Betriebsebene bei Azure Disk-basierte Volumes schnellere Wiederherstellungen.

  • Tresor-Standardebene (Vorschau): Um Sicherungsdaten über einen längeren Zeitraum zu geringeren Kosten als Momentaufnahmen zu speichern, unterstützt die AKS-Sicherung den Tresor-Standarddatenspeicher. 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. Zudem können Sie Sicherungen, die im Tresor gespeichert sind, auch zur Wiederherstellung in eine andere Region (gekoppelte Azure-Region) 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 Cloudsicherung. Wählen Sie Azure Kubernetes Service als Workload aus.

  • Momentaufnahmegebühr: Azure Backup für AKS schützt datenträgerbasierte persistente Volumes 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 Details zu den Preisen für Momentaufnahmen finden Sie unter Verwalteter Datenträger – Preise.

  • Sicherungsspeichergebühr: Azure Backup für AKS unterstützt auch das Speichern von Sicherungen auf Tresorebene. Dies kann erreicht werden, indem Sie Aufbewahrungsregeln für vault-standard in der Sicherungsrichtlinie definieren, wobei ein Wiederherstellungspunkt pro Tag in den Tresor verschoben werden kann. Für Wiederherstellungspunkte, die auf der Tresorebene gespeichert sind, wird eine separate Gebühr mit dem Namen „Sicherungsspeichergebühr“ gemäß der Gesamtmenge der gespeicherten Daten (in GBs) und des Redundanztyps berechnet, der für den Sicherungstresor aktiviert ist.

Nächster Schritt

Voraussetzungen für die Azure Kubernetes Service-Sicherung