Docker Compose e Kubernetes non sono sostituti diretti
| Criterio | Docker Compose | Kubernetes | Commento |
|---|---|---|---|
| Sviluppo locale | Eccellente | Possibile, di solito più pesante | Compose ha un costo iniziale inferiore |
| Produzione single-host | Eccellente | Spesso eccessivo | Docker documenta questo scenario |
| HA multi-node | Nessuno scheduler cluster nativo | Eccellente | Kubernetes mantiene workload sui nodi |
| Self-healing | Restart sull'host | Eccellente | Kubernetes sostituisce anche Pods e reagisce ai guasti dei nodi |
| Autoscaling | Manuale | HPA | Scaling basato su metriche |
| Rolling updates | Manuale | HPA | Deployment integra RollingUpdate e rollback |
| Costo operativo | Più basso | Più alto | Il cluster richiede più piattaforma e competenze |
Docker Compose definisce in modo dichiarativo servizi, reti, volumi, configurazioni e secrets di un'app containerizzata. Compose Specification è il formato raccomandato. [1]
Kubernetes gestisce workload e servizi in un cluster e offre service discovery, load balancing, storage orchestration, rollout, rollback e scaling. [8]
La vera domanda è se il progetto ha bisogno di orchestrazione di cluster o se basta un singolo host ben gestito.
Cosa fa bene Docker Compose
Compose riunisce immagini, variabili, reti, volumi, healthcheck, dipendenze, secrets e configurazioni. [1][3]
La stessa definizione può essere usata in sviluppo, CI, staging e produzione con file di override. Docker documenta questo modello. [2]
Questo riduce la complessità iniziale e mantiene semplice il deploy.
Compose in produzione: il singolo server è documentato
Docker documenta esplicitamente Compose in produzione e indica il singolo server come modello di deploy più semplice. [2]
In produzione è comune usare `compose.production.yaml`, adattare porte e variabili, rimuovere bind mount del codice e impostare restart policies. [2]
Se tutti i container sono sullo stesso host, quell'host resta un dominio comune di guasto.
Healthcheck, dipendenze e restart
Con `depends_on` e `condition: service_healthy`, Compose può attendere che una dipendenza superi il proprio healthcheck. [3][4]
Il campo `restart` supporta `no`, `always`, `on-failure` e `unless-stopped`. [3][7]
Questa resilienza resta però confinata allo stesso Docker host.
Scaling con Compose: le repliche non sono un cluster
`docker compose up --scale SERVICE=N` e `docker compose scale` possono avviare più istanze di un servizio. [6]
Nel modello standard documentato da Docker, Compose in produzione continua a funzionare su un singolo server. [2]
Compose Deploy Specification definisce `replicas`, `placement`, `resources`, `update_config` e `rollback_config`, ma `deploy` è opzionale e può essere ignorato se non supportato. [5][3]
Cosa aggiunge Kubernetes oltre il singolo host
Kubernetes mantiene lo stato desiderato tramite controller. Deployment è l'astrazione tipica per applicazioni stateless e gestisce Pods tramite ReplicaSets. [10]
Può distribuire repliche sui nodi, mantenerne il numero, offrire endpoint stabili con Service e reagire ai guasti. [8][10][15]
La differenza principale è questo control plane, non il formato YAML.
Self-healing: guasto del processo contro guasto del nodo
| Funzione | Docker Compose | Kubernetes | Differenza |
|---|---|---|---|
| Restart container | Sì | Sì | Entrambi possono riavviare processi |
| Recovery dopo guasto nodo | No | Sì | Kubernetes può spostare il Pod su un altro nodo |
| Mantenimento repliche | Manuale | Dichiarativo | I controller mantengono lo stato desiderato |
| Autoscaling da metriche | No | Sì | HPA regola periodicamente le repliche |
| Endpoint stabile | Rete Compose | Service | Service astrae Pods variabili |
| Scheduling CPU/RAM | Su un host | Scheduler cluster | Lo scheduler considera i requests |
Compose può riavviare un container in base alla restart policy finché il Docker host funziona. [7]
Kubernetes può inoltre sostituire Pods, mantenere le repliche e rischedulare workload quando un nodo diventa indisponibile. [12]
Readiness può rimuovere un Pod non pronto dai backend Service, mentre liveness può provocare un restart. Una liveness probe sbagliata può causare disservizi. [16]
Rete e service discovery
Compose crea reti applicative e permette la comunicazione tramite nome del servizio, sufficiente per molte applicazioni single-host. [1]
Kubernetes Service fornisce IP o hostname stabile per un insieme dinamico di Pods. [15]
Questa astrazione è particolarmente utile in cluster multi-node dove Pods e IP possono cambiare.
Autoscaling e gestione delle risorse
Compose permette scaling manuale ma non fornisce un controller equivalente a HPA basato su metriche. [6]
HorizontalPodAutoscaler può modificare il numero di repliche in base a CPU, memoria o metriche personalizzate. [13]
Kubernetes supporta anche `requests` e `limits`; lo scheduler considera i requests nella scelta del nodo. [14]
Deploy, rolling update e rollback
Con Compose, un deploy tipico costruisce o scarica una nuova image e ricrea i container interessati. Docker documenta, per esempio, `docker compose up --no-deps -d web`. [2]
Deployment integra RollingUpdate, storico delle revisioni e `kubectl rollout undo`. [11]
Per deploy frequenti con più repliche, Kubernetes offre quindi un meccanismo nativo di orchestrazione.
Database e workload stateful
Compose può eseguire database con volumi se il team accetta il modello single-host e gestisce backup, replica e recovery.
StatefulSet mantiene identità stabili dei Pods e può associarle a storage persistente. [17]
StatefulSet non rende automaticamente un database altamente disponibile. Replica, consistenza, backup e disaster recovery dipendono ancora dal database e dall'architettura.
Il costo operativo di Kubernetes conta
La documentazione Kubernetes afferma che un cluster production-quality richiede pianificazione per resilienza, accessi, disponibilità e risorse. [9]
Kubernetes non è un PaaS completo. Logging, monitoring, alerting e altri componenti restano opzionali e pluggable. [8]
Managed Kubernetes riduce il lavoro sul control plane, ma workload, rete, risorse, storage e troubleshooting restano responsabilità del team.
Microservices non è un motivo automatico per Kubernetes
Kubernetes supporta workload distribuiti e dinamici, ma dividere un'app in più servizi non crea da solo un requisito di cluster. [8]
Frontend, API, worker, Redis e PostgreSQL possono funzionare bene con Compose se un host basta e i requisiti di disponibilità lo consentono.
Criteri migliori sono tolleranza al guasto host, repliche, autoscaling, SLO, frequenza dei deploy e numero di team.
Quando migrare davvero a Kubernetes
| Domanda | Compose è sensato quando | Kubernetes ha senso quando |
|---|---|---|
| Guasto host | Recovery esterno è sufficiente | Il workload deve sopravvivere automaticamente al guasto nodo |
| Scala | Tutto sta su un host | Servono più nodi e autoscaling |
| Deploy | Recreate semplice o processo proprio basta | Servono rollout multi-replica controllati |
| Team | Uno o pochi team gestiscono uno stack semplice | Molti team hanno bisogno di una piattaforma comune |
| Numero servizi | Il numero da solo non è un problema cluster | Le operazioni richiedono standardizzazione e automazione |
| Piattaforma | La semplicità operativa è prioritaria | Servono policy, scheduling e astrazioni cluster |
La migrazione ha senso quando il modello single-host diventa un limite operativo, non quando `compose.yaml` diventa semplicemente più lungo.
Segnali concreti sono continuità dopo guasto di nodo, placement automatico di repliche, autoscaling, rollout controllati, piattaforma condivisa o policy comuni di risorse e rete. [8][9][12][13]
Senza questi requisiti Kubernetes può aggiungere più complessità che valore.
Percorso pratico di crescita
Un percorso comune è Dockerfile per ogni applicazione, Compose per sviluppo e integrazione, poi Compose anche in produzione finché un host è sufficiente.
Prima di Kubernetes rendi stateless ciò che puoi, esternalizza sessioni e file, aggiungi health endpoint corretti e definisci risorse, secrets e storage.
Compose può restare lo strumento locale anche se la produzione usa Kubernetes.
- Parti da SLO e disponibilità.
- Se un host basta, valuta prima Compose.
- Se il guasto dell'host non deve fermare l'applicazione, serve un design multi-node.
- Per carico dinamico valuta HPA.
- Per rollout controllati multi-replica Kubernetes offre controller integrati.
- Non spostare il database in Kubernetes solo perché l'app è lì.
- Considera il costo di cluster, osservabilità, rete e upgrade.
- Scegli il modello più semplice che soddisfa i requisiti.
