---
title: "Kubernetes e Docker: differenze e come lavorano insieme"
description: "Non sono due alternative: uno costruisce ed esegue i container, l'altro li coordina su molte macchine. Cosa fa ciascuno e quando serve davvero il secondo."
url: "https://www.alemasone.com/it/kubernetes-e-docker-differenze/"
language: "it"
published: 2026-04-04
updated: 2026-09-20
categories: ["Programmazione E Sviluppo"]
translations:
  en: "https://www.alemasone.com/en/kubernetes-vs-docker-differences-how-they-work/"
  es: "https://www.alemasone.com/es/diferencias-kubernetes-y-docker/"
  fr: "https://www.alemasone.com/fr/difference-kubernetes-docker-orchestration/"
  pt: "https://www.alemasone.com/pt/diferencas-kubernetes-e-docker-como-funciona/"
  de: "https://www.alemasone.com/de/kubernetes-vs-docker-unterschiede-zusammenarbeit/"
---

# Kubernetes e Docker: differenze e come lavorano insieme

Chiedersi se usare [Kubernetes](https://kubernetes.io/) o [Docker](https://www.docker.com/) è un po' come chiedersi se comprare un camion o costruire un porto. **Docker crea e fa girare i container. Kubernetes coordina centinaia di container su decine di macchine.** Lavorano a due livelli diversi e spesso si usano insieme. Oppure si usa solo Docker, perché il problema che risolve Kubernetes molti progetti non ce l'hanno.

Per capire la differenza aiuta il paragone con il trasporto merci, da cui questi strumenti hanno preso in prestito nomi e logo: la balena di Docker carica container, il timone di Kubernetes (in greco *kubernetes* vuol dire proprio «timoniere») li guida.

## Il container e il porto

**Il container** è una scatola standard. Dentro metti l'applicazione, le sue librerie e la versione esatta del linguaggio che le serve. Da fuori è sempre la stessa scatola, con gli stessi agganci: chi la sposta non deve sapere cosa c'è dentro. Così sparisce il classico «sul mio computer funziona».

A differenza di una macchina virtuale, un container non si porta dietro un sistema operativo intero: usa il kernel del sistema che lo ospita. Per questo parte in un secondo e pesa decine di megabyte invece di gigabyte. In cambio è meno isolato di una VM, e un container Linux ha bisogno di un kernel Linux.

**Docker** è l'officina che costruisce la scatola e la gru che la carica sul camion. Scrivi le istruzioni in un **Dockerfile**, Docker produce un'**immagine** e la fa girare con il **Docker Engine**. Le immagini pronte le trovi su **[Docker Hub](https://hub.docker.com/)**, il registro pubblico più usato.

![Schema che confronta macchine virtuali con sistema operativo completo e container appoggiati a un solo kernel](architettura-container-e-virtuali-kubernetes-docker.png "Il container condivide il kernel: è questo che lo rende leggero")

**Kubernetes** è il porto. Non costruisce scatole e non le apre: decide **su quale nave va ciascuna**, quante copie dello stesso carico tenere in giro, cosa fare quando una nave affonda e come smistare i camion in arrivo verso il molo giusto. Se una scatola cade in mare, ne carica subito un'altra identica e nessuno se ne accorge.

In pratica un cluster Kubernetes ha un **control plane**, che prende le decisioni, e dei **nodi** (le macchine) che eseguono il lavoro. I container girano dentro i **pod**, l'unità più piccola che Kubernetes gestisce: di solito un pod contiene un container, a volte due o tre che devono stare insieme.

Un porto con tre container è un piazzale con tre scatole: organizzarlo costa più del problema che risolve. Per questo tanti progetti stanno benissimo con il solo Docker.

![Schema di un cluster Kubernetes con il control plane e i nodi worker che ospitano pod e container](architettura-kubernetes-e-docker.png "Il control plane decide, i nodi eseguono")

## Cosa fa ciascuno

| | Docker | Kubernetes |
|---|---|---|
| Ambito | Una macchina | Molte macchine insieme |
| Compito | Costruire ed eseguire container | Distribuirli, sorvegliarli, sostituirli |
| Problema che risolve | «Funziona ovunque allo stesso modo» | «Resta in piedi e regge il carico» |
| Difficoltà | L'essenziale lo impari in un pomeriggio | Settimane, e non si finisce mai |
| Quando serve | In quasi tutti i progetti | Quando la scala lo richiede |

Kubernetes si giustifica con cinque funzioni. Se non te ne serve nessuna, non ti serve Kubernetes:

- **Riavvio automatico** di quello che smette di funzionare (*self-healing*).
- **Scalabilità**: aumenta e riduce le copie in base al carico.
- **Distribuzione del traffico** fra le copie attive.
- **Aggiornamenti graduali**, che sostituiscono le copie poche alla volta senza interruzioni, con ritorno alla versione precedente se qualcosa va storto.
- **Configurazione dichiarativa**: scrivi in un file YAML lo stato che vuoi e il sistema lavora per mantenerlo, invece di eseguire comandi uno per uno.

## «Kubernetes ha abbandonato Docker»: cosa è successo

Questa notizia torna fuori ogni tanto, e di solito è raccontata male.

Nella versione 1.24, uscita a maggio 2022, Kubernetes ha tolto il *dockershim*, il pezzo che gli permetteva di usare il **motore di Docker** per far girare i container. Oggi usa runtime più leggeri che rispettano lo standard CRI, come **containerd** (che, tra l'altro, è lo stesso motore che Docker usa al suo interno) e **CRI-O**.

Le immagini non c'entrano: quelle create con Docker seguono lo standard aperto OCI e girano identiche su Kubernetes. Per chi sviluppa non è cambiato niente, costruisci con Docker ed esegui su Kubernetes come prima. La modifica ha toccato solo chi amministra i cluster.

## Cosa usare, a seconda di dove sei

**Un'applicazione sola su un server.** Docker e basta: un'immagine, un comando per avviarla e l'opzione `--restart unless-stopped` perché riparta da sola. Aggiungere un orchestratore qui vuol dire avere un secondo sistema da mantenere per gestire una cosa sola.

**Più servizi collegati su una macchina**, per esempio applicazione, database e cache. Qui serve **[Docker Compose](https://docs.docker.com/compose/)**: un file `compose.yaml` descrive tutti i servizi e come si parlano, e `docker compose up` li avvia insieme. Copre l'[ambiente di sviluppo](/it/alternative-a-xampp/) di quasi ogni progetto e tante installazioni in produzione di dimensioni contenute.

**Più macchine, carico che cambia, nessuna interruzione ammessa.** Qui Kubernetes comincia a ripagarsi. Il criterio: se un servizio deve restare in piedi mentre una macchina si rompe, e il numero di copie deve cambiare da solo con il traffico, sei nel posto giusto.

**Le vie di mezzo.** **[k3s](https://k3s.io/)** è un Kubernetes leggero che dà le funzioni essenziali con molta meno complessità, adatto a un paio di macchine o a un Raspberry Pi. **Docker Swarm**, incluso in Docker, mette insieme più macchine con comandi che già conosci. E i servizi gestiti dei grandi fornitori, **Amazon EKS**, **Google GKE** e **Azure AKS**, si occupano del control plane al posto tuo, anche se il modello di Kubernetes devi impararlo comunque. Su AWS c'è anche **ECS**, che fa girare container senza Kubernetes.

> **Impara in quest'ordine.** Prima a costruire un'immagine e a farla girare, poi Compose per qualche servizio su una macchina, solo dopo Kubernetes, in locale con [minikube](https://minikube.sigs.k8s.io/), [kind](https://kind.sigs.k8s.io/) o il cluster integrato in Docker Desktop. Chi salta i primi due passaggi finisce a copiare file YAML che non capisce, ed è da lì che nasce la fama di strumento incomprensibile.

## I costi nascosti

Chi mette Kubernetes su un progetto piccolo scopre presto che il conto non è solo tecnico:

- **Le macchine del cluster consumano** anche senza traffico, perché i componenti di sistema girano comunque.
- **Serve competenza continua**: rete interna, volumi persistenti, gestione delle credenziali, aggiornamenti di versione. Kubernetes pubblica tre versioni l'anno e ognuna è supportata per circa quattordici mesi, quindi non lo installi e te ne dimentichi.
- **Il debug si allunga**: fra il tuo codice e la richiesta dell'utente ci sono più strati, e imparare a leggerli richiede tempo.
- **Docker Desktop è a pagamento per le aziende grandi**: gratis per uso personale, studio e aziende sotto i 250 dipendenti e i 10 milioni di dollari di fatturato, altrimenti serve un abbonamento. Se ti serve un'alternativa aperta ci sono [Podman](https://podman.io/), Rancher Desktop e, su Mac, OrbStack o Colima.

Sono ottimi motivi per non usarlo quando non serve, e nessuno di questi è un motivo per evitarlo quando serve.

> **Chi lo rimette in piedi alle tre di notte?** Conta quante persone nel gruppo saprebbero farlo. Se la risposta è «una», un'infrastruttura complessa è un rischio in più. La disponibilità continua si ottiene con strumenti che il gruppo conosce bene, anche se sono meno potenti.

## Domande frequenti

### Devo imparare Docker prima di Kubernetes?

Sì, e ti fa risparmiare tempo. Kubernetes coordina container: se non sai cos'è un'immagine, come si costruisce e come si avvia, finisci a copiare configurazioni senza sapere cosa fanno.

### Kubernetes può funzionare senza Docker?

Sì, ed è la norma: dal 2022 i cluster usano containerd o CRI-O per far girare i container. Docker però resta lo strumento più comodo per costruire le immagini che poi Kubernetes esegue.

### Qual è la differenza fra container e macchina virtuale?

La [macchina virtuale](/it/migliori-software-macchine-virtuali/) contiene un sistema operativo completo, pesa gigabyte e ci mette un po' ad avviarsi. Il container usa il kernel del sistema che lo ospita, pesa molto meno e parte in un secondo. In cambio è meno isolato, e per far girare container Linux su Windows o Mac serve comunque una piccola macchina virtuale, che [Docker Desktop](/it/virtualizzazione-mac-apple-silicon/) gestisce da solo.

### Kubernetes sostituisce Docker Compose?

Su una macchina sola no, e tanti progetti restano su Compose per sempre. Compose descrive più servizi su un computer, ed è perfetto per lo sviluppo e le installazioni piccole. Kubernetes descrive gli stessi servizi distribuiti su più macchine, con le regole per resistere ai guasti.

### Serve per un sito o un blog?

No, nella stragrande maggioranza dei casi. Un sito statico, un blog o un'applicazione con qualche centinaio di visite al giorno stanno bene su un server con Docker, o anche senza. L'orchestrazione comincia a ripagarsi quando la scala e i requisiti di disponibilità la impongono.

### Quando scegliere Docker Swarm invece di Kubernetes?

Quando hai poche macchine, un gruppo piccolo e vuoi partire in fretta: Swarm si attiva con `docker swarm init` e usa file simili a quelli di Compose. È però molto meno diffuso, con un ecosistema ridotto. Se prevedi di crescere, conviene investire direttamente su Kubernetes, magari partendo da k3s.

### Quanto costa un cluster gestito?

Dipende dal fornitore e dalle dimensioni. La voce principale di solito sono le macchine che lo compongono, sempre accese, più una piccola tariffa oraria per il control plane su alcuni servizi. Un ambiente minimo con ridondanza costa comunque più di un server singolo: fai il conto prima di partire.