Programmazione · DevOps · orchestrazione

Cos’è Kubernetes?

Una volta impacchettata un’app in un container, sorge un nuovo problema: chi lo avvia, lo riavvia quando va in crash, ne lancia più copie sotto carico e li collega tutti – su decine di macchine? È l’orchestrazione, e Kubernetes è il sistema che la maggior parte dei team usa per questo. Questa guida spiega cos’è Kubernetes, i concetti che contano, il suo legame con Docker e quando ne hai davvero bisogno.

La definizione breve

Kubernetes è una piattaforma open source per eseguire e coordinare container su un gruppo di macchine. Descrivi lo stato desiderato – «avvia cinque copie di questa app, tienile in salute, esponile a questo indirizzo» – e Kubernetes lavora di continuo perché la realtà corrisponda: colloca i container sulle macchine, riavvia quelli che falliscono, regola la scala e instrada il traffico verso di essi. Lo si abbrevia spesso in K8s (K, otto lettere, s).

Il problema che risolve

Avviare un container a mano è semplice. Avviarne centinaia, in modo affidabile, non lo è. Le macchine cadono, il traffico esplode, occorre distribuire nuove versioni senza interruzioni, e i container devono trovarsi e parlarsi. Fare tutto manualmente è fonte di errori e non dorme mai. Kubernetes ne fa un sistema dichiarativo: descrivi ciò che vuoi, e il ciclo di controllo della piattaforma lo applica senza sosta – sostituendo un container andato in crash o ripianificando il lavoro fuori da una macchina morta, senza svegliare un ingegnere alle 3 del mattino.

I concetti chiave

• Cluster – l’intero sistema: un gruppo di macchine che Kubernetes gestisce come un tutto. Ha un piano di controllo (il cervello che decide) e dei nodi di lavoro (dove i tuoi container girano davvero).
• Nodo – una singola macchina (fisica o virtuale) del cluster che esegue container.
• Pod – la più piccola unità che Kubernetes esegue: uno o più container strettamente collegati che condividono uno storage e un indirizzo di rete. Si eseguono in genere molti pod identici di un’app.
• Deployment – una dichiarazione dello stato desiderato per i tuoi pod: quale immagine, quante repliche e come distribuire gli aggiornamenti. Kubernetes allinea lo stato reale a esso.
• Service – un indirizzo di rete stabile e un bilanciatore di carico per un insieme di pod, affinché le altre parti del sistema li raggiungano anche quando i singoli pod vanno e vengono.

Come funziona, in breve

Sottometti una descrizione di ciò che vuoi – spesso un file YAML che definisce un deployment e un service. Il piano di controllo registra questo stato desiderato e pianifica i pod su nodi che hanno spazio. Un ciclo di controllo confronta poi di continuo lo stato desiderato e lo stato reale: se un pod muore o un nodo fallisce, Kubernetes se ne accorge e ricrea altrove i pod mancanti. La scalabilità segue la stessa idea – passa da «5 repliche» a «20» e lo scheduler colma il divario. Questo modello dichiarativo e auto-riparante è al cuore della fiducia accordata a Kubernetes in produzione.

Kubernetes vs Docker

Sono complementari, non rivali. Docker costruisce ed esegue un container individuale su una macchina. Kubernetes orchestra molti container su molte macchine – li pianifica, li scala, li ripara e li mette in rete. Docker impacchetta ed esegue un container; Kubernetes gestisce una flotta. Kubernetes esegue container costruiti secondo gli standard aperti che Docker ha reso popolari: i due occupano livelli diversi dello stesso stack anziché concorrere.

Ne hai davvero bisogno?

Onestamente, spesso no – almeno non ancora. Kubernetes brilla quando esegui molti servizi, hai bisogno di alta disponibilità e disponi del team per gestirlo. Per una singola app o un piccolo progetto, è di solito eccessivo: un singolo server, un servizio di container gestito o una platform-as-a-service sarà più semplice ed economico. Il costo di Kubernetes è una vera complessità – rete, storage, sicurezza e aggiornamenti richiedono competenza. Adottalo quando la scala giustifica il sovraccarico, non per moda.

Gestito vs auto-ospitato

Puoi eseguire Kubernetes tu stesso, ma la maggior parte dei team usa un servizio gestito in cui un fornitore cloud gestisce il piano di controllo per te, così che gestisci solo i tuoi carichi di lavoro. Questo toglie gran parte del fardello operativo e costituisce la scelta predefinita ragionevole per la maggior parte dei progetti che hanno davvero bisogno di orchestrazione.

I container espongono in genere un’API e si parlano tramite protocolli come gRPC o REST. Sfoglia altre spiegazioni chiare nel nostro indice delle guide.

Domande frequenti