Wat is Azure Kubernetes Service backup?

AKS-back-up (Azure Kubernetes Service) is een eenvoudig, cloudeigen proces dat u kunt gebruiken om back-ups te maken van toepassingen en gegevens in containers en gegevens die worden uitgevoerd in uw AKS-cluster. U kunt geplande back-ups configureren voor clusterstatus- en toepassingsgegevens die zijn opgeslagen op Kubernetes Persistent Volumes in CSI-stuurprogramma's (Container Storage Interface) op basis van Azure Disk Storage.

De oplossing biedt u gedetailleerde controle. U kunt een back-up maken van een specifieke naamruimte of een heel cluster door back-ups lokaal op te slaan in een blobcontainer en als momentopnamen van schijven. U kunt AKS-back-ups gebruiken voor end-to-end-scenario's, waaronder operationeel herstel, kloonontwikkelaars of testomgevingen en scenario's voor clusterupgrades.

AKS-back-up kan worden geïntegreerd met Backup Center in Azure om één weergave te bieden waarmee u back-ups op schaal kunt beheren, bewaken, gebruiken en analyseren. Uw back-ups zijn ook beschikbaar in Azure Portal onder Instellingen in het servicemenu voor een AKS-exemplaar.

Hoe werkt AKS-back-up?

U kunt een back-up van AKS gebruiken om een back-up te maken van uw AKS-workloads en permanente volumes die zijn geïmplementeerd in AKS-clusters. Voor de oplossing moet de back-upextensie worden geïnstalleerd in het AKS-cluster. De Backup-kluis communiceert met de extensie om back-up- en herstelbewerkingen te voltooien. Het gebruik van de Backup-extensie is verplicht. De extensie moet worden geïnstalleerd in het AKS-cluster om back-up en herstel in te schakelen voor het cluster. Wanneer u een AKS-back-up configureert, voegt u waarden toe voor een opslagaccount en een blobcontainer waarin back-ups worden opgeslagen.

Naast de back-upextensie wordt een gebruikersidentiteit (een extensie-id genoemd) gemaakt in de beheerde resourcegroep van het AKS-cluster. De identiteit van de extensie wordt toegewezen aan de rol Opslagaccountbijdrager op het opslagaccount waarin back-ups worden opgeslagen in een blobcontainer.

Voor het ondersteunen van openbare, privé- en geautoriseerde IP-clusters moet u de functie Vertrouwde toegang tussen het AKS-cluster en de Backup-kluis inschakelen. Met vertrouwde toegang kan de Backup-kluis toegang krijgen tot het AKS-cluster, omdat er specifieke machtigingen aan worden toegewezen voor back-upbewerkingen. Zie Azure-resources inschakelen voor toegang tot AKS-clusters met vertrouwde toegang voor meer informatie over vertrouwde toegang tot AKS.

Met een AKS-back-up kunt u back-ups opslaan in zowel de operationele laag als de kluislaag. De operationele laag is een lokaal gegevensarchief (back-ups worden opgeslagen in uw tenant als momentopnamen). U kunt nu één herstelpunt per dag verplaatsen en opslaan in de Vault-tier als een blob (buiten uw tenant) met AKS-backup. Back-ups die zijn opgeslagen in de kluislaag kunnen ook worden gebruikt om gegevens in een secundaire regio (gekoppelde Azure-regio) te herstellen.

Nadat u de back-upextensie hebt geïnstalleerd en Vertrouwde toegang hebt ingeschakeld, kunt u geplande back-ups voor de clusters configureren volgens uw back-upbeleid. U kunt de back-ups ook herstellen naar het oorspronkelijke cluster of naar een ander cluster in hetzelfde abonnement en dezelfde regio. Wanneer u de specifieke bewerking instelt, kunt u een specifieke naamruimte of een volledig cluster kiezen als back-up- en herstelconfiguratie.

AKS-back-up maakt back-upbewerkingen mogelijk voor uw AKS-gegevensbronnen die in het cluster zijn geïmplementeerd. Het maakt ook back-upbewerkingen mogelijk voor de gegevens die zijn opgeslagen in het permanente volume voor het cluster. Vervolgens worden de back-ups opgeslagen in een blobcontainer. Er wordt een back-up gemaakt van de schijf-gebaseerde permanente volumes als momentopnamen in een resourcegroep voor momentopnamen. De momentopnamen en de clusterstatus worden gecombineerd binnen een blob om een herstelpunt te vormen dat de Operationele Laag vormt en wordt opgeslagen in uw tenant. U kunt ook back-ups (de eerste geslaagde back-up in een dag, week, maand of jaar) in de operationele laag converteren naar blobs en deze vervolgens één keer per dag verplaatsen naar een kluis (buiten uw tenant).

