🥇Storage dei dati nel cluster Kubernetes

È possibile configurare lo storage dei dati delle applicazioni eseguite in un cluster Kubernetes in vari modi. Alcuni di essi sono obsoleti, mentre altri sono recenti. In questo articolo esploreremo il concetto di tre opzioni di connessione allo storage, inclusa l'ultima: la connessione tramite Container Storage Interface.

Metodo 1. Specifica del PV nel manifesto del pod

Un tipico manifesto che descrive un pod in un cluster Kubernetes:

Le parti del manifesto in evidenza indicano quale volume viene collegato e dove.

Nella sezione volumeMounts indica i punti di montaggio (mountPath) — in quale cartella all'interno del contenitore verrà montato il volume persistente, così come il nome del volume.

Nella sezione x elenca tutti i volumi utilizzati nel pod. Indica il nome di ogni volume, così come il tipo (nel nostro caso: awsElasticBlockStore) e i parametri di connessione. I parametri specifici elencati nel manifesto dipendono dal tipo di volume.

Lo stesso volume può essere montato simultaneamente in più contenitori del pod. Così, diversi processi dell'applicazione possono accedere agli stessi dati.

Questo metodo di connessione è stato ideato all'inizio, quando Kubernetes stava appena emergendo, e oggi è obsoleto.

L'utilizzo di questo comporta diversi problemi:

tutti i volumi devono essere creati manualmente, Kubernetes non può crearne nessuno per noi;
le impostazioni di accesso a ciascun volume sono uniche e devono essere specificate nei manifest di tutti i pod che utilizzano il volume;
per cambiare il sistema di archiviazione (ad esempio, passare da AWS a Google Cloud), è necessario modificare le impostazioni e il tipo di volumi collegati in tutti i manifest.

Tutto ciò è molto scomodo, quindi nella pratica questo metodo viene utilizzato solo per connettere alcuni tipi speciali di volumi: configMap, secret, emptyDir, hostPath:

configMap e secret sono volumi di servizio, consentono di creare un volume con file dai manifest di Kubernetes nel contenitore.
emptyDir è un volume temporaneo, creato solo per la durata del pod. È comodo da utilizzare per test o per memorizzare dati temporanei. Quando il pod viene eliminato, anche il volume di tipo emptyDir viene eliminato e tutti i dati vengono persi.
hostPath — consente di montare all'interno del contenitore dell'applicazione qualsiasi directory del disco locale del server su cui è in esecuzione l'applicazione, incluso /etc/kubernetes. Questa è una funzionalità non sicura, quindi in genere le politiche di sicurezza vietano l'uso di volumi di questo tipo. Altrimenti, un'applicazione malevola potrebbe collegare all'interno del suo contenitore la directory HTC Kubernetes e rubare tutti i certificati del cluster. In generale, i volumi hostPath sono consentiti solo per le applicazioni di sistema che vengono eseguite nel namespace kube-system.

I sistemi di archiviazione con cui Kubernetes lavora nativamente sono descritti nella documentazione.

Metodo 2. Collegamento a pod SC/PVC/PV

Un metodo alternativo di collegamento è la concezione di Storage class, PersistentVolumeClaim, PersistentVolume.

Storage class memorizza i parametri di collegamento al sistema di archiviazione.

PersistentVolumeClaim descrive le esigenze del volume necessario per l'applicazione.
PersistentVolume memorizza i parametri di accesso e lo stato del volume.

L'idea principale: nel manifesto del pod si specifica il volume di tipo PersistentVolumeClaim e si indica il nome di questa entità nel parametro claimName.

Nel manifesto PersistentVolumeClaim si descrivono i requisiti per i dati necessari all'applicazione. Questi includono:

dimensione del disco;
modo di accesso: ReadWriteOnce o ReadWriteMany;
riferimento alla Storage class — in quale sistema di archiviazione vogliamo creare il volume.

Nel manifesto della Storage class sono memorizzati il tipo e i parametri di connessione al sistema di archiviazione. Questi sono necessari al kubelet per montare il volume sul nodo.

Nei manifesti PersistentVolume sono specificati la Storage class e i parametri di accesso a un volume specifico (ID del volume, percorso, ecc.).

Creando un PVC, Kubernetes verifica quale volume di dimensioni e proveniente da quale Storage class è necessario e cerca un PersistentVolume disponibile.

Se non ci sono PV disponibili, Kubernetes può avviare un programma speciale — il Provisioner (il cui nome è specificato nella Storage class). Questo programma si connette allo storage, crea un volume delle dimensioni richieste, ottiene l'identificativo e crea nel cluster Kubernetes un manifesto PersistentVolume, collegato al PersistentVolumeClaim.

Tutta questa moltitudine di astrazioni consente di nascondere le informazioni relative al sistema di archiviazione con cui l'applicazione interagisce, portandole dal livello del manifesto delle applicazioni a quello di amministrazione.

