Come proteggere i dati dei suoi StatefulSet con Backup for GKE

Gli StatefulSet sono una potente risorsa Kubernetes per gestire le applicazioni stateful, ma possono anche risultare complessi e difficili da sottoporre a backup, con il rischio di perdita di dati in caso di guasto.

Nel 2022 Google ha annunciato un nuovo add-on per GKE, Backup for GKE: un modo semplice e cloud-native per proteggere, gestire e ripristinare tutte le applicazioni containerizzate e i relativi dati.

In questo articolo vedremo i componenti di Backup for GKE e come effettuare il backup dei volumi di uno StatefulSet MySQL distribuito in un cluster GKE.

Backup for GKE è composto da due elementi principali:

• Un servizio in esecuzione su Google Cloud che espone un'API REST basata su risorse. Questo servizio funge da control plane di Backup for GKE e include gli elementi della UI nella console Google Cloud che interagiscono con l'API.
• Un agent in esecuzione in ogni cluster su cui vengono eseguite operazioni di backup o restore. L'agent gestisce queste operazioni interagendo con l'API di Backup for GKE.

Il servizio Backup for GKE si integra con la UI di GKE, con la Google Cloud CLI e con le API REST, offrendo flussi di lavoro coerenti tra sviluppo e operations. Un backup acquisisce due tipi di dati:

• Config backup: un insieme di manifest delle risorse Kubernetes estratti dall'API server del cluster sottoposto a backup, che fotografa lo stato del cluster.
• Volume backups: un insieme di backup dei volumi corrispondenti alle risorse PersistentVolumeClaim presenti nel config backup.

Può scegliere quali workloads sottoporre a backup o ripristino, oppure operare su tutti i workloads. Può effettuare il backup dei workloads di un cluster e ripristinarli su un altro, oltre a programmare l'esecuzione automatica dei backup per ripristinare rapidamente i workloads in caso di incidente.

Nei prossimi passaggi creeremo un cluster GKE zonale, distribuiremo uno StatefulSet MySQL e testeremo sia la creazione del backup sia il restore del nostro DB.

Definire le variabili

Per semplificare, creiamo alcune variabili d'ambiente:

export PROJECT_ID=felipe-playground-378415
export REGION=us-east1
export LOCATION=us-east1-c
export CLUSTER=backup-for-gke
export BK_PLAN_ALL_NAMESPACES=mysql-bk-plan-all-ns
export RESTORE_PLAN_ALL_NAMESPACES=mysql-bk-plan-all-ns
export BK_ALL_NAMESPACES=mysql-bk-all-namespaces
export RESTORE_ALL_NAMESPACES=mysql-restore-all-namespaces

Creare il cluster GKE

Impostiamo alcune variabili per snellire i comandi. Si ricordi di inserire il proprio PROJECT_ID. In questo esercizio creeremo un cluster GKE zonale nella zona us-east1-c. Un cluster zonale ha un singolo control plane in un'unica zona. Per i workloads di produzione consiglio comunque cluster regionali, che offrono maggiore disponibilità grazie a più repliche del control plane distribuite su più zone della stessa regione. Stiamo inoltre usando tutti i valori predefiniti del cluster, come VPC e subnet di default, numero di nodi, service account predefinito, ecc. Per i cluster di produzione i valori predefiniti sono da evitare.

Si ricordi di aggiungere il flag --addons=BackupRestore al comando, in modo da distribuire anche i controller di backup e tutte le CRD.

gcloud container clusters create ${CLUSTER} \
    --release-channel stable \
    --zone ${LOCATION} \
    --node-locations ${LOCATION} \
    --project ${PROJECT_ID} \
    --addons=BackupRestore

Ora colleghiamoci al cluster:

gcloud container clusters get-credentials ${CLUSTER} \
--zone ${LOCATION} \
--project ${PROJECT_ID}

Installare uno StatefulSet

Creiamo ora il nostro StatefulSet. Per questo esercizio ho scelto l'operator MySQL, davvero semplice e immediato da installare con Helm.

helm repo add mysql-operator https://mysql.github.io/mysql-operator/
helm repo update
helm install my-mysql-operator mysql-operator/mysql-operator \
   --namespace mysql-operator --create-namespace

Installare MySQL

Installi MySQL con Helm e — mi raccomando — cambi la password!

helm install mycluster mysql-operator/mysql-innodbcluster \
   --set tls.useSelfSigned=true \
   --set credentials.root.user=safeuser \
   --set credentials.root.password=notsupersafepassword \
   --set credentials.root.host="%"

Con il comando kubectl get pods,pvc dovrebbe vedere qualcosa di simile:

NAME                                    READY   STATUS    RESTARTS   AGE
pod/mycluster-0                         2/2     Running   0          23m
pod/mycluster-1                         2/2     Running   0          23m
pod/mycluster-2                         2/2     Running   0          23m
pod/mycluster-router-67585969f6-m9nd7   1/1     Running   0          22m

NAME                                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/datadir-mycluster-0   Bound    pvc-d5214172-9b81-4d29-9bf0-9e0dcdc8f691   2Gi        RWO            standard-rwo   23m
persistentvolumeclaim/datadir-mycluster-1   Bound    pvc-df8e188a-51aa-4c4f-acb1-73daa72bc721   2Gi        RWO            standard-rwo   23m
persistentvolumeclaim/datadir-mycluster-2   Bound    pvc-defb5e6e-5946-4183-99d2-c168b05a3d6c   2Gi        RWO            standard-rwo   23m

