Kubernetes: cos’è, come funziona, architettura, cluster e differenze con Docker

Kubernetes è una piattaforma open source per gestire workload e servizi containerizzati attraverso configurazione dichiarativa e automazione. In pratica, non si limita ad avviare container: descrivi come vuoi che sia il sistema — quante repliche devono essere attive, quali risorse servono, come devono essere raggiungibili — e il control plane lavora continuamente per avvicinare lo stato reale a quello desiderato.

La documentazione ufficiale mette proprio questo modello al centro dell’architettura.

È il passaggio che distingue un orchestratore da strumenti pensati soprattutto per costruire ed eseguire container su una singola macchina. Se vuoi capire prima il livello sottostante, la guida a Docker chiarisce il percorso Dockerfile → immagine → registry → container e il ruolo di Docker Compose.

Kubernetes, spesso abbreviato in K8s, entra in gioco quando il problema non è più soltanto “come eseguo questo container?”, ma “come mantengo disponibili, aggiornati e distribuiti molti workload su uno o più nodi senza amministrare ogni istanza a mano?”.

Questa guida parte da quel problema e arriva a cluster, Pod, Deployment, Service, scheduling, container runtime, rapporto con Docker e servizi gestiti. Il punto non è imparare a memoria i nomi dei componenti, ma capire chi prende quale decisione e quando la complessità introdotta dall’orchestrazione è realmente giustificata.

Cos’è Kubernetes e perché esiste

La piattaforma nasce per gestire workload e servizi containerizzati con un modello portabile, estensibile e dichiarativo.

La parola importante è dichiarativa.

Con un sistema puramente imperativo potresti ragionare così: avvia questo processo, poi avvia una seconda copia, sposta il traffico e sostituisci manualmente quella che si è fermata.

Il modello dichiarativo sposta il problema su un livello diverso. Dichiari, per esempio, che vuoi tre repliche di una certa applicazione e lasci ai controller il compito di mantenere quella condizione nel tempo.

La gestione non coincide quindi con una sequenza fissa di comandi. È un insieme di loop di controllo che osservano continuamente lo stato del cluster e reagiscono quando lo stato reale si discosta da quello richiesto.

Dal singolo container all’orchestrazione

Un container risolve soprattutto un problema di packaging ed esecuzione. Racchiude applicazione e dipendenze in un’immagine che può essere avviata da un container runtime compatibile.

Quando però il numero di istanze aumenta, emergono domande diverse:

• su quale macchina deve partire ogni workload?
• cosa succede se un nodo non ha abbastanza CPU o memoria?
• come sostituisco automaticamente una replica che non esiste più?
• come distribuisco un aggiornamento senza interrompere tutto?
• come trovo i Pod se i loro indirizzi cambiano?
• come espongo un’applicazione attraverso un endpoint stabile?
• come gestisco configurazione, storage e permessi?

L’orchestratore interviene su questo livello.

Per questo è più corretto pensarlo come una piattaforma di controllo dei workload che come un semplice programma che avvia container.

K8s e il modello dello stato desiderato

L’abbreviazione K8s deriva dalle otto lettere comprese tra la K iniziale e la s finale di Kubernetes.

Il concetto decisivo, però, non è il nome. È il desired state, cioè lo stato desiderato.

Immagina di dichiarare:

repliche desiderate = 3

Se il cluster ne sta eseguendo soltanto due, il sistema non considera automaticamente accettabile quella situazione. Il controller responsabile confronta stato attuale e configurazione richiesta e prova a creare la replica mancante.

Il meccanismo può essere sintetizzato così:

stato desiderato
↓
osservazione dello stato reale
↓
differenza rilevata
↓
azione correttiva
↓
nuova osservazione

È il modello mentale che rende comprensibili Deployment, ReplicaSet, scheduling e gran parte dell’architettura.

Cosa Kubernetes non è

Kubernetes non sostituisce ogni altro livello della stack.

Non:

