Come mantenere la calma quando il tuo cluster Kubernetes va in crash, o perché hai bisogno di Velero

Immagina questo: è venerdì sera, stai pianificando di rilassarti, quando improvvisamente appare una notifica Slack — uno dei tuoi cluster Kubernetes di produzione è andato in crash. Una misconfigurazione, un'interruzione del provider cloud, o semplice errore umano — la causa non ha più importanza. Ciò che conta è quanto velocemente puoi riportare tutto in funzione. Se hai solo file YAML in Git, in bocca al lupo per recuperare le applicazioni stateful e i loro dati.

È qui che entra in gioco Velero. È un progetto di VMware (originariamente creato da Heptio) che è diventato lo standard de facto per il backup nel mondo K8s.

Cos'è e perché GitOps da solo non basta

Molti sviluppatori credono che se la loro intera infrastruttura è definita nel codice (IaC) e distribuita tramite ArgoCD o Flux, i backup non sono necessari. Questa è una misconception pericolosa. Git memorizza i manifest, ma non sa nulla dello stato dei tuoi Persistent Volumes (PV), dei certificati emessi dinamicamente o dei secret che non sono mai entrati nel repository.

Velero fa due cose: salva gli oggetti dell'API Kubernetes (deployments, configmaps, secrets) e crea snapshot del disco con i dati. Funziona nei cloud pubblici (AWS, GCP, Azure) così come nei data center on-premises su bare metal.

Tre scenari in cui Velero salva la situazione

Vedo spesso Velero utilizzato non solo per la protezione dai disastri. Ecco i casi d'uso principali:

1. Disaster Recovery classico. Questo è semplice: il cluster è andato, fai partire un nuovo cluster e ripristini tutto dallo storage S3 con un singolo comando.
2. Migrazione cross-cloud. Passare da AWS a Google Cloud o da una regione all'altra diventa un'operazione banale. Velero raggruppa le risorse e le distribuisce nella nuova posizione.
3. Clonazione dell'ambiente. Hai bisogno di creare rapidamente una copia esatta della produzione per i test? Fai un backup di produzione, ripristinalo nel namespace staging. I dati del database saranno attuali, non di un dump vecchio di un mese.

Come funziona internamente

L'architettura del progetto è abbastanza trasparente. C'è un componente server che gira all'interno del cluster come operatore e un client CLI per gestire il processo.

Quando attivi un backup, ecco cosa succede:

1. Il client invia una richiesta all'API di Velero.
2. Il controller di Backup trova tutti gli oggetti specificati (puoi filtrare per label o namespace).
3. Velero effettua richieste all'API di Kubernetes per raccogliere le descrizioni JSON delle risorse.
4. In parallelo, vengono invocati i plugin per la gestione dei dischi (es. EBS in AWS o driver CSI) per creare snapshot dei dati.
5. Tutto questo viene archiviato e inviato allo storage oggetti (compatibile con S3).

A proposito, Velero supporta Restic e Kopia. Questo significa che puoi fare backup incrementali del filesystem anche dove gli snapshot cloud non sono disponibili.

Esempio pratico

Diciamo che dobbiamo fare il backup di un'intera applicazione nel namespace app-production. Il comando da terminale sarebbe qualcosa del tipo:

velero backup create production-backup --include-namespaces app-production

E se qualcuno elimina accidentalmente quel namespace una settimana dopo, il ripristino richiede solo pochi minuti:

velero restore create --from-backup production-backup

Interessante, Velero può modificare i parametri delle risorse al volo durante il ripristino. Per esempio, puoi cambiare la StorageClass dei dischi se la vecchia classe non è disponibile nel nuovo cluster.

Sfumature di compatibilità

Gli sviluppatori di Velero mantengono una matrice di compatibilità abbastanza rigorosa. Attualmente, la versione 1.18 è testata contro le ultime release di Kubernetes (fino alla 1.35). Questo è importante perché l'API di Kubernetes cambia rapidamente e gli strumenti più vecchi spesso si rompono quando il cluster viene aggiornato.

Il progetto è sotto l'egida della Cloud Native Computing Foundation (CNCF), che fornisce alcune garanzie: non scomparirà domani e la sua sicurezza viene monitorata.

Vale la pena implementarlo

Se stai eseguendo Kubernetes in produzione e hai dati sui dischi (database, code, config store), Velero è un must-have.

Chi ne trarrà sicuramente beneficio:

• Ingegneri SRE che hanno bisogno di dormire sonni tranquilli di notte.
• Team che migrano frequentemente tra cluster.
• Sviluppatori che hanno bisogno di dati di produzione freschi per il debug di bug complessi.

Inizia con la documentazione ufficiale su velero.io. È abbastanza dettagliata, anche se a volte può sembrare opprimente. La cosa principale da ricordare è che un backup esiste solo quando l'hai ripristinato con successo almeno una volta. Prova a farlo in un cluster di test prima di fidarti dello strumento con dati reali.