Kubernetes è diventato quasi sinonimo di infrastruttura moderna, al punto che molti lo adottano prima di capire se ne hanno bisogno. È uno strumento potente, nato per gestire molti container su molte macchine, ma porta con sé un modello mentale nuovo e una complessità operativa non trascurabile. Conoscere i suoi concetti base aiuta sia a usarlo bene sia a decidere quando lasciarlo da parte.
Il principio: stato desiderato e riconciliazione
L'idea centrale di Kubernetes è dichiarativa. Non gli si dice «avvia tre container», ma «voglio che ci siano sempre tre copie di questa applicazione». Kubernetes confronta continuamente lo stato desiderato con lo stato reale e interviene per farli coincidere: se un container si blocca lo riavvia, se un nodo si spegne sposta i container altrove, se ne mancano li crea.
Questo ciclo di riconciliazione è ciò che distingue un orchestratore da uno script di avvio. Il cluster si autoripara entro certi limiti, purché gli si descriva correttamente cosa si vuole.
L'architettura in breve
Un cluster è composto da due parti:
- il control plane, che contiene l'API server (il punto di ingresso di ogni comando), il database etcd dove è salvato lo stato, lo scheduler che decide su quale nodo far girare ogni carico e i controller che eseguono la riconciliazione;
- i nodi di lavoro, macchine fisiche o virtuali su cui girano davvero i container, ciascuna con un agente chiamato kubelet.
Nei servizi gestiti offerti dai provider cloud il control plane è curato dal fornitore, e chi usa il cluster si occupa solo dei nodi e delle applicazioni.
Gli oggetti fondamentali
Tutto in Kubernetes è un oggetto descritto in un file YAML e inviato all'API server. Quelli da conoscere per primi sono pochi.
| Oggetto | A cosa serve |
|---|---|
| Pod | La più piccola unità eseguibile: uno o più container che condividono rete e volumi |
| Deployment | Mantiene un certo numero di repliche di un pod e ne gestisce gli aggiornamenti |
| Service | Fornisce un indirizzo stabile e bilancia il traffico tra le repliche |
| Ingress | Instrada le richieste HTTP dall'esterno verso i Service, per dominio o percorso |
| ConfigMap e Secret | Separano configurazione e credenziali dall'immagine |
| Namespace | Divide il cluster in spazi logici, per team o ambienti |
Pod e Deployment
Raramente si crea un pod a mano. I pod sono effimeri: possono essere distrutti e ricreati in qualsiasi momento, con un indirizzo IP diverso. Si crea invece un Deployment, che descrive il modello di pod e il numero di repliche. Quando si aggiorna l'immagine, il Deployment sostituisce le repliche gradualmente, così il servizio resta disponibile durante il rilascio.
Service e Ingress
Poiché i pod cambiano indirizzo, le altre applicazioni non possono contattarli direttamente. Il Service offre un nome DNS interno stabile e distribuisce le richieste tra i pod sani. L'Ingress, insieme a un controller come quello basato su Nginx, espone i servizi all'esterno e di solito gestisce anche i certificati TLS.
Due dettagli che fanno la differenza
Le sonde di salute
Kubernetes può controllare lo stato di ogni container con delle probe:
- la liveness probe verifica che il processo non sia bloccato; se fallisce, il container viene riavviato;
- la readiness probe verifica che sia pronto a ricevere traffico; se fallisce, il pod viene escluso temporaneamente dal Service.
Senza readiness probe, durante un aggiornamento il traffico può arrivare a un'applicazione che sta ancora caricando, generando errori visibili agli utenti.
Richieste e limiti di risorse
Ogni container dovrebbe dichiarare quanta CPU e memoria richiede e qual è il suo limite. Le richieste servono allo scheduler per collocare i pod su nodi con spazio sufficiente; i limiti impediscono a un container di consumare tutte le risorse. Un container che supera il limite di memoria viene terminato, quindi i valori vanno stimati osservando il consumo reale.
Quando Kubernetes conviene
Kubernetes ha senso quando si verificano più condizioni insieme:
- molti servizi diversi da gestire, spesso a cura di team diversi;
- necessità di alta disponibilità su più macchine;
- carichi variabili che richiedono di aggiungere e togliere repliche automaticamente;
- un'organizzazione disposta a investire nel mantenimento del cluster e nella formazione.
Quando se ne può fare a meno
Per un'applicazione web con database, un gestionale interno o un sito con traffico prevedibile, Kubernetes è spesso eccessivo. Aggiornamenti di versione del cluster, rete, controller, permessi, certificati e monitoraggio richiedono tempo e competenze dedicate. Nel mio lavoro, prima di proporlo, chiedo sempre quante persone lo gestiranno e cosa succede alle tre di notte quando qualcosa si rompe.
Le alternative più semplici sono concrete: Docker Compose su un singolo server, servizi gestiti che eseguono container senza esporre il cluster, piattaforme che accettano direttamente il codice o l'immagine. Molte aziende funzionano benissimo con queste soluzioni, e passano a Kubernetes solo quando i loro limiti diventano un problema reale e non ipotetico.
In sintesi
- Kubernetes lavora in modo dichiarativo: descrivi lo stato desiderato e il cluster lo mantiene.
- I concetti da conoscere per primi sono Pod, Deployment, Service, Ingress, ConfigMap, Secret e namespace.
- Liveness e readiness probe, insieme a richieste e limiti di risorse, sono essenziali per un cluster stabile.
- Conviene con molti servizi, team diversi e necessità di alta disponibilità.
- Per progetti piccoli o prevedibili esistono alternative più semplici ed economiche da gestire.
