Che cos'è il servizio di backup di Azure Kubernetes?

Il backup del servizio Azure Kubernetes è un semplice processo nativo del cloud che è possibile usare per eseguire il backup e il ripristino di applicazioni e dati in contenitori eseguiti nel cluster del servizio Azure Kubernetes. È possibile configurare i backup pianificati per lo stato del cluster e i dati dell'applicazione archiviati in volumi persistenti nell’Archiviazione su disco di Azure basati su driver CSI. La soluzione offre un controllo granulare per scegliere uno spazio dei nomi specifico o un intero cluster di cui eseguire il backup o il ripristino archiviando i backup in locale in un contenitore BLOB e come snapshot del disco. È possibile usare il backup del servizio Azure Kubernetes per scenari end-to-end, tra cui ripristino operativo, clonazione di ambienti di sviluppo/testing e scenari di aggiornamento del cluster.

Il backup del servizio Azure Kubernetes si integra con il Centro backup in Azure, offrendo una singola visualizzazione che consente di gestire, monitorare, gestire e analizzare i backup su larga scala. I backup sono disponibili anche nel portale di Azure in Impostazioni nel menu di servizio per un'istanza del servizio Azure Kubernetes (AKS).

Come funziona il backup del servizio Azure Kubernetes?

Usare il backup del servizio Azure Kubernetes per eseguire il backup dei carichi di lavoro del servizio Azure Kubernetes e dei volumi permanenti distribuiti nei cluster del servizio Azure Kubernetes. La soluzione richiede che l'estensione Backup sia installata all'interno del cluster del servizio Azure Kubernetes. L'insieme di credenziali di backup comunica con l'estensione per completare le operazioni correlate al backup e al ripristino. L'uso dell'estensione backup è obbligatorio e l'estensione deve essere installata all'interno del cluster del servizio Azure Kubernetes per abilitare il backup e il ripristino per il cluster. Quando si configura il backup del servizio Azure Kubernetes, si aggiungono valori per un account di archiviazione e un contenitore BLOB in cui vengono archiviati i backup.

Insieme all'estensione Backup, viene creata un'identità utente (denominata identità dell'estensione) nel gruppo di risorse gestite del cluster del servizio Azure Kubernetes. All'identità dell'estensione viene assegnato il ruolo Collaboratore account di archiviazione nell'account di archiviazione in cui vengono archiviati i backup in un contenitore BLOB.

Per supportare cluster pubblici, privati e autorizzati basati su IP, il backup del servizio Azure Kubernetes richiede l'abilitazione dell'Accesso attendibile tra il cluster del servizio Azure Kubernetes e l'insieme di credenziali di backup. Accesso attendibile consente all'insieme di credenziali di Backup di accedere al cluster del servizio Azure Kubernetes a causa di autorizzazioni specifiche assegnate per le operazioni di backup. Per altre informazioni sull'Accesso attendibile del servizio Azure Kubernetes, vedere Abilitare le risorse di Azure per accedere ai cluster del servizio Azure Kubernetes tramite Accesso attendibile.

Dopo l'installazione dell'estensione Backup e l'abilitazione di Accesso attendibile, è possibile configurare i backup pianificati per i cluster in base ai criteri di backup. È anche possibile ripristinare i backup nel cluster originale o in un cluster alternativo che si trova nella stessa sottoscrizione e nella stessa area. È possibile scegliere uno spazio dei nomi specifico o un intero cluster come configurazione di backup e ripristino durante la configurazione dell'operazione specifica.

La soluzione di backup consente le operazioni di backup per le origini dati del servizio Azure Kubernetes distribuite nel cluster e per i dati archiviati nel volume permanente per il cluster e quindi l'archiviazione dei backup in un contenitore BLOB. I volumi persistenti basati su disco vengono sottoposti a backup come snapshot del disco in un gruppo di risorse snapshot. Gli snapshot e lo stato del cluster in un BLOB si combinano entrambi per formare un punto di ripristino archiviato nel tenant denominato Livello operativo. È anche possibile convertire i backup (primo backup riuscito in un giorno, settimana, mese o anno) nel livello operativo in BLOB e quindi spostarli in un insieme di credenziali (all'esterno del tenant) una volta al giorno.

