Il Restore su cluster Kubernetes non funziona? Il motivo è uno.

Se lanciate un Restore in Kubernetes che non funziona a dovere, la domanda che dovete porvi è una sola: state usando un tool Kubernetes-Native?

Se lanciate un Restore in Kubernetes che non funziona a dovere, la domanda che dovete porvi è una sola: state usando un tool Kubernetes-Native?

La maggior parte delle volte la risposta è che sono usati strumenti standard di backup delle VM e, a quel punto, chiedo sempre se sia mai stata fatta una prova di Restore totale o parziale. E qui di solito avviene l’illuminazione sulla strada di Damasco.  

Il dilemma sul funzionamento o meno del Restore K8s (Kubernetes) sorge perché si tratta di un sistema autoconsistente con un approccio olistico, in grado di gestire internamente tutti gli stack che costituiscono un Datacenter fisico.

Per questo Kubernetes non può funzionare con strumenti standard, come Secret, ConfigMap, StatefulSet, PVC e altro; questi infatti devono essere preservati nelle proprietà per garantire la consistenza di ciò che viene “restorato”. Ricordiamo poi che quello delle applicazioni stateless è un mito! Esistono Technical Strategist che vedono le applicazioni su Kubernetes come delle specie di “Dory alla ricerca di Nemo”, oggetti che ad ogni evento ricominciano da zero nella costruzione dell’output, dimenticandosi tutto ciò che era successo poco prima (e senza nemmeno il plus di conoscere il balenese).

blank

La realtà è molto diversa.

Qualche servizio o microservizio potrà essere stateless, sicuramente la maggioranza, ma un’applicazione tende ad essere stateful e, quindi, da qualche parte, sul Database o sul messaging system, per esempio, si finirà per notare l’utilizzo di un PVC (Persistent Volume Claim) che deve essere salvato e deve poter essere recuperato con dei precisi RPO ed RTO.

Ho incontrato tante aziende che hanno scelto di far affidamento sul Pipeline Manager per la gestione del ripristino delle applicazioni, limitandosi a fare una nuova promote in produzione della versione stabile.

Questo è un approccio corretto ma parziale; si deve tenere presente che funziona solo con le applicazioni stateless, che potrebbe fallire perché i certificati nel frattempo sono ruotati e che gli Ops in generale, ed i NetOps in particolare, potrebbero aver operato qualche aggiustamento alle configurazioni per adattarlo alle peculiarità dell’ambiente.

Un altro fattore da tenere in considerazione in merito al funzionamento del Restore dei dati del cluster Kubernetes è poi quello del cuore del sistema attorno a cui ruota il tutto, ovvero ETCD, il Key Value Store distribuito dove tutti gli stati degli oggetti sono memorizzati: il giudice supremo del “live or die” del sistema.

Si può dire che il 95% di ciò che è fuori ETCD sia effimero e, come tale, non meritevole di essere “backuppato” o, meglio, inconsistente se “restorato”.

Il perché di questa situazione è semplice; Kubernetes è resiliente, a volte provoca dei seri “batticuore”, ma la maggior parte delle volte si rimette in moto da solo lasciandosi alle spalle solo qualche (dolorosa) ora di disservizio.

Come professionista, mi è capitato di avere il cluster completamente fermo; la soluzione è stata spostarsi sul cluster del secondo laboratorio ed aspettare che il primo si rimettesse in moto.

Detto questo, si sa che la fortuna è cieca e che la sorella antitetica ci vede benissimo.

Si verificano errori per mano degli operatori (secondo il poll, infatti, il 37% dei problemi di DataLoss in abienti Cloud sono causati da errate operazioni da parte dei DevOps), bachi del sistema operativo e di Kubernetes stesso e, in questi casi, i servizi sono fermi e bisogna garantire che esista un punto di consistenza da cui ripartire nel più breve tempo possibile.

blank

Copyright by Kasten

E la soluzione?

Una volta che ci si è resi conto che anche il DevOps ha bisogno di un processo di backup e Restore tradizionale, il passo successivo è la definizione delle Policy con la stesura delle procedure da seguire in funzione della criticità del dato e dell’applicazione.

Anche in fase di definizione delle procedure emerge comunque la necessità di superare gli strumenti tradizionali e di adottare un tool Kubernetes-Native progettato avendo come fulcro K8s e che non venga da un porting di soluzioni pensate per un mondo di server fisici.

Possiamo poi analizzare in dettaglio le diverse casistiche di backup e Restore:

Worker: il worker è un oggetto effimero; in caso di perdita di un nodo worker la cosa migliore è cancellarlo (Kubernetes comunque cancella i worker unrensponsible dopo alcuni giorni) e crearne uno nuovo da agganciare al cluster.

Singolo Master: in caso di perdita di un singolo master il sistema non presenta disservizi dato che il quorum di etcd è preservato. Un restore non è possibile (a meno di non riuscire ad escludere etcd dal Restore stesso) ed è consigliabile cancellare ricreare il master andato perduto lasciando ad etcd il compito di allineare la nuova istanza. 

