Introduzione
In questo tutorial, imparerai come distribuire TrilioVault per Kubernetes (o TVK) nel tuo cluster DOKS, creare backup e ripristinare da un backup in caso di problemi. Puoi eseguire il backup dell’intero cluster, oppure scegliere facoltativamente backup basati su namespace o etichette.
Vantaggi dell’utilizzo di Trilio:
- Eseguire backup completi (o incrementali) del tuo cluster e ripristinarli in caso di perdita di dati.
- Migrare da un cluster a un altro.
- I backup del rilascio di Helm sono supportati.
- Eseguire pre e post-hooks per le operazioni di backup e ripristino.
- Console di gestione Web che ti consente di ispezionare in dettaglio lo stato delle operazioni di backup/ripristino.
- Definire le politiche di conservazione per i tuoi backup.
- Il ciclo di vita dell’applicazione (cioè, TVK stesso) può essere gestito tramite un operatore dedicato TrilioVault`.
- Integrazione Velero.
- Puoi eseguire il backup e il ripristino delle applicazioni basate su operatore.
Per ulteriori informazioni, fare riferimento alla documentazione ufficiale TVK CRDs.
Tabella dei contenuti
- Prerequisiti
- Passo 1 – Installazione di TrilioVault per Kubernetes
- Passo 2 – Creazione di un target TrilioVault per memorizzare i backup
- Passo 3 – Conoscere la console di gestione Web di TVK
- Passo 4 – Esempio di backup e ripristino su namespace
- Passo 5 – Esempio di backup e ripristino dell’intero cluster
- Passo 6 – Backup pianificati
- Passo 7 – Politica di conservazione dei backup
- Conclusioni
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 Git client to clone the Starter Kit repository.
- Helm, per gestire rilasci e aggiornamenti di TrilioVault Operator.
- Doctl per l’interazione con l’API di DigitalOcean.
- Kubectl per l’interazione con Kubernetes.
Per far sì che TrilioVault funzioni correttamente e faccia il backup dei tuoi PVC, DOKS deve essere configurato per supportare l’interfaccia di archiviazione dei contenitori (o CSI per breve). Per impostazione predefinita, viene fornito con il driver già installato e configurato. Puoi verificare usando il seguente comando:
L’output dovrebbe essere simile al seguente frammento. Nota che il provisioner è dobs.csi.digitalocean.com.
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
do-block-storage (default) dobs.csi.digitalocean.com Delete Immediate true 10d
L’installazione di TrilioVault necessita anche della definizione di risorsa personalizzata (CRD) volumeSnapshot per un’installazione riuscita. Puoi verificare usando il seguente comando:
L’output dovrebbe essere simile al seguente frammento. Se la CRD VolumeSnapshot non è installata, consulta Installing VolumeSnapshot CRDs.
volumesnapshotclasses.snapshot.storage.k8s.io 2022-02-01T06:01:14Z
volumesnapshotcontents.snapshot.storage.k8s.io 2022-02-01T06:01:14Z
volumesnapshots.snapshot.storage.k8s.io 2022-02-01T06:01:15Z
Inoltre, assicurati che la CRD supporti entrambe le versioni API v1beta1 e v1. Puoi eseguire il seguente comando per verificare la versione API:
Alla fine del YAML CRD, dovresti vedere un elenco storedVersions, contenente sia valori v1beta1 che v1 (se non installato, consulta Installing VolumeSnapshot CRDs):
...
- lastTransitionTime: "2022-01-20T07:58:06Z"
message: approved in https://github.com/kubernetes-csi/external-snapshotter/pull/419
reason: ApprovedAnnotation
status: "True"
type: KubernetesAPIApprovalPolicyConformant
storedVersions:
- v1beta1
- v1
Passaggio 1 – Installazione di TrilioVault per Kubernetes
In questo passaggio, imparerai come distribuire TrilioVault per DOKS e gestire le installazioni di TVK tramite Helm. I dati di backup verranno archiviati nel bucket DO Spaces creato in precedenza nella sezione Prerequisiti.
L’applicazione TrilioVault può essere installata in molti modi:
- Tramite l’operatore TrilioVault. Definisci un CRD
TrilioVaultManagerche indica all’operatoreTrilioVaultcome gestire l’installazione, le fasi di post-configurazione e gli aggiornamenti futuri dei componenti dell’applicazione Trilio. - Tramite il grafico triliovault-operator completamente gestito da Helm, (trattato in questo tutorial).
Installazione di TrilioVault tramite Helm
Il tutorial Starter Kit utilizza il tipo di installazione Cluster per l’applicazione TVK (applicationScope è impostato su “Cluster”). Tutti gli esempi di questo tutorial dipendono da questo tipo di installazione per funzionare correttamente.
Prima, clona il repository Git del Starter Kit e cambia la directory nella tua copia locale:
Successivamente, aggiungi il repository di Helm di TrilioVault e elenca i grafici disponibili:
L’output assomiglia a quanto segue:
NAME CHART VERSION APP VERSION DESCRIPTION
triliovault-operator/k8s-triliovault-operator 2.9.2 2.9.2 K8s-TrilioVault-Operator is an operator designe...
Il grafico di interesse è triliovault-operator/k8s-triliovault-operator, che installerà TrilioVault per Kubernetes sul cluster insieme al TrilioVault-Manager. Puoi eseguire helm show values triliovault-operator/k8s-triliovault-operator ed esportare in un file per vedere tutte le opzioni disponibili.
Successivamente, apri e ispeziona il file dei valori di Helm di TrilioVault fornito nel repository del kit di avviamento utilizzando un editor a tua scelta (preferibilmente con supporto per il controllo YAML).
Infine, installa TrilioVault per Kubernetes usando Helm:
–create-namespace \
Il comando sopra installa sia l’Operatore TrilioVault che la Risorsa Personalizzata TriloVault Manager (TVM) utilizzando i parametri forniti nel triliovault-values.yaml. La versione di TVK è ora gestita dal campo tag nel file 05-setup-backup-restore/assets/manifests/triliovault-values.yaml, quindi il comando helm avrà sempre l’ultima versione di TVK.
- Puoi aggiornare i seguenti campi in
values.yaml: installTVK.applicationScopeper l’installazione di TVK con ambito, ad es.ClusteroNamespacedinstallTVK.ingressConfig.hostper l’hostname dell’interfaccia utente di TVK, ad es.tvk-doks.com
installTVK.ComponentConfiguration.ingressController.service.type per il tipo di servizio per accedere all’interfaccia utente di TVK, ad es. NodePort o LoadBalancer
Ora, controlla il tuo deployment di TVK:
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
triliovault-manager-tvk tvk 1 2022-06-08 08:30:08.490304959 +0000 UTC deployed k8s-triliovault-2.9.2 2.9.2
triliovault-operator tvk 1 2022-06-08 11:32:55.755395 +0300 EEST deployed k8s-triliovault-operator-2.9.2 2.9.2
L’output assomiglia al seguente snippet (la colonna STATUS dovrebbe visualizzare deployed):
Successivamente, verifica che TrilioVault sia attivo e in esecuzione:
NAME READY UP-TO-DATE AVAILABLE AGE
k8s-triliovault-admission-webhook 1/1 1 1 83s
k8s-triliovault-control-plane 1/1 1 1 83s
k8s-triliovault-exporter 1/1 1 1 83s
k8s-triliovault-ingress-nginx-controller 1/1 1 1 83s
k8s-triliovault-web 1/1 1 1 83s
k8s-triliovault-web-backend 1/1 1 1 83s
triliovault-operator-k8s-triliovault-operator 1/1 1 1 4m22s
L’output assomiglia al seguente snippet. Tutti i pod di distribuzione devono essere nello stato Ready.
Se l’output è simile a questo, hai installato TVK con successo. Successivamente, imparerai come controllare il tipo e la validità della licenza, nonché come rinnovarla.
Licenza dell’applicazione TrilioVault
- Per impostazione predefinita, durante l’installazione di TVK tramite Helm, non viene installata automaticamente alcuna licenza di prova gratuita. Puoi sempre andare sul sito web di Trilio e generare una nuova licenza per il tuo cluster che si adatti alle tue esigenze (ad esempio, puoi scegliere il tipo di licenza di base che ti consente di eseguire TrilioVault a tempo indeterminato se la capacità del tuo cluster non supera i 10 nodi). Una licenza di prova gratuita ti consente di eseguire TVK per un mese su nodi di cluster illimitati.
- TrilioVault è gratuito per i cluster Kubernetes con un massimo di 100000 nodi per gli utenti di DigitalOcean. Possono seguire i seguenti passaggi per creare una licenza speciale disponibile solo per i clienti di DO.
Gli esempi del kit di avvio si basano su un tipo di licenza Cluster per funzionare correttamente.
Creazione e verifica della licenza dell’applicazione TVK
Esegui il seguente comando per creare una nuova licenza per il tuo cluster (è gestito tramite il CRD della licenza):
Il comando sopra creerà un job job.batch/tvk-license-digitalocean che eseguirà un pod tvk-license-digitalocean-828rx per estrarre la licenza dal server delle licenze di Trilio e installarla sul cluster DOKS. Dopo che il job è completato, verrà eliminato in 60 secondi.
Se stai scaricando una licenza gratuita dal sito web di Trilio, applicala utilizzando questo comando:
Si prega di eseguire il seguente comando per verificare se la licenza è installata e nello stato Attivo sul tuo cluster.
NAME STATUS MESSAGE CURRENT NODE COUNT GRACE PERIOD END TIME EDITION CAPACITY EXPIRATION TIME MAX NODES
test-license-1 Active Cluster License Activated successfully. 1 FreeTrial 100000 2023-02-25T00:00:00Z 1
L’output è simile al seguente. Nota lo STATUS che dovrebbe essere Attivo, così come il tipo di licenza nella colonna EDITION e il TEMPO DI SCADENZA.
La licenza è gestita tramite un CRD speciale chiamato oggetto License. Puoi ispezionarlo eseguendo il seguente comando:
L’output è simile al seguente. Nota i campi Messaggio e Capacità, così come l’Edizione.
L’output sopra ti indicherà anche quando la licenza sta per scadere nel campo Timestamp di Scadenza e lo Scope (in questo caso Cluster). Puoi optare per un tipo di licenza a livello di cluster o basato su namespace.
Rinnovo della Licenza dell’Applicazione TVK
Per rinnovare la licenza, dovrai richiederne una nuova dal sito web di Trilio navigando alla pagina delle licenze per sostituire quella vecchia. Dopo aver completato il modulo, dovresti ricevere il manifesto YAML della Licenza, che può essere applicato al tuo cluster utilizzando kubectl. I seguenti comandi presuppongono che TVK sia installato nello namespace predefinito tvk (sostituisci i segnaposto <> dove necessario):
# Ottenere informazioni su una licenza specifica dal namespace `tvk`
Nel prossimo passaggio, imparerai come definire il backend di archiviazione per TrilioVault per archiviare i backup chiamato un target.
Passaggio 2 – Creazione di un Target TrilioVault per Conservare i Backup
A typical Target definition looks like:
TrilioVault ha bisogno di sapere prima dove conservare i tuoi backup. TrilioVault si riferisce al backend di archiviazione utilizzando il termine target, ed è gestito tramite un CRD speciale chiamato Target. I seguenti tipi di target sono supportati: S3 e NFS. Per DigitalOcean e per lo scopo del Starter Kit, ha senso fare affidamento sul tipo di archiviazione S3 perché è economico e scalabile. Per beneficiare di un livello avanzato di protezione, è possibile creare più tipi di target (sia per S3 che per NFS), in modo che i tuoi dati siano conservati in luoghi multipli, ottenendo così la ridondanza dei backup.
- In questa configurazione,
spec.type: Tipo di target per l’archiviazione dei backup (S3 è un archivio di oggetti).spec.vendor: Fornitore di archiviazione di terze parti che ospita il target (per DigitalOcean Spaces è necessario utilizzareOtherinvece diAWS).spec.enableBrowsing: Abilita la navigazione per il target.spec.objectStoreCredentials: Definisce le credenziali richieste (tramitecredentialSecret) per accedere all’archiviazioneS3, oltre ad altri parametri come la regione e il nome del bucket.
spec.thresholdCapacity: Capacità massima di soglia per archiviare i dati di backup.
# il valore deve essere codificato in base64
Si noti che il nome del segreto è trilio-s3-target ed è referenziato dal campo spec.objectStoreCredentials.credentialSecret del CRD Target spiegato in precedenza. Il segreto può essere nello stesso namespace dove è stato installato TrilioVault (impostato per impostazione predefinita su tvk), o in un altro namespace a tua scelta. Assicurati solo di fare riferimento al namespace correttamente. D’altra parte, assicurati di proteggere il namespace in cui archivi i segreti TrilioVault tramite RBAC per motivi di sicurezza.
Passaggi per creare una Destinazione per TrilioVault:
Innanzitutto, cambia la directory in cui è stato clonato il repository Git del Starter Kit sulla tua macchina locale:
Successivamente, crea il segreto Kubernetes contenente le credenziali del tuo bucket S3 di destinazione (sostituisci i segnaposto <> di conseguenza):
–from-literal=accessKey=“<IL_TUO_ACCESSO_CHIAVE_DO_SPACES_QUI>” \
–from-literal=secretKey=“<LA_TUA_CHIAVE_SEGRETA_DO_SPACES_QUI>”
Quindi, apri e ispeziona il file manifest del target fornito nel repository del kit di avvio utilizzando un editor a tua scelta (preferibilmente con supporto YAML lint).
Ora, sostituisci i segnaposto <> di conseguenza per il tuo bucket DO Spaces Trilio, come nomeBucket, regione, url e segretoCredenziali.
Infine, salva il file manifest e crea l’oggetto Target utilizzando kubectl:
NAME TYPE THRESHOLD CAPACITY VENDOR STATUS BROWSING ENABLED
trilio-s3-target ObjectStore 10Gi Other Available
Successivamente, TrilioVault genererà un lavoro worker chiamato trilio-s3-target-validator responsabile della validazione del tuo bucket S3 (come disponibilità, autorizzazioni, ecc.). Se il lavoro si conclude con successo, il bucket è considerato sano o disponibile e la risorsa lavoro trilio-s3-target-validator viene eliminata in seguito. Se accade qualcosa di negativo, il lavoro di validazione del target S3 rimane attivo così che tu possa ispezionare i log e trovare il possibile problema.
Ora, procedi e verifica se la risorsa Target creata in precedenza è sana:
# L’output assomiglia a:
...
INFO:root:2021-11-24 09:06:50.595166: waiting for mount operation to complete.
INFO:root:2021-11-24 09:06:52.595772: waiting for mount operation to complete.
ERROR:root:2021-11-24 09:06:54.598541: timeout exceeded, not able to mount within time.
ERROR:root:/triliodata is not a mountpoint. We can't proceed further.
Traceback (most recent call last):
File "/opt/tvk/datastore-attacher/mount_utility/mount_by_target_crd/mount_datastores.py", line 56, in main
utilities.mount_datastore(metadata, datastore.get(constants.DATASTORE_TYPE), base_path)
File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 377, in mount_datastore
mount_s3_datastore(metadata_list, base_path)
File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 306, in mount_s3_datastore
wait_until_mount(base_path)
File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 328, in wait_until_mount
base_path))
Exception: /triliodata is not a mountpoint. We can't proceed further.
...
#trilio-s3-target-validator-tio99a-6lz4q 1/1 In esecuzione 0 104s
# Ora, recuperare i dati dei log
L’output sarà questa eccezione:
Successivamente, scoprirai la console web TVK che è un’utile aggiunta per aiutarti a gestire facilmente le operazioni di backup e ripristino, tra molte altre.
Passaggio 3 – Conoscere la Console di Gestione Web di TVK
Sebbene tu possa gestire le operazioni di backup e ripristino completamente dalla CLI tramite kubectl e CRD, TVK fornisce una Console di Gestione Web per eseguire le stesse operazioni tramite l’interfaccia grafica. La console di gestione semplifica le attività comuni tramite operazioni point-and-click, fornisce una migliore visualizzazione e ispezione degli oggetti del cluster TVK, così come per creare piani di ripristino di emergenza (o DRP).
L’installazione basata su Helm trattata in Passaggio 1 – Installazione di TrilioVault per Kubernetes ha già provveduto all’installazione dei componenti necessari per la console di gestione web.
Ottenere l’accesso alla Console di Gestione Web TVK
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
k8s-triliovault-admission-webhook ClusterIP 10.245.202.17 <none> 443/TCP 13m
k8s-triliovault-ingress-nginx-controller NodePort 10.245.192.140 <none> 80:32448/TCP,443:32588/TCP 13m
k8s-triliovault-ingress-nginx-controller-admission ClusterIP 10.3.20.89 <none> 443/TCP 13m
k8s-triliovault-web ClusterIP 10.245.214.13 <none> 80/TCP 13m
k8s-triliovault-web-backend ClusterIP 10.245.10.221 <none> 80/TCP 13m
triliovault-operator-k8s-triliovault-operator-webhook-service ClusterIP 10.245.186.59 <none> 443/TCP 16m
Per poter accedere alla console e esplorare le funzionalità che offre, è necessario inoltrare la porta del servizio del controller di ingresso per TVK.
L’output è simile al seguente. Cerca la riga k8s-triliovault-ingress-nginx-controller e nota che ascolta sulla porta 80 nella colonna PORT(S).
127.0.0.1 tvk-doks.com
TVK sta utilizzando un Controller di Ingress Nginx per instradare il traffico ai servizi della console di gestione web. L’instradamento è basato sull’host e il nome dell’host è tvk-doks.com come definito nel file dei valori di Helm del Kit di Avvio:
# Il nome host da utilizzare quando si accede alla console web tramite il controller di ingresso TVK nginx
Infine, esporta il file kubeconfig per il tuo cluster DOKS. Questo passaggio è necessario affinché la console web possa autenticarti.
# Elenco dei cluster disponibili
# Salva la configurazione del cluster in formato YAML
Se hai solo un cluster, esegui il seguente comando:
Dopo aver seguito questi passaggi, puoi accedere alla console nel tuo browser web navigando su: http://tvk-doks.com:8080. Quando ti viene richiesto il file kubeconfig, seleziona quello che hai creato nell’ultimo comando di cui sopra.
Per favore, conserva il file kubeconfig generato in un luogo sicuro perché contiene dati sensibili.
- Esplorazione dell’interfaccia utente della console web TVK
- Esplora ogni sezione sulla sinistra, come:
- Gestione del cluster: Questo mostra l’elenco dei cluster primari e degli altri cluster che hanno istanze TVK, aggiunte al cluster primario OVH utilizzando la funzionalità di Gestione Multi-Cluster.
- Backup & Ripristino: Questo è il cruscotto principale che ti fornisce una panoramica generale dell’intero cluster, come Namespace scoperti, Applicazioni, Elenco dei piani di backup, Destinazioni, Hooks, Policy, ecc.
Monitoraggio: Questo ha due opzioni- Monitoraggio TrilioVault e Monitoraggio Velero se l’utente ha configurato Velero sul loro cluster OVH.
Ripristino di Emergenza: Ti consente di gestire e eseguire operazioni di ripristino di emergenza.
Ripristino di Emergenza: Ti consente di gestire e eseguire operazioni di ripristino di emergenza.
Puoi anche vedere la Destinazione S3 creata in precedenza, navigando su Backup & Ripristino -> Destinazioni -> <Namespace> tvk dal menu a discesa in alto.
Proseguendo, puoi esaminare la destinazione ed elencare i backup disponibili cliccando sul pulsante Azioni sulla destra, e quindi selezionando l’opzione Avvia Browser dal menu a comparsa. Perché ciò funzioni, la destinazione deve avere il flag enableBrowsing impostato su true.
Per ulteriori informazioni e funzionalità disponibili, consulta la documentazione ufficiale dell’Interfaccia Utente del Console di Gestione Web di TVK.
Successivamente, imparerai come eseguire operazioni di backup e ripristino per casi d’uso specifici.
Passaggio 4 – Esempio di Backup e Ripristino di Namespace
In questo passaggio, imparerai come creare un backup una tantum per un intero namespace (ambassador in questo caso) dal tuo cluster DOKS e successivamente ripristinarlo, assicurandoti che tutte le risorse vengano ricreate. TVK ha una funzionalità che ti consente di eseguire backup a un livello superiore rispetto ai soli namespace.
- Creazione del Backup del Rilascio di Helm di Ambassador
- Per eseguire backup per un’applicazione singola a livello di namespace (o rilascio di Helm), è necessario un BackupPlan seguito da un Backup CRD. BackupPlan è una definizione di ‘cosa’, ‘dove’, ‘a’, e ‘come’ del processo di backup, ma non esegue effettivamente il backup. Il CRD di Backup è responsabile di avviare effettivamente il processo di backup, come dettato dalle specifiche del BackupPlan.
- In questa configurazione,
A typical Backup CRD looks like below:
spec.backupConfig.target.name: Indica a TVK quale nome target utilizzare per memorizzare i backup.
spec.backupConfig.target.namespace: Indica a TVK in quale namespace è stato creato il target.spec.backupComponents: Definisce un elenco di risorse da eseguire il backup.
In questa configurazione,
spec.type: Specifica il tipo di backup.
spec.backupPlan: Specifica il BackupPlan che questo Backup dovrebbe utilizzare.
Passaggi per avviare il backup di una sola volta del rilascio Ambassador Helm:
Prima di tutto, assicurati che Ambassador Edge Stack sia distribuito nel tuo cluster seguendo i passaggi del tutorial Ambassador Ingress.
Successivamente, cambia la directory in quella in cui è stato clonato il repository Git del kit di avvio sulla tua macchina locale:
Quindi, apri e ispeziona i file di manifesto Ambassador BackupPlan e Backup forniti nel repository del kit di avvio utilizzando un editor a tua scelta (preferibilmente con supporto YAML lint).
NAME TARGET ... STATUS
ambassador-helm-release-backup-plan trilio-s3-target ... Available
Infine, crea le risorse BackupPlan e Backup utilizzando kubectl.
Ora, ispeziona lo stato di BackupPlan (mirando al rilascio Helm ambassador) utilizzando kubectl:
NAME BACKUPPLAN BACKUP TYPE STATUS ...
ambassador-helm-release-full-backup ambassador-helm-release-backup-plan Full InProgress ...
L’output assomiglia a quanto segue. Nota il valore della colonna STATUS che dovrebbe essere impostato su Disponibile.
Successivamente, controlla lo stato dell'oggetto Backup utilizzando kubectl:
NAME BACKUPPLAN BACKUP TYPE STATUS ... PERCENTAGE
ambassador-helm-release-full-backup ambassador-helm-release-backup-plan Full Available ... 100
L’output assomiglia a quanto segue. Nota il valore della colonna STATUS che dovrebbe essere impostato su In corso, così come il BACKUP TYPE impostato su Completo.
Dopo che tutti i componenti del rilascio di Ambassador Helm sono stati caricati con successo nel target S3, dovresti ottenere questi risultati:
2021-11-25 07:04 28 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/
2021-11-25 07:04 28 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/
2021-11-25 07:04 311 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backup-namespace.json.manifest.00000004
2021-11-25 07:04 302 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backup.json.manifest.00000004
2021-11-25 07:04 305 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backupplan.json.manifest.00000004
2021-11-25 07:04 28 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/
2021-11-25 07:04 28 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/metadata-snapshot/
2021-11-25 07:04 330 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/metadata-snapshot/metadata.json.manifest.00000002
...
# L’output assomiglia a quanto segue (nota che lo `STATUS` è cambiato in `Disponibile`, e `PERCENTUALE` è `100`)
Se l’output assomiglia a questo, hai eseguito il backup del rilascio di ambassador Helm con successo. Puoi procedere e vedere come TrilioVault memorizza i metadati di Kubernetes elencando i contenuti del Bucket S3 di TrilioVault. Ad esempio, puoi utilizzare s3cmd:
ambassador-helm-release-full-backup-metamover-mg9gl0--1-2d6wx 1/1 Running 0 4m32s
L’output assomiglia a quanto segue. Nota che l’elenco contiene i manifesti JSON e gli UID, che rappresentano gli oggetti Kubernetes.
Nel caso in cui il backup non diventi disponibile, puoi ispezionare i log del Pod metamover per individuare il problema:
...
{"component":"meta-mover","file":"pkg/metamover/snapshot/parser/commons.go:1366","func":"github.com/trilioData/k8s-triliovault/pkg/metamover/snapshot/parser.(*Component).ParseForDataComponents","level":"info","msg":"Parsing data components of resource rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding: [edge-stack]","time":"2022-06-14T06:20:56Z"}
{"component":"meta-mover","file":"pkg/metamover/snapshot/parser/commons.go:1366","func":"github.com/trilioData/k8s-triliovault/pkg/metamover/snapshot/parser.(*Component).ParseForDataComponents","level":"info","msg":"Parsing data components of resource rbac.authorization.k8s.io/v1, Kind=RoleBinding: [edge-stack-agent-config]","time":"2022-06-14T06:20:56Z"}
...
L’output assomiglia a:
Ora, recupera i dati dei log:
L’output assomiglia a quanto segue.
Infine, puoi verificare che il backup sia disponibile anche nella console web navigando su Gestione Risorse -> Ambassador -> Piani di Backup. Nota che è nello stato Disponibile e che il rilascio di Ambassador Helm è stato eseguito il backup nella sottovista Dettagli Componente.
Eliminazione del Rilascio di Ambassador Helm e delle Risorse
Ora, procedi e simula un disastro eliminando intenzionalmente il rilascio ambassador di Helm:
Successivamente, verifica che le risorse dello spazio dei nomi siano state eliminate (l’elenco dovrebbe essere vuoto):
- Infine, verifica che l’endpoint dei servizi di backend
echoequotesiaDOWN. Si prega di fare riferimento a Creazione dei servizi di backend dello stack di bordo dell’ambasciatore riguardo alle applicazioni di backend utilizzate nel tutorial Starter Kit. Puoi utilizzarecurlper testare (o puoi utilizzare il tuo browser web): - Ripristino del backup del rilascio di Helm di Ambassador
- Importante
Se si sta ripristinando lo stesso spazio dei nomi, assicurarsi che i componenti dell’applicazione originale siano stati rimossi. Soprattutto il PVC dell’applicazione deve essere eliminato.
Se si ripristina su un altro cluster (scenario di migrazione), assicurarsi che TrilioVault for Kubernetes sia in esecuzione anche nel namespace/cluster remoto. Per ripristinare su un nuovo cluster (dove il CR di backup non esiste), source.type deve essere impostato su location. Fare riferimento alla Sezione di ripristino della definizione di risorsa personalizzata per visualizzare un esempio di ripristino per posizione.
- Quando si elimina il namespace
ambassador, la risorsa del bilanciamento del carico associata al servizio di ambassador verrà eliminata anche. Quindi, quando si ripristina il servizioambassador, il bilanciamento del carico verrà ricreato da DigitalOcean. Il problema è che si otterrà un NUOVO INDIRIZZO IP per il tuo bilanciamento del carico, quindi sarà necessario regolare irecord Aper indirizzare il traffico nei domini ospitati sul cluster. - Per ripristinare un backup specifico, è necessario creare un
RestoreCRD. Un tipico CRD di ripristino appare come segue: - In questa configurazione,
spec.source.type: Specifica quale tipo di backup ripristinare.
spec.source.backup: Contiene un riferimento all’oggetto di backup da cui eseguire il ripristino.
spec.skipIfAlreadyExists: Specifica se saltare il ripristino di una risorsa se essa esiste già nel namespace ripristinato.
Restore consente di ripristinare l’ultimo Backup riuscito per un’applicazione. Viene utilizzato per ripristinare un singolo namespace o un rilascio Helm, protetto dal Backup CRD. Il Backup CRD è identificato dal suo nome ambassador-helm-release-full-backup.
Innanzitutto, ispeziona l’esempio di Restore CRD dal repository Git Starter Kit:
NAME STATUS DATA SIZE START TIME END TIME PERCENTAGE COMPLETED DURATION
ambassador-helm-release-restore Completed 0 2021-11-25T15:06:52Z 2021-11-25T15:07:35Z 100 43.524191306s
Successivamente, crea la risorsa Restore utilizzando kubectl:
Infine, ispeziona lo stato dell’oggetto Restore:
L’output appare simile al seguente. Notare la colonna STATUS impostata su Completed, così come il PERCENTAGE COMPLETED impostato su 100.
Se l’output appare in questo modo, allora il processo di ripristino del rilascio Helm ambassador è completato con successo.
NAME READY STATUS RESTARTS AGE
pod/ambassador-5bdc64f9f6-42wzr 1/1 Running 0 9m58s
pod/ambassador-5bdc64f9f6-nrkzd 1/1 Running 0 9m58s
pod/ambassador-agent-bcdd8ccc8-ktmcv 1/1 Running 0 9m58s
pod/ambassador-redis-64b7c668b9-69drs 1/1 Running 0 9m58s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ambassador LoadBalancer 10.245.173.90 157.245.23.93 80:30304/TCP,443:30577/TCP 9m59s
service/ambassador-admin ClusterIP 10.245.217.211 <none> 8877/TCP,8005/TCP 9m59s
service/ambassador-redis ClusterIP 10.245.77.142 <none> 6379/TCP 9m59s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ambassador 2/2 2 2 9m59s
deployment.apps/ambassador-agent 1/1 1 1 9m59s
deployment.apps/ambassador-redis 1/1 1 1 9m59s
NAME DESIRED CURRENT READY AGE
replicaset.apps/ambassador-5bdc64f9f6 2 2 2 9m59s
replicaset.apps/ambassador-agent-bcdd8ccc8 1 1 1 9m59s
replicaset.apps/ambassador-redis-64b7c668b9 1 1 1 9m59s
Verifica dell’integrità delle applicazioni dopo il ripristino
Verifica che tutte le risorse del namespace ambassador siano presenti ed in esecuzione:
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:
Ottenere gli host 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 appare simile al seguente. Lo STATE dovrebbe essere Ready, così come la colonna HOSTNAME che punta al nome host completo.
Ottenere i mapping dell’ambassador:
L’output assomiglia a quanto segue. Notare il echo-backend che è mappato sull’host echo.starter-kit.online e il prefisso di origine /echo/, lo stesso vale per quote-backend.
Ora è necessario aggiornare i tuoi record DNS A, poiché la risorsa del bilanciamento del carico di DigitalOcean è stata ricreata e ha un nuovo IP esterno assegnato.
Infine, verifica se le applicazioni backend rispondono anche alle richieste HTTP. Si prega di fare riferimento a Creazione dei Servizi di Backend Ambassador Edge Stack riguardo alle applicazioni backend utilizzate nel tutorial Starter Kit.
Il prossimo passo riguarda il backup e il ripristino dell’intero cluster.
Passaggio 5 – Esempio di Backup e Ripristino dell’Intero Cluster
A typical ClusterBackupPlan manifest targeting multiple namespaces looks like this:
In questo passaggio, simulerai uno scenario di ripristino da disastro. L’intero cluster DOKS verrà eliminato e poi le applicazioni importanti ripristinate da un backup precedente.
Creazione del Backup del Cluster DOKS
L’idea principale qui è eseguire un backup del cluster DOKS includendo tutti i namespace importanti che contengono le tue applicazioni e configurazioni essenziali.
Nota che il namespace kube-system (o altri namespace correlati al cluster DOKS) non è incluso nell’elenco. Di solito, quelli non sono necessari, a meno che non ci sia un caso speciale che richieda che alcune impostazioni siano conservate a quel livello.
Prima, cambia la directory in cui è stato clonato il repository Git del Starter Kit sul tuo computer locale:
Quindi, apri e ispeziona i file di manifesto ClusterBackupPlan e ClusterBackup forniti nel repository Starter Kit utilizzando un editor a tua scelta (preferibilmente con supporto per lint YAML).
NAME TARGET ... STATUS
starter-kit-cluster-backup-plan trilio-s3-target ... Available
Infine, crea le risorse ClusterBackupPlan e ClusterBackup utilizzando kubectl:
Ora, ispeziona lo stato di ClusterBackupPlan utilizzando kubectl:
NAME BACKUPPLAN BACKUP TYPE STATUS ... PERCENTAGE COMPLETE
starter-kit-cluster-backup starter-kit-cluster-backup-plan Full Available ... 100
La produzione è simile a quanto segue. Nota il valore della colonna STATUS che dovrebbe essere impostato su Available.
Successivamente, controlla lo stato di ClusterBackup utilizzando kubectl:
La produzione è simile a quanto segue. Nota il valore della colonna STATUS che dovrebbe essere impostato su Available, così come il PERCENTAGE COMPLETE impostato su 100.
Se l’output è simile a quanto sopra, allora tutti i tuoi namespace delle applicazioni importanti sono stati salvati correttamente.
Potrebbe richiedere un po’ di tempo per completare il backup completo del cluster, a seconda di quanti namespace e risorse associate sono coinvolte nel processo.
È possibile aprire anche il cruscotto principale della console web e ispezionare il backup multi-namespace (notare come tutti i namespace importanti che sono stati eseguiti il backup siano evidenziati in verde, in una struttura a nido d’ape):
Ricreare il cluster DOKS e ripristinare le applicazioni
Un aspetto importante da tenere presente è che ogni volta che si distrugge un cluster DOKS e poi lo si ripristina, viene creato anche un nuovo bilanciamento del carico con un nuovo IP esterno quando TVK ripristina il controller degli ingressi. Quindi, assicurati di aggiornare i tuoi record DNS di DigitalOcean A di conseguenza.
Ora, elimina l’intero cluster DOKS (assicurati di sostituire i segnaposto <> di conseguenza):
Successivamente, ricrea il cluster come descritto in Impostare Kubernetes di DigitalOcean.
Per eseguire l’operazione di ripristino, è necessario installare l’applicazione TVK come descritto in Passaggio 1 – Installazione di TrilioVault per Kubernetes. È importante utilizzare la stessa versione della Helm Chart.
Dopo che l’installazione è stata completata con successo, configura il target TVK come descritto nel Passaggio 2 – Creazione di un Target TrilioVault per Archiviare i Backup, e puntalo allo stesso bucket S3 dove sono situati i tuoi dati di backup. Inoltre, assicurati che la navigazione del target sia abilitata.
Successivamente, verifica e attiva una nuova licenza come descritto nella sezione Licenza dell’Applicazione TrilioVault.
Per accedere all’interfaccia utente della console web, consulta la sezione Ottenere l’Accesso alla Console di Gestione Web TVK.
Quindi, naviga su Gestione Risorse -> Spazio dei Nomi TVK -> Target (nel caso del Kit di Avvio il Nome dello Spazio dei Nomi TVK è tvk):
Procedi, sfoglia il target e elenca i backup disponibili cliccando sul pulsante Azioni. Quindi, seleziona l’opzione Avvia Browser dal menu a comparsa. Perché ciò funzioni, il target deve avere il flag enableBrowsing impostato su true.
Ora, clicca sull’elemento starter-kit-cluster-backup-plan dalla lista, e poi clicca ed espandi l’elemento starter-kit-cluster-backup dalla sotto-finestra destra:
Per avviare il processo di ripristino, clicca sul pulsante Ripristina.
Verifica dello stato delle applicazioni del cluster DOKS
Prima, verifica tutte le risorse del cluster Kubernetes.
In seguito, assicurati che i record A del DNS siano aggiornati per puntare all’IP esterno del tuo nuovo bilanciamento del carico.
Infine, le applicazioni backend dovrebbero rispondere anche alle richieste HTTP. Si prega di fare riferimento a Creazione dei servizi backend di Ambassador Edge Stack riguardo alle applicazioni backend utilizzate nel tutorial del Kit di Avvio.
Nel prossimo passaggio, imparerai come eseguire backup programmati (o automatici) per le applicazioni del cluster DOKS.
Effettuare 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. Questa sezione fornisce un esempio di un backup automatico su un programma di 5 minuti (il namespace kube-system è stato scelto).
Prima di tutto, è necessario creare un CRD Policy di tipo Schedule che definisca il programma di backup nel formato cron (stesso formato di Linux cron). Le policy di programmazione possono essere utilizzate per i CRD BackupPlan o ClusterBackupPlan. Una tipica policy di programmazione CRD appare come segue (definisce un programma di 5 minuti):
# attiva ogni 5 minuti
Successivamente, è possibile applicare la policy di programmazione a un CRD ClusterBackupPlan ad esempio, come mostrato di seguito:
Puoi notare che si tratta di un CRD ClusterBackupPlan di base, che fa riferimento al CRD Policy definito in precedenza attraverso il campo spec.backupConfig.schedulePolicy. È possibile creare policy separate per backup completi o incrementali, pertanto possono essere specificate le fullBackupPolicy o incrementalBackupPolicy nello spec.
Ora, per favore crea la policy di programmazione utilizzando il manifesto di esempio fornito dal tutorial Starter Kit.
NAME POLICY DEFAULT
scheduled-backup-every-5min Schedule false
Cambia la directory in cui è stato clonato il repository Git di Starter Kit sul tuo computer locale.
Infine, crea le risorse per i backup pianificati nel namespace kube-system:
# Crea prima il piano di backup per il namespace kube-system
NAME TARGET ... FULL BACKUP POLICY STATUS
kube-system-ns-backup-plan-5min-schedule trilio-s3-target ... scheduled-backup-every-5min Available
# Crea e attiva il backup pianificato per il namespace kube-system
Controlla lo stato del piano di backup pianificato per kube-system:
NAME BACKUPPLAN BACKUP TYPE STATUS ...
kube-system-ns-full-backup-scheduled kube-system-ns-backup-plan-5min-schedule Full Available ...
L’output è simile al seguente. Nota il valore FULL BACKUP POLICY impostato sulla risorsa del piano precedentemente creato scheduled-backup-every-5min, così come lo STATUS che dovrebbe essere Available.
Controlla lo stato del backup pianificato per kube-system:
L’output è simile al seguente. Nota il valore BACKUPPLAN impostato sulla risorsa del piano di backup precedentemente creato, così come lo STATUS che dovrebbe essere Available.
Ora puoi verificare che i backup vengano eseguiti con un intervallo regolare (5 minuti), interrogando la risorsa di backup del cluster e ispezionando la colonna START TIME (kubectl get clusterbackup -n tvk). Dovrebbe riflettere il delta di 5 minuti, come evidenziato nell’immagine qui sotto:
Nel prossimo passaggio, imparerai come impostare una policy di conservazione dei backup.
Passaggio 7 – Politica di conservazione dei backup
La policy di conservazione consente di definire il numero di backup da conservare e la cadenza per eliminare i backup secondo i requisiti di conformità. Il CRD della policy di conservazione fornisce una specifica YAML semplice per definire il numero di backup da conservare in termini di giorni, settimane, mesi, anni, l’ultimo, ecc.
- Utilizzo delle Politiche di Conservazione
- Le politiche di conservazione possono essere utilizzate per i CRD (
Custom Resource Definition)BackupPlanoClusterBackupPlan. Un tipico manifesto diPolicyper il tipo diRetentionappare come segue: - La politica di conservazione sopra indicata si traduce in:
- Ogni settimana, conserva un backup per ogni mercoledì.
Ogni mese, conserva un backup il giorno 15.
A typical ClusterBackupPlan example configuration that has a retention set looks like:
Ogni anno, conserva un backup ogni marzo.
In generale, dovrebbero essere disponibili 2 backup più recenti.
Il flusso di base per la creazione di una risorsa di politica di conservazione segue lo stesso procedimento dei backup pianificati. È necessario definire un CRD BackupPlan o ClusterBackupPlan per fare riferimento alla politica di conservazione, e quindi avere un oggetto Backup o ClusterBackup per avviare il processo.
Si noti che utilizza un campo retentionPolicy per fare riferimento alla politica in questione. Naturalmente, è possibile avere un piano di backup che abbia impostato entrambi i tipi di politiche, in modo da poter eseguire backup pianificati e gestire strategie di conservazione.
Utilizzo delle Politiche di Pulizia
È necessario un modo per eliminare tutti quegli oggetti che non sono più in uso. Per questo, è necessario introdurre il CRD Cleanup Policy:
La politica di pulizia sopra indicata deve essere definita nel namespace di installazione di TVK. Successivamente, viene creato automaticamente un lavoro cron che si esegue ogni 30 minuti e elimina i backup falliti in base al valore specificato per backupdays all’interno del campo spec.
Conclusione
- In questo tutorial, hai imparato come eseguire backup una tantum e pianificati e come ripristinare tutto.
- Tutte le operazioni e le attività di base spiegate in questo tutorial sono pensate per darti un’introduzione di base e una comprensione di ciò di cui è capace TrilioVault per Kubernetes.
- Per saperne di più