Back-up configureren

Als u back-ups voor AKS-clusters wilt configureren, maakt u eerst een Backup-kluis. De kluis biedt u een geconsolideerde weergave van de back-ups die zijn ingesteld in diverse gegevensbronnen. AKS-back-up ondersteunt back-ups voor zowel de operationele laag als de kluislaag.

De instelling voor opslagredundantie van de Back-upkluis (lokaal redundante opslag of geografisch redundante opslag) is alleen van toepassing op back-ups die zijn opgeslagen in de kluislaag. Als u back-ups wilt gebruiken voor herstel na noodgevallen, stelt u de opslagredundantie in als GRS waarvoor Herstel tussen regio's is ingeschakeld.

Met een AKS-back-up wordt automatisch een geplande back-uptaak geactiveerd. De taak kopieert de clusterbronnen naar een blobcontainer en maakt een incrementele momentopname van de schijfgebaseerde Permanente Volumes volgens de frequentie van de back-ups. De back-ups worden bewaard in de operationele laag en de kluislaag volgens de retentieduur die is gedefinieerd in het back-upbeleid. De back-ups worden verwijderd wanneer de duur is verstreken.

U kunt AKS-back-ups gebruiken om meerdere back-upexemplaren voor één AKS-cluster te maken met behulp van verschillende back-upconfiguraties per back-upexemplaren. We raden echter aan elke back-upinstantie van een AKS-cluster op een van de volgende twee manieren te maken.

• In een andere Backup-kluis
• Door een afzonderlijk back-upbeleid te gebruiken in dezelfde Backup-kluis

Back-ups beheren

Wanneer de back-upconfiguratie voor een AKS-cluster is voltooid, wordt er een back-upexemplaar gemaakt in de Backup-kluis. U kunt het back-upexemplaar voor het cluster weergeven in de sectie Back-up voor een AKS-exemplaar in de Azure-portal. U kunt alle back-upbewerkingen uitvoeren voor het exemplaar, zoals het initiëren van herstelbewerkingen, bewaking, het stoppen van beveiliging, enzovoort, via het bijbehorende back-upexemplaren.

AKS-back-up kan ook rechtstreeks worden geïntegreerd met Backup Center, zodat u de beveiliging voor al uw AKS-clusters en andere workloads die door back-ups worden ondersteund centraal kunt beheren. Back-upcentrum biedt één weergave voor al uw back-upvereisten, zoals bewakingstaken en de status van back-ups en herstelbewerkingen. Back-upcentrum helpt u naleving en governance te garanderen, back-upgebruik te analyseren en kritieke bewerkingen uit te voeren om een back-up te maken van gegevens en deze te herstellen.

AKS-back-up maakt gebruik van beheerde identiteit voor toegang tot andere Azure-resources. Als u de back-up van een AKS-cluster wilt configureren en wilt herstellen vanaf een eerdere back-up, vereist de beheerde identiteit van de Back-upkluis een set machtigingen voor het AKS-cluster. Er is ook een set machtigingen vereist voor de resourcegroep voor momentopnamen waarin momentopnamen worden gemaakt en beheerd. Op dit moment is voor het AKS-cluster een set machtigingen vereist voor de resourcegroep voor momentopnamen.

De back-upextensie maakt ook een gebruikersidentiteit en wijst een set machtigingen toe voor toegang tot het opslagaccount waarin back-ups worden opgeslagen in een blob. U kunt machtigingen verlenen aan de beheerde identiteit met behulp van op rollen gebaseerd toegangsbeheer van Azure. Een beheerde identiteit is een speciaal type service-principe dat alleen kan worden gebruikt met Azure-resources. Meer informatie over beheerde identiteiten.

Herstellen van backup

U kunt gegevens herstellen vanaf elk tijdstip waarvoor een herstelpunt bestaat. Er wordt een herstelpunt gemaakt wanneer een back-upexemplaar een beschermde toestand heeft. Het kan worden gebruikt om gegevens te herstellen totdat het back-upbeleid de gegevens bewaart.

