‫Finora con Kubernetes non abbiamo davvero discusso di archiviazione
‫o volumi.
‫Ne hai avuto a che fare con Docker,
‫e poi con Compose, Swarm e in una certa misura, è la
‫stessa cosa in Kubernetes.
‫Hai dei contenitori e presumiamo che i contenitori siano
‫apolidi, il che significa che quando butti via
‫il contenitore, tutto in esso scompare.
‫Quando sostituisci un contenitore con un aggiornamento o
‫cambi qualcosa e lo applichi con un'applicazione kubectl, perdi il contenitore, perdi tutto
‫ciò che contiene.
‫Ovviamente, Kubernetes, proprio come gli altri orchestratori,
‫deve avere un modo per mantenere
‫i dati persistenti. È anche più dei volumi stessi.
‫Anche i contenitori e le distribuzioni possono essere diversi in
‫Kubernetes con qualcosa chiamato StatefulSets.
‫Queste sono risorse diverse
‫dalle distribuzioni.
‫Fondamentalmente sono progettati attorno a database e cose che richiedono molta più
‫persistenza, incluso lo stesso nome, le stesse
‫cose IP di questo tipo.
‫Non l'abbiamo ottenuto immediatamente con Swarm
‫o Docker.
‫Non ha davvero avuto modo di mantenere quei
‫diversi attributi tra i contenitori.
‫StatefulSets è una nuova funzionalità di Kubernetes che
‫è stata fuori solo un po 'di tempo qui.
‫È quello che guarderesti se prendi
‫in considerazione database o qualcosa che è molto sensibile a
‫cambiamenti come nomi, indirizzi IP, volumi e dati
‫persistenti. Una parola di cautela qui.
‫Il motivo per cui non analizzeremo molti
‫dettagli è perché non raccomando che il tuo primo
‫schieramento di Kubernetes includa molti
‫StatefulSet in esso. In effetti, idealmente, il tuo
‫primo schieramento di un orchestratore, di qualsiasi orchestratore,
‫sia esso Sciame o Kubernetes, è coinvolto solo con apolidi
‫e, sai, è semplice. Forse esegui semplicemente i tuoi front-end
‫Web o alcune API o alcune funzionalità di lavoro o qualcosa
‫che non coinvolge database. In effetti, se è possibile
‫utilizzare database cloud, farlo.
‫Consiglio sempre di esternalizzare i tuoi database a meno
‫che tu non abbia requisiti specifici che non puoi
‫evitare di eseguire da solo. L'orchestrazione, inizialmente, era
‫davvero progettata attorno a contenitori immutabili, distribuiti
‫e sostituibili.
‫Questa idea di appiccicosità per la statualità aggiungerà più
‫lavoro, complessità e molti più
‫test per te. Idealmente, immediatamente, non devi
‫preoccuparti di questo.
‫Più tardi, una volta che ti sentirai più a tuo agio con tutte le altre
‫cose intorno a Kubernetes, puoi tornare indietro e dire, ora
‫voglio prendere in considerazione i miei database.
‫Non è che non si dovrebbero eseguire database nei cluster.
‫È solo più lavoro. È più difficile.
‫I database e l'archiviazione persistente sono sempre più difficili e con maggiori
‫dettagli su cui lavorare. Ecco il mio consiglio per i professionisti.
‫Con qualsiasi contenitore, puoi aggiungere un volume molto
‫simile a quello che hai fatto in Swarm
‫e in Docker e Docker Compose. Puoi semplicemente aggiungere un'istruzione di volume nel
‫modello all'interno delle specifiche. Se pensi al file YAML,
‫possiamo semplicemente inserire un volume come ti aspetteresti,
‫e il formato esatto e i
‫dettagli sono nelle risorse. A differenza di Docker
‫e Swarm in cui il volume è con un contenitore,
‫in questo caso è tecnicamente con il pod. Si collega a ciascun contenitore, o solo a un
‫contenitore, nel pod se glielo dici.
‫Quindi, lo stai controllando a livello di contenitore, ma la sua persistenza è a
‫livello di pod. C'è una
‫nuova funzionalità che è volumi persistenti.
‫Funziona con qualcos'altro chiamato un reclamo.
‫L'idea interessante è che lo stai usando,
‫o lo definisci, al di fuori
‫dei pod. Fondamentalmente stai creando quella
‫risorsa da solo, e quindi stai rivendicando tale
‫risorsa all'interno delle specifiche del tuo pod.
‫Il motivo per cui questo è più interessante è che Kubernetes
‫prende il controllo dell'azienda, spesso ci sono persone che si
‫occupano dello spazio di archiviazione, spesso di terze parti, che non è lo stesso
‫team che esegue Kubernetes.
‫Saranno quelli coinvolti nella gestione e nella creazione
‫di questi volumi persistenti.
‫Quindi sono i distributori di applicazioni che diranno, ehi,
‫ho bisogno di
‫un volume di questo tipo. Quindi, avrò un reclamo di SSD
‫o potremmo aver bisogno di memoria RAM, o forse ho bisogno di NFS,
‫o altro. Tale spazio di
‫archiviazione verrà fornito automaticamente perché il team di archiviazione
‫lo ha già impostato in Kubernetes.
‫Questa è l'idea dei volumi persistenti.
‫Se hai solo bisogno di un po 'di spazio
‫di archiviazione temporaneo su un singolo server per il pod, usa semplicemente l'attributo
‫dei volumi standard.
‫Un'ultima cosa qui è
‫sulla creazione di plugin CSI. Nella storia di Kubernetes,
‫tutto ciò che era spazio di archiviazione di terze parti, che si
‫tratti di spazio di archiviazione nel cloud o di spazio di archiviazione di
‫terze parti o di qualcosa di personalizzato, è stato aggiunto
‫in albero qualsiasi elemento del genere.
‫Ciò significa che è stato aggiunto ai file binari
‫di Kubernetes e spedito con Kubernetes.
‫Ciò significa che Kubernetes è arrivato con lo storage Amazon
‫e Azure già pronto all'uso.
‫È stato abbastanza conveniente, ma ha aggiunto
‫tante sfide.
‫La maggior parte di questi erano legati al fatto che
‫i fornitori di archiviazione ora stavano contribuendo con il codice al nucleo del
‫sistema che probabilmente non ti serviva nemmeno perché potresti usare un solo fornitore di archiviazione,
‫quindi perché averli tutti?
‫Inoltre, i fornitori di storage dovevano quindi controllare i loro cicli di rilascio
‫durante il ciclo di rilascio di Kubernetes, e non era
‫un modello molto flessibile.
‫Quindi, l'industria si è unita e, come ha
‫fatto con le reti, con Dockerfile e le immagini stesse,
‫ha creato uno standard. Quello standard è il CSI.
‫Questo è l'acronimo di Container Storage Interface.
‫Ciò fornirà i plug-in ora in modo che qualsiasi fornitore di
‫archiviazione possa creare un plug-in da installare su tutti
‫i nodi e che sarebbe diverso in base al
‫plug-in e alle relative istruzioni.
‫Quindi, opereranno su un'API standard fornita dal CSI in modo
‫che tutti i container possano
‫utilizzare quel plug-in per accedere al loro archivio.
‫È un modello molto migliore e più flessibile.
‫È un po 'il futuro di Kubernetes, ma
‫è ancora piuttosto nuovo. Così spesso negli esempi, e
‫persino i tuoi fornitori di storage possono raccomandare, a seconda
‫della loro maturità di CSI, di utilizzare il loro plug-in tradizionale, che
‫è integrato in Kubernetes ed è pronto all'uso.