Docker vs Kubernetes: vediamo in cosa differiscono

Sentiamo ancora regolarmente la domanda: è meglio usare Docker o Kubernetes? È uno dei malintesi più persistenti nell’ecosistema dei container.

La risposta breve è: Docker e Kubernetes non sono concorrenti diretti. Si trovano a livelli diversi dello stesso stack e la maggior parte degli ambienti di produzione li utilizza entrambi. Ciò che è cambiato è l’ecosistema intorno a loro: Kubernetes ha rimosso il dockershim, containerd è diventato il runtime de facto, Docker ha rilasciato una release importante con Engine v29.

Questa guida aggiornata è scritta per sysadmin e MSP che hanno bisogno di un quadro aggiornato e accurato di dove si trovano queste due tecnologie nel 2026 e come scegliere tra di esse.

Cos’è Docker?

Docker è una piattaforma di containerizzazione: un insieme di strumenti che consente di costruire immagini container, eseguirle come processi isolati su un host (container) e condividerle tramite registry come Docker Hub o un registry privato conforme a OCI.

Il componente principale è il Docker Engine, un’applicazione client/server composta da:

• un processo daemon a lunga esecuzione (dockerd),
• una REST API per interagire con il daemon,
• la CLI docker.

Sotto il daemon, Docker utilizza containerd come runtime di basso livello da diversi anni. Con Docker Engine v29, rilasciato alla fine del 2025, questo allineamento è stato completato: il containerd image store è ora il predefinito per le nuove installazioni, e Docker ha ufficialmente alzato la versione minima dell’API a 1.44 (Moby v25), rendendo obsolete le versioni precedenti alla 25. Per i sysadmin questo è importante perché il nuovo daemon rifiuterà di accettare client con API 1.43 o inferiore a meno che DOCKER_MIN_API_VERSION non venga esplicitamente sovrascritto.

Nel lavoro quotidiano, Docker nel 2026 è ancora lo strumento di riferimento per:

• Costruire immagini container da un Dockerfile.
• Avviare singoli container o stack multi-container locali tramite Docker Compose.
• Workflow lato sviluppatore su workstation (Docker Desktop su Windows, macOS e Linux).
• Pubblicare immagini conformi OCI su registry che verranno poi scaricate dagli orchestratori.

Vale la pena notare per i sysadmin che lavorano su distribuzioni derivate da Red Hat: Podman, il container engine senza daemon e rootless mantenuto da Red Hat, è diventato lo strumento container predefinito su RHEL, Fedora, Rocky Linux e AlmaLinux. È in gran parte compatibile con la CLI di Docker (alias docker=podman è un punto di partenza comune) e produce immagini OCI che funzionano in modo identico in Kubernetes. Per i workflow basati su Docker non è necessario cambiare, ma sugli host della famiglia RHEL Podman è ciò che troverai preinstallato.

Docker rimane lo strumento di build dominante e il formato di immagine OCI che Docker ha reso popolare è consumato da praticamente ogni orchestratore sul mercato, Kubernetes incluso.

Cos’è Kubernetes?

Kubernetes (K8s) è una piattaforma open-source di orchestrazione di container, sviluppata originariamente da Google e ora mantenuta dalla Cloud Native Computing Foundation (CNCF). Fornisce un’API dichiarativa che descrive cosa si vuole in esecuzione (quali workload, quante repliche, su quali nodi, esposti come) e un loop di controllo che riconcilia continuamente lo stato del cluster con quello stato desiderato.

Kubernetes gestisce la complessità operativa che emerge quando si scalano container su più host: scheduling, service discovery, load balancing, rolling update, self-healing, gestione di secret e configurazioni, autoscaling orizzontale, astrazione dello storage e applicazione delle network policy.

Cadenza delle release e versioni supportate

Kubernetes segue una cadenza di rilascio di circa quattro mesi (circa tre versioni minori all’anno) con una policy di supporto N-2: solo le tre versioni minori più recenti ricevono fix di sicurezza e bug, per una finestra di supporto totale di circa 14 mesi per release.

