Kubernetes: cos’è e come funziona

Cos’è Kubernetes?

Kubernetes (spesso abbreviato in K8s) è la piattaforma open-source diventata lo standard de facto per la gestione dei workload containerizzati su larga scala. Il suo nome deriva dal greco e significa “timoniere” o “pilota” — un’immagine appropriata per uno strumento il cui compito è guidare flotte di container attraverso infrastrutture eterogenee.

Creato originariamente da un team di ingegneri Google e donato alla Cloud Native Computing Foundation (CNCF) nel 2015, Kubernetes è oggi mantenuto da una delle più grandi community open-source al mondo. Secondo la CNCF Annual Cloud Native Survey 2025 (pubblicata a gennaio 2026), l’82% degli utenti di container utilizza ora Kubernetes in produzione, e il 66% delle organizzazioni che eseguono workload di intelligenza artificiale generativa utilizza Kubernetes per gestire parte o tutti i propri workload di inferenza.

Per sysadmin e MSP, la proposta di valore è diretta: un sistema dichiarativo che riconcilia continuamente lo stato desiderato delle applicazioni con il loro stato effettivo, automatizzando tutto, dai rollout al recovery. La release stabile più recente, Kubernetes v1.36 “Haru”, è stata pubblicata il 22 aprile 2026 e conferma la direzione del progetto verso un isolamento più forte, il supporto ai workload AI e una postura di sicurezza più rigorosa di default.

Se ti stai chiedendo come Kubernetes si relaziona con altri strumenti per container, consulta la nostra guida completa: Docker vs Kubernetes nel 2026: in cosa differiscono e come lavorano insieme.

Architettura di un cluster Kubernetes

Ogni deployment Kubernetes è organizzato come un cluster, composto da due livelli principali:

• Il control plane: l’insieme di componenti che gestiscono lo stato complessivo del cluster — quali applicazioni devono essere in esecuzione, quali immagini container utilizzano e come vengono allocate le risorse.
• I worker node: le macchine (fisiche o virtuali) dove i workload containerizzati vengono effettivamente eseguiti.

Un cluster di livello production è progettato per essere:

• Ad alta disponibilità. Il control plane può essere replicato su più macchine per evitare un singolo punto di guasto. In produzione, la best practice è avere almeno tre nodi control plane.
• Dichiarativo. Descrivi lo stato desiderato della tua applicazione in file di configurazione YAML o JSON, e Kubernetes lavora continuamente per far corrispondere lo stato effettivo a quello desiderato. Questi manifest sono tipicamente versionati in Git, costituendo la base di un workflow GitOps.
• Estensibile. Kubernetes non è legato a nessun vendor specifico e supporta risorse personalizzate, operator e plugin per adattarsi a praticamente qualsiasi workload.

Nota terminologica: il termine “master” utilizzato nella documentazione Kubernetes più vecchia è stato sostituito in tutto il progetto da “control plane” dal 2020. Se leggi guide legacy, considera i due termini come equivalenti.

Componenti del control plane

Il control plane è il livello decisionale del cluster. Espone l’API Kubernetes, archivia lo stato del cluster e avvia i controller che riconciliano lo stato desiderato con la realtà. In produzione, i componenti del control plane sono distribuiti su almeno tre nodi per garantire l’alta disponibilità.

kube-apiserver

Il server API è il punto di accesso centrale per tutte le interazioni con il cluster. Ogni comando eseguito con kubectl e ogni comunicazione interna tra i componenti passa attraverso il server API. Valida e processa le richieste RESTful, gestisce l’autenticazione e l’RBAC, ed è l’unico componente che comunica direttamente con etcd. Aggiorna quindi lo stato del cluster di conseguenza.

etcd

etcd è un datastore distribuito e coerente di tipo key-value che funge da unica fonte di verità per l’intero stato del cluster — inclusi i dati di configurazione, lo stato dei nodi e dei pod, i secret e le informazioni di service discovery. Perdere etcd significa perdere lo stato del cluster, motivo per cui eseguire backup regolari di etcd e crittografarlo at rest sono requisiti operativi critici negli ambienti di produzione.

kube-scheduler

Lo scheduler monitora i pod appena creati che non hanno un nodo assegnato e seleziona il nodo migliore per ciascun pod in base ai requisiti di risorse, ai vincoli hardware, alle regole di affinità/anti-affinità, ai taint, alle toleration e ad altre policy di scheduling.

kube-controller-manager

Il controller manager esegue un insieme di loop di controllo che monitorano continuamente lo stato del cluster e intraprendono azioni correttive. I controller principali includono:

