Il cargo cult di Kubernetes
C’è una parola che negli ultimi anni è entrata nei consigli di amministrazione senza passare dal reparto tecnico: Kubernetes. La sento pronunciare come se fosse un requisito di conformità, non una scelta architetturale. E il risultato lo vedo sul campo con regolarità: aziende che montano un cluster completo per far girare tre o quattro container che sarebbero stati benissimo su un Docker Compose o una singola VM.
Il problema non è tecnico. Kubernetes funziona, orchestra bene, scala. Il problema è che nessuno si chiede se quel livello di orchestrazione serva davvero. E quando la risposta è no, quello che hai costruito non è un’infrastruttura moderna: è un debito operativo che presenterà il conto al primo incidente.
Il caso tipico: la PMI che “sente” di aver bisogno di K8s
Il pattern si ripete. Una PMI decide che “serve Kubernetes” — di solito perché lo ha letto da qualche parte, o perché un fornitore lo ha proposto come standard. Si ritrova un cluster in produzione che nessuno in azienda sa gestire davvero. Finché tutto gira, l’illusione regge. Poi arriva il giorno in cui si rompe etcd, oppure un upgrade di versione va storto, e scopri che il team non ha le competenze per rimettere in piedi il control plane.
A quel punto scatta la consulenza d’emergenza: fatturata a peso d’oro, in orario notturno, mentre i servizi sono giù. Ho visto cluster che, sommando manutenzione ordinaria, troubleshooting e questi interventi straordinari, consumavano più tempo-uomo di quanto ne richiedessero le applicazioni che ci giravano sopra. È il paradosso dell’over-engineering: paghi per gestire lo strumento, non per far funzionare il prodotto.
Il trade-off vero è di competenze, non di tecnologia
Quando valuto se un cliente debba andare su Kubernetes, non parto dai carichi. Parto dal team ops. La complessità che aggiungi con un cluster non è solo il container runtime: è tutto il contorno che diventa obbligatorio per gestirlo in modo serio.
- Networking: CNI, service mesh eventuale, policy di rete, ingress controller da mantenere aggiornati.
- Storage persistente: CSI driver, gestione dei volumi, backup consistenti degli stateful set — il punto dove più spesso vedo esplodere le cose.
- Monitoring e osservabilità: uno stack (Prometheus, Grafana, log aggregation) che è di per sé un progetto.
- Sicurezza del cluster: RBAC, gestione dei segreti, hardening dei nodi, patching regolare del control plane.
Ognuna di queste voci richiede competenza dedicata. Sotto una certa soglia, la complessità che aggiungi ti costa più di quanto ti fa risparmiare. E il risparmio, spesso, semplicemente non c’è: se non hai bisogno di autoscaling, self-healing distribuito e deploy multipli al giorno, stai pagando per feature che non userai mai.
La soglia pratica: quando K8s inizia a ripagare
Nella mia esperienza, Kubernetes comincia a giustificarsi quando convergono più fattori insieme, non uno solo:
- Numero di servizi: parliamo di decine di microservizi, non di sei. Con pochi servizi, l’orchestrazione manuale è banale.
- Frequenza dei deploy: deploy quotidiani o più frequenti, dove rolling update automatici e rollback fanno una differenza reale sul tempo del team.
- Esigenze di scaling/HA reali: carichi variabili che richiedono davvero di scalare automaticamente, non picchi teorici.
- Dimensione del team ops: qualcuno che ci lavora sopra con continuità. Un cluster gestito da un solo sysadmin part-time è una bomba a orologeria.
Un caso concreto: cliente con 6 servizi, un solo sysadmin, zero esigenze di autoscaling. La proposta sul tavolo era Kubernetes “perché fa moderno”. Gli ho consigliato di restare su Docker Compose più un buon reverse proxy. Deploy semplici, un solo punto da presidiare, competenze già in casa. Nessun rimpianto.
Il caso opposto: azienda con decine di microservizi e deploy quotidiani. Lì Kubernetes l’ho consigliato davvero, e la complessità si è ripagata perché c’era il volume e c’era il team per sostenerla.
Quando anche la via semplice si rompe
Non voglio dare l’impressione che Docker Compose sia sempre la risposta. Ha punti di rottura precisi, e vanno riconosciuti prima di arrivarci. Il momento in cui la scelta semplice inizia a fare male è quando compaiono, tutti insieme:
- Necessità di self-healing: un container che muore di notte e nessuno lo riavvia fino al mattino.
- Deploy manuali che diventano un rito fragile, dipendente da una persona.
- Assenza di rolling update: ogni rilascio comporta downtime percepibile.
Il consiglio che do oggi è di non farsi trovare in mezzo al guado. Prima di saltare direttamente sul cluster, esistono gradini intermedi sensati: Docker Compose con restart policy e healthcheck per il self-healing di base, oppure Nomad quando serve orchestrazione ma non tutto il peso di K8s. La via peggiore è la mezza migrazione a Kubernetes lasciata incompleta: metà servizi dentro, metà fuori, nessuno che padroneggia davvero il sistema. Quella è la via ingestibile per eccellenza.
Il verdetto
Per la maggior parte delle PMI e delle infrastrutture di dimensioni contenute, il verdetto è 0: non muoverti verso Kubernetes ora. Non è arretratezza, è disciplina architetturale. Adotta il cluster quando arrivi genuinamente alla soglia — decine di servizi, deploy quotidiani, un team che ci vive sopra — e non un giorno prima. Fino ad allora, tre VM ben fatte e un Docker Compose curato non sono un compromesso: sono la scelta corretta. Il momento giusto per Kubernetes lo riconoscerai perché sarà la semplicità, non la moda, a spingerti verso di lui.