• scrive il codice della tua applicazione;
• crea necessariamente le immagini dei container;
• sostituisce il registry;
• rende automaticamente scalabile un’applicazione progettata male;
• corregge bug applicativi o dati corrotti;
• fornisce da solo una strategia completa di CI/CD, logging, backup o sicurezza;
• elimina la necessità di server, rete, storage e capacità di calcolo.

Può coordinare e integrare molti di questi aspetti, ma l’infrastruttura continua a esistere sotto l’astrazione.

Qui nasce uno degli errori di valutazione più frequenti: automatizzare la gestione di un sistema distribuito non significa eliminare la complessità del sistema distribuito.

Come funziona Kubernetes: dal container al workload

Per capire il funzionamento conviene seguire un percorso concreto.

Parti da un’immagine containerizzata. L’immagine viene resa disponibile tramite un registry. Nel cluster non la “avvii” normalmente come oggetto isolato: la riferisci dentro la definizione di un workload, che porta alla creazione di uno o più Pod.

Il control plane registra ciò che hai dichiarato, i controller mantengono il numero e il tipo di risorse richieste, lo scheduler decide dove collocare i Pod e i componenti del nodo fanno effettivamente eseguire i container.

La catena concettuale diventa:

immagine
↓
Pod
↓
workload controller
↓
scheduler
↓
nodo
↓
container runtime

A questa struttura si aggiungono rete, Service, configurazione e storage.

Immagini, container e Pod

La documentazione sui Pod li descrive come la più piccola unità di calcolo distribuibile del sistema.

Un Pod può contenere uno o più container che vengono collocati sullo stesso nodo e condividono alcuni aspetti dell’ambiente di esecuzione, fra cui il contesto di rete.

Nella maggior parte delle applicazioni web semplici trovi un container principale per Pod. Più container nello stesso Pod hanno senso quando devono collaborare molto strettamente e condividere ciclo di vita e risorse locali.

Un punto importante: il Pod non è pensato come una macchina da preservare per sempre.

Può essere sostituito. Può sparire se un nodo fallisce. Può essere ricreato da un controller.

Per questo in produzione normalmente non gestisci manualmente una collezione di Pod “uno per uno”: utilizzi risorse di livello superiore.

Deployment e ReplicaSet: repliche, rollout e self-healing

Un Deployment descrive lo stato desiderato di un insieme di Pod e gestisce gli aggiornamenti tramite ReplicaSet.

Se dichiari due repliche, il controller cerca di mantenerne due compatibili con il template definito nel Deployment.

Se aggiorni l’immagine, può creare progressivamente nuove repliche e ridurre quelle vecchie. Se un Pod gestito scompare, ne viene creato un altro per riportare il workload verso lo stato desiderato.

È una delle forme di self-healing più citate.

Il termine va però interpretato correttamente.

Il sistema può reagire alla perdita di una replica o a determinati problemi di salute del workload; non “ripara” il codice della tua applicazione, non corregge una configurazione sbagliata e non recupera magicamente dati che non hai protetto.

Il vantaggio reale è più preciso: automatizza molte reazioni operative che altrimenti richiederebbero interventi manuali.

Service, rete e accesso alle applicazioni

I Pod sono dinamici. Possono essere creati, distrutti e sostituiti, quindi affidarsi all’indirizzo IP di una singola istanza sarebbe fragile.

Un Service introduce un endpoint logico stabile davanti a un insieme di Pod selezionati.

Questo permette, per esempio, a un frontend di chiamare un backend tramite un nome stabile anche mentre le repliche del backend cambiano.

I tipi di Service più comuni includono:

• ClusterIP, per esporre il servizio all’interno del cluster;
• NodePort, per rendere disponibile una porta sui nodi;
• LoadBalancer, per integrarsi con un load balancer esterno quando l’ambiente lo supporta;
• ExternalName, per mappare un Service a un nome DNS esterno.

Per traffico HTTP e HTTPS proveniente dall’esterno possono entrare in gioco anche Gateway o Ingress, in base all’architettura e all’implementazione scelta.

La distinzione da ricordare è semplice:

i Pod sono istanze dinamiche; il Service fornisce un punto di accesso stabile al gruppo di istanze.