Azure Backup biedt u de mogelijkheid om alle items waarvan een back-up is gemaakt te herstellen of om gedetailleerde besturingselementen te gebruiken om specifieke items uit de back-ups te selecteren met behulp van naamruimten en andere filteropties. U kunt ook het herstel uitvoeren op het oorspronkelijke AKS-cluster (het back-upcluster) of op een alternatief AKS-cluster. U kunt back-ups herstellen die zijn opgeslagen in de operationele laag en de kluislaag naar een cluster in hetzelfde of een ander abonnement. Alleen back-ups die zijn opgeslagen in de kluislaag kunnen worden gebruikt om een herstelbewerking uit te voeren naar een cluster in een andere regio (gekoppelde Azure-regio).

Als u een back-up wilt herstellen die is opgeslagen in de kluislaag, moet u een tijdelijke opslaglocatie opgeven waar de back-upgegevens worden hersteld. Deze implementatielocatie bevat een resourcegroep en een opslagaccount binnen dezelfde regio en hetzelfde abonnement als het doelcluster voor herstel. Tijdens het herstellen worden specifieke resources (blob-container, schijf en schijfmomentopnames) gecreëerd als onderdeel van hydratatie. Ze worden gewist nadat de herstelbewerking is voltooid.

Azure Backup voor AKS ondersteunt momenteel de volgende twee opties voor een scenario waarin een resourceconflict optreedt. Een resourceconflict ontstaat wanneer een geback-upte resource dezelfde naam heeft als een resource in het doel-AKS-cluster. U kunt een van deze opties kiezen bij het definiëren van de herstelconfiguratie.

• Overslaan: deze optie is standaard geselecteerd. Als u bijvoorbeeld een back-up maakt van een permanent volumeclaim (PVC) met de naam pvc-azuredisk en deze herstelt in een doelcluster waarin zich een PVC met dezelfde naam bevindt, dan slaat de back-upextensie het herstel van de geback-upte PVC over. In dergelijke scenario's wordt u aangeraden de resource uit het cluster te verwijderen. Voer vervolgens de herstelbewerking uit zodat de back-upitems alleen in het cluster beschikbaar zijn en er niets wordt overgeslagen.

• Patch: Met deze optie kan een veranderlijke variabele in de back-upresource worden gepatcht op de resource in het doelcluster. Als u het aantal replica's in het doelcluster wilt bijwerken, kunt u ervoor kiezen om te patchen als een bewerking.

Aangepaste hooks gebruiken voor back-up en herstel

U kunt aangepaste hooks gebruiken om toepassingsconsistente momentopnamen te maken van volumes die worden gebruikt voor databases die zijn geïmplementeerd als workloads in containers.

Wat zijn aangepaste haken?

U kunt AKS-back-ups gebruiken om aangepaste hooks uit te voeren als onderdeel van een back-up- en herstelbewerking. Hooks zijn geconfigureerd om een of meer opdrachten uit te voeren die tijdens een back-upbewerking of na het herstellen in een pod onder een container moeten worden uitgevoerd.

U definieert deze hooks als een aangepaste resource en implementeert deze in het AKS-cluster waarvoor u een back-up wilt maken of herstellen. Wanneer de aangepaste resource wordt geïmplementeerd in het AKS-cluster in de vereiste naamruimte, geeft u de details op als invoer voor de stroom voor het configureren van back-up en herstel. Met de back-upextensie worden de hooks uitgevoerd zoals gedefinieerd in een YAML-bestand.

Backup in AKS heeft twee soorten koppelingen:

• Backuphooks
• Hooks herstellen

Backuphooks

Wanneer u een back-uphook gebruikt, kunt u de opdrachten configureren om de hook uit te voeren vóór een aangepaste actieverwerking (PreHooks). U kunt de hook ook uitvoeren nadat alle aangepaste acties zijn voltooid en eventuele extra items die door aangepaste acties zijn opgegeven, worden een back-up gemaakt (PostHooks).

Zie hier bijvoorbeeld de YAML-sjabloon voor een aangepaste resource die moet worden uitgerold met behulp van back-uphooks:

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 herstellen

In het herstelhookscript worden aangepaste opdrachten of scripts geschreven die moeten worden uitgevoerd in de containers van een herstelde AKS-pod.

Hier volgt de YAML-sjabloon voor een aangepaste resource die wordt geïmplementeerd via herstelhook:

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

Leer hoe je hooks gebruikt tijdens AKS-back-ups.

Tijdens het herstellen wacht de back-upextensie totdat de container verschijnt en voert vervolgens exec-opdrachten uit, die zijn gedefinieerd in de herstelhook.

