Definisci la logica personalizzata di backup e ripristino

Quando abiliti l'agente Backup per GKE nel cluster Google Kubernetes Engine, Backup per GKE fornisce un CustomResourceDefinition che introduce un nuovo tipo di risorsa Kubernetes: ProtectedApplication.

La composizione di un ProtectedApplication prevede tre attività:

Le risorse ProtectedApplication ti offrono queste funzionalità quando personalizzi la logica di backup e ripristino a livello di applicazione:

  • Operazioni di backup e ripristino più granulari. Senza ProtectedApplications, l'ambito dei backup deve essere definito a livello di Namespace (selezionando allNamespaces o selectedNamespaces). Una logica simile si applica al ripristino delle risorse con spazio dei nomi. La creazione di risorse ProtectedApplication ti consente di fornire un nome a un sottoinsieme delle risorse in un Namespace. Puoi quindi eseguire il backup e il ripristino di questo sottoinsieme elencando selectedApplications nell'ambito del backup (e analogamente, per il ripristino).

  • Orchestrazione dei dettagli granulari del processo di backup o ripristino, tra cui:

    • Ignorando i volumi selezionati durante il backup.

    • Incorporare la topologia dell'applicazione nel backup e nel ripristino (ad esempio, eseguire il backup di una sola istanza di un database replicato e utilizzarla per ripristinare più istanze).

    • Esecuzione di hook definiti dall'utente prima e dopo la creazione degli snapshot dei volumi. Questi possono essere utilizzati, ad esempio, per svuotare e sospendere un workload prima di creare lo snapshot e riattivarlo in seguito.

Puoi creare ProtectedApplication utilizzando kubectl come altre risorse Kubernetes. Sono completamente facoltativi. Se le risorse ProtectedApplication non sono presenti, Backup per GKE crea backup del volume per tutti i volumi nell'ambito di un backup e i backup del volume risultanti saranno coerenti con gli arresti anomali: tutti i dati scritti sul disco in un determinato momento verranno acquisiti (ovvero, non ci saranno scritture parziali). Tuttavia, alcune applicazioni potrebbero conservare in memoria dati che non vengono scaricati su disco, pertanto la possibilità che un'applicazione possa essere recuperata correttamente da un backup coerente con gli arresti anomali dipende dalla logica dell'applicazione.

Selezione delle risorse

Il primo passo per creare la risorsa ProtectedApplication è identificare le altre risorse nello stesso Namespace che vuoi includere nell'applicazione. Questo è l'insieme di risorse di cui verrà eseguito il backup o il ripristino se fornisci l'opzione di ambito selectedApplications nella configurazione di BackupPlan.

Le risorse vengono identificate utilizzando un selettore di etichette. A questo scopo, devi etichettare tutte le risorse (utilizzando il campo metadata.label in ogni risorsa) con la stessa etichetta. Tieni presente che questo vale anche per le risorse create automaticamente dai controller. Queste risorse create automaticamente sono etichettate utilizzando il modello corrispondente. Tieni presente che è comune riutilizzare la stessa etichetta che stai già utilizzando per associare Pods e PersistentVolumeClaims generati alla risorsa principale.

Le considerazioni sull'utilizzo includono:

  • Se vuoi proteggere le risorse che creano risorse secondarie, sia le risorse principali (come StatefulSet, Deployment o DaemonSet) sia le risorse secondarie (come Pod o PersistentVolumeClaim) devono avere l'etichetta utilizzata nel campo Selector di ProtectedApplication.
  • Se alcune delle risorse a cui fa riferimento il tuo ProtectedApplication vengono create automaticamente da un operatore, devi includere anche le risorse personalizzate dell'operatore nel selettore ProtectedApplication. In questo modo, si evita una race condition al momento del ripristino che può verificarsi quando l'operator tenta di creare una risorsa mentre viene ripristinata contemporaneamente dal backup.