Configurazione e storage persistente

Un’immagine dovrebbe rimanere il più possibile indipendente dalla configurazione specifica dell’ambiente.

Oggetti come ConfigMap permettono di separare configurazioni non riservate dall’immagine, mentre Secret gestisce dati sensibili destinati ai workload.

Per i dati che devono sopravvivere alla sostituzione di un Pod serve invece storage persistente.

L’orchestratore astrae questo problema attraverso volumi e risorse persistenti, mentre l’effettivo storage può essere fornito da sistemi locali, cloud o plugin compatibili.

La distinzione è essenziale: la sostituibilità di un Pod non deve significare perdita dei dati che devono durare più del Pod stesso.

Architettura Kubernetes: control plane e worker node

Un cluster comprende un control plane e uno o più worker node.

La documentazione sui componenti distingue chiaramente questi due livelli.

Il control plane coordina le decisioni globali. I nodi forniscono invece la capacità di calcolo sulla quale vengono eseguiti i Pod.

Non devi pensare al control plane come a un unico “server centrale” monolitico. È un insieme di componenti con responsabilità differenti.

kube-apiserver, etcd, scheduler e controller manager

I componenti fondamentali del control plane includono:

kube-apiserver

Espone l’API del cluster. È il punto attraverso il quale utenti, kubectl, controller e altri componenti leggono o modificano lo stato del sistema.

etcd

È il datastore distribuito key-value nel quale vengono conservati i dati dell’API.

Proprio perché contiene lo stato del cluster, disponibilità e backup di etcd diventano aspetti critici negli ambienti self-managed.

kube-scheduler

Osserva i Pod che non hanno ancora un nodo assegnato e sceglie dove collocarli.

kube-controller-manager

Esegue diversi controller che osservano lo stato delle risorse e cercano di avvicinarlo allo stato desiderato.

Negli ambienti cloud può essere presente anche un cloud-controller-manager, che separa parte dell’integrazione specifica con il provider dai componenti core.

kubelet, container runtime e kube-proxy

Sul worker node entrano in gioco altri componenti.

kubelet è l’agente che si assicura che i Pod assegnati al nodo vengano effettivamente eseguiti secondo la loro specifica.

Il container runtime è il software che esegue i container. Il kubelet comunica con i runtime attraverso la Container Runtime Interface, o CRI.

kube-proxy, quando utilizzato, contribuisce a implementare il comportamento di rete dei Service mantenendo regole sul nodo.

Non è però l’unica architettura possibile: alcune implementazioni di rete possono sostituire parte delle sue funzioni.

Il punto importante è che l’orchestratore non esegue i container “direttamente”. Coordina il sistema; il runtime sul nodo esegue realmente i processi containerizzati.

Come Kubernetes riconcilia continuamente lo stato del cluster

Mettiamo insieme i pezzi.

1. invii una configurazione all’API;
2. kube-apiserver valida e registra la nuova risorsa;
3. un controller nota che lo stato reale non coincide con quello richiesto;
4. vengono creati gli oggetti necessari;
5. lo scheduler trova un nodo adatto per i Pod non assegnati;
6. il kubelet del nodo riceve la specifica;
7. il container runtime esegue i container;
8. lo stato viene riportato all’API;
9. i controller continuano a osservare e intervenire se qualcosa cambia.

Non è un processo che termina definitivamente al punto 9. È un ciclo continuo.

Questa è la differenza tra capire Kubernetes come elenco di componenti e capirlo come sistema di controllo.

Cos’è un cluster Kubernetes

Un cluster Kubernetes è l’insieme coordinato del control plane e dei nodi che forniscono le risorse necessarie a eseguire i workload.

Un ambiente locale di apprendimento può avere un solo nodo. Un cluster di produzione può invece distribuire workload su molti nodi e progettare ridondanza anche per i componenti di controllo.

La parola “cluster”, quindi, non significa automaticamente grande infrastruttura enterprise. Indica il sistema di risorse gestito come un insieme.

Nodi, Pod e risorse del cluster