• Node controller: monitora lo stato di salute dei nodi e risponde quando i nodi diventano irraggiungibili.
• ReplicaSet controller: garantisce che il numero desiderato di repliche dei pod sia in esecuzione in ogni momento.
• Endpoint controller: popola gli oggetti endpoint che collegano i Service ai pod.
• Job controller: gestisce i pod che vengono eseguiti fino al completamento (workload batch).

cloud-controller-manager

Il cloud-controller-manager gestisce l’integrazione con il cloud provider sottostante: load balancer, volumi persistenti e ciclo di vita dei nodi. È presente solo nei cluster ospitati su cloud e separa la logica specifica del cloud dai controller principali di Kubernetes.

Componenti dei worker node

Ogni worker node esegue i componenti necessari per avviare e gestire i container e riporta lo stato al control plane.

kubelet

Il kubelet è un agente che viene eseguito su ogni nodo. Registra il nodo presso il control plane, riceve le specifiche dei pod dal server API e assicura che i container descritti in quelle specifiche siano in esecuzione e in stato di salute. Se un container va in crash, il kubelet lo riavvia.

Container runtime

Il container runtime è il software responsabile dell’effettivo download delle immagini e dell’esecuzione dei container. Kubernetes richiede un runtime che implementi la Container Runtime Interface (CRI). I due runtime più utilizzati sono:

• containerd — il runtime standard del settore, originariamente estratto da Docker Engine e ora un progetto CNCF graduated. È il runtime predefinito nella maggior parte dei servizi Kubernetes gestiti (EKS, GKE, AKS), in kubeadm e in K3s.
• CRI-O — un runtime leggero costruito specificamente per Kubernetes, utilizzato di default in Red Hat OpenShift.

Nota: Docker Engine era supportato come runtime Kubernetes attraverso un componente chiamato dockershim, che è stato rimosso in Kubernetes 1.24 (maggio 2022). Le immagini Docker restano pienamente compatibili con tutti i runtime conformi a CRI — è cambiata solo l’interfaccia del runtime.

kube-proxy

kube-proxy viene eseguito su ogni nodo e gestisce le regole di rete che abilitano l’astrazione dei Service. Gestisce il service discovery e il load balancing mantenendo regole iptables o IPVS che instradano il traffico verso gli endpoint dei pod corretti, consentendo la comunicazione verso i pod dall’interno e dall’esterno del cluster.

Pod: l’unità distribuibile più piccola

Un pod è l’unità più piccola gestita da Kubernetes. Un pod incapsula uno o più container che condividono lo stesso namespace di rete (indirizzo IP e porte), i volumi di storage e il ciclo di vita. Nella maggior parte dei casi un pod esegue un singolo container, ma i pod multi-container sono utilizzati per pattern come sidecar, init container e raccoglitori di log.

In produzione, i pod non vengono quasi mai creati direttamente. Sono gestiti da oggetti di livello superiore — Deployment, StatefulSet, DaemonSet — che gestiscono replica, rolling update e policy di scheduling.

Puoi creare un pod semplice con un manifest YAML:

apiVersion: v1
kind: Pod

metadata:

  name: my-nginx

spec:

  containers:

  - name: nginx

    image: nginx:alpine

    ports:

    - containerPort: 80

Apply it with:

$ kubectl apply -f my-nginx.yaml

$ kubectl get pods

Gli operatori interagiscono con il cluster attraverso lo strumento a riga di comando kubectl, che invia manifest YAML dichiarativi al kube-apiserver.

Come funziona il tutto in Kubernetes

Ecco cosa succede quando distribuisci un’applicazione su un cluster Kubernetes:

1. Invii un manifest di deployment al server API (tramite kubectl apply).
2. Il server API valida la richiesta e archivia lo stato desiderato in etcd.
3. Lo scheduler rileva i nuovi pod senza un nodo assegnato e seleziona il nodo migliore per ciascuno.
4. Il kubelet sul nodo selezionato scarica l’immagine container e avvia il container tramite il container runtime.
5. Il controller manager monitora continuamente lo stato in esecuzione. Se un pod va in crash o un nodo fallisce, crea pod sostitutivi per corrispondere allo stato desiderato.
6. kube-proxy aggiorna le regole di rete in modo che il traffico possa raggiungere i nuovi pod.

Questo loop di riconciliazione viene eseguito continuamente — Kubernetes non si limita a distribuire la tua applicazione, la mantiene attivamente.

Quali sono i vantaggi di Kubernetes nel 2026?

La promessa originale di Kubernetes — orchestrare container su più host, automatizzare i deployment, gestire lo scaling — resta valida. Ciò che è cambiato nel 2026 è la maturità e l’ampiezza di ciò che è disponibile out of the box.