Configurare il backup

• Per configurare i backup per i cluster del servizio Azure Kubernetes, creare prima di tutto un insieme di credenziali di backup. L'insieme di credenziali offre una vista consolidata dei backup configurati per diverse origini dati. Il backup del servizio Azure Kubernetes supporta sia il livello operativo che i backup a livello di insieme di credenziali.

  Nota

  • L'insieme di credenziali di backup e il cluster del servizio Azure Kubernetes di cui si vuole eseguire il backup o il ripristino devono trovarsi nella stessa area e nella stessa sottoscrizione.
  • L'impostazione di ridondanza dell'archiviazione dell'insieme di credenziali di backup (LRS/GRS) si applica solo ai backup archiviati nel livello dell'insieme di credenziali. Se si vogliono usare i backup per il ripristino di emergenza, impostare la ridondanza dell'archiviazione come archiviazione con ridondanza geografica con ripristino tra aree abilitato.

• Il backup del servizio Azure Kubernetes attiva automaticamente un processo di backup pianificato. Il processo copia le risorse del cluster in un contenitore BLOB e crea uno snapshot incrementale dei volumi persistenti basati su disco in base alla frequenza di backup. I backup vengono conservati nel livello operativo e nel livello dell'insieme di credenziali in base alla durata di conservazione definita nei criteri di backup e vengono eliminati una volta superata questa durata.

  Nota

  È possibile usare il backup del servizio Azure Kubernetes per creare più istanze di backup per un singolo cluster del servizio Azure Kubernetes usando configurazioni di backup diverse per ogni istanza di backup. Tuttavia, ogni istanza di backup di un cluster del servizio Azure Kubernetes deve essere creata in un insieme di credenziali di backup diverso o usando un criterio di backup separato nello stesso insieme di credenziali di backup.

Gestire il backup

Al termine della configurazione di backup per un cluster del servizio Azure Kubernetes, viene creata un'istanza di backup nell'insieme di credenziali di backup. È possibile visualizzare l'istanza di backup per il cluster nella sezione Backup per un'istanza del servizio Azure Kubernetes nel portale di Azure. È possibile eseguire qualsiasi operazione correlata al backup per l'istanza, ad esempio l'avvio di ripristini, il monitoraggio, l'arresto della protezione e così via, tramite l'istanza di backup corrispondente.

Il backup del servizio Azure Kubernetes si integra direttamente con il Centro backup per gestire la protezione per tutti i cluster del servizio Azure Kubernetes e altri carichi di lavoro supportati dal backup in modo centralizzato. Il Centro backup è una singola visualizzazione per tutti i requisiti di backup, ad esempio il monitoraggio dei processi e lo stato dei backup e dei ripristini. Il Centro backup consente di garantire la conformità e la governance, analizzare l'utilizzo dei backup ed eseguire operazioni critiche per eseguire il backup e il ripristino dei dati.

Il backup del servizio Azure Kubernetes usa un'identità gestita per accedere ad altre risorse di Azure. Per configurare il backup di un cluster del servizio Azure Kubernetes e per eseguire il ripristino da un backup precedente, l'identità gestita dell'insieme di credenziali di backup richiede un set di autorizzazioni per il cluster servizio Azure Kubernetes e il gruppo di risorse snapshot in cui vengono creati e gestiti gli snapshot. Attualmente, il cluster del servizio Azure Kubernetes richiede un set di autorizzazioni per il gruppo di risorse snapshot. Inoltre, l'estensione Backup crea un'identità utente e assegna un set di autorizzazioni per accedere all'account di archiviazione in cui vengono archiviati i backup in un BLOB. È possibile concedere autorizzazioni all'identità gestita usando il controllo degli accessi in base al ruolo di Azure. Un'identità gestita è un tipo speciale di entità servizio che può essere usato solo con le risorse di Azure. Vedere altre informazioni sulle identità gestite.

