Esistono diversi modi per configurare l'archiviazione dei dati per le applicazioni in esecuzione su un cluster Kubernetes. Alcuni di essi sono già obsoleti, altri sono apparsi di recente. In questo articolo esamineremo il concetto di tre opzioni per connettere i sistemi di storage, inclusa la più recente: la connessione tramite Container Storage Interface.
Metodo 1: specifica il PV nel manifest del pod
Un tipico manifest che descrive un pod in un cluster Kubernetes:
Le parti del manifesto che descrivono quale volume è collegato e dove sono evidenziate a colori.
Nella sezione volumeMonti indicare i punti di montaggio (mountPath) - in quale directory all'interno del contenitore verrà montato il volume permanente, nonché il nome del volume.
Nella sezione x elenca tutti i volumi utilizzati nel pod. Specificare il nome di ciascun volume, nonché il tipo (nel nostro caso: awsElasticBlockStore) e i parametri di connessione. I parametri elencati nel manifest dipendono dal tipo di volume.
Lo stesso volume può essere montato contemporaneamente in più contenitori pod. In questo modo, diversi processi applicativi possono accedere agli stessi dati.
Questo metodo di connessione è stato inventato all’inizio, quando Kubernetes era appena agli albori, e oggi è obsoleto.
Ci sono diversi problemi quando lo si utilizza:
- tutti i volumi devono essere creati manualmente; Kubernetes non può creare nulla per noi;
- i parametri di accesso per ciascun volume sono univoci e devono essere specificati nei manifest di tutti i pod che utilizzano il volume;
- per modificare il sistema di storage (ad esempio, passare da AWS a Google Cloud), è necessario modificare le impostazioni e il tipo di volumi montati in tutti i manifest.
Tutto ciò è molto scomodo, quindi in realtà questo metodo viene utilizzato per connettere solo alcuni tipi speciali di volumi: configMap, secret, emptyDir, hostPath:
-
configMap e secret sono volumi di servizio che ti consentono di creare un volume con file dai manifest Kubernetes nel contenitore.
-
emptyDir è un volume temporaneo, creato solo per la durata del pod. Comodo da usare per testare o archiviare dati temporanei. Quando un pod viene eliminato, viene eliminato anche il volume emptyDir e tutti i dati vengono persi.
-
hostPath - consente di montare qualsiasi directory sul disco locale del server su cui è in esecuzione l'applicazione all'interno del contenitore con l'applicazione, incluso /etc/kubernetes. Si tratta di una funzionalità non sicura, pertanto le policy di sicurezza in genere vietano l'uso di volumi di questo tipo. In caso contrario, l'applicazione di un utente malintenzionato sarà in grado di montare la directory HTC Kubernetes all'interno del suo contenitore e rubare tutti i certificati del cluster. In genere, i volumi hostPath possono essere utilizzati solo dalle applicazioni di sistema eseguite nello spazio dei nomi kube-system.
sono riportati nella documentazione.
Metodo 2. Collegamento a focolari in SC/PVC/PV
Un metodo di connessione alternativo è il concetto di classe Storage, PersistentVolumeClaim, PersistentVolume.
Classe di archiviazione memorizza i parametri di connessione al sistema di archiviazione dei dati.
Persistent VolumeClaim descrive i requisiti di cui ha bisogno l'applicazione.
Volume persistente memorizza i parametri di accesso e lo stato del volume.
L'essenza dell'idea: nel manifest del pod indicano un volume di tipo PersistentVolumeClaim e indicano il nome di questa entità nel parametro ClaimName.
Il manifest PersistentVolumeClaim descrive i requisiti per il volume di dati richiesti dall'applicazione. Compreso:
- dimensione del disco;
- metodo di accesso: ReadWriteOnce o ReadWriteMany;
- collegamento alla classe di archiviazione: in quale sistema di archiviazione dati vogliamo creare il volume.
Il manifesto della classe Storage archivia il tipo e i parametri della connessione al sistema di storage. Il cubetto ne ha bisogno per montare il volume sul suo nodo.
I manifesti PersistentVolume indicano la classe di archiviazione e i parametri di accesso per un volume specifico (ID volume, percorso, ecc.).
Durante la creazione di una PVC, Kubernetes esamina la dimensione del volume e la classe di archiviazione richiesta e seleziona un PersistentVolume gratuito.
Se tali PV non sono disponibili, Kubernetes può avviare un programma speciale - Provisioner (il suo nome è indicato nella classe Storage). Questo programma si connette al sistema di archiviazione, crea un volume della dimensione richiesta, riceve un identificatore e crea un manifest PersistentVolume nel cluster Kubernetes, che è associato al PersistentVolumeClaim.
Tutto questo insieme di astrazioni consente di rimuovere informazioni su quale sistema di archiviazione sta lavorando l'applicazione dal livello manifest dell'applicazione al livello di amministrazione.
Tutti i parametri per la connessione al sistema di archiviazione dei dati si trovano nella classe Storage, di cui sono responsabili gli amministratori del cluster. Tutto quello che devi fare quando passi da AWS a Google Cloud è modificare il nome della classe Storage in PVC nei manifest dell'applicazione. Il volume di persistenza per l'archiviazione dei dati verrà creato automaticamente nel cluster utilizzando il programma Provisioner.
Metodo 3: interfaccia di archiviazione del contenitore
Tutto il codice che interagisce con i vari sistemi di storage fa parte del core Kubernetes. Il rilascio di correzioni di bug o nuove funzionalità è legato alle nuove versioni; il codice deve essere modificato per tutte le versioni supportate di Kubernetes. Tutto questo è difficile da mantenere e aggiungere nuove funzionalità.
Per risolvere il problema, gli sviluppatori di Cloud Foundry, Kubernetes, Mesos e Docker hanno creato Container Storage Interface (CSI) - una semplice interfaccia unificata che descrive l'interazione del sistema di gestione dei container e un driver speciale (CSI Driver) che funziona con uno specifico sistema di archiviazione. Tutto il codice per l'interazione con i sistemi di storage è stato spostato dal core Kubernetes a un sistema separato.
.
In genere, il driver CSI è costituito da due componenti: plug-in del nodo e plug-in del controller.
Il plugin del nodo viene eseguito su ciascun nodo ed è responsabile del montaggio dei volumi e dell'esecuzione di operazioni su di essi. Il plugin Controller interagisce con il sistema di storage: crea o elimina volumi, assegna diritti di accesso, ecc.
Per ora i vecchi driver rimangono nel kernel Kubernetes, ma non è più consigliabile utilizzarli e si consiglia a tutti di installare il driver CSI appositamente per il sistema con cui lavoreranno.
L'innovazione può spaventare chi è già abituato a configurare l'archiviazione dei dati tramite la classe Storage, ma in realtà non è successo nulla di terribile. Per i programmatori non cambia veramente nulla: hanno lavorato solo con il nome classe Storage e continueranno a farlo. Per gli amministratori è stata aggiunta l'installazione della plancia di comando ed è stata modificata la struttura delle impostazioni. Se prima le impostazioni venivano inserite direttamente nella classe Storage, ora devono essere impostate prima nell'helm chart, e poi nella classe Storage. Se guardi bene, non è successo niente di brutto.
Facciamo un esempio per vedere i vantaggi che puoi ottenere passando alla connessione dei sistemi di storage Ceph utilizzando il driver CSI.
Quando si lavora con Ceph, il plug-in CSI offre più opzioni per lavorare con i sistemi di archiviazione rispetto ai driver integrati.
- Creazione del disco dinamico. In genere i dischi RBD vengono utilizzati solo in modalità RWO, ma CSI per Ceph consente di utilizzarli in modalità RWX. Diversi pod su nodi diversi possono montare lo stesso disco RDB sui propri nodi e lavorare con essi in parallelo. Per essere onesti, non tutto è così brillante: questo disco può essere collegato solo come dispositivo a blocchi, il che significa che dovrai adattare l'applicazione per lavorare con esso in modalità di accesso multiplo.
- Creazione di istantanee. In un cluster Kubernetes, puoi creare un manifest con il requisito di creare uno snapshot. Il plugin CSI lo vedrà e scatterà uno snapshot dal disco. Sulla base di esso, puoi effettuare un backup o una copia di PersistentVolume.
- Aumento delle dimensioni del disco sullo storage e sul PersistentVolume nel cluster Kubernetes.
- Quote. I driver CephFS integrati in Kubernetes non supportano le quote, ma i nuovi plugin CSI con l'ultimo Ceph Nautilus possono abilitare le quote sulle partizioni CephFS.
- Metriche. Il plugin CSI può fornire a Prometheus una varietà di parametri su quali volumi sono connessi, quali comunicazioni hanno luogo, ecc.
- Consapevole della topologia. Ti consente di specificare nei manifest in che modo il cluster è distribuito geograficamente ed evitare di connettere un sistema di archiviazione situato ad Amsterdam ai pod in esecuzione a Londra.
Come connettere Ceph a un cluster Kubernetes tramite CSI, vedere . Puoi anche iscriverti a , che verrà lanciato il 15 ottobre.
Autore dell'articolo: Sergey Bondarev, architetto praticante presso Southbridge, amministratore certificato Kubernetes, uno degli sviluppatori di kubespray.
Un piccolo Post Scriptum non a scopo pubblicitario, ma a scopo di beneficenza...
PS Sergey Bondarev conduce due corsi intensivi: aggiornati 28-30 settembre e avanzati 14-16 ottobre.
Fonte: habr.com