🥇Storage dei dati nel cluster Kubernetes

È possibile configurare l'archiviazione dei dati delle applicazioni in esecuzione nel cluster Kubernetes in vari modi. Alcuni di questi sono già obsoleti, altri sono emersi di recente. In questo articolo, esamineremo 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 manifesto tipico che descrive un pod nel 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 directory all'interno del contenitore verrà montato il volume persistente, oltre al nome del volume.

Nella sezione x elenca tutti i volumi utilizzati nel pod. Specifica il nome di ciascun volume, oltre al tipo (nel nostro caso: awsElasticBlockStore) e ai parametri di connessione. I parametri specificati nel manifesto dipendono dal tipo di volume.

Lo stesso volume può essere montato simultaneamente in più contenitori del pod. In questo modo, diversi processi dell'applicazione possono avere accesso agli stessi dati.

Questo metodo di connessione è stato ideato all'inizio, quando Kubernetes stava appena nascendo, ed è obsoleto al giorno d'oggi.

Il suo utilizzo comporta diversi problemi:

tutti i volumi devono essere creati manualmente, Kubernetes non sarà in grado di crearne alcuno per noi;
i parametri di accesso a ciascuno dei volumi sono unici e devono essere specificati nei manifesti di tutti i pod che utilizzano il volume;
per cambiare il sistema di storage (ad esempio, spostandosi da AWS a Google Cloud), è necessario modificare le impostazioni e il tipo di volumi connessi in tutti i manifesti.

Tutto ciò è molto scomodo, quindi nella realtà questo metodo viene usato solo per collegare alcuni tipi speciali di volumi: configMap, secret, emptyDir, hostPath:

configMap e secret — volumi di servizio, consentono di creare nel contenitore un volume con file dai manifesti di Kubernetes.
emptyDir — volume temporaneo, viene creato solo per la durata della vita del pod. È comodo da usare per test o per memorizzare dati temporanei. Quando il pod viene rimosso, il volume di tipo emptyDir viene anch'esso rimosso e tutti i dati scompaiono.
hostPath consente di montare all'interno di un contenitore con applicazione qualsiasi directory del disco locale del server su cui è in esecuzione l'applicazione, inclusa /etc/kubernetes. Questa è una funzionalità insicura, quindi di solito le politiche di sicurezza vietano l'uso di volumi di questo tipo. Altrimenti, l'applicazione di un malintenzionato potrebbe montare all'interno del proprio 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 eseguite nel namespace kube-system.

Sistemi di archiviazione dati con cui Kubernetes lavora di default sono riportati nella documentazione.

Metodo 2. Collegamento ai pod SC/PVC/PV

Un altro modo di collegarsi è il concetto di Storage class, PersistentVolumeClaim, PersistentVolume.

Storage class memorizza i parametri di connessione al sistema di archiviazione dati.

PersistentVolumeClaim descrive i requisiti per il volume necessario all'applicazione.
PersistentVolume memorizza i parametri di accesso e lo stato del volume.

Il concetto è: nel manifesto del pod si specifica un volume di tipo PersistentVolumeClaim e si indica il nome di questa entità nel parametro claimName.

Nel manifesto del PersistentVolumeClaim si descrivono i requisiti per il volume di dati necessario all'applicazione. Includendo:

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

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

Nel manifesto del PersistentVolume si specifica la Storage class e i parametri di accesso a un volume specifico (ID del volume, percorso, ecc.).

Creando un PVC, Kubernetes esamina la dimensione del volume e da quale Storage class sarà necessario, e seleziona un PersistentVolume disponibile.

Se tali PV non sono disponibili, Kubernetes può avviare un programma speciale — Provisioner (il cui nome è specificato nella Storage class). Questo programma si connette allo storage, crea un volume della dimensione richiesta, ottiene un identificatore e crea nel cluster Kubernetes il manifesto del PersistentVolume, che viene associato al PersistentVolumeClaim.