Eseguire il ripristino da un backup

È possibile ripristinare dati da qualsiasi momento per cui esiste un punto di ripristino. Un punto di ripristino viene creato quando un'istanza di backup è in uno stato protetto e può essere usata per ripristinare i dati fino a quando non viene mantenuta dai criteri di backup.

Backup di Azure offre la possibilità di ripristinare tutti gli elementi di cui è stato eseguito il backup o di usare controlli granulari per selezionare elementi specifici dai backup scegliendo spazi dei nomi e altre opzioni di filtro. È anche possibile eseguire il ripristino nel cluster del servizio Azure Kubernetes originale (il cluster di cui è stato eseguito il backup) o in un cluster del servizio Azure Kubernetes alternativo. È possibile ripristinare i backup archiviati nel livello operativo e dell'insieme di credenziali in un cluster nella stessa sottoscrizione e in una sottoscrizione diversa. Solo i backup archiviati nel livello insieme di credenziali possono essere usati per eseguire un ripristino in un cluster in un'area diversa (area abbinata di Azure).

Per ripristinare il backup archiviato nel livello insieme di credenziali, è necessario specificare un percorso di gestione temporanea in cui i dati di backup vengono idratati. Questo percorso di gestione temporanea include un gruppo di risorse e un account di archiviazione all'interno della stessa area e una sottoscrizione del cluster di destinazione per il ripristino. Durante il ripristino, le risorse specifiche (contenitore BLOB, disco e snapshot del disco) vengono create come parte dell'idratazione, che viene quindi cancellata dopo il completamento dell'operazione di ripristino.

Backup di Azure per il servizio Azure Kubernetes supporta attualmente le due opzioni seguenti per i conflitti di risorse (la risorsa di cui è stato eseguito il backup ha lo stesso nome della risorsa nel cluster del servizio Azure Kubernetes di destinazione) durante un'operazione di ripristino. È possibile scegliere una di queste opzioni quando si definisce la configurazione di ripristino.

1. Ignora: questa opzione è selezionata per impostazione predefinita. Ad esempio, se è stato eseguito il backup di un'attestazione di volume permanente denominata pvc-azuredisk e la si sta ripristinando in un cluster di destinazione con un'attestazione di volume permanente con lo stesso nome, l'estensione di backup ignora il ripristino dell'attestazione di volume permanente di cui è stato eseguito il backup. In questi scenari, è consigliabile eliminare la risorsa dal cluster e quindi eseguire l'operazione di ripristino in modo che gli elementi di cui è stato eseguito il backup siano disponibili solo nel cluster e non vengano ignorati.

2. Patch: questa opzione consente di applicare patch alla variabile modificabile nella risorsa sottoposta a backup nella risorsa nel cluster di destinazione. Se si vuole aggiornare il numero di repliche nel cluster di destinazione, è possibile optare per l'applicazione di patch.

Usare hook personalizzati per il backup e il ripristino

È possibile usare hook personalizzati per creare snapshot coerenti con l'applicazione di volumi usati per i database distribuiti come carichi di lavoro in contenitori.

Che cosa sono gli hook personalizzati?

È possibile usare il backup del servizio Azure Kubernetes per eseguire hook personalizzati come parte di un'operazione di backup e ripristino. Gli hook sono comandi configurati per eseguire uno o più comandi in un pod di un contenitore durante un'operazione di backup o dopo il ripristino. Questi hook vengono definiti come risorsa personalizzata e distribuiti nel cluster del servizio Azure Kubernetes di cui si vuole eseguire il backup o il ripristino. Quando la risorsa personalizzata viene distribuita nel cluster del servizio Azure Kubernetes nello spazio dei nomi richiesto, specificare i dettagli come input per il flusso per configurare il backup e il ripristino. L'estensione Backup esegue gli hook come definito in un file YAML.