A metà 2026, le versioni supportate sono:

Versione	Ultima patch	Stato	Fine del ciclo di vita
1.37	1.37.0	Stabile attuale	2027-10-28
1.36	1.36.4	Stabile attuale	2027-06-28
1.35	1.35.8	Supportata	2027-02-28
1.34	1.34.11	Maintenance mode (solo fix critici)	2026-10-27

Con Kubernetes 1.37 rilasciato il 26 agosto 2026, la versione 1.34 è entrata in maintenance mode il 27 agosto 2026 ed esce dai branch attivamente mantenuti una volta raggiunta la fine del ciclo di vita il 27 ottobre 2026; qualsiasi versione 1.33 o precedente dovrebbe già essere considerata un rischio di sicurezza in qualsiasi ambiente di cui sei responsabile. Verifica sempre lo stato di supporto aggiornato su kubernetes.io/releases prima di pianificare un aggiornamento.

Il container runtime: containerd, non Docker

I nodi Kubernetes hanno bisogno di un container runtime conforme a CRI per avviare effettivamente i container nei pod. A partire da Kubernetes v1.24 (maggio 2022) il dockershim integrato è stato rimosso: kubelet comunica ora direttamente con il runtime tramite la Container Runtime Interface (CRI), e i runtime dominanti sono containerd e CRI-O.

Questa è una delle fonti di confusione più comuni nel 2026. “Kubernetes ha rimosso Docker” non significa che Kubernetes non possa più eseguire immagini create con Docker – può farlo, perché quelle immagini sono conformi a OCI e qualsiasi runtime CRI le comprende. Significa che Kubernetes non include più un livello di traduzione per utilizzare il Docker Engine completo come runtime. Il runtime CRI (containerd, CRI-O, o il cri-dockerd mantenuto da Mirantis se davvero ne hai bisogno) sostituisce quel ruolo.

Per i sysadmin oggi questo è per lo più un non-problema: ogni servizio gestito (EKS, GKE, AKS) è containerd-only da anni, e anche i cluster self-managed costruiti con kubeadm utilizzano containerd come predefinito.

Allora perché la domanda “Docker vs Kubernetes” continua a emergere?

Due motivi.

Primo, Docker ha storicamente distribuito il proprio orchestratore, Docker Swarm, che era un’alternativa diretta a Kubernetes. Quindi a un certo punto il confronto era tecnicamente valido – ma solo per l’orchestrazione. Torneremo su Swarm tra poco.

Secondo, Docker Desktop include un cluster Kubernetes locale a nodo singolo, e molti sviluppatori imparano entrambi gli strumenti contemporaneamente. Il risultato è che “Docker” e “Kubernetes” finiscono per essere menzionati insieme come se fossero intercambiabili, anche se vivono a livelli diversi:

Livello	Strumento
Formato immagine e registry	OCI / Docker Hub / registry privati
Build dell’immagine	Docker, Buildah, Kaniko, BuildKit
Container runtime (basso livello)	containerd, CRI-O, runc
Runtime single-host + tooling	Docker Engine
Orchestrazione multi-host	Kubernetes, Docker Swarm

Docker opera sui tre livelli inferiori. Kubernetes vive in cima.

Dove si inserisce Docker Swarm nel 2026

Docker Swarm è la modalità di orchestrazione nativa di Docker, integrata direttamente in Docker Engine e gestita tramite la CLI Docker standard. Un cluster viene inizializzato con un singolo `docker swarm init`, i servizi vengono distribuiti utilizzando lo stesso formato Compose file che gli sviluppatori già conoscono, e il modello operativo è volutamente minimale: nodi manager, nodi worker, servizi, task. Nessun control plane separato da installare, nessun manifest YAML oltre a Compose, nessun CRD.