Tutti questi livelli di astrazione consentono di rimuovere le informazioni su quale SCD stia utilizzando l'applicazione, dal livello del manifesto delle applicazioni al livello di amministrazione.

Tutti i parametri di connessione al sistema di archiviazione sono nel Storage class, di cui sono responsabili gli amministratori del cluster. Tutto ciò che è necessario fare durante il passaggio da AWS a Google Cloud è modificare il nome dello Storage class nel PVC nei manifesti dell'applicazione. I Persistent Volume per l'archiviazione dei dati verranno creati automaticamente nel cluster, utilizzando il programma Provisioner.

Metodo 3. Container Storage Interface

Tutto il codice che interagisce con i vari sistemi di archiviazione fa parte del kernel di Kubernetes. I rilasci di patch o nuove funzionalità sono legati ai nuovi rilasci, il codice deve essere modificato per tutte le versioni supportate di Kubernetes. Tutto ciò è difficile da mantenere e aggiungere nuove funzionalità.

Per risolvere il 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 contenitori e uno speciale driver (CSI Driver) che lavora con uno specifico sistema di archiviazione. Tutto il codice per l'interazione con il sistema di archiviazione è stato spostato dal kernel di Kubernetes a 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 viene eseguito su ciascun nodo e si occupa del montaggio dei volumi e delle operazioni su di essi. Il Controller Plugin interagisce con il sistema di archiviazione: crea o elimina volumi, assegna diritti di accesso, ecc.

Nel kernel di Kubernetes rimangono ancora i vecchi driver, ma non sono più raccomandati e si consiglia a tutti di installare il CSI Driver specifico per il sistema con cui si intende lavorare.

La novità può spaventare coloro che sono già abituati a configurare l'archiviazione tramite Storage class, ma in realtà non è successo nulla di grave. Non cambia nulla per i programmatori — continueranno a lavorare solo con il nome dello 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 nello Storage class, ora devono prima essere definite nel helm chart e poi nello Storage class. Se si approfondisce, non è successo nulla di grave.

Diamo un'occhiata, per esempio, a quali vantaggi si possono ottenere passando alla connessione con il sistema di archiviazione Ceph tramite il driver CSI.

Lavorando con Ceph, il plugin CSI offre maggiori opportunità per lavorare con il sistema di archiviazione rispetto ai driver integrati.

Creazione dinamica di dischi. Di solito, i dischi RBD sono utilizzati solo in modalità RWO, mentre CSI per Ceph consente di utilizzarli in modalità RWX. Più pod su nodi diversi possono montare lo stesso disco RBD sui propri nodi e lavorare con esso in parallelo. A onor del vero, non è tutto roseo: questo disco può essere collegato solo come dispositivo a blocchi, quindi sarà necessario adattare l'applicazione per lavorare con esso in modalità accesso condiviso.
Creazione di snapshot. In un cluster Kubernetes è possibile creare un manifesto con la richiesta di creare uno snapshot. Il plugin CSI lo vedrà e realizzerà uno snapshot dal disco. Sulla base di esso sarà possibile eseguire un backup o una copia di PersistentVolume.
Aumento delle dimensioni del disco su SAN e PersistentVolume nel cluster Kubernetes.
Quote. I driver CephFS integrati in Kubernetes non supportano le quote, mentre i nuovi plugin CSI con il nuovo Ceph Nautilus possono attivare le quote sulle partizioni CephFS.
Metriche. Il plugin CSI può fornire a Prometheus molte metriche su quali volumi sono connessi, quali interazioni sono in corso, ecc.
Consapevole della topologia. Permette di specificare nei manifesti come è distribuito geograficamente il cluster e di evitare connessioni ai pod avviati a Londra da un sistema di storage situato ad Amsterdam.

Per collegare Ceph al cluster Kubernetes tramite CSI, vedere nella parte pratica della lezione della scuola serale Slёrm. È anche possibile iscriversi al corso video Ceph, che inizierà il 15 ottobre.

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

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

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