Il backup nel servizio Azure Kubernetes include due tipi di hook:

• Hook di backup
• Hook di ripristino

Hook di backup

In un hook di backup è possibile configurare i comandi per eseguire l'hook prima di qualsiasi elaborazione di azioni personalizzata (pre-hook) o dopo il completamento di tutte le azioni personalizzate, quando eventuali elementi aggiuntivi specificati dalle azioni personalizzate vengono sottoposti a backup (post-hook).

Ad esempio, di seguito è riportato il modello YAML per la distribuzione di una risorsa personalizzata usando hook di backup:

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

Hook di ripristino

Nello script hook di ripristino, i comandi o gli script personalizzati vengono scritti per essere eseguiti nei contenitori di un pod del servizio Azure Kubernetes ripristinato.

Ecco il modello YAML per una risorsa personalizzata da distribuire usando gli hook di ripristino:

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

Informazioni su come usare gli hook durante il backup del servizio Azure Kubernetes.

Modificare la risorsa durante il ripristino dei backup nel cluster del servizio Azure Kubernetes

È possibile usare la funzionalità Modifica delle risorse per modificare le risorse Kubernetes di cui è stato eseguito il backup durante il ripristino specificando patch JSON come configmap distribuite nel cluster del servizio Azure Kubernetes.

Creare e applicare una mappa di configurazione del modificatore di risorse durante il ripristino

Per creare e applicare la modifica delle risorse, seguire questa procedura:

1. Creare una mappa di configurazione dei modificatori di risorse.

   È necessario creare un file configmap nello spazio dei nomi preferito da un file YAML che ha definito i modificatori di risorse.

   Esempio per la creazione del comando:

   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"
   

   • La configmap precedente applica la patch JSON a tutte le copie del volume persistente negli spazi dei nomi bar e foo con il nome che inizia con mysql e match label foo: bar. La patch JSON sostituisce il storageClassName con premium e rimuove l'etichetta test dalle copie del volume persistente.
   • In questo caso, lo Spazio dei nomi è lo spazio dei nomi originale della risorsa di cui è stato eseguito il backup e non il nuovo spazio dei nomi in cui verrà ripristinata la risorsa.
   • È possibile specificare più patch JSON per una determinata risorsa. Le patch vengono applicate in base all'ordine specificato nella configmap. Viene applicata una patch successiva in ordine. Se vengono specificate più patch per lo stesso percorso, l'ultima patch sostituisce quelle precedenti.
   • È possibile specificare più resourceModifierRules nella configmap. Le regole vengono applicate in base all'ordine specificato nella configmap.

2. Creazione di un riferimento al modificatore di risorse nella configurazione di ripristino

   Quando si esegue un'operazione di ripristino, specificare il nome ConfigMap e lo Spazio dei nomi in cui viene distribuita come parte della configurazione di ripristino. Questi dettagli devono essere forniti in Regole del modificatore di risorse.

   

Operazioni supportate dal Modificatore di risorse

• Aggiunta

  È possibile usare l'operazione Add per aggiungere un nuovo blocco al file JSON della risorsa. Nell'esempio seguente l'operazione aggiunge dettagli di un nuovo contenitore alla specifica con una distribuzione.

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

• Rimuovi

  È possibile usare l'operazione Remove per rimuovere una chiave dal file JSON della risorsa. Nell'esempio seguente l'operazione rimuove l'etichetta con test come chiave.

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

• Sostituzione

  È possibile usare l'operazione Replace per sostituire un valore per il percorso indicato impostando un percorso alternativo. Nell'esempio seguente, l'operazione sostituisce storageClassName nell'attestazione del volume permanente con premium.

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

