Come Kubernetes crea un pod
Published: 2023-10-03 14:23:22

---
title: Come Kubernetes crea un pod
published: true
date: 2023-06-15 00:00:00 UTC
tags: 
canonical_url: 
---

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](https://etcd.io/) 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](https://etcd.io/) hanno definito <ins>lo stato desiderato in
cui il sistema dovrà essere</ins>.

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.

![](https://theredcode.it/img/k8s-create-pod-kube-api.png)

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.

![](https://theredcode.it/img/k8s-scheduler.png)

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.

![](https://theredcode.it/img/k8s-compute-kubelet.png)

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](https://theredcode.it/podman/cos-e-podman)e comunque può essere una delle tante tecnologie conformi alla [OCI](https://opencontainers.org/).

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.

![](https://theredcode.it/img/k8s-compute-cri.png)

Tornando allo _scheduler_, questo andrà a valutare <ins>quali nodi <em>compute</em> sono disponibili</ins>, 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.

![](https://theredcode.it/img/k8s-compute-create-pod.png)

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

![](https://theredcode.it/img/k8s-controller-manager.png)

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](https://etcd.io/), andrà a fare richiesta per la creazione di un nuovo pod con le caratteristiche di quello andato in errore.

![](https://theredcode.it/img/k8s-controller-manager-new-pod.png)

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

# Risorse utili

- [Docker](https://amzn.to/3cSVvUG) - per cominciare bene con Docker e Kubernetes
- [Kubernetes](https://amzn.to/44bLfyR) - Guida per gestire e orchestrare i container
- [Come installare Docker (e Docker Compose)](https://www.youtube.com/watch?v=Xea_9GYFpaA)
- [Esplorando il Dockerfile](https://www.theredcode.it/esplorando-il-dockerfile/)
- [Canale di Emmecilab](https://www.youtube.com/c/EmmeCiLab/about)