Applicazione: Il Backup ed il Restore di una applicazione può essere gestito esclusivamente adottando un tool Kubernetes-native come Kasten K10. Utilizzando Kasten K10, l’applicazione con tutti i suoi oggetti può essere sottoposta a snapshot e backup.

Se lo storage primario non è andato perduto, il Restore può essere fatto da uno qualsiasi degli snapshot consistenti, altrimenti si deve utilizzare uno dei backup che sono stati esportati su un target S3 locale o nel cloud.

Questo sarà il caso d’uso più frequente, sia per il Restore in locale che, soprattutto, per la migrazione su un altro cluster oppure nel Cloud.

Ricordiamoci poi del problema della consistenza; i tool tradizionali di Backup mettono a disposizione gli agent specifici delle applicazioni, un approccio che in un mondo fatto di container deve essere ripensato in ottica Kubernetes-Native.

Qui ci viene in aiuto un progetto della Community chiamato Kanister.

Kanister mette a disposizione una serie di Blueprint (MySQL, MongoDB, EleasticSearch) in grado di mettere in quiescenza l’applicazione prima di farne uno snapshot per avere una garanzia di totale consistenza del punto di ripristino.

Kasten è pensato per essere integrabile nativamente in una Pipeline di sviluppo; la gestione è fatta tramite le annotation di Kubernetes e quindi perfettamente controllabile dai values di un Helm, che scatena l’inserzione di un Sidecar container nel pod dell’applicazione da proteggere, il perfetto approccio Kubernetes native.

PersistentVolumeClaim: a volte l’esigenza di Restore si limita ai dati dell’applicazione per gestire corruzioni logiche o fisiche oppure errori umani (la classica drop table sul DB sbagliato, per citare un caso da manuale). Dato che Kasten K10 permette di selezionare gli oggetti che devono essere recuperati da uno snapshot o da un backup, è possibile in qualsiasi momento recuperare un PVC portandolo ad un punto di consistenza scelto fra quelli disponibili.

ETCD: bisogna ricordare che Kubernetes si appoggia per la gestione degli stati ad un Key Value Store distribuito chiamato ETCD e che è questo il cuore del sistema che contiene i dati che devono essere “restorati”.

ETCD ha una logica di funzionamento basata sulla presenza di un quorum che richiede che il numero di nodi registrati sia dispari e per cui è in grado di sopravvivere alla perdita di un numero pari a N/2 nodi.

Ogni sistema di backup e Restore di K8s  deve garantire un salvataggio consistente dei dati all’interno di ETCD da cui ripartire con un Restore totale o parziale.

Esistono specifiche procedure di Backup di ETCD che partono da una sua messa in quiescenza seguita da un backup consistente.

Il Restore di ETCD deve poi avvenire su un unico nodo da usare poi per ricreare le istanze sugli altri nodi.

Vorrei puntualizzare che è buona norma procedere sempre ad un salvataggio consistente e periodico di ETCD in modo che esista un punto di ripristino dello stato del cluster.

Un salvataggio consistente richiede che sia seguita una specifica procedura che Kasten K10 ha già codificato in una Blueprint specifica di Kanister; è importante che vengano salvati anche i secret relativi ad ETCD altrimenti i dati rimarranno non fruibili.

Per il Restore di ETCD questo deve essere fatto con una precisa procedura manuale che prevede il Restore su un unico master dopo aver fermato tutti i servizi sugli altri nodi ed un successivo redeploy di ETCD.

Kasten mette a disposizione una serie di script customizzati per automatizzare in parte l’operazione.

Intero cluster: ci possono essere varie filosofie per il Restore di un intero cluster. Una soluzione può essere ripartire da un clone dei master su cui applicare nuovamente l’ultimo salvataggio di ETCD.

Questa procedura non è in grado però di “restorare” i PVC in caso questi siano andati perduti e serve quindi solo in caso di corruzione dello stato del cluster stesso.

Un’altra soluzione, sicuramente più efficace, è quella di partire da un cluster esistente, per esempio il secondo cluster del sito, applicare le procedure di Restore di K10 e da questa “restorare” tutte le applicazioni che sono state salvate inclusi quindi i PVC.

blank

Copyright by Kasten

Il messaggio alla fine di questa serie di riflessioni è chiaro: il consiglio è di adottare un tool Kubernetes-Native e di prepararsi anche per gli scenari peggiori possibili, specie quando si tratta di errori umani.

L’invito è quello di eseguire un assessment delle politiche di backup e il Restore dei vostri ambienti basati su Kubernetes e di incrociare i risultati con la BIA, che molto probabilmente esiste già all’interno della vostra orgonizzazione.

È molto probabile che emergeranno delle significative discrepanze e che l’esigenza di una soluzione di Backup e Restore Kubernetes-native come Kasten K10 sorga prepotentemente.

Per ulteriori dettagli e informazioni su come potete garantire il corretto e funzionante Restore dei dati del cluster Kubernetes, potete inviare le vostre richieste alla nostra mail di riferimento Aditinet: sales@aditinet.it.

blank
Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on email
Share on print

Articoli correlati

Non sei ancora iscritto alla nostra newsletter?

Torna su