Kubernetes in produzione: quello che nessuno ti dice prima della migrazione

La maggior parte dei team che migrano a Kubernetes arrivano convinti di risolvere un problema infrastrutturale. Ciò che scoprono, di solito sei mesi dopo, è che hanno sostituito una serie di problemi con uno molto più sofisticato e che la complessità operativa che pensavano di aver eliminato si è semplicemente spostata.

Ciò che Kubernetes fa davvero bene

Kubernetes è nato per risolvere un problema concreto: orchestrare container su larga scala, con resilienza e capacità di ripristino automatico. Lo fa molto bene. Se la tua organizzazione gestisce decine di servizi con modelli di traffico variabili, necessita di implementazioni senza tempi di inattività e dispone di un team maturo per gestire la piattaforma, Kubernetes offre un valore reale.

La pianificazione del carico di lavoro, la gestione delle risorse, il supporto per strategie di implementazione progressiva e l'integrazione con gli strumenti di osservabilità sono davvero buoni. Questi vantaggi non sono marketing: esistono, funzionano e fanno la differenza nella produzione.

Il problema non è ciò che promette Kubernetes. Questo è ciò che chiede in cambio.

La complessità che appare dopo la migrazione

La rete in Kubernetes non è una configurazione semplice. Si tratta di un intero livello di astrazione (plugin CNI, mesh di servizi, policy di rete, DNS interno, controller di ingresso) che è necessario comprendere, mantenere ed eseguire il debug quando qualcosa si rompe. E qualcosa si romperà.

Lo stoccaggio è un altro punto di attrito che molti sottovalutano. Volumi persistenti, StorageClass, modalità di accesso, snapshot, PVC di backup: tutto questo deve essere progettato con attenzione. Le applicazioni stateful su Kubernetes sono significativamente più complesse delle stesse applicazioni eseguite su macchine virtuali convenzionali.

RBAC, a sua volta, è il genere di cose che nessuno documenta bene durante la migrazione e che si trasforma in debito tecnico nel giro di poche settimane. L'impostazione di autorizzazioni granulari per spazi dei nomi, account di servizio e carichi di lavoro distinti richiede una disciplina che i team sotto pressione raramente riescono a mantenere.

Gli aggiornamenti del cluster sono un altro capitolo. Kubernetes ha un ciclo di vita aggressivo: le versioni diventano obsolete rapidamente e ogni aggiornamento richiede la convalida della compatibilità di API, manifest, grafici Helm e operatori. Ignoralo per alcuni mesi e eseguirai una versione non supportata in produzione.

Il paradosso SRE

C'è un'ironia ben nota nel fatto che i team adottino Kubernetes senza un'adeguata pianificazione: sono necessari ingegneri esperti in affidabilità per utilizzare lo strumento che dovrebbe ridurre la necessità di operazioni manuali. Kubernetes è stato creato per la scala Google. Porta questa eredità.

I piccoli team spesso scoprono di dedicare più tempo alla gestione della piattaforma che allo sviluppo del prodotto. Ogni incidente coinvolge log di più pod, tracciamento degli eventi di pianificazione, analisi dei limiti delle risorse e debug della rete che ha senso solo per coloro che comprendono profondamente le astrazioni interne.

Questo non è un difetto di progettazione. È una conseguenza diretta della generalità della piattaforma. Kubernetes risolve problemi complessi in modi complessi e tale complessità non scompare solo perché i contenitori sono in esecuzione.

Quando gestito Kubernetes modifica il calcolo

EKS, GKE e AKS non eliminano la complessità operativa, ma ne distribuiscono una parte al provider cloud. Il piano di controllo - etcd, server API, scheduler, controller manager - è responsabilità del fornitore. Gli aggiornamenti di versione diventano meno traumatici. L'integrazione con l'identità, l'archiviazione e i servizi di rete del provider è preconfigurata.

Per i team che già operano all'interno di uno specifico provider cloud, Kubernetes gestito riduce significativamente il costo di ingresso. Non è zero, ma è sostanzialmente inferiore alla gestione di un cluster autogestito.

Il calcolo cambia nuovamente se si considera il lock-in. GKE Autopilot, ad esempio, astrae così tanto da farti perdere il controllo sulla pianificazione e sulla configurazione dei nodi. È uno scambio valido per alcune squadre e inaccettabile per altre. La scelta dipende da dove si vuole la sovranità e da dove si accetta la delega.

Quando una strategia più semplice è la decisione intelligente

Kubernetes non è la risposta giusta per ogni carico di lavoro. Se gestisci un monolite ben strutturato con traffico prevedibile, un'istanza EC2 ben configurata con un processo di distribuzione automatizzato può essere più affidabile, più economica e molto più facile da utilizzare.

Strumenti come Fly.io, Railway, Render o anche AWS App Runner offrono la maggior parte dei vantaggi operativi di Kubernetes (tempi di inattività pari a zero, scalabilità automatica, rollback) senza il livello di astrazioni che richiede la manutenzione da parte di esperti.

La domanda che i team raramente si pongono prima della migrazione è semplice: quale problema specifico risolverà Kubernetes che l'attuale infrastruttura non è in grado di risolvere? Se la risposta è vaga – “scalabilità”, “modernizzazione”, “migliore gestione dei container” – l’investimento operativo probabilmente non è giustificato.

Kubernetes ha senso quando si hanno più servizi con cicli di distribuzione indipendenti, la necessità di isolamento tra carichi di lavoro, modelli di traffico altamente variabili e un team con capacità reali per gestire la piattaforma. Questi quattro criteri insieme raramente compaiono prima che un'organizzazione abbia dozzine di ingegneri e anni di maturità dei container.

La decisione che arriva nel momento sbagliato

La migrazione a Kubernetes avviene quasi sempre in un momento di minore preparazione. Il team sta crescendo, è emersa la pressione per espandersi, qualcuno ha visto un discorso al KubeCon - e la decisione viene presa prima che il team abbia abbastanza esperienza per capire cosa stanno intraprendendo.

Il risultato tipico: sei mesi di sforzi per migrare, seguiti da altri sei nel tentativo di stabilizzare l’ambiente. I problemi che hanno motivato la migrazione – fragili implementazioni, mancanza di isolamento, difficoltà di scalabilità – continuano a esistere, ora con un ulteriore livello di diagnosi.

Ciò non significa che la migrazione sia stata sbagliata. Significa che aveva bisogno di più pianificazione, di un programma realistico e di formazione prima dell'esecuzione. Kubernetes è una piattaforma potente. Ma potere e semplicità raramente coesistono – e coloro che non capiscono questa distinzione imparano dopo che la decisione è già stata presa.