Pillole di Kubernetes: un po' di terminologia
Quando si approccia Kubernetes per la prima volta ci si può spaventare di fronte alla vastità dei termini utilizzati: nodo, cluster, pod, deployment, ingress ecc.
In questo articolo cercheremo di fare un po' di chiarezza, spiegando il significato dei principali concetti nella maniera più semplice possibile, anche se talvolta in modo non propriamente rigorosissimo, così da farci un'idea di massima dei vari mattoncini che compongono questo mondo straordinario e allo stesso tempo complesso.
In primis occupiamoci dell'hardware, senza il quale nulla funzionerebbe.
Un nodo rappresenta l'elemento hardware di base in Kubernetes, così come lo è una cellula nei sistemi viventi. Non è altro che una singola unità di elaborazione, sia che si tratti di una macchina fisica o di una virtual machine. Per esempio potremmo avere un certo numero di nodi costituiti da server, notebook e VM su AWS, Google, Azure o qualsiasi altro cloud provider.
Più nodi possono costituire un cluster in cui ciascuno di essi condivide le proprie risorse, consentendo di creare una "macro macchina" più potente delle singole unità prese ad una ad una.
Gli eventuali processi in esecuzione verranno distribuiti sui vari nodi in modo da bilanciare il carico applicativo ed ogni variazione del cluster (aggiunta/rimozione di nodi) comporterà una conseguente rimodulazione in modo da garantire la migliore configurazione possibile.
Un aspetto molto importante è rappresentato dallo storage dei dati. Quando un programma gira su un cluster può essere materialmente eseguito da uno dei nodi disponibili, senza alcuna garanzia che si tratti sempre dello stesso, pena il venir meno di uno dei vantaggi dei sistemi distribuiti. Ovvero se dipendesse esclusivamente da un nodo, la sua indisponibilità metterebbe in crisi l'intero sistema.
Quindi non si può pensare di salvare i dati localmente se non come una sorta di cache temporanea. Senza contare il fatto che lo storage associato ad un container ha il suo stesso e limitato ciclo di vita.
Per questo motivo la persistenza viene affidata ai persistent volumes che vengono collegati al cluster ma non gestiti direttamente da quest'ultimo, nel senso che la loro "esistenza" non è da esso dipendente.
Sul fronte software troviamo in primo luogo i container che non vengono eseguiti direttamente da Kubernetes ma raggruppati in una struttura logica astratta denominata pod all'interno della quale condividono le proprie risorse e la rete. Questo significa che i container presenti in uno stesso pod possono comunicare con estrema facilità, ma anche che possono essere completamente isolati tra di loro anche se presenti sulla stessa macchina ma in pod differenti.
Questo garantisce un'ottimizzazione delle risorse senza rinunciare alla sicurezza.
Generalmente è l'intero pod ad essere replicato su nodi differenti in caso di necessità (bilanciamento del carico e fault tolerance). Proprio per questo motivo conviene avere al suo interno un numero limitato di container, onde evitare di scalare anche container che non lo richiedono, sprecando risorse e conseguentemente denaro.
Sarebbe buona norma includere in un pod esclusivamente i container associati ad un singolo processo in modo che le eventuali repliche siano coerenti.
Anche i pod non sono "avviati" direttamente da Kubernetes ma inglobati all'interno di un altro livello di astrazione: il deployment.
Poichè si ragiona in termini di pod, quest'ultimo consente di definire il numero di repliche richieste che poi andranno assegnate ai vari nodi. Una volta aggiunto al cluster vengono attivati i pod specificati e quando uno di essi non è più disponibile viene ricreato in automatico per rispettare i limiti imposti.
A questo punto abbiamo un'idea quasi completa di tutti gli elementi occorrenti per creare un cluster Kubernetes. Resta da definire in quale modo possiamo comunicare con questo mondo, visto che di default tutti gli accessi dall'esterno sono bloccati per garantire il massimo livello di isolamento.
Entra in gioco un nuovo termine: ingress che come si può intuire rappresenta una sorta di canale di comunicazione e che può essere rappresentato da un controller Ingress o da un LoadBalancer.
Per il momento limitiamoci a dire che un LoadBalancer è un servizio che punta ad un bilanciatore esterno al cluster Kubernetes. In generale si tratta di un servizio messo a disposizione da un cloud provider. E' un modo semplice per esternalizzare dei servizi ed utilizzare risorse di terze parti.
Viceversa un controller Ingress è un pod che si occupa di interpretare le regole di comunicazione impostate. In un certo senso opera alla stregua di un firewall con cui si decide quale traffico bloccare o consentire in base a protocolli, porte e via dicendo. E' molto potente e flessibile ma anche più complesso da gestire.
Naturalmente ci sarebbe molto altro da approfondire ma come già detto lo scopo di questo articolo introduttivo è di dare le basi minime per poter affrontare con più semplicità articoli, tutorial, libri tecnici sull'argomento.
Buona lettura!
--> Guarda tutti i video sul canale YouTube <--
--> Repository GitHub con esempi <--
LIBRI CONSIGLIATI
Soluzioni personalizzate per le vostre esigenze