• Copia

  È possibile usare l'operazione Copy per copiare un valore da un percorso dalle risorse definite a un altro percorso.

  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

  È possibile usare l'operazione Test per verificare se nella risorsa è presente un valore specifico. Se il valore è presente, viene applicata la patch. Se il valore non è presente, non viene applicata la patch. Nell'esempio seguente l'operazione controlla se le attestazioni del volume permanente hanno premium come StorageClassName e lo sostituiscono con standard, se 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"
  

• Patch JSON

  Questa configmap applica la patch JSON a tutte le distribuzioni negli spazi dei nomi per impostazione predefinita e ''nginxwith the name that starts withnginxdep'. La patch JSON aggiorna il numero di repliche a 12 per tutte queste distribuzioni.

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

• Patch di merge JSON

  Questa mappa di configurazione applicherà la patch di merge JSON a tutte le distribuzioni negli spazi dei nomi predefinite e nginx con il nome che inizia con nginxdep. La patch di merge JSON aggiunge/aggiorna l'etichetta "app" con il valore "nginx1".

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

• Patch di merge strategico

  Questa mappa di configurazione applicherà la patch di merge strategico a tutti i pod nello spazio dei nomi predefinito con il nome che inizia con nginx. La patch di merge strategico aggiornerà l'immagine di nginx del contenitore in 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"
              }
            ]
          }
        }
  

Quale livello di archiviazione di backup supporta il backup del servizio Azure Kubernetes?

Backup di Azure per il servizio Azure Kubernetes supporta due livelli di archiviazione come archivi dati di backup:

• Livello operativo: l'estensione di backup installata nel cluster servizio Azure Kubernetes esegue prima il backup tramite snapshot del volume con il driver CSI e archivia lo stato del cluster in un contenitore BLOB nel proprio tenant. Questo livello supporta un RPO (obiettivo del punto di ripristino) inferiore con la durata minima tra due backup di quattro ore. Inoltre, per i volumi basati su dischi di Azure, il livello operativo supporta ripristini più rapidi.

• Livello standard dell'insieme di credenziali (anteprima): per archiviare i dati di backup per una durata più lunga a un costo inferiore rispetto agli snapshot, il backup del servizio Azure Kubernetes supporta l'archivio dati standard dell'insieme di credenziali. In base alle regole di conservazione impostate nei criteri di backup, il primo backup riuscito (di un giorno, di una settimana, di un mese o di un anno) viene spostato in un contenitore BLOB all'esterno del tenant. Questo archivio dati non solo consente una conservazione più lunga, ma fornisce anche protezione ransomware. È anche possibile spostare i backup archiviati nell'insieme di credenziali in un'altra area (area abbinata di Azure) per il ripristino abilitando Ridondanza geografica e Ripristino tra aree nell'insieme di credenziali di backup.

Informazioni sui prezzi

Vengono effettuati addebiti per:

• Tariffa dell'istanza protetta: Backup di Azure per il servizio Azure Kubernetes addebita una tariffa di istanza protetta per spazio dei nomi al mese. Quando si configura il backup per un cluster del servizio Azure Kubernetes, viene creata un'istanza protetta. Ogni istanza ha un numero specifico di spazi dei nomi di cui viene eseguito il backup come definito nella configurazione di backup. Per altre informazioni sui prezzi di backup del servizio Azure Kubernetes, vedere Prezzi per il backup nel cloud e selezionare Servizio Azure Kubernetes come carico di lavoro

• Tariffa snapshot: Backup di Azure per il servizio Azure Kubernetes protegge un volume permanente basato su disco eseguendo snapshot archiviati nel gruppo di risorse nella sottoscrizione di Azure. Questi snapshot comportano addebiti per l'archiviazione. Poiché gli snapshot non vengono copiati nell'insieme di credenziali di backup, i costi di archiviazione del backup non si applicano. Per altre informazioni sui prezzi degli snapshot, vedere Prezzi del disco gestito.

Passaggio successivo