Per anni questo ha reso Swarm l’alternativa “leggera” ovvia a Kubernetes. Nel 2026 il quadro è più sfumato. Swarm è ancora mantenuto, viene ancora distribuito con Docker Engine e ancora esegue workload in produzione – ma ha ricevuto pochissime nuove funzionalità rispetto al ritmo dell’ecosistema Kubernetes, e il ruolo di “orchestratore semplice per piccoli cluster” è stato in gran parte assunto da distribuzioni Kubernetes leggere come K3s e MicroK8s (trattate più avanti in questa guida).

Per un sysadmin o MSP che valuta Swarm oggi, il riassunto onesto è questo:

• Scelta ragionevole per ambienti piccoli e stabili dove la semplicità è l’obiettivo: pochi servizi su due o tre nodi, strumenti interni, homelab, o ambienti dove il team già conosce Docker e non vuole addossarsi la complessità operativa di Kubernetes.
• Non la scelta predefinita per nuovi progetti di dimensioni significative, deployment multi-tenant, o qualsiasi cosa che necessiti dell’ecosistema CNCF più ampio (Helm chart, operator, service mesh, tooling GitOps come Argo CD o Flux).
• Vale la pena tenere a mente se si eredita un cluster Swarm esistente: non è rotto e non è necessariamente urgente migrarlo, ma i nuovi investimenti è meglio dirigerli altrove.

Kubernetes è molto più complesso di Swarm e offre funzionalità di gran lunga superiori, soprattutto in termini di scala, primitive di sicurezza ed ecosistema circostante. Il trade-off è lo stesso del 2022 — semplicità vs. capacità – ma il centro di gravità dell’industria si è chiaramente spostato.

Come Docker e Kubernetes lavorano effettivamente insieme

In una pipeline tipica del 2026 le due tecnologie sono sovrapposte, non alternative:

1. Build. Uno sviluppatore scrive un Dockerfile e usa Docker (o BuildKit) per costruire un’immagine OCI localmente.
2. Test. L’immagine viene eseguita localmente tramite docker run o docker compose, oppure sul cluster Kubernetes a nodo singolo incluso in Docker Desktop.
3. Push. La CI pubblica l’immagine su un registry (Docker Hub, GHCR, ECR, GAR, Harbor, Artifactory).
4. Deploy. Uno strumento nativo Kubernetes (kubectl, Helm, Argo CD, Flux) distribuisce l’immagine su un cluster.
5. Esecuzione. Kubernetes scarica l’immagine tramite containerd su ogni nodo e la esegue all’interno dei pod, gestendo scheduling, scaling, health check e rollout.

Docker domina i passi 1-2; Kubernetes domina i passi 4-5; il registry nel passo 3 è neutro rispetto alla tecnologia.

Scegliere lo strumento giusto: una guida pratica per sysadmin e MSP

Per il tipo di pubblico per cui scriviamo solitamente su The Solving – amministratori di sistema, MSP, team IT che gestiscono ambienti eterogenei di clienti — la domanda è raramente “Docker o Kubernetes?” in isolamento. È più spesso “quanta orchestrazione mi serve davvero, e dove la eseguo?”

Usa Docker da solo quando

• Un workload gira su un singolo host e non hai bisogno di failover automatico tra nodi.
• Stai impacchettando un’applicazione da distribuire ai clienti come immagine container senza prescrivere come la orchestrano.
• Stai eseguendo workload di utilità su una workstation di sysadmin o un piccolo server: un DNS privato, un endpoint Wireguard, un’istanza Vaultwarden, qualche stack Compose.
• Stai facendo sviluppo locale e build CI.

Docker Compose da solo copre una quantità sorprendentemente grande di scenari MSP di piccole e medie dimensioni.

Usa Kubernetes quando

• Devi eseguire workload su più nodi con ripianificazione automatica in caso di guasto.
• Hai bisogno di autoscaling orizzontale guidato da metriche o eventi.
• Stai gestendo decine o centinaia di servizi che beneficiano di un workflow dichiarativo e GitOps.
• Hai bisogno di multi-tenancy con isolamento adeguato, RBAC e network policy.
• I requisiti di compliance o di platform engineering del cliente lo richiedono esplicitamente.