Als u herstel uitvoert naar dezelfde naamruimte waarvan een back-up is gemaakt, wordt de herstelhook niet uitgevoerd. Er wordt alleen gezocht naar een zojuist voortgekomen container. Dit resultaat treedt op, ongeacht of u de overslaan- of patchbeleid hanteert.

Resource wijzigen tijdens het herstellen van back-ups naar een AKS-cluster

U kunt de functie Resourcewijziging gebruiken om tijdens herstel van geback-upte Kubernetes-resources te wijzigen door JSON-patches op te geven zoals geïmplementeerd in het AKS-cluster.

Een resourceaanpassingsconfiguratiemap maken en toepassen tijdens het herstel

Voer de volgende stappen uit om een bronwijziging te creëren en toe te passen:

1. Een ressourcewijziging configmap maken.

   U moet een configmap maken in uw voorkeursnaamruimte vanuit een YAML-bestand dat resource-modificatoren definieert.

   Voorbeeld voor het maken van een opdracht:

   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"
   

   • De vorige configmap past de JSON-patch toe op alle kopieën van permanente volumes in de namespaces en foo met een naam die begint met mysql en match label foo: bar. De JSON-patch vervangt het storageClassName door premium en verwijdert het label test uit de permanente volumekopieën.
   • Hier is de namespace oorspronkelijke naamruimte van de back-upbron, en niet de nieuwe naamruimte waarnaar de bron wordt hersteld.
   • U kunt meerdere JSON-patches voor een bepaalde resource opgeven. De patches worden toegepast op basis van de volgorde die is opgegeven in de configmap. De volgende patch wordt op volgorde toegepast. Als er meerdere patches zijn opgegeven voor hetzelfde pad, overschrijft de laatste patch de vorige patches.
   • U kunt meerdere resourceModifierRules opgeven in de configmap. De regels worden toegepast op basis van de volgorde die is opgegeven in de configmap.

2. Een referentie voor resource-modificator maken in de herstelconfiguratie

   Wanneer u een herstelbewerking uitvoert, geeft u de ConfigMap name en de namespace locatie op waar deze wordt geïmplementeerd als onderdeel van de herstelconfiguratie. Deze details moeten worden opgegeven onder Resource Modifier-regels.

   

Bewerkingen die worden ondersteund door Resource Modifier

• Toevoegen

  U kunt de bewerking Toevoegen gebruiken om een nieuw blok toe te voegen aan de JSON van de resource. In het volgende voorbeeld voegt de bewerking nieuwe containerdetails toe aan de specificatie met een implementatie.

  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}]}"
  

• Verwijderen

  U kunt de bewerking Verwijderen gebruiken om een sleutel uit de JSON van de resource te verwijderen. In het volgende voorbeeld verwijdert de bewerking het label met test als sleutel.

  version: v1
  resourceModifierRules:
  - conditions:
        groupResource: persistentvolumeclaims
        resourceNameRegex: "^mysql.*$"
        namespaces:
        - bar
        - foo
        labelSelector:
          matchLabels:
              foo: bar
    patches:
    - operation: remove
      path: "/metadata/labels/test"
  

• vervangen

  U kunt de bewerking Vervangen gebruiken om een waarde voor het genoemde pad door een alternatieve te vervangen. In het volgende voorbeeld vervangt de bewerking het storageClassName in pvc door premium.

  version: v1
  resourceModifierRules:
  - conditions:
       groupResource: persistentvolumeclaims
       resourceNameRegex: "^mysql.*$"
       namespaces:
       - bar
       - foo
       labelSelector:
          matchLabels:
             foo: bar
    patches:
    - operation: replace
      path: "/spec/storageClassName"
      value: "premium"
  

• kopie

  U kunt de kopieerbewerking gebruiken om een waarde te kopiëren van het ene pad van de resources die zijn gedefinieerd naar een ander pad.

  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"
  

•   Testen

  U kunt de testbewerking gebruiken om te controleren of een bepaalde waarde aanwezig is in de resource. Als de waarde aanwezig is, wordt de patch toegepast. Als de waarde niet aanwezig is, wordt de patch niet toegepast. In het volgende voorbeeld controleert de bewerking of de PVC's premium als StorageClassName hebben en zo ja, deze vervangen door standard.

  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

  Hiermee configmap wordt de JSON-patch standaard toegepast op alle implementaties in de naamruimten en nginx met de naam die begint met nginxdep. De JSON-patch werkt het aantal replica's bij tot 12 voor alle dergelijke implementaties.

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

