Introduzione
Come qualsiasi altro ambiente, i dati in un cluster Kubernetes possono essere a rischio di perdita. Per prevenire problemi gravi, è essenziale avere un piano di ripristino dati a portata di mano. Un modo semplice ed efficace per farlo è effettuare backup, garantendo che i tuoi dati siano al sicuro in caso di eventi imprevisti. I backup possono essere eseguiti una tantum o pianificati. È una buona idea avere backup programmati per assicurarsi di avere un backup recente su cui tornare facilmente.
Velero – uno strumento open source progettato per aiutare le operazioni di backup e ripristino per i cluster Kubernetes. È ideale per il caso d’uso di ripristino di emergenza, così come per fare uno snapshot dello stato della tua applicazione prima di eseguire operazioni di sistema sul tuo cluster, come gli aggiornamenti. Per ulteriori dettagli su questo argomento, visita la pagina ufficiale Come funziona Velero.
In questo tutorial, imparerai come distribuire Velero nel tuo cluster Kubernetes, creare backup e ripristinare un backup in caso di problemi. Puoi eseguire il backup dell’intero cluster o scegliere facoltativamente uno spazio dei nomi o un selettore di etichette per eseguire il backup del tuo cluster.
Indice
- Prerequisiti
- Passaggio 1 – Installare Velero usando Helm
- Passaggio 2 – Esempio di Backup e Ripristino dello Spazio dei Nomi
- Passaggio 3 – Esempio di Backup e Ripristino dell’intero Cluster
- Passaggio 4 – Backup Programmati
- Passaggio 5 – Eliminare i Backup
Prerequisiti
Per completare questo tutorial, è necessario quanto segue:
- A DO Spaces Bucket and access keys. Save the access and secret keys in a safe place for later use.
- A DigitalOcean API token for Velero to use.
- A Git client, to clone the Starter Kit repository.
- Helm per gestire rilasci e aggiornamenti di Velero.
- Doctl per l’interazione con l’API di DigitalOcean.
- Kubectl per l’interazione con Kubernetes.
- Cliente Velero per gestire i backup di Velero.
Passaggio 1 – Installare Velero usando Helm
In questo passaggio, effettuerai il deployment di Velero e tutti i componenti necessari, in modo che possa eseguire il backup delle risorse del tuo cluster Kubernetes (inclusi i PV). I dati di backup verranno archiviati nel bucket DO Spaces creato in precedenza nella sezione Prerequisiti.
Prima, clona il repository Git del Kit di Avvio e cambia la directory alla tua copia locale:
Successivamente, aggiungi il repository Helm e elenca le chart disponibili:
L’output sarà simile al seguente:
NAME CHART VERSION APP VERSION DESCRIPTION
vmware-tanzu/velero 2.29.7 1.8.1 A Helm chart for velero
La chart di interesse è vmware-tanzu/velero, che installerà Velero sul cluster. Per ulteriori dettagli su questa chart, visita la pagina velero-chart.
Successivamente, apri e ispeziona il file dei valori Helm di Velero fornito nel repository del Kit di Avvio utilizzando un editor a tua scelta (possibilmente con supporto per il linting YAML).
Poi, sostituisci i segnaposto <> di conseguenza per il tuo bucket Velero DO Spaces (come nome, regione e segreti). Assicurati di fornire anche il tuo token API DigitalOcean (chiave DIGITALOCEAN_TOKEN).
Infine, installa Velero usando helm:
A specific version of the Velero Helm chart is used. In this case 2.29.7 is picked, which maps to the 1.8.1 version of the application (see the output from Step 2.). It’s a good practice in general to lock on a specific version. This helps to have predictable results and allows versioning control via Git.
–create-namespace \
Ora, verifica il tuo deployment di Velero eseguendo:
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
velero velero 1 2022-06-09 08:38:24.868664 +0300 EEST deployed velero-2.29.7 1.8.1
L’output sarà simile al seguente (la colonna STATUS dovrebbe mostrare deployed):
Successivamente, verifica che Velero sia attivo e in esecuzione:
NAME READY UP-TO-DATE AVAILABLE AGE
velero 1/1 1 1 67s
L’output è simile al seguente (i pod di distribuzione devono essere nello stato Ready):
Se sei interessato a esplorare ulteriormente, puoi visualizzare i componenti lato server di Velero:
- Esplora le pagine di aiuto della CLI di Velero per vedere quali comandi e sotto-comandi sono disponibili. Puoi ottenere aiuto per ciascuno usando il flag
--help: - Elencare tutti i comandi disponibili per
Velero:
Elencare le opzioni del comando backup per Velero:
Velero utilizza diverse CRD (Definizioni di risorse personalizzate) per rappresentare le sue risorse come backup, pianificazioni di backup, ecc. Scoprirai ciascuna nei passaggi successivi del tutorial, insieme ad alcuni esempi di base.
Passaggio 2 – Esempio di backup e ripristino dello spazio dei nomi
In questo passaggio, imparerai come eseguire un backup di una volta per un’intera namespace dal tuo cluster DOKS e successivamente ripristinarlo assicurandoti che tutte le risorse vengano ricreate. Il namespace in questione è ambassador.
Creazione del Backup del Namespace Ambassador
Innanzitutto, inizia il backup:
Successivamente, verifica che il backup sia stato creato:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
ambassador-backup Completed 0 0 2021-08-25 19:33:03 +0300 EEST 29d default <none>
L’output è simile a:
Quindi, dopo qualche istante, puoi ispezionarlo:
Name: ambassador-backup
Namespace: velero
Labels: velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: ambassador
Excluded: <none>
...
- L’output è simile a:
- Cerca la riga
Phase. Dovrebbe direCompleted. - Verifica che non vengano segnalati errori.
Viene creato un nuovo oggetto di backup di Kubernetes:
~ kubectl get backup/ambassador-backup -n velero -o yaml
apiVersion: velero.io/v1
kind: Backup
metadata:
annotations:
velero.io/source-cluster-k8s-gitversion: v1.21.2
velero.io/source-cluster-k8s-major-version: "1"
velero.io/source-cluster-k8s-minor-version: "21"
...
Infine, dai un’occhiata al bucket di DO Spaces e controlla che ci sia una nuova cartella chiamata backups che contiene le risorse create per il tuo ambassador-backup:
Eliminazione del Namespace e delle Risorse dell’Ambasciatore
Prima di tutto, simula un disastro eliminando intenzionalmente il namespace ambassador:
Successivamente, verifica che il namespace sia stato eliminato (l’elenco dei namespace non dovrebbe stampare ambassador):
Infine, verifica che il punto finale dei servizi di backend echo e quote sia DOWN. Si prega di fare riferimento a Creazione dei Servizi di Backend dell’Ambasciatore Edge Stack riguardo alle applicazioni di backend utilizzate nel tutorial del Kit di Avvio. Puoi utilizzare curl per testare (o puoi utilizzare il tuo browser web):
Ripristino del Backup del Namespace dell’Ambasciatore
Ripristina il ambassador-backup:
Importante: Quando elimini lo spazio dei nomi ambassador, anche la risorsa del bilanciamento del carico associata al servizio ambassador verrà eliminata. Quindi, quando ripristini il servizio ambassador, il bilanciamento del carico verrà ricreato da DigitalOcean. Il problema qui è che otterrai un NUOVO indirizzo IP per il tuo bilanciamento del carico, quindi dovrai aggiustare i record A per indirizzare il traffico verso i tuoi domini ospitati sul cluster.
Controllo del Ripristino dello Spazio dei Nomi Ambassador
Per verificare il ripristino dello spazio dei nomi ambassador, controlla la linea Fase dall’output del comando di ripristino ambassador-backup. Dovrebbe dire Completato (inoltre, prendi nota della sezione Avvisi – indica se c’è stato un problema):
Successivamente, verifica che tutte le risorse siano state ripristinate per lo spazio dei nomi ambassador. Cerca i pod, i servizi e i deployments di ambassador.
NAME READY STATUS RESTARTS AGE
pod/ambassador-5bdc64f9f6-9qnz6 1/1 Running 0 18h
pod/ambassador-5bdc64f9f6-twgxb 1/1 Running 0 18h
pod/ambassador-agent-bcdd8ccc8-8pcwg 1/1 Running 0 18h
pod/ambassador-redis-64b7c668b9-jzxb5 1/1 Running 0 18h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ambassador LoadBalancer 10.245.74.214 159.89.215.200 80:32091/TCP,443:31423/TCP 18h
service/ambassador-admin ClusterIP 10.245.204.189 <none> 8877/TCP,8005/TCP 18h
service/ambassador-redis ClusterIP 10.245.180.25 <none> 6379/TCP 18h
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ambassador 2/2 2 2 18h
deployment.apps/ambassador-agent 1/1 1 1 18h
deployment.apps/ambassador-redis 1/1 1 1 18h
NAME DESIRED CURRENT READY AGE
replicaset.apps/ambassador-5bdc64f9f6 2 2 2 18h
replicaset.apps/ambassador-agent-bcdd8ccc8 1 1 1 18h
replicaset.apps/ambassador-redis-64b7c668b9 1 1 1 18h
L’output appare simile a:
Ottieni gli host ambassador:
NAME HOSTNAME STATE PHASE COMPLETED PHASE PENDING AGE
echo-host echo.starter-kit.online Ready 11m
quote-host quote.starter-kit.online Ready 11m
L’output appare simile a:
STATO dovrebbe essere Pronto e la colonna NOME HOST dovrebbe puntare all’hostname completamente qualificato.
Ottieni i mapping di ambassador:
NAME SOURCE HOST SOURCE PREFIX DEST SERVICE STATE REASON
ambassador-devportal /documentation/ 127.0.0.1:8500
ambassador-devportal-api /openapi/ 127.0.0.1:8500
ambassador-devportal-assets /documentation/(assets|styles)/(.*)(.css) 127.0.0.1:8500
ambassador-devportal-demo /docs/ 127.0.0.1:8500
echo-backend echo.starter-kit.online /echo/ echo.backend
quote-backend quote.starter-kit.online /quote/ quote.backend
L’output assomiglia a (nota il echo-backend che è mappato sull’host echo.starter-kit.online e il prefisso di origine /echo/, lo stesso per quote-backend):
Infine, dopo aver riconfigurato il bilanciamento del carico e le impostazioni del dominio DigitalOcean, verifica che il punto finale dei servizi di backend echo e quote sia UP. Fai riferimento a Creazione dei Servizi di Backend di Ambassador Edge Stack.
Nel prossimo passaggio, simulerai un disastro eliminando intenzionalmente il tuo cluster DOKS.
Passaggio 3 – Esempio di Backup e Ripristino dell’Intero Cluster
In questo passaggio, simulerai uno scenario di ripristino da disastro. L’intero cluster DOKS verrà eliminato e quindi ripristinato da un backup precedente.
Creazione del Backup del Cluster DOKS
Per prima cosa, crea un backup dell’intero cluster DOKS:
Successivamente, verifica che il backup sia stato creato e non segnali errori. Il seguente comando elenca tutti i backup disponibili:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
all-cluster-backup Completed 0 0 2021-08-25 19:43:03 +0300 EEST 29d default <none>
L’output è simile a:
Infine, ispeziona lo stato e i log del backup (verifica che non siano segnalati errori):
Importante: Ogni volta che si elimina un cluster DOKS senza specificare il flag --dangerous al comando doctl e quindi lo si ripristina, lo stesso bilanciamento del carico con lo stesso IP viene ricreato. Ciò significa che non è necessario aggiornare i record A del DNS di DigitalOcean.
Ma quando il flag --dangerous viene applicato al comando doctl, il bilanciamento del carico esistente verrà eliminato e verrà creato un nuovo bilanciamento del carico con un nuovo IP esterno quando Velero ripristina il tuo controller di ingresso. Quindi, assicurati di aggiornare di conseguenza i tuoi record A del DNS di DigitalOcean.
Per prima cosa, elimina l’intero cluster DOKS (assicurati di sostituire i segnaposto <> di conseguenza).
Per eliminare il cluster Kubernetes senza distruggere il bilanciamento del carico associato, esegui:
Oppure per eliminare il cluster Kubernetes insieme al bilanciamento del carico associato:
Successivamente, ricrea il cluster, come descritto in Configura Kubernetes di DigitalOcean. È importante assicurarsi che il conteggio dei nodi del nuovo cluster DOKS sia uguale o maggiore rispetto a quello originale.
Successivamente, installa Velero CLI e Server, come descritto nella sezione Prerequisiti e nel passaggio Passaggio 1 – Installazione di Velero tramite Helm rispettivamente. È importante utilizzare la stessa versione di Helm Chart.
Infine, ripristina tutto eseguendo il seguente comando:
Controllo dello Stato delle Applicazioni del Cluster DOKS
Innanzitutto, controlla la linea Fase del comando di descrizione del ripristino all-cluster-backup. (Sostituisci di conseguenza i segnaposto <>). Dovrebbe indicare Completato.
Ora, verifica tutte le risorse del cluster eseguendo:
Adesso, le applicazioni backend dovrebbero rispondere anche alle richieste HTTP. Si prega di fare riferimento alla sezione Creazione dei Servizi Backend di Ambassador Edge Stack riguardo alle applicazioni backend utilizzate nel tutorial Starter Kit.
Nel prossimo passaggio, imparerai come eseguire backup programmati (o automatici) per le applicazioni del tuo cluster DOKS.
Passaggio 4 – Backup Programmati
Eseguire backup automaticamente in base a un programma è una funzionalità davvero utile. Ti consente di tornare indietro nel tempo e ripristinare il sistema a uno stato di funzionamento precedente se qualcosa va storto.
Creare un backup programmato è un processo molto semplice. Di seguito viene fornito un esempio per un intervallo di 1 minuto (è stato selezionato il namespace kube-system).
Innanzitutto, creare il programma:
schedule="*/1 * * * *"
È supportato anche il formato cronjob di Linux:
Successivamente, verificare che il programma sia stato creato:
NAME STATUS CREATED SCHEDULE BACKUP TTL LAST BACKUP SELECTOR
kube-system-minute-backup Enabled 2021-08-26 12:37:44 +0300 EEST @every 1m 720h0m0s 32s ago <none>
L’output è simile a:
Quindi, ispezionare tutti i backup dopo circa un minuto:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
kube-system-minute-backup-20210826093916 Completed 0 0 2021-08-26 12:39:20 +0300 EEST 29d default <none>
kube-system-minute-backup-20210826093744 Completed 0 0 2021-08-26 12:37:44 +0300 EEST 29d default <none>
L’output è simile a:
Verifica dello stato del backup programmato
Innanzitutto, controllare la riga Fase di uno dei backup (sostituire i segnaposto <> di conseguenza). Dovrebbe essere Completato.
Ripristino del Backup Programmato
Per ripristinare i backup di un minuto fa, segui gli stessi passaggi appresi nei passaggi precedenti di questo tutorial. Questo è un buon modo per esercitarsi e testare l’esperienza accumulata finora.
Nel prossimo passaggio, imparerai come eliminare manualmente o automaticamente backup specifici che hai creato nel tempo.
Passaggio 5 – Eliminazione dei Backup
Se non hai bisogno di backup più vecchi, puoi liberare risorse sia sul cluster Kubernetes che sul bucket Velero DO Spaces.
Eliminazione Manuale di un Backup
Per prima cosa, seleziona ad esempio un backup di un minuto e utilizza il seguente comando (sostituisci i segnaposto <> di conseguenza):
Ora, controlla che sia scomparso dall’output del comando velero backup get. Dovrebbe essere eliminato anche dal bucket DO Spaces.
Successivamente, eliminerai più backup contemporaneamente utilizzando un selettore. Il sotto-comando velero backup delete fornisce un flag chiamato --selector. Ti permette di eliminare più backup contemporaneamente in base alle etichette di Kubernetes. Si applicano le stesse regole dei Selettori di etichette di Kubernetes.
Prima, elenca i backup disponibili:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
ambassador-backup Completed 0 0 2021-08-25 19:33:03 +0300 EEST 23d default <none>
backend-minute-backup-20210826094116 Completed 0 0 2021-08-26 12:41:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826094016 Completed 0 0 2021-08-26 12:40:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093916 Completed 0 0 2021-08-26 12:39:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093816 Completed 0 0 2021-08-26 12:38:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093716 Completed 0 0 2021-08-26 12:37:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093616 Completed 0 0 2021-08-26 12:36:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093509 Completed 0 0 2021-08-26 12:35:09 +0300 EEST 24d default <none>
L’output è simile a:
Successivamente, dici che vuoi eliminare tutti gli asset backend-minute-backup-*. Scegli un backup dalla lista e ispeziona le Etichette:
Name: backend-minute-backup-20210826094116
Namespace: velero
Labels: velero.io/schedule-name=backend-minute-backup
velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: backend
Excluded: <none>
...
L’output è simile a (nota il valore dell’etichetta velero.io/schedule-name):
Successivamente, puoi eliminare tutti i backup che corrispondono al valore backend-minute-backup dell’etichetta velero.io/schedule-name:
Infine, controlla che tutti gli asset backend-minute-backup-* siano scomparsi dall’output del comando velero backup get così come dal bucket DO Spaces.
Eliminazione automatica dei backup tramite TTL
- Quando crei un backup, puoi specificare un TTL (Time To Live), utilizzando il flag
--ttl. Se Velero rileva che una risorsa di backup esistente è scaduta, rimuove: - La risorsa
Backup - Il file di backup dall’oggetto
storagecloud - Tutti gli snapshot di
PersistentVolume
Tutti i Restores associati
Il flag TTL consente all’utente di specificare il periodo di conservazione del backup con il valore specificato in ore, minuti e secondi nel formato --ttl 24h0m0s. Se non specificato, verrà applicato un valore TTL predefinito di 30 giorni.
Per prima cosa, crea il backup ambassador, utilizzando un valore TTL di 3 minuti:
Successivamente, ispeziona il backup ambassador:
Name: ambassador-backup-3min-ttl
Namespace: velero
Labels: velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: ambassador
Excluded: <none>
Resources:
Included: *
Excluded: <none>
Cluster-scoped: auto
Label selector: <none>
Storage Location: default
Velero-Native Snapshot PVs: auto
TTL: 3m0s
...
A new folder should be created in the DO Spaces Velero bucket as well, named ambassador-backup-3min-ttl.
L’output assomiglia a questo (nota la sezione Namespaces -> Included – dovrebbe visualizzare ambassador, e il campo TTL è impostato su 3ms0):
Infine, dopo circa tre minuti, il backup e le risorse associate dovrebbero essere eliminate automaticamente. Puoi verificare che l’oggetto di backup sia stato distrutto usando: velero backup describe ambassador-backup-3min-ttl. Dovrebbe restituire un errore indicando che il backup non esiste più. La cartella corrispondente ambassador-backup-3min-ttl dal bucket Velero di DO Spaces verrà eliminata anche.