Kubernetes: perché la tua azienda non può più ignorare l'orchestrazione dei container
In un progetto per un'azienda del settore servizi digitali, la piattaforma web gestiva picchi di traffico imprevedibili - campagne marketing che raddoppiavano le richieste in poche ore, poi settimane di traffico regolare. L'infrastruttura era un singolo server con Docker Compose: quando il traffico cresceva, l'unica opzione era fare upgrade manuale del server, operazione che richiedeva downtime e non era reversibile nei periodi di basso traffico. Dopo la migrazione a un cluster Kubernetes su tre nodi, la piattaforma scala automaticamente i pod PHP-FPM da 2 a 12 in base al carico, e riduce a 2 quando il traffico cala - il tutto senza intervento umano, senza downtime e con costi infrastrutturali proporzionali all'uso reale.
Cos'è Kubernetes e quando ha senso per una PMI?
Kubernetes è una piattaforma open source per l'orchestrazione dei container: automatizza il deployment, lo scaling e la gestione delle applicazioni containerizzate su cluster di server. Originariamente sviluppato da Google e ora mantenuto dalla Cloud Native Computing Foundation (CNCF), Kubernetes è diventato lo standard de facto per l'infrastruttura cloud-native - il CNCF Annual Survey 2024 riporta che l'80% delle organizzazioni usa Kubernetes in produzione, con un ulteriore 13% in fase di piloting.
La domanda rilevante per una PMI non è "se" adottare l'orchestrazione, ma "quando" ha senso farlo. Docker Compose è sufficiente per applicativi con 1-5 servizi su un singolo server, senza necessità di auto-scaling o alta disponibilità. Kubernetes diventa necessario quando servono: scalabilità orizzontale automatica (aggiungere o rimuovere istanze in base al traffico), alta disponibilità multi-nodo (se un server muore, l'applicativo continua a funzionare sugli altri), rolling update a zero-downtime (aggiornamenti graduali senza interruzione del servizio), o gestione di più applicativi sullo stesso cluster con isolamento delle risorse. La sicurezza dei container Docker resta fondamentale indipendentemente dalla scelta di orchestrazione.
I concetti fondamentali di Kubernetes
Per capire Kubernetes è necessario comprendere le sue primitive fondamentali, ciascuna con un ruolo specifico nell'architettura.
Il Pod è l'unità base: uno o più container che condividono rete e storage. Per un applicativo PHP, un pod tipico contiene un container Nginx e un container PHP-FPM che comunicano via socket. Il Deployment dichiara lo stato desiderato - quanti replica di un pod devono essere attivi - e Kubernetes si occupa di mantenerlo: se un pod crasha, viene ricreato automaticamente. Il Service fornisce un endpoint di rete stabile per accedere ai pod, indipendentemente da quale nodo li ospita. L'Ingress gestisce il routing HTTP/HTTPS dall'esterno, con virtual host, TLS termination e path-based routing. I ConfigMap e i Secret esternalizzano la configurazione e le credenziali, separandole dal codice dell'applicativo.
L'HPA (Horizontal Pod Autoscaler) è la primitiva che implementa lo scaling automatico: monitora metriche come CPU e memoria dei pod, e aggiunge o rimuove repliche per mantenere l'utilizzo entro soglie definite. Ecco una configurazione completa per un applicativo PHP:
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-php
spec:
replicas: 2
selector:
matchLabels:
app: gestionale
template:
metadata:
labels:
app: gestionale
spec:
containers:
- name: php-fpm
image: registry.example.com/gestionale:1.4.2
resources:
requests:
cpu: 250m
memory: 256Mi
limits:
cpu: 1000m
memory: 512Mi
envFrom:
- configMapRef:
name: app-config
- secretRef:
name: app-secrets
readinessProbe:
httpGet:
path: /health
port: 9000
initialDelaySeconds: 5
periodSeconds: 10
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: app-php-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: app-php
minReplicas: 2
maxReplicas: 12
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70Questo manifest definisce un deployment con 2 repliche minime, un HPA che scala fino a 12 repliche quando l'utilizzo CPU medio supera il 70%, resource request e limit per garantire la schedulazione corretta, e un readiness probe che impedisce di inoltrare traffico a pod non ancora pronti.
K3s: Kubernetes leggero per le PMI
Kubernetes "full" richiede un'infrastruttura significativa per il control plane. K3s, sviluppato da SUSE (ex Rancher Labs), è una distribuzione Kubernetes certificata che riduce drasticamente la complessità operativa: un singolo binario sotto i 100MB, requisiti minimi di 512MB RAM e 1 CPU, installazione in 30 secondi, piena compatibilità con l'API Kubernetes standard. K3s usa SQLite come datastore di default (con opzione per etcd, MySQL o PostgreSQL), include Traefik come Ingress controller e CoreDNS, e supporta architetture ARM - perfetto per ambienti edge e single-node.
Per una PMI che vuole i benefici dell'orchestrazione senza la complessità operativa di un cluster Kubernetes enterprise, K3s su tre VPS Hetzner (ad esempio 3× CX41 con 4 vCPU e 16GB RAM ciascuno, per circa 48 euro al mese totali) offre alta disponibilità, auto-scaling e rolling update a un costo infrastrutturale contenuto. Le alternative managed includono DigitalOcean Kubernetes (DOKS, control plane gratuito, nodi da 12 dollari/mese) e OVHcloud Managed Kubernetes (control plane gratuito con SLA 99.99%, senza costi di egress).
Helm: il package manager che semplifica i deployment
Gestire decine di manifest YAML per ogni applicativo è tedioso e soggetto a errori. Helm è il package manager per Kubernetes: raggruppa tutti i manifest (Deployment, Service, ConfigMap, Secret, Ingress, HPA) in un chart versionato e parametrizzato. Un helm install gestionale ./chart deploya l'intero stack in un comando, con valori personalizzabili per ogni ambiente (staging, produzione). L'81% delle organizzazioni che usano Kubernetes adotta Helm, secondo il CNCF Survey 2024.
Errori da evitare nell'adozione di Kubernetes
L'errore più frequente che osservo nelle PMI è adottare Kubernetes quando Docker Compose sarebbe sufficiente. Kubernetes aggiunge complessità operativa reale - networking, storage, RBAC, monitoring del cluster - che ha senso solo se i benefici (scaling, HA, multi-tenancy) sono effettivamente necessari. Un gestionale con 50 utenti interni su un singolo server non ha bisogno di Kubernetes.
Il secondo errore è non definire resource request e limit sui pod. Senza limit, un singolo pod con un memory leak può consumare tutta la RAM del nodo, causando l'eviction di altri pod. Senza request, lo scheduler non può distribuire i pod in modo efficiente sui nodi.
Il terzo è trascurare la sicurezza del cluster: RBAC non configurato, Secret non crittografati, immagini non scannerizzate per vulnerabilità, pod che girano come root. La sicurezza in Kubernetes è un tema a sé - Network Policies, Pod Security Standards, e image scanning devono essere parte del setup iniziale, non un afterthought.
Kubernetes non è una bacchetta magica - è uno strumento potente che risolve problemi specifici di scalabilità, disponibilità e gestione multi-applicativo. Per una PMI, la decisione corretta dipende dal contesto: Docker Compose per lo stack semplice, K3s per il primo passo verso l'orchestrazione, Kubernetes managed per la crescita strutturata. L'adozione di tecnologie open source e l'automazione del rilascio con pipeline CI/CD sono i prerequisiti naturali di questo percorso. Per conoscere il mio approccio e le competenze specifiche su infrastrutture cloud-native, visita la mia pagina professionale. Se stai valutando l'adozione di Kubernetes o vuoi ottimizzare un cluster esistente, contattami per una consulenza dedicata - partiamo dall'analisi delle tue reali esigenze operative.