• JSON-samenvoegingpatch

  Hiermee configmap wordt de JSON-mergepatch toegepast op alle implementaties in de standaardnaamruimte en in nginx met een naam die begint met nginxdep. Met de JSON-samenvoegpatch wordt het label app toegevoegd of bijgewerkt met de waarde nginx1.

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

• Patch voor strategische samenvoeging

  Met deze configmap wordt de strategische samenvoeging toegepast op alle pods in de standaardnaamruimte waarvan de naam begint met nginx. De strategische samenvoegpatch werkt de afbeelding van container nginx bij naar 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"
              }
            ]
          }
        }
  

Welke back-uplaag voor opslag ondersteunt AKS-back-up?

Azure Backup voor AKS ondersteunt twee opslaglagen als back-upgegevensarchieven:

• Operationele laag: De back-upextensie die in het AKS-cluster is geïnstalleerd, maakt eerst de back-up door volumemomentopnamen te maken via het CSI-stuurprogramma. De clusterstatus wordt vervolgens opgeslagen in een blobcontainer in uw eigen tenant. Deze laag ondersteunt een lagere RPO (Recovery Point Objective) met de minimale duur van vier uur tussen twee back-ups. Daarnaast biedt de operationele laag ondersteuning voor snellere herstelbewerkingen voor azure-schijfvolumes.

• Kluislaag: Voor het opslaan van back-upgegevens voor een langere duur tegen lagere kosten dan momentopnamen, ondersteunt AKS-back-up kluisstandaardgegevensarchieven. Volgens de bewaarregels die zijn ingesteld in het back-upbeleid, wordt de eerste geslaagde back-up (van een dag, week, maand of jaar) verplaatst naar een blobcontainer buiten uw tenant. Dit gegevensarchief staat niet alleen langere retentie toe, maar biedt ook ransomwarebeveiliging. U kunt ook back-ups die in de kluis zijn opgeslagen, verplaatsen naar een andere regio (gekoppelde Azure-regio) voor herstel door georedundantie en herstel tussen regio's in de Back-upkluis in te schakelen.

  Notitie

  U kunt de back-upgegevens opslaan in een standaard kluisgegevensopslag via het Back-upbeleid door bewaarregels te definiëren. Er wordt slechts één gepland herstelpunt per dag verplaatst naar de Vault-laag. U kunt echter een willekeurig aantal back-ups op aanvraag naar de kluis verplaatsen volgens de geselecteerde regel.

Inzicht in prijscategorieën

Er worden kosten in rekening gebracht voor:

• Kosten voor beveiligde exemplaren: Voor Azure Backup voor AKS worden kosten in rekening gebracht voor een beveiligd exemplaar per naamruimte per maand. Wanneer u een back-up voor een AKS-cluster configureert, wordt er een beveiligd exemplaar gemaakt. Elk exemplaar heeft een specifiek aantal naamruimten waarvan een back-up wordt gemaakt zoals gedefinieerd in de back-upconfiguratie. Zie Prijzen voor Azure Backup en selecteer Azure Kubernetes Service als workload voor meer informatie over de prijzen voor AKS-back-ups.

• Kosten voor momentopnamen: Azure Backup voor AKS beveiligt een permanent volume op basis van schijven door momentopnamen te maken die zijn opgeslagen in de resourcegroep in uw Azure-abonnement. Voor deze momentopnamen worden opslagkosten in rekening gebracht. Omdat de momentopnamen niet naar de Backup-kluis worden gekopieerd, zijn de kosten voor back-upopslag niet van toepassing. Voor meer informatie over de prijzen van momentopnamen, zie Managed Disks pricing.

• Kosten voor back-upopslag: Azure Backup voor AKS biedt ook ondersteuning voor het opslaan van back-ups in de kluislaag. U kunt back-ups opslaan in de kluislaag door bewaarregels voor kluisstandaard in het back-upbeleid te definiëren, waarbij één herstelpunt per dag in aanmerking komt om naar de kluis te worden verplaatst. Herstelpunten die zijn opgeslagen in de kluislaag, worden een afzonderlijke vergoeding in rekening gebracht (ook wel back-upopslagkosten genoemd) op basis van het totale aantal gegevens dat is opgeslagen (in gigabytes) en het redundantietype dat is ingeschakeld voor de Backup-kluis.

Verwante inhoud

• Vereisten voor back-up van Azure Kubernetes Service
• Een back-up maken van AKS met behulp van Azure PowerShell
• AKS herstellen met behulp van de Azure CLI
• Goed ontworpen ontwerp voor AKS-clusterbeveiliging