Il punto di rottura non è mai il runtime, è il control plane
Chi gestisce Kubernetes in produzione da qualche anno lo sa: il container in sé raramente ti sveglia alle tre di notte. A rompersi per primo è quasi sempre il layer di gestione, quella distribuzione che ci mettiamo sopra per non toccare l’YAML a mani nude. E qui le tre strade — Rancher, OpenShift, vanilla — divergono in modo brutale.
Nella mia esperienza diretta, Rancher è pericolosamente dipendente dal suo pod di cluster management. Il modello architetturale è elegante sulla carta: un management cluster centrale che governa una flotta di downstream cluster tramite Fleet. Il problema è che quel componente diventa un single point of pain. Mi è capitato più di una volta che, dopo un upgrade o un rinnovo di certificati, Fleet si “incartasse” sulla riconciliazione delle dipendenze: il management cluster resta up, l’interfaccia risponde, ma perde di fatto il controllo dei cluster downstream. Gli agent restano orfani, gli stati vanno in Waiting o Error e tu ti ritrovi con workload che girano ma che non puoi più governare in modo centralizzato.
L’incidente Rancher: come se ne esce
Il caso concreto: dopo un upgrade del management cluster, Fleet ha smesso di sincronizzare i downstream. La UI mostrava i cluster ma i deployment GitOps non arrivavano più a destinazione. La tentazione è reinstallare tutto. La via d’uscita reale, invece, è stata chirurgica:
- Isolare il problema: i workload sui downstream continuavano a girare, perché il piano dati è indipendente. Nessun disservizio applicativo immediato.
- Rigenerare gli agent sui cluster downstream, riallineando i token di registrazione verso il management cluster.
- Forzare la riconciliazione di Fleet cluster per cluster, evitando il “big bang” che avrebbe propagato lo stato inconsistente.
- Trattare il management cluster come infrastruttura sacrificabile: backup regolare di stato ed etcd, con procedura di ripristino testata.
La lezione: con Rancher non devi mai far coincidere la salute dei tuoi workload con la salute del control plane di gestione. Il giorno che confondi le due cose, un incidente banale diventa un incident maggiore.
Vanilla: più gestibile riga per riga, ma serve presidio costante
Il paradosso del Kubernetes vanilla è che, quando qualcosa si rompe, è più gestibile. Non c’è un layer di astrazione che ti nasconde cosa sta succedendo: kubectl, i log del kubelet, lo stato del CNI. Se il CNI si pianta — un Calico o un Cilium che perde le route dopo un cambio di configurazione — hai visibilità totale e intervieni sul componente esatto, senza combattere contro l’orchestratore dell’orchestratore.
Il prezzo, però, è la compresenza: vanilla pretende che qualcuno nel team conosca davvero l’internals. Etcd, certificati, upgrade delle control plane node uno alla volta, gestione manuale del CNI e dell’ingress. Nessuna guida assistita. È la scelta più onesta dal punto di vista tecnico e la più spietata dal punto di vista delle competenze richieste.
Il trade-off vero: licenze vs ore-uomo
Qui casca il ragionamento FinOps che porto sempre ai CIO. OpenShift costa in licenze in modo importante, e su cluster medio-grandi la subscription per core diventa una voce di bilancio che salta all’occhio. Ma quello che paghi in licenza lo stai spesso spostando dal costo nascosto delle ore-uomo.
In ordini di grandezza, da casi reali:
- OpenShift: costo licenza rilevante e prevedibile, ma upgrade guidati, operator certificati, supporto vendor. Le ore-uomo dedicate al mantenimento del control plane crollano.
- Vanilla o Rancher fai-da-te: licenza zero o quasi, ma un cluster vanilla in produzione può mangiarti agevolmente 0,5–1 FTE di sistemista senior tra upgrade, patching, CNI, troubleshooting. Un FTE senior italiano, caricato, non è mai a buon mercato: fai il conto e spesso pareggia o supera la subscription OpenShift.
Il punto è che il costo del vanilla è opaco: non appare in una fattura, appare come stanchezza del team, ticket in ritardo, rischio operativo. Chi ragiona solo sulla riga “licenze” sbaglia i conti.
Quando un CIO mi chiede “quale scelgo?”
La risposta è sempre: dipende dallo use case, ma la variabile discriminante reale è quasi sempre una sola — le competenze interne del team. Le altre (sovranità/on-prem, certificazioni, exit strategy) contano, ma il team è il vincolo che non puoi bypassare a colpi di budget.
- Team forte su Linux e Kubernetes internals, esigenza di massima sovranità e nessun lock-in: vanilla. Ma solo se accetti il presidio continuo.
- Team piccolo, bisogno di certificazioni, compliance e supporto formale: OpenShift. La licenza è un’assicurazione, non uno spreco.
- Flotta multi-cluster eterogenea, edge o multi-sito: Rancher ha senso, a patto di trattare il management cluster come componente critico ridondato.
Il caso in cui ho sconsigliato la scelta ovvia: un cliente con team ridotto voleva vanilla “per risparmiare licenze e restare sovrano”. Sulla carta perfetto. Nella realtà non avevano le competenze per gestire etcd e CNI in produzione: li ho indirizzati verso una distribuzione supportata. Il vanilla lì sarebbe stato il modo più costoso di risparmiare.
Verdetto: conviene muoversi
Verdetto 1: conviene muoversi, ma con lucidità. Standardizzare la propria piattaforma container non è più rinviabile nell’enterprise italiana, tra spinta alla sovranità, EU AI Act e workload sempre più container-native. La scelta giusta non è “quella più moderna” o “quella gratis”: è quella sostenibile per il tuo team nei prossimi tre anni. Muoviti ora, ma parti dalle competenze che hai in casa e dal costo reale — ore-uomo incluse — non dalla riga di licenza. Chi aspetta oggi non risparmia: accumula solo debito tecnico da pagare a interessi più alti domani.