Kubernetes leggero per MSP e siti edge

Se il workload necessita davvero di orchestrazione ma un cluster Kubernetes upstream completo è eccessivo – tipicamente il caso in uffici remoti, siti edge, sedi dei clienti e ambienti gestiti da MSP di piccole dimensioni – esistono ora distribuzioni leggere mature e conformi CNCF:

• K3s (Rancher / SUSE). La distribuzione leggera più adottata. Binario singolo, default opinionati (Traefik come ingress, ServiceLB), SQLite o etcd integrato come datastore. Production-ready e utilizzato su larga scala nei deployment edge delle telco.
• MicroK8s (Canonical). Basato su Snap, con un sistema di add-on potente (microk8s enable ingress prometheus). Ottima scelta se sei già standardizzato su Ubuntu.
• K0s (Mirantis). Binario singolo autocontenuto con pochissime dipendenze dall’OS host; una scelta solida per deployment immutabili o air-gapped.
• Minikube. Ancora la scelta di riferimento per lo sviluppo locale e l’apprendimento, non per la produzione.

Tutte e tre le distribuzioni sono progettate per funzionare comodamente entro 1-2 GB di RAM su una configurazione a nodo singolo – una frazione di quanto richiede un control plane upstream completo – rendendole praticabili su un Raspberry Pi, un PC industriale fanless o una piccola VM. Il footprint di memoria esatto dipende dagli add-on abilitati e dal backend di storage, quindi esegui benchmark sul tuo workload prima di dimensionare.

Per un MSP, l’implicazione pratica è che oggi è possibile distribuire un cluster Kubernetes certificato CNCF presso la sede di un cliente, su hardware che normalmente si considererebbe troppo piccolo per l’orchestrazione, e gestirlo da remoto con gli stessi kubectl e tooling GitOps che si usano ovunque.

Kubernetes gestito: EKS, GKE, AKS

Quando il cluster risiede in un cloud pubblico, i tre servizi gestiti dominano:

• Amazon EKS. Il più flessibile, il meno opinionato. Si abbina bene con Karpenter per il fast node autoprovisioning. EKS Anywhere estende il modello all’on-premises.
• Google GKE. Spesso citato come la migliore esperienza “pura” di Kubernetes, dato che Google ha originato il progetto. GKE Autopilot gestisce completamente il data plane: si definiscono solo i pod, Google si occupa dei nodi. Il più forte per workload AI/ML grazie al supporto TPU.
• Azure AKS. Tre livelli di pricing per il control plane: Free (nessun SLA, destinato a dev/test), Standard (SLA con garanzia finanziaria sul server API Kubernetes, il predefinito per i workload di produzione) e Premium (aggiunge Long-Term Support, estendendo la manutenzione per una determinata versione di Kubernetes fino a 2 anni). Stretta integrazione con Entra ID (ex Azure AD), Azure Monitor e Azure DevOps. Azure Arc estende la gestione AKS all’on-premises e all’edge tramite un unico piano di controllo.
• Red Hat OpenShift. Vale una menzione separata per ambienti enterprise e regolamentati: OpenShift è una distribuzione Kubernetes certificata CNCF con un layer di piattaforma opinionato sopra (CI/CD integrata, registry interno, console per gli sviluppatori, default di sicurezza più rigidi). Disponibile self-managed (OpenShift Container Platform) o come servizi gestiti su AWS (ROSA), Azure (ARO), Google Cloud e IBM Cloud. Scelta comune in finanza, sanità e settore pubblico dove i contratti di supporto Red Hat e le certificazioni di compliance sono rilevanti.

Tutti e quattro supportano le versioni minori attuali di Kubernetes, con GKE tipicamente la più rapida ad adottare le nuove release, seguita da AKS, EKS e OpenShift, che rimane intenzionalmente indietro rispetto all’upstream per consentire hardening e certificazione aggiuntivi. 

Considerazioni sulla sicurezza e operative per il 2026

