L’esperienza interna di Google diventa open source
Nel giugno 2014 Google annuncia il rilascio di Kubernetes, un sistema di orchestrazione per container ispirato a Borg, l’infrastruttura interna che Google utilizza da oltre un decennio per gestire i propri carichi di lavoro su scala planetaria. Il nome viene dal greco e significa “timoniere” — un riferimento alla navigazione che si riflette anche nel logo, un timone a sette raggi.
L’obiettivo è ambizioso: fornire un livello di astrazione sopra i container che permetta di dichiarare lo stato desiderato di un’applicazione distribuita e lasciare al sistema il compito di raggiungerlo e mantenerlo nel tempo.
Le primitive di Kubernetes
Kubernetes organizza l’infrastruttura attorno a un insieme di primitive dichiarative:
- Pod: l’unità minima di deployment, composta da uno o più container che condividono rete e storage. Un pod rappresenta un singolo processo logico dell’applicazione
- Service: un’astrazione di rete stabile che espone un gruppo di pod dietro un indirizzo IP e una porta costanti, indipendentemente da quali pod siano attivi in un dato momento
- ReplicaSet: garantisce che un numero specificato di repliche di un pod sia sempre in esecuzione. Se un pod viene terminato, il ReplicaSet ne crea uno nuovo
- Deployment: gestisce il ciclo di vita dei ReplicaSet, permettendo aggiornamenti graduali (rolling update) e rollback a versioni precedenti
Queste primitive si compongono: un Deployment crea un ReplicaSet, che mantiene i Pod, che vengono esposti tramite un Service. Lo stato desiderato viene dichiarato in file YAML e inviato all’API server del cluster.
Modello dichiarativo e self-healing
La differenza fondamentale rispetto agli script di deployment tradizionali è il passaggio da un modello imperativo a uno dichiarativo. L’operatore non dice al cluster “avvia tre istanze”; dichiara “voglio tre istanze in esecuzione”. Il controller manager di Kubernetes osserva continuamente lo stato corrente del cluster, lo confronta con lo stato desiderato e agisce per colmare le differenze.
Se un nodo del cluster diventa irraggiungibile, Kubernetes ripianifica i pod su nodi sani. Se un container termina in modo anomalo, viene riavviato. Questo meccanismo di self-healing riduce la necessità di intervento manuale e rende il sistema resiliente ai guasti parziali.
Il service discovery integrato permette ai pod di trovarsi tramite DNS interno, eliminando la configurazione statica degli endpoint. Lo scheduler assegna i pod ai nodi in base alle risorse disponibili, ai vincoli di affinità e alle policy di distribuzione.
Link: kubernetes.io