Perfetto! Il passo successivo è configurare le risorse Backup for GKE per il nostro cluster.

Backup for GKE prevede due tipi di risorse di configurazione e controllo:

• BackupPlan: una risorsa parent per le risorse Backup che rappresentano una catena di backup. Contiene la configurazione del backup, ovvero il cluster di origine, la selezione dei workloads da proteggere e la regione in cui vengono archiviati gli artefatti Backup generati nell'ambito del piano.
• RestorePlan: fornisce un template di restore riutilizzabile. Contiene la configurazione del restore: cluster di destinazione, piano di backup di origine, scope del restore, gestione dei conflitti e regole di sostituzione.

Creare un piano di backup per tutti i namespace

gcloud beta container backup-restore backup-plans create ${BK_PLAN_ALL_NAMESPACES} \
    --project=${PROJECT_ID} \
    --location=${REGION} \
    --cluster=projects/${PROJECT_ID}/locations/${LOCATION}/clusters/${CLUSTER} \
    --all-namespaces \
    --include-secrets \
    --include-volume-data

Creare un piano di restore per tutti i namespace

gcloud beta container backup-restore restore-plans create ${RESTORE_PLAN_ALL_NAMESPACES}\
  --all-namespaces \
  --project=${PROJECT_ID} \
  --location=${REGION} \
  --backup-plan=projects/${PROJECT_ID}/locations/${REGION}/backupPlans/${BK_PLAN_ALL_NAMESPACES} \
  --cluster=projects/${PROJECT_ID}/locations/${LOCATION}/clusters/${CLUSTER} \
  --cluster-resource-conflict-policy=use-existing-version \
  --namespaced-resource-restore-mode=delete-and-restore \
  --volume-data-restore-policy=restore-volume-data-from-backup \
  --cluster-resource-restore-scope="storage.k8s.io/StorageClass","scheduling.k8s.io/PriorityClass"

Se i comandi precedenti sono andati a buon fine, i piani sono pronti.

Creare un backup per tutti i namespace

gcloud beta container backup-restore backups create ${BK_ALL_NAMESPACES} \
--project=${PROJECT_ID} \
--location=${REGION} \
--backup-plan=${BK_PLAN_ALL_NAMESPACES} \
--wait-for-completion

L'operazione può richiedere del tempo, in base alla dimensione dei volumi, ma al termine dovrebbe comparire questo messaggio:

Backup completed. Backup state: SUCCEEDED

Testare il restore del backup

gcloud beta container backup-restore restores create ${RESTORE_ALL_NAMESPACES} \
  --project=${PROJECT_ID} \
  --location=${REGION} \
  --restore-plan=${RESTORE_PLAN_ALL_NAMESPACES} \
  --backup=projects/$PROJECT_ID/locations/${REGION}/backupPlans/${BK_PLAN_ALL_NAMESPACES}/backups/${BK_ALL_NAMESPACES} \
  --wait-for-completion

Restore Completed. Restore stat: SUCCEEDED

Funziona alla perfezione!

Backup for GKE consente anche di sottoporre a backup un singolo bundle applicativo creato tramite la CRD ProtectedApplication, ma sarà argomento di un altro articolo.

IaC

Ad oggi (giugno 2023) è disponibile una sola risorsa Terraform per creare un GKE Backup Plan, google_gke_backup_backup_plan, introdotta nel Google provider versione 4.5.0, come può vedere qui. Ci aspettiamo che presto se ne aggiungano altre.

Prezzi

Backup for GKE genera costi su due fronti: una tariffa di gestione del backup GKE, calcolata sul numero di pod GKE protetti, e una tariffa di archiviazione del backup, calcolata sul volume di dati (GB) archiviati. Entrambe sono fatturate su base mensile, in linea con la fatturazione delle altre funzionalità GKE.

Ad esempio, un cliente con un singolo piano di backup in Iowa (us-central1) che protegge una media di 20 pod nell'arco di un mese e archivia 200 GB di dati di backup in Iowa, sosterrebbe un costo di 25,60 $: 20 $ mensili per la gestione del backup GKE (20 x 1,00 $ / pod-mese) e 5,60 $ per l'archiviazione (200 x 0,028 $ / GB-mese).

Dal 26 giugno 2023 saranno introdotti nuovi addebiti di network egress per i backup archiviati in una regione diversa da quella del cluster GKE di origine. Tali addebiti dipenderanno dalla regione di origine e di destinazione e dal numero di byte trasferiti per ogni operazione di backup "cross-region".

Pulizia

Eliminare il cluster:

gcloud container clusters delete ${CLUSTER} --project $PROJECT_ID --zone ${LOCATION}

Non dimentichi di eliminare anche i backup e i piani.

# Elimina backup
gcloud beta container backup-restore backups delete ${BK_ALL_NAMESPACES} \
  --location=${REGION} \
  --backup-plan=${BK_PLAN_ALL_NAMESPACES}
# Elimina backup plan
gcloud beta container backup-restore backup-plans delete ${BK_PLAN_ALL_NAMESPACES} \
  --location=${REGION}
# Elimina restore plan
gcloud beta container backup-restore restore-plans delete ${RESTORE_PLAN_ALL_NAMESPACES} \
  --location=${REGION}

Spero che questo percorso le sia utile: per qualsiasi domanda, non esiti a scrivermi!