Alcune cose sono cambiate abbastanza dal 2022 da meritare di essere segnalate esplicitamente:

• La sicurezza della supply chain è ora un requisito di base. La firma delle immagini (Cosign / Sigstore), la generazione di SBOM (docker scout sbom, syft) e gli admission controller che applicano le immagini firmate non sono più opzionali negli ambienti regolamentati. L’iniziativa di Docker per le immagini hardened e le policy come Kyverno o OPA Gatekeeper sul lato Kubernetes sono le risposte standard.
• Le CVE di runtime interessano entrambi i mondi. Docker Engine v29 ha chiuso tre gravi vulnerabilità in docker cp (CVE-2026-41567, CVE-2026-41568, CVE-2026-42306) che consentivano a un container malevolo di eseguire binari dell’host o scrivere in percorsi arbitrari dell’host, e Docker Desktop ha ricevuto una fix urgente nel ciclo precedente per CVE-2025-9074 (CVSS 9.3), una presa di controllo da container a host. Kubernetes non è al riparo: ogni runtime CRI alla fine avvia container tramite runc, quindi una CVE di container-escape in runc (come CVE-2024-21626, corretta in runc 1.1.12) si propaga in modo identico a qualsiasi cluster che vi si affidi. La conclusione pratica è che “usiamo solo Docker, non Kubernetes” — o viceversa — non ti sposta su una superficie più sicura. Entrambi gli stack condividono la stessa discendenza OCI/runc a valle, ed entrambi hanno bisogno della stessa disciplina di patching.
• Il versionamento delle API e lo skew sono importanti. Con Docker Engine v29 che alza la versione minima dell’API a 1.44 e Kubernetes che applica rigidamente la policy di supporto N-2, “non abbiamo aggiornato da due anni” non è più una posizione sostenibile. Pianifica una cadenza di aggiornamento regolare, idealmente legata a un flusso GitOps.
• Backup e disaster recovery non scompaiono con i container. I workload stateless sono semplici; i workload stateful (database in StatefulSet, volumi persistenti) necessitano ancora di una reale strategia di backup. Velero è l’opzione canonica nativa Kubernetes; per il lato host, le VM sottostanti e lo storage persistente devono essere coperti anche da una soluzione di backup a livello infrastrutturale.

La conclusione pratica per sysadmin e MSP

L’inquadratura originale “Docker vs Kubernetes” era fuorviante nel 2022 ed è ancora fuorviante nel 2026 – solo che ora il quadro sottostante si è evoluto.

• Docker è lo strumento di build e il runtime single-host che quasi tutti usano, e Engine v29 con il containerd image store ha consolidato il suo posto nello stack.
• Kubernetes è l’orchestratore su cui l’industria si è standardizzata per qualsiasi cosa vada oltre un singolo host, con tre versioni minori attivamente supportate e una cadenza di rilascio di quattro mesi.
• Docker Swarm esiste ancora e funziona ancora, ma ha smesso di essere la risposta ovvia a “voglio un’orchestrazione semplice”; le distribuzioni Kubernetes leggere hanno in gran parte assunto quel ruolo.
• K8s leggero (K3s, MicroK8s, k0s) è il modo in cui MSP e sysadmin portano la vera orchestrazione in siti piccoli e dispositivi edge nel 2026.
• K8s gestito (EKS, GKE, AKS, OpenShift) è il modo in cui la maggior parte delle organizzazioni consuma Kubernetes nel cloud, e quale scegliere dipende più dal resto del proprio footprint cloud, dai rapporti con i vendor e dai requisiti di compliance che da Kubernetes stesso.

Per un sysadmin o MSP che inizia oggi, la raccomandazione non è cambiata molto: acquisisci prima dimestichezza con Docker, perché è il punto di accesso universale alla containerizzazione, e impara abbastanza Kubernetes – partendo da una distribuzione leggera come K3s – per gestire il livello di orchestrazione diventato lo standard de facto per i workload container in produzione.