Tutti i parametri di connessione al sistema di storage si trovano nella Storage class, di cui sono responsabili gli amministratori del cluster. Tutto ciò che è necessario fare quando si passa da AWS a Google Cloud è modificare il nome della Storage class nel PVC nei manifesti dell'applicazione. I Persistent Volumes per lo storage dei dati verranno creati automaticamente nel cluster tramite il Provisioner.

Metodo 3. Container Storage Interface

Tutto il codice che interagisce con i vari sistemi di storage è parte integrante del kernel di Kubernetes. Il rilascio di patch per bug o nuove funzionalità è legato a nuovi rilasci, e il codice deve essere modificato per tutte le versioni supportate di Kubernetes. Tutto ciò è difficile da mantenere e richiede una continua aggiunta di nuove funzioni.

Per risolvere questo problema, gli sviluppatori di Cloud Foundry, Kubernetes, Mesos e Docker hanno creato il Container Storage Interface (CSI) — un'interfaccia semplice e unificata che descrive l'interazione tra il sistema di gestione dei container e un driver specifico (CSI Driver) progettato per lavorare con un particolare sistema di storage. Tutto il codice di interazione con il sistema di storage è stato estratto dal kernel di Kubernetes in un sistema separato.

Documentazione sul Container Storage Interface.

Di norma, il CSI Driver è composto da due componenti: Node Plugin e Controller Plugin.

Il Node Plugin si avvia su ciascun nodo e si occupa del montaggio dei volumi e delle operazioni su di essi. Il Controller plugin interagisce con lo storage: crea o elimina volumi, assegna permessi di accesso, ecc.

Finché nel kernel di Kubernetes rimarranno driver vecchi, non è più consigliato utilizzarli e si consiglia a tutti di installare il CSI Driver specifico per il sistema con cui si dovrà lavorare.

Questa novità potrebbe spaventare chi è già abituato a configurare l'archiviazione dei dati tramite Storage class, ma in realtà non c'è nulla di cui preoccuparsi. Per i programmatori non cambia nulla: continueranno a lavorare usando il nome Storage class. Per gli amministratori è stata aggiunta l'installazione del helm chart e la struttura delle impostazioni è cambiata. Se prima le impostazioni venivano inserite direttamente nella Storage class, ora devono prima essere definite nel helm chart e poi nella Storage class. Se ci si fa attenzione, non è successo niente di drammatico.

Vediamo, con un esempio, quali vantaggi si possono ottenere passando alla connessione dello storage Ceph tramite CSI driver.

Lavorando con Ceph, il plugin CSI offre più possibilità per lavorare con lo storage rispetto ai driver integrati.

Creazione dinamica dei dischi. Di solito, i dischi RBD vengono utilizzati solo in modalità RWO, mentre CSI per Ceph consente di usarli in modalità RWX. Diversi pod su nodi differenti possono montare lo stesso disco RDB sui propri nodi e lavorare con essi in parallelo. A dire il vero, non è tutto rose e fiori: questo disco può essere connesso solo come dispositivo di blocco, quindi sarà necessario adattare l'applicazione per lavorare con esso in modalità di accesso simultaneo.
Creazione di snapshot. In un cluster Kubernetes, è possibile creare un manifesto che richiede la creazione di uno snapshot. Il plugin CSI lo rileverà e farà uno snapshot del disco. Sulla base di esso, sarà possibile eseguire un backup o creare una copia del PersistentVolume.
Aumento delle dimensioni del disco su storage e PersistentVolume nel cluster Kubernetes.
Quote. I driver CephFS integrati in Kubernetes non supportano le quote, mentre i nuovi plugin CSI con l'ultima versione di Ceph Nautilus possono abilitare le quote per le partizioni CephFS.
Metriche. Il plugin CSI può fornire a Prometheus molte metriche riguardo a quali volumi sono collegati, quali interazioni si stanno verificando, ecc.
Consapevolezza della topologia. Permette di indicare nei manifesti come è geograficamente distribuito il cluster e di evitare di connettersi a pod avviati a Londra con sistemi di storage dati situati ad Amsterdam.

Per collegare Ceph al cluster Kubernetes tramite CSI, vedere nella parte pratica della lezione della scuola serale Slërm. Si può anche iscriversi al corso video Ceph, che sarà avviato il 15 ottobre.

Autore dell'articolo: Sergey Bondarev, architetto praticante di Southbridge, Certified Kubernetes Administrator, uno dei sviluppatori di kubespray.

Un po' di Post Scriptum non come pubblicità, ma per utilità…

P.S. Sergey Bondarev conduce due intensivi: rinnovato Base di Kubernetes 28-30 settembre e avanzato Kubernetes Mega dal 14 al 16 ottobre.