kubernetes volumi

in Architetture Software, Informatica

Kubernetes – Considerazioni sui Volumi – parte1

Reading Time: 2 minutes

Sebbene Kubernetes abbiamo uno scenario molto dinamico che consente di definire la scalabilità, la portabilità e la gestione, con un “piccolo” problema relativo allo storage.

Con la diffusione dell’architettura dei microservizi e il disaccoppiamento dell’infrastruttura dalla logica dell’applicazione dal punto di vista dello sviluppatore, gli sviluppatori si stanno concentrando sempre più solo sulla creazione di software.

In un’architettura Kubernetes, la parola chiave è dinamicità. I container vengono creati e distrutti a seconda del carico e dalle logiche definite all’interno dello yaml file scritti dagli sviluppatori. I Pods e i containers hanno la capacità di auto-ripararsi in caso di problemi, e di replicarsi.

Quasi tutte le applicazioni di produzione sono stateful: necessitano di una sorta di memoria esterna all’interno della quale memorizzare le informazioni.

Come già visto nel post precedente, Kubernetes crea meccanismi di storage basati sui volumi persistent (PV), gestiti mediante claims (PVC). Prendendo in considerazione uno semplice scenario composto da un container, per poter persistere i dati al suo interno è necessario configurare un volume.

La natura stessa del container è di tipo stateless: quando un container viene riavviato, vengono persi tutti i dati e le modifiche fatte all’interno del suo filesystem.

Una soluzione di archiviazione persistente non si può permettere la stessa dinamicità vista per pods e containers. L’utilizzo di un sistema di archiviazione persistente non può essere vincolata a tutte le regole di creazione e distruzione dinamiche.

Le applicazioni stateful rappresentano una sorta di sfida nello sviluppo di architetture distribuite: quando è necessario migrare su un’altra infrastruttura è necessario dettagliare il piu’ possibile come migrare i dati. Spesso risulta molto utile l’utilizzo di provider esterni, ad esempio presenti nel cloud.

Volumi

Un volume garantisce la persistenza dei dati anche oltre il normale ciclo di vita di un container. I volumi consentono di montare unità all’interno dei container aumentando la capacità di storage dei singoli nodi. I volumi tradizionali saranno comunque eliminati al momento della cancellazione del pod.

Un volume permanente è invece un volume che è posizionato direttamente all’interno di un servizio di storage di rete, come ad esempio NFS o EBS. In passato sono stati sviluppati numerosi protocolli di rete come NFS, iSCSI e SMB.

L’utilizzo di uno storage “tradizionale” però comporta alcuni step di configurazione aggiuntiva, come ad esempio l’introduzione di un sistema di backup dei dati e dei volumi. L’alternativa è quella di utilizzare sistemi di storage cloud di terze parti.

Ad esempio, si possono utilizzare i servizi di storage di AWS, come S3. Utilizzando S3, o altri servizi di storage esterni, si ha il vantaggio di non dover utilizzare strumenti di terze parti per effettuare i backup.

Supponiamo di dover realizzare un’applicazione che ha la necessità di utilizzare un database: la prima idea potrebbe essere quella di implementare una soluzione che utilizza un container ed eseguirla all’interno del cluster. Questa potrebbe sembrare un’ottima soluzione, ma considerando le caratteristiche di un database, potremmo trovarci a gestire problemi di sincronizzazione di mantenimento.

Inoltre i container sono stati sviluppati principalmente per la gestione di filesystem statici, e le performance per ottimizzare le operazioni non sono sicuramente ottimali. L’utilizzo di un database all’interno di un container richiede scritture e letture piuttosto frequenti.

Inoltre, utilizzando un database lo stato dei dati deve essere memorizzato.

Idealmente sarebbe consigliato effettuare il deploy di un contenitore all’interno dello stesso pod in cui vien eseguito il container con il database. Tipicamente però, questo tipo di approccio vine utilizzato all’interno di ambienti di pre-produzione dove le ottimizzazioni non sono un requisito importante.

In produzione si preferisce utilizzare provider con storage esterni.

In un prossimo post vedremo quali soluzioni possono essere adottate.