Il seguente esempio mostra come applicare l'etichetta app: nginx alle altre risorse oltre a Deployment.

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-vars
  namespace: webserver
  labels:
    app: nginx
  data:
    ...
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nginx-logs
  namespace: webserver
  labels:
    app: nginx
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Mi
  storageClassName: standard-rwo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: webserver
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      volumes:
        - name: nginx-logs
          persistentVolumeClaim:
           claimName: nginx-logs
      containers:
      ...

Dopo aver applicato l'etichetta selezionata a tutte le risorse di destinazione (e ai template da cui vengono generate risorse aggiuntive), puoi fare riferimento a queste risorse da un ProtectedApplication. Ad esempio:

kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
metadata:
  name: nginx
  namespace: webserver
spec:
  resourceSelection:
    type: Selector
    selector:
      matchLabels:
        app: nginx
  ...

Definisci regole di orchestrazione

Una volta identificate tutte le risorse nel tuo ProtectedApplication, puoi scegliere di definire regole di orchestrazione dettagliate per un sottoinsieme di queste risorse. Queste regole possono essere applicate solo a due tipi di risorse: Deployments e StatefulSets e sono menzionate nella sezione components del ProtectedApplication.

Panoramica dei componenti

La configurazione di un componente prevede quanto segue:

  • Selezionare una strategia fondamentale per il funzionamento del backup e del ripristino per questo componente. Sono disponibili tre strategie:

    • BackupAllRestoreAll: esegui il backup dei volumi associati a tutte le istanze del componente e ripristinali tutti dai backup.

    • BackupOneRestoreAll: esegui il backup dei volumi di una sola istanza del componente e utilizza questi backup per ripristinare tutte le istanze.

    • DumpAndLoad: esporta i dati dall'applicazione in un unico volume al momento del backup e importa questi dati nell'applicazione al momento del ripristino.

  • Definizione di hook di esecuzione da eseguire durante il backup (ed eventualmente il ripristino, a seconda della strategia). Un hook è un comando eseguito in container specifici.

  • Selezione di un sottoinsieme di volumi di cui eseguire il backup.

Hook di esecuzione

Un hook è un comando shell che Backup per GKE esegue in un container in una fase specifica del processo di backup o ripristino.

Esistono quattro tipi di hook:

  • pre hooks: questi comandi vengono eseguiti immediatamente prima del backup dei volumi e in genere svuotano i dati in memoria sul disco e mettono inattiva l'applicazione in modo che non vengano eseguite nuove scritture su disco. Questi hook vengono utilizzati nelle strategie BackupAllRestoreAll e BackupOneRestoreAll.

  • post hooks: questi comandi vengono eseguiti durante la procedura di backup del volume subito dopo il passaggio SNAPSHOTTING della procedura di backup del volume (prima del passaggio UPLOADING). In genere, il passaggio SNAPSHOTTING richiede solo pochi secondi. In genere, si prevede che riattivino l'applicazione (ovvero consentano la normale elaborazione e le scritture su disco). Questi hook vengono utilizzati nelle strategie BackupAllRestoreAll, BackupOneRestoreAll e DumpAndLoad.

  • dump hooks: questi comandi vengono eseguiti prima del backup del volume nella strategia DumpAndLoad e in genere prevedono l'esportazione dei dati dall'applicazione nel volume di backup designato.

  • load hooks: questi comandi vengono eseguiti al momento del ripristino dopo il ripristino del volume di backup nei casi della strategia DumpAndLoad. In genere, si prevede che importino i dati dal volume di backup nell'applicazione.

Puoi fornire più di un hook per ogni tipo e Backup per GKE li eseguirà nell'ordine in cui li definisci.

