Kubernetes è composto da più componenti che interagiscono tra loro per compiere diverse attività, come il deploy di un Deployment o un servizio.

Cos’è che succede quando un utente richiede che un pod venga creato? Vediamo step-by-step come funziona!

Cosa vedrai

Concetti di base

In Kubernetes esistono due tipi di nodi: i nodi control plane e i nodi computazionali: i primi sono quelli che si occupano di gestire il cluster, mentre i secondo faranno da backup del cluster di Kubernetes. Se questa definizione ti sembra generica, a breve vedremo nel dettaglio quali sono gli attori che muovono le fila dietro questi nodi.

In un ambiente di produzione, il cluster avrà almeno 3 nodi control plane.

Negli step successivi andremo ad analizzare come avviene la creazione di un pod a partire da un cluster con un nodo control plane e due nodi computazionali.

Come funziona

Immaginiamo un/una utente che, tramite il comando kubectl richiede la creazione di un pod. L’istruzione kubectl si collegherà al server Kube API e sarà pronto per lavorare con il cluster.

Il primo step consiste, da parte del componente kube-api, nell’autenticare l’utente e convalidare la sua richiesta per verificare che abbia i permessi per poter procedere. Una volta che questo passaggio è stato smarcato, comunica a etcd la richiesta e questa verrà inserita all’interno del datastore di modo che si proceda alla sua esecuzione.

Nel frattempo, kube-api comunica all’utente che la creazione è in esecuzione, anche se siamo ancora all’inizio del processo. Questo avviene perché sia kube-api che etcd hanno definito lo stato desiderato in cui il sistema dovrà essere.

Questo vuol dire che tutti i componenti lavoreranno affinché lo stato desiderato sia quello reale e attuale, una volta terminate le operazioni necessarie al completamente della richiesta.

Ora è il turno dello scheduler: questo si occupa di tenere d’occhio le richieste di possibili task che devono essere eseguiti e scegliere su quale nodo questi andranno. Per farlo, richiede a kube-api a intervalli regolari (circa 5 secondi) se ci siano attività da svolgere e, in tal caso, si occupa della loro pianificazione.

Una volta che questa richiesta arriva e che lo scheduler deve eseguirla, comunica con i nodi computazionali grazie a kubelet: questo componente permette infatti a nodi control plane e compute di interagire attraverso kube-api.

Tra i diversi compiti di kubelet, c’è il controllo periodico dello stato dei nodi, così da informarmare kube-api in caso di problematiche, nonché la creazione dei diversi oggetti.

All’interno dei nodi compute c’è inoltre un componente che lavorerà come motore di esecuzione dei container: questo è storicamente associato a Docker, anche se spesso si tratta di Podman e comunque può essere una delle tante tecnologie conformi alla OCI.

L’ultimo componente nei nodi compute è kube-proxy: questo va citato anche se non strettamente necessario all’esempio di questo articolo, ma perché parte del funzionamento tra nodi compute: si occupa infatti di gestire la presenza di attività che coinvolgono più nodi compute all’interno del cluster.

Tornando allo scheduler, questo andrà a valutare quali nodi compute sono disponibili, escludendo quelli che non hanno abbastanza risorse per il pod che deve essere creato, o che magari sono stati esclusi dall’amministratore del cluster per diversi motivi.

Una volta scelto il nodo su cui eseguire l’attività, comunica la sua decisione a kube-api: questo, a sua volta, inserirà l’informazione su etcd e una volta che lo stato desiderato sarà quindi parte del datastore, si proseguirà per far sì che questo diventi lo stato attuale.

Il server kube-api comunicherà quindi con il kubelet del nodo compute che si occuperà della creazione del pod secondo la scelta eseguita dallo scheduler: a questo punto, kubelet e CRI (che sta per Container Runtime Interface) lavoreranno congiuntamente per creare il pod.

Cosa succede se il pod va in errore e la sua politica di riavvio prevede che venga avviato automaticamente?

Entra in gioco l’ultimo componente di Kubernetes, ossia il controller-manager: questo è composto dall’unione dei controller, il quale, come lo scheduler, comunica con kube-api per tenere sotto controllo il numero di repliche presenti all’interno del cluster.

In tal caso, verificando che uno dei pod è andato in errore e che lo stato attuale e quello desiderato non corrispondono -grazie ai dati presenti in etcd, andrà a fare richiesta per la creazione di un nuovo pod con le caratteristiche di quello andato in errore.

Se ti è piaciuto questo articolo, non ti dimenticare di commentare e condividere! ⬇️

Risorse utili

• Docker - per cominciare bene con Docker e Kubernetes
• Kubernetes - Guida per gestire e orchestrare i container
• Come installare Docker (e Docker Compose)
• Esplorando il Dockerfile
• Canale di Emmecilab