Un nodo può essere una macchina fisica o virtuale compatibile con l’architettura prevista.

I Pod vengono assegnati ai nodi in base a vincoli e risorse. Da lì consumano CPU, memoria, rete e, quando necessario, storage.

Questo crea tre livelli da non confondere:

cluster → insieme gestito

node → macchina che offre capacità

Pod → unità di workload collocata su un nodo

Un container è ancora un livello più interno: viene eseguito dentro un Pod attraverso il runtime del nodo.

Come lo scheduler decide dove eseguire un Pod

Il kube-scheduler non distribuisce casualmente i Pod.

In termini semplificati, il processo prevede due passaggi principali.

Filtering

Vengono esclusi i nodi che non soddisfano i requisiti del Pod.

Scoring

I nodi rimasti vengono valutati per scegliere il placement più adatto.

Fra i fattori che possono influire ci sono disponibilità di risorse, vincoli hardware o software, affinity e anti-affinity, topology constraints e altre regole di scheduling.

Se nessun nodo è adatto, il Pod può rimanere in attesa invece di essere collocato in un punto incompatibile.

Questo è un esempio concreto del valore dell’orchestrazione: non stai scegliendo manualmente “server 1” o “server 2” per ogni istanza.

Cluster multi-node e alta disponibilità

Aggiungere nodi non rende automaticamente un sistema altamente disponibile.

Per ottenere vera resilienza devi considerare almeno:

• ridondanza del control plane;
• disponibilità dei worker node;
• distribuzione delle repliche;
• rete;
• storage;
• health check;
• load balancing;
• failure domain;
• backup;
• procedure di upgrade e ripristino.

La piattaforma offre i meccanismi con cui costruire resilienza. L’architettura concreta determina se quei meccanismi vengono usati bene.

Kubernetes e Docker: differenze e come lavorano insieme

Kubernetes e Docker vengono spesso presentati come due alternative da mettere una contro l’altra.

È un confronto impreciso.

Docker è un ecosistema di strumenti per costruire, distribuire ed eseguire container. L’orchestratore gestisce invece workload containerizzati su un cluster e coordina scheduling, repliche, aggiornamenti, networking e stato desiderato.

Puoi quindi utilizzare Docker nella fase di sviluppo e build delle immagini e una piattaforma di orchestrazione per l’esecuzione distribuita in produzione.

Docker e Kubernetes non sono concorrenti diretti

Il confronto più utile è questo:

Aspetto	Docker / Docker Compose	Kubernetes
Focus principale	Build ed esecuzione dei container	Gestione dichiarativa dei workload
Ambito tipico	Host singolo e ambienti di sviluppo	Cluster e workload distribuiti
Unità applicativa	Container / servizi Compose	Pod e risorse del cluster
Scheduling multi-node	Non è il ruolo principale di Compose	Funzione centrale
Repliche e riconciliazione	Più limitate	Native nel modello dei controller
Service discovery	Semplice su rete Docker	Service e DNS del cluster
Rolling update	Non equivalente al modello Deployment	Gestito dai workload controller
Complessità operativa	Inferiore	Superiore

Su una singola macchina, Docker Engine e Compose possono risolvere moltissimi casi senza bisogno di un cluster.

Il salto ha senso quando il problema diventa realmente distribuito o quando servono capacità operative che giustificano il costo della piattaforma.

Cosa è cambiato dopo la rimozione di dockershim

Qui circola ancora molta confusione.

Il componente interno dockershim è stato rimosso a partire dalla versione 1.24.

Questo non significa che “Kubernetes non supporta più le immagini Docker”.

La documentazione sui container runtime richiede runtime compatibili con la Container Runtime Interface (CRI).

Runtime come containerd e CRI-O implementano direttamente questa interfaccia.

Docker Engine non implementa CRI nativamente; quando viene utilizzato come runtime di un nodo serve un adapter come cri-dockerd.

La distinzione corretta è:

immagine container ≠ Docker Engine come runtime del nodo

Puoi continuare a costruire un’immagine con Docker, pubblicarla in un registry e farla eseguire nel cluster da un runtime compatibile.

Docker images, containerd, CRI-O e Container Runtime Interface

La CRI evita che il core debba integrare ogni runtime in modo proprietario.

Il kubelet comunica attraverso questa interfaccia e il runtime si occupa dell’esecuzione concreta dei container.

Una pipeline comune può essere:

Dockerfile
↓
docker build
↓
registry
↓
Pod
↓
containerd

Docker ha costruito l’immagine. containerd la esegue sul nodo. Il control plane decide dove e in quali condizioni quel workload deve essere mantenuto.

È una relazione complementare, non una sostituzione uno-a-uno.

A cosa serve Kubernetes: casi d’uso concreti

Kubernetes diventa interessante quando hai un problema di gestione coordinata di workload containerizzati.

Il fatto di usare container, da solo, non basta per giustificarlo.

Applicazioni distribuite e microservizi

Un’architettura a microservizi può generare molti workload indipendenti con esigenze diverse di replica, configurazione, networking e aggiornamento.

Un orchestratore fornisce una base comune per descriverli e gestirli.

Ma non bisogna invertire la relazione:

microservizi possono rendere utile Kubernetes; Kubernetes non rende automaticamente utile un’architettura a microservizi.

Se un monolite soddisfa bene requisiti di prodotto, team e scala, dividerlo solo per poter adottare un orchestratore aumenta la complessità senza un beneficio garantito.

Scalabilità, replica e alta disponibilità

Se un servizio deve eseguire più repliche, il sistema può mantenere il numero desiderato di Pod e distribuire il traffico attraverso un Service.

Puoi inoltre utilizzare meccanismi di autoscaling per adattare replica o capacità in base ai segnali disponibili.

Ma scalare container non equivale a scalare bene l’applicazione.

Database, code, storage, limiti esterni, sessioni e dipendenze devono essere progettati per supportare l’aumento del carico.

L’orchestratore automatizza una parte del problema. Non elimina i colli di bottiglia applicativi.

Deployment progressivi e gestione degli aggiornamenti

I Deployment permettono di sostituire progressivamente una versione del workload con un’altra.

Questo riduce il bisogno di fermare manualmente tutte le istanze e riavviarle insieme.

La capacità di rollout, rollback e controllo dello stato diventa particolarmente utile quando il software viene aggiornato frequentemente e la disponibilità deve essere preservata.

Anche qui, però, la piattaforma non rende sicura qualsiasi release: compatibilità di database, migrazioni, backward compatibility e test continuano a essere responsabilità dell’architettura applicativa.

Workload cloud, ibridi e infrastrutture diverse

La piattaforma può essere eseguita on-premises, su macchine virtuali, bare metal e diversi cloud provider.

Questa portabilità è reale a livello di API e workload, ma non va trasformata nel mito “scrivi una volta e sposta tutto senza costi”.

Load balancer, storage class, identity, networking, GPU, servizi gestiti e integrazioni cloud possono essere molto specifici del provider.

Il modello crea un livello comune. Le dipendenze infrastrutturali restano da progettare.

Vantaggi e limiti di Kubernetes

Kubernetes ha successo perché automatizza problemi difficili e ricorrenti. Proprio per questo può diventare una scelta costosa quando quei problemi non esistono davvero nel tuo progetto.

Vantaggio	Cosa risolve	Costo o limite da considerare
Stato dichiarativo	Riduce gestione manuale delle istanze	Richiede imparare oggetti e controller
Scheduling	Colloca workload sui nodi	Richiede capacity planning e policy
Self-healing	Sostituisce workload mancanti o non sani in diversi scenari	Non corregge bug e dati
Scaling	Gestisce repliche e può automatizzare ridimensionamenti	L’app deve essere scalabile
Service discovery	Stabilizza l’accesso a Pod dinamici	Il networking va progettato
Rolling update	Automatizza sostituzione progressiva dei Pod	Non elimina rischi applicativi e migrazioni
Portabilità	API e modello comuni fra ambienti	Storage, rete e servizi cloud possono creare lock-in operativo
Estensibilità	Ampio ecosistema e API	Aumenta superficie operativa e competenze richieste

Cosa Kubernetes automatizza davvero

Kubernetes è molto efficace nel mantenere invarianti operativi dichiarati:

• numero desiderato di repliche;
• placement dei Pod;
• stato dei workload;
• esposizione tramite Service;
• rollout di Deployment;
• riconciliazione delle risorse gestite dai controller.

Questo sposta il lavoro umano dalla gestione ripetitiva di singole istanze alla progettazione delle regole del sistema.

È un vantaggio enorme quando hai abbastanza scala o complessità da giustificarlo.

La complessità che non scompare

Anche dopo aver introdotto un orchestratore restano da prendere decisioni su:

• dimensionamento;
• rete;
• storage;
• accessi e RBAC;
• gestione dei Secret;
• backup;
• logging e monitoring;
• aggiornamenti;
• policy;
• costi;
• disaster recovery;
• sicurezza delle immagini;
• affidabilità dell’applicazione.

In un cluster self-managed devi inoltre occuparti molto più direttamente della piattaforma stessa.

Se esegui l’orchestratore sopra macchine virtuali, il livello di Infrastructure as a Service continua a esistere: compute, rete e storage non scompaiono perché sopra hai aggiunto un layer di gestione.

Quando Kubernetes è eccessivo

Kubernetes può essere overkill quando hai:

• una sola applicazione relativamente semplice;
• pochi container su un singolo server;
• un team senza capacità operativa dedicata;
• requisiti di disponibilità modesti;
• workload che una PaaS o un servizio serverless può gestire con meno complessità;
• poca necessità di controllo sul livello di orchestrazione.

La domanda corretta non è “Kubernetes è potente?”.

Lo è.

La domanda utile è:

il valore dell’automazione ottenuta supera il costo di possedere, mantenere e comprendere la piattaforma?

Docker Compose, Kubernetes o Kubernetes gestito: cosa scegliere

Non esiste una scala di maturità obbligatoria nella quale ogni progetto debba passare da Docker a Kubernetes.

Sono strumenti con costi e responsabilità differenti.

Scenario	Docker Compose	Kubernetes self-managed	Kubernetes gestito
Sviluppo locale	Ottimo fit	Utile per simulare il target, ma più complesso	Raramente necessario
Piccola app su un server	Spesso sufficiente	Frequentemente eccessivo	Spesso eccessivo
Più servizi su più nodi	Limitato	Forte fit	Forte fit
Repliche e rollout frequenti	Possibile con tool aggiuntivi	Forte fit	Forte fit
Alta disponibilità del cluster	Non è il suo obiettivo	Possibile, ma impegnativa	Parte dell’operatività viene delegata
Team con poca esperienza K8s	Semplice	Rischio operativo alto	In genere più sensato
Controllo profondo dell’infrastruttura	Alto sul singolo host	Molto alto	Dipende dal servizio
Minimo overhead operativo	Forte	Debole	Intermedio, variabile per provider

Quando basta Docker Compose

Docker Compose ha molto senso quando devi descrivere e avviare un’applicazione composta da più container su un ambiente relativamente semplice.

Per sviluppo, test, demo, piccoli deployment e servizi ospitati su un singolo host può essere una scelta più trasparente.

Non hai un control plane dedicato, non devi mantenere un cluster e il modello operativo è più piccolo.

Quando un cluster Kubernetes diventa giustificato

Il salto diventa più razionale quando più esigenze compaiono insieme:

• workload distribuiti;
• repliche su più nodi;
• aggiornamenti frequenti;
• necessità di scheduling;
• alta disponibilità;
• team o piattaforma che possono gestire il cluster;
• standardizzazione di molti servizi;
• bisogno di API e policy comuni.

Una sola di queste esigenze non è necessariamente sufficiente. È il loro peso combinato a cambiare la decisione.

Quando conviene delegare parte della gestione al cloud

Se il cluster serve davvero ma non vuoi possedere completamente control plane e infrastruttura, un servizio gestito riduce una parte dell’overhead.

Questo non rende l’orchestrazione “semplice” in assoluto.

Ti lascia comunque responsabilità su workload, configurazione, sicurezza applicativa, utilizzo delle risorse e spesso una parte significativa di networking e storage.

Riduce però il numero di componenti della piattaforma che devi operare direttamente.

Kubernetes self-managed e managed Kubernetes

Puoi installare e amministrare direttamente Kubernetes oppure utilizzare un provider che gestisce parte del cluster.

La differenza più utile non è il marchio del servizio, ma il confine delle responsabilità.

Gestire direttamente il cluster con kubeadm

Per un cluster amministrato in autonomia, la documentazione ufficiale di setup indica kubeadm come uno degli strumenti supportati per predisporre il sistema.

Questo approccio lascia molto controllo, ma anche molte responsabilità:

• configurazione del control plane;
• disponibilità;
• upgrade;
• certificati;
• runtime;
• rete del cluster;
• integrazione storage;
• backup di etcd;
• sicurezza del nodo;
• monitoraggio della piattaforma.

È molto diverso dall’avviare un cluster locale per imparare.

Per produzione, il self-managed ha senso quando esistono requisiti di controllo specifici e competenze sufficienti a sostenere operativamente la scelta.

EKS, GKE e AKS: cosa significa managed Kubernetes

Tra i servizi gestiti più noti ci sono:

• Amazon Elastic Kubernetes Service, EKS;
• Google Kubernetes Engine, GKE;
• Azure Kubernetes Service, AKS.

Questi servizi riducono il lavoro necessario per gestire il control plane rispetto a un’installazione completamente self-managed.

Alcune modalità spostano inoltre al provider una parte crescente della gestione dei nodi, degli upgrade e dell’infrastruttura.

Non significa che siano equivalenti o che trasferiscano le stesse responsabilità.

Per confrontarli devi guardare concretamente:

control plane
→ worker node
→ networking
→ storage
→ autoscaling
→ upgrade
→ osservabilità
→ sicurezza
→ costi

È lo stesso criterio utile per distinguere le diverse forme di Containers as a Service: l’etichetta dice meno della divisione effettiva del lavoro tra provider e cliente.

Kubernetes e CaaS: dove cambia la responsabilità operativa

Kubernetes è tecnologia. CaaS descrive un modello di consumo del servizio container.

Puoi installare l’orchestratore su macchine che amministri tu: in questo caso possiedi praticamente tutta la piattaforma.

Puoi utilizzare un servizio Kubernetes gestito: il provider prende in carico almeno una parte del cluster.

Puoi infine scegliere servizi container ancora più astratti nei quali il concetto stesso di nodo o control plane diventa quasi invisibile all’utente.

La continuità è questa:

self-managed
↓
managed control plane
↓
managed nodes
↓
container platform fortemente astratta

Più ti sposti verso il fondo, meno infrastruttura gestisci direttamente; in cambio accetti un modello più opinionated e una dipendenza maggiore dalle scelte del provider.

Come iniziare con Kubernetes senza complicarsi

Il modo peggiore di imparare Kubernetes è iniziare costruendo subito un cluster di produzione ad alta disponibilità.

Prima devi capire il modello.

La guida ufficiale agli ambienti di apprendimento suggerisce strumenti locali come kind e minikube, oltre a kubectl per interagire con il cluster.

kubectl: come si comunica con il cluster

kubectl è la CLI principale per inviare richieste all’API.

Puoi usarla per:

• applicare manifest;
• vedere Pod e Deployment;
• ispezionare eventi;
• leggere log;
• modificare o eliminare risorse;
• controllare rollout.

È importante capire che kubectl non “è Kubernetes”.

È un client che parla con l’API del cluster.

kind e minikube per imparare in locale

kind crea cluster utilizzando container come nodi ed è particolarmente leggero per test e apprendimento.

minikube crea invece un ambiente locale pensato per sviluppo e studio.

Per un primo contatto entrambi evitano di aggiungere subito provisioning cloud, bilanciatori, account IAM, costi e alta disponibilità.

Prima impari:

Pod
↓
Deployment
↓
Service
↓
kubectl

Poi aggiungi il resto.

Dal primo Deployment al primo Service

Una volta disponibile un cluster di test, puoi applicare un manifest minimo come questo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-web
  template:
    metadata:
      labels:
        app: demo-web
    spec:
      containers:
        - name: web
          image: nginx:alpine
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: demo-web
spec:
  selector:
    app: demo-web
  ports:
    - port: 80
      targetPort: 80

Salvalo, per esempio, come app.yaml e applicalo:

kubectl apply -f app.yaml
kubectl get deployment
kubectl get pods
kubectl get service

Questo piccolo esempio contiene già gran parte del modello mentale:

• il Deployment dichiara due repliche;
• il controller crea i Pod necessari;
• lo scheduler decide su quale nodo collocarli;
• il kubelet e il runtime li eseguono;
• il Service crea un endpoint stabile davanti ai Pod selezionati.

Non hai ancora costruito un’applicazione production-ready, ma hai attraversato la catena fondamentale dell’orchestrazione.

FAQ su Kubernetes

Kubernetes è gratuito?

Il software Kubernetes è open source e distribuito con licenza Apache 2.0.

Questo non significa che eseguire un cluster sia gratis.

Devi comunque pagare o possedere compute, storage, rete, traffico, osservabilità e competenze operative. Nei servizi managed possono inoltre esistere costi specifici del control plane o della gestione.

Quindi:

il software può essere usato senza licenza commerciale; infrastruttura e operatività hanno comunque un costo.

Serve Docker per usare Kubernetes?

No.

I nodi richiedono un container runtime compatibile con CRI. containerd e CRI-O sono due esempi comuni.

Puoi però continuare a usare Docker per costruire le immagini che poi eseguirai nel cluster.

Che cosa significa K8s?

K8s è l’abbreviazione di Kubernetes.

Il numero 8 rappresenta le otto lettere comprese tra la K iniziale e la s finale.

È soltanto una forma abbreviata: non indica una versione o una tecnologia differente.

Kubernetes è utile solo con i microservizi?

No.

Può gestire workload stateless, stateful, job batch e applicazioni di vario tipo.

I microservizi sono un caso frequente perché creano molti componenti indipendenti da distribuire e gestire, ma un’applicazione non deve essere suddivisa in microservizi per poter utilizzare un orchestratore.

E soprattutto il contrario non è vero: adottare Kubernetes non è un motivo sufficiente per trasformare un monolite in microservizi.

Qual è la differenza tra kubectl e kubeadm?

kubectl è il client a riga di comando utilizzato per interagire con un cluster attraverso la sua API.

kubeadm è invece uno strumento per creare e gestire la configurazione di base di un cluster self-managed.

In sintesi:

kubectl → usa e amministra le risorse del cluster

kubeadm → aiuta a predisporre il cluster

Conclusione

Kubernetes ha senso quando il problema non è più avviare qualche container, ma mantenere nel tempo lo stato di un sistema containerizzato distribuito.

Il suo valore nasce da un modello preciso: dichiari lo stato desiderato, il control plane osserva il cluster e una serie di controller prova continuamente a riconciliare realtà e configurazione.

Pod, Deployment, Service, scheduler e nodi sono pezzi dello stesso meccanismo, non definizioni indipendenti da memorizzare.

È anche il criterio migliore per decidere se adottarlo.

Se stai gestendo pochi container su una sola macchina, Docker Compose può essere più semplice e sufficiente.

Se devi coordinare repliche, nodi, rollout, disponibilità e policy su molti workload, un orchestratore offre un livello di automazione molto più adatto.

Se il cluster serve ma non vuoi amministrarne ogni componente, managed Kubernetes sposta parte dell’operatività verso il provider.

La scelta giusta, quindi, non è usare la tecnologia più potente. È usare il livello di orchestrazione che risolve problemi reali senza introdurre più complessità di quella che il progetto può sostenere.