Gli hook vengono definiti nella sezione dei componenti della specifica ProtectedApplication. Tutte le definizioni di hook hanno gli stessi campi disponibili:

  • name: un nome che assegni all'hook.

  • container - (facoltativo) nome del container in cui eseguire il comando. Se non fornisci il container, Backup per GKE eseguirà l'hook nel primo container definito per i Pod target.

  • command: questo è il comando effettivo inviato al container, costruito come array di parole. La prima parola nell'array è il percorso del comando e le parole successive sono gli argomenti da passare al comando.

  • timeoutSeconds - (facoltativo) tempo prima dell'interruzione dell'esecuzione dell'hook. Se non lo fornisci, il valore predefinito è 30 secondi.

  • onError: (facoltativo) comportamento adottato quando l'hook non va a buon fine. Può essere impostato su Ignore o Fail (impostazione predefinita). Se imposti questo valore su Fail, quando un hook non va a buon fine, il backup del volume non andrà a buon fine. Se imposti questo valore su Ignore, gli errori di questo hook vengono ignorati.

Prima di applicare gli hook ProtectedApplication alla tua applicazione, devi testare il comando utilizzando kubectl exec per assicurarti che gli hook si comportino come previsto:

kubectl exec POD_NAME -- COMMAND

Sostituisci quanto segue:

  • POD_NAME: il nome del pod che contiene la risorsa ProtectedApplication.
  • COMMAND: l'array contenente il comando che vuoi eseguire nel container.

Selezione di un sottoinsieme di volumi di cui eseguire il backup

A volte, le applicazioni scrivono su volumi che non è interessante ripristinare (ad esempio, determinati volumi di log o di scratch). Puoi eliminare il backup di questi volumi utilizzando un selettore di volumi.

Per utilizzare questa funzionalità, devi prima applicare un'etichetta comune alle risorse PersistentVolumeClaim dei volumi di cui vuoi eseguire il backup. Devi anche lasciare questa etichetta disattivata per le risorse PersistentVolumeClaim dei volumi di cui non vuoi eseguire il backup. Quindi, includi una clausola volumeSelector nella definizione del componente come segue:

spec:
  ...
  components:
  ...
    strategy:
      ...
      volumeSelector:
        matchLabels:
          label_name: label_value

Se fornisci un volumeSelector per un componente, vengono sottoposti a backup e ripristinati solo i volumi le cui risorse PersistentVolumeClaim hanno l'etichetta specificata. Al momento del ripristino, tutti gli altri volumi vengono sottoposti a provisioning come vuoti anziché ripristinati da un backup del volume.

Strategia: BackupAllRestoreAll

Si tratta della strategia più semplice, che esegue il backup di tutti i volumi del componente al momento del backup e li ripristina tutti dai backup dei volumi al momento del ripristino. È la scelta migliore quando la tua applicazione non prevede la replica tra Pods.

Questa strategia supporta i seguenti parametri:

  • backupPreHooks - (facoltativo) un elenco ordinato di hook eseguiti immediatamente prima del backup dei volumi. Questi comandi vengono eseguiti su tutti i Pods nel componente.

  • backupPostHooks - (facoltativo) un elenco ordinato di hook che vengono eseguiti dopo che i backup del volume hanno raggiunto la fase UPLOADING. Questi comandi vengono eseguiti su tutti i Pods nel componente.

  • volumeSelector: (facoltativo) logica per la corrispondenza di un sottoinsieme di volumi da sottoporre a backup.

Questo esempio crea una risorsa ProtectedApplication che mette in pausa il file system prima di eseguire il backup del volume dei log e lo riattiva dopo il backup:

kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
metadata:
  name: nginx
  namespace: sales
spec:
  resourceSelection:
    type: Selector
    selector:
      matchLabels:
        app: nginx
  components:
  - name: nginx-app
    resourceKind: Deployment
    resourceNames: ["nginx-deployment"]
    strategy:
      type: BackupAllRestoreAll
      backupAllRestoreAll:
        backupPreHooks:
        - name: freeze
          container: nginx
          command:
          - bash
          - "-c"
          - |
            # Add application logic to flush data to disk before snapshot
            # and freeze the application from further changes.
            echo "Freezing the application"

            # Return 0 on successful freeze of application, and non-zero
            # for errors
            exit 0
        backupPostHooks:
        - name: unfreeze
          container: nginx
          command:
          - bash
          - "-c"
          - |
            # Add application logic to unfreeze the application.
            echo "Unfreezing the application"

            # Return 0 on successful freeze of application, and non-zero
            # for errors
            exit 0

