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!

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 la creazione di un Pod

Immaginiamo un 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.

Autenticazione

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.

Scheduling

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.

Engine

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.

Kube-proxy

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.

Controller-manager

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