Infrastruttura dichiarativa e self-healing. L’intero stato desiderato del cluster vive in manifest YAML, versionati in Git e riconciliati automaticamente. I pod in errore vengono riavviati, i nodi in errore drenati, la capacità regolata da HPA, VPA e Cluster Autoscaler (o Karpenter su EKS) senza intervento dell’operatore.

Portabilità dei workload. Gli stessi manifest funzionano su EKS, GKE, AKS, OpenShift, cluster kubeadm on-premises o K3s all’edge. Nessun’altra piattaforma offre una portabilità paragonabile — un argomento concreto per gli MSP che gestiscono ambienti eterogenei dei clienti.

Postura di sicurezza moderna. Dalla v1.25, il controller Pod Security Admission applica i Pod Security Standard (Privileged, Baseline, Restricted) tramite label sui namespace. Nella v1.36, gli User Namespace sono passati a Stable, fornendo un livello critico di defence-in-depth che mappa il root del container su un utente non privilegiato sull’host — una mitigazione attesa da tempo contro le vulnerabilità di container breakout.

Workload AI e ML come cittadini di prima classe. La Dynamic Resource Allocation (DRA) è passata a GA nella v1.34 e ha continuato a maturare attraverso la v1.36 con ulteriori funzionalità che hanno raggiunto lo stato stable, rendendo Kubernetes la piattaforma standard per lo scheduling GPU, il gang scheduling per il training distribuito e l’inference serving.

Un ecosistema di servizi gestiti. Amazon EKS, Google GKE e Azure AKS eliminano l’onere di gestire il control plane e si integrano nativamente con l’identità cloud (IRSA, Workload Identity, Entra ID), rendendoli la scelta predefinita per organizzazioni e MSP senza team dedicati alla piattaforma. Per un confronto dettagliato, leggi il nostro articolo sui servizi Kubernetes Cloud.

Un ecosistema operativo maturo. Observability (Prometheus, Grafana, OpenTelemetry), GitOps (Argo CD, Flux), backup (Velero), policy enforcement (Kyverno, OPA Gatekeeper) e service mesh (Istio, Linkerd, Cilium) sono tutti progetti open-source di livello production sotto la supervisione attiva della CNCF.

Cosa significa questo per sysadmin e MSP

Kubernetes nel 2026 è una piattaforma matura, con sicurezza rafforzata e pronta per l’AI — ma una piattaforma che richiede una disciplina operativa costante. Il progetto segue un ciclo di rilascio di quattro mesi e una policy di supporto N−2: le branch supportate sono v1.34, v1.35 e v1.36, mentre la v1.33 resta in modalità di manutenzione fino alla fine del ciclo di vita il 28 giugno 2026. Rimandare gli aggiornamenti non è più una strategia praticabile, e una migrazione critica è ora nella roadmap di tutti — il progetto community Ingress NGINX è stato ufficialmente ritirato da marzo 2026, con la Gateway API come successore raccomandato per la gestione del traffico.

Per sysadmin e MSP, il caso operativo poggia su tre punti:

• Infrastruttura dichiarativa che scala senza far crescere il team.
• Portabilità dei workload in qualsiasi ambiente.
• Un ecosistema abbastanza maturo da erogare servizi di piattaforma ai clienti con margini che semplicemente non erano possibili un decennio fa.

Se gestisci cluster Kubernetes in produzione, proteggere i tuoi dati è fondamentale — in particolare lo stato di etcd e i volumi persistenti. Uranium Backup supporta il backup di macchine virtuali, database e dell’infrastruttura che alimenta i tuoi ambienti containerizzati.

Domande frequenti su Kubernetes

Quali sono i principali componenti di Kubernetes?

Kubernetes è composto da un control plane (kube-apiserver, etcd, kube-scheduler, kube-controller-manager) e worker node che eseguono kubelet, kube-proxy e un container runtime. Il runtime predefinito dalla versione 1.24 di Kubernetes è containerd.

Qual è la differenza tra Docker e Kubernetes?

Docker è uno strumento per costruire e avviare singoli container. Kubernetes è una piattaforma di orchestrazione che gestisce flotte di container su più host, gestendo automaticamente scheduling, scaling, self-healing e rolling update.

Quali versioni di Kubernetes sono supportate nel 2026?

A metà 2026, le branch supportate sono v1.34, v1.35 e v1.36 (l’ultima release stabile). Kubernetes segue una policy di supporto N-2 con un ciclo di rilascio di 4 mesi. La v1.33 raggiunge la fine del ciclo di vita il 28 giugno 2026.

Kubernetes è adatto per gli MSP?

Sì, in particolare attraverso servizi gestiti come Amazon EKS, Google GKE e Azure AKS, che eliminano l’onere della gestione del control plane. Il vantaggio principale per gli MSP è la portabilità dei workload: gli stessi manifest funzionano su diversi cloud provider e ambienti on-premises senza modifiche.