Strategia: BackupOneAndRestoreAll

Questa strategia esegue il backup di una copia di un pod selezionato. Questa singola copia è l'origine per il ripristino di tutti i pod durante un ripristino. Questo metodo può contribuire a ridurre i costi di archiviazione e i tempi di backup. Questa strategia funziona in una configurazione ad alta affidabilità quando un componente viene implementato con un PersistentVolumeClaim primario e più PersistentVolumeClaims secondari.

Questa strategia supporta i seguenti parametri:

  • backupTargetName (obbligatorio) specifica quale Deployment o StatefulSet vuoi utilizzare per eseguire il backup dei dati. Viene selezionato automaticamente il Pod migliore per il backup. In una configurazione ad alta affidabilità, ti consigliamo di impostare questo valore su una delle repliche dell'applicazione.

  • backupPreHooks - (facoltativo) un elenco ordinato di hook che vengono eseguiti subito prima del backup dei volumi. Questi comandi vengono eseguiti solo sul backup selezionato Pod.

  • backupPostHooks - (facoltativo) un elenco ordinato di hook che vengono eseguiti dopo che i backup del volume hanno raggiunto la fase UPLOADING. Questi comandi vengono eseguiti solo sul backup selezionato Pod.

  • volumeSelector: (facoltativo) logica per la corrispondenza di un sottoinsieme di volumi da sottoporre a backup.

Se un componente è configurato con più Deployment o StatefulSet, tutte le risorse devono avere la stessa struttura PersistentVolume, il che significa che devono rispettare queste regole:

  • Il numero di PersistentVolumeClaims utilizzati da tutti i deployment o StatefulSet deve essere lo stesso.
  • Lo scopo di PersistentVolumeClaims nello stesso indice deve essere lo stesso. Per gli StatefulSet, l'indice è definito in volumeClaimTemplate. Per i deployment, l'indice è definito in Volumes e tutti i volumi non persistenti vengono ignorati.
  • Se il componente dell'applicazione è costituito da deployment, ogni deployment deve avere esattamente una replica.

Tenendo conto di queste considerazioni, è possibile selezionare più set di volumi per il backup, ma verrà selezionato un solo volume da ogni set di volumi.

Questo esempio, che presuppone un'architettura con un StatefulSet primario e un StatefulSet secondario, mostra un backup dei volumi di un pod nel StatefulSet secondario e un ripristino in tutti gli altri volumi:

kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
metadata:
  name: mariadb
  namespace: mariadb
spec:
  resourceSelection:
    type: Selector
    selector:
      matchLabels:
        app: mariadb
  components:
  - name: mariadb
    resourceKind: StatefulSet
    resourceNames: ["mariadb-primary", "mariadb-secondary"]
    strategy:
      type: BackupOneRestoreAll
      backupOneRestoreAll:
        backupTargetName: mariadb-secondary
        backupPreHooks:
        - name: quiesce
          container: mariadb
          command: [...]
        backupPostHooks:
        - name: unquiesce
          container: mariadb
          command: [...]

Strategia: DumpAndLoad

Questa strategia utilizza un volume dedicato per i processi di backup e ripristino e richiede un PersistentVolumeClaim dedicato collegato a un componente che archivia i dati di dump.

Questa strategia supporta i seguenti parametri:

  • dumpTarget (obbligatorio) specifica quale Deployment o StatefulSet vuoi utilizzare per eseguire il backup dei dati. Il pod migliore per il backup viene selezionato automaticamente. In una configurazione a disponibilità elevata, ti consigliamo di impostare questo valore su una delle repliche dell'applicazione.

  • loadTarget (obbligatorio): specifica quale deployment o StatefulSet deve essere utilizzato per caricare i dati. Viene selezionato automaticamente il Pod migliore per il backup. Il carico target non deve essere uguale al dump target.

  • dumpHooks - (obbligatorio) un elenco ordinato di hook eseguiti per compilare il volume di backup dedicato. Questi comandi vengono eseguiti solo sul dump selezionato Pod.

  • backupPostHooks - (facoltativo) un elenco ordinato di hook che vengono eseguiti dopo che i backup del volume hanno raggiunto la fase UPLOADING. Questi comandi vengono eseguiti solo sul dump selezionato Pod.

  • loadHooks - (obbligatorio) un elenco ordinato di hook eseguiti per caricare i dati dal volume ripristinato dopo l'avvio dell'applicazione. Questi comandi vengono eseguiti solo sul carico selezionato Pod.

  • volumeSelector - (obbligatorio) logica per la corrispondenza di un singolo volume per il backup e il ripristino (il volume "dump"). Sebbene debba corrispondere a un solo volume, configuri questa opzione nello stesso modo in cui configuri il sottoinsieme di volumi di cui eseguire il backup utilizzato da altre strategie.

Se l'applicazione è costituita da deployment, ogni deployment deve avere esattamente una replica.

Questo esempio, che presuppone un'architettura di un StatefulSet primario e un StatefulSet secondario con PersistentVolumeClaims dedicato sia per il StatefulSet primario che per quello secondario, mostra una strategia DumpAndLoad:

kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
metadata:
  name: mariadb
  namespace: mariadb
spec:
  resourceSelection:
    type: Selector
    selector:
      matchLabels:
        app: mariadb
  components:
  - name: mariadb-dump
    resourceKind: StatefulSet
    resourceNames: ["mariadb-primary", "mariadb-secondary"]
    strategy:
      type: DumpAndLoad
      dumpAndLoad:
        loadTarget: mariadb-primary
        dumpTarget: mariadb-secondary
        dumpHooks:
        - name: db_dump
          container: mariadb
          command:
          - bash
          - "-c"
          - |
            mysqldump -u root --all-databases > /backup/mysql_backup.dump
        loadHooks:
        - name: db_load
          container: mariadb
          command:
          - bash
          - "-c"
          - |
            mysql -u root < /backup/mysql_backup.sql
        volumeSelector:
          matchLabels:
            gkebackup.gke.io/backup: dedicated-volume

Controllare se un ProtectedApplication è pronto per il backup

Puoi verificare se un ProtectedApplication è pronto per un backup eseguendo il seguente comando:

kubectl describe protectedapplication APPLICATION_NAME

Sostituisci APPLICATION_NAME con il nome della tua applicazione.

Se è pronta, la descrizione dell'applicazione mostrerà lo stato Ready to backup come true, come in questo esempio:

% kubectl describe protectedapplication nginx
Name:         nginx
Namespace:    default
API Version:  gkebackup.gke.io/v1
Kind:         ProtectedApplication
Metadata:
  UID:               90c04a86-9dcd-48f2-abbf-5d84f979b2c2
Spec:
  Components:
    Name:           nginx
    Resource Kind:  Deployment
    Resource Names:
      nginx
    Strategy:
      Backup All Restore All:
        Backup Pre Hooks:
          Command:
             /sbin/fsfreeze
             -f
             /var/log/nginx
          Container:         nginx
          Name:              freeze
        Backup Post Hooks:
          Command:
             /sbin/fsfreeze
             -u
             /var/log/nginx
          Container:         nginx
          Name:              unfreeze
      Type:                  BackupAllRestoreAll
  Resource Selection:
    Selector:
      Match Labels:
        app:        nginx
    Type:           Selector
 Status:
  Ready To Backup:  true 
Events:             <none>

Passaggi successivi