La domanda che mi arriva più spesso dai CIO italiani che stanno costruendo la loro piattaforma container sovrana è secca: Rancher Prime davanti a RKE2 è un moltiplicatore o un layer di troppo? Dopo aver gestito parchi RKE2 reali in produzione, la mia risposta è meno ambigua di quanto vorrei ammettere in una riunione di procurement. Ma vale la pena spiegare quando l’orchestrazione ti salva e quando ti lascia con le mani nel fango di etcd.
Dove l’orchestrazione mi ha salvato il lavoro
Il punto di forza che ho toccato con mano è l’integrazione nativa con Harvester. Rancher Prime non si limita a orchestrare cluster Kubernetes: riesce a fare il deploy e la gestione delle VM di control plane e worker direttamente sull’infrastruttura HCI di Harvester. Questo chiude un cerchio che con RKE2 vanilla resta aperto: hai un unico piano di controllo che parte dall’hypervisor, provisiona le macchine, ci installa sopra RKE2 e poi ne governa il ciclo di vita.
Lo stesso vale verso i cloud service provider: la gestione dei cluster su provider esterni è efficiente e coerente con quella on-prem, e questo per chi lavora in scenari ibridi — la norma nel contesto enterprise italiano — è oro. Non devi mantenere due mentalità operative diverse.
Il secondo punto dove l’orchestrazione ripaga è l’importazione di cluster già esistenti. Qui l’esperienza è netta: l’import è indolore. Prendi un RKE2 nato a mano, lo importi in Rancher, e da quel momento la gestione centralizzata (RBAC, monitoring, catalog, policy) è immediata senza dover ricostruire nulla. Per chi ha ereditato cluster stratificati nel tempo, questa è la differenza tra un weekend di migrazione e un pomeriggio.
Dove ti lascia a debuggare a mano
Il limite che va detto senza giri di parole riguarda l’autoprovisioning delle VM fuori dallo scenario Harvester. Quando esci dal binario Harvester + Rancher, la gestione e l’autoprovisioning delle macchine diventano fuori scope o comunque molto meno lisce. Fuori dall’ecosistema SUSE integrato ti ritrovi a gestire il layer VM con altri strumenti, e l’illusione del “pannello unico” si incrina.
Tradotto operativamente: se l’infrastruttura è Harvester-based, l’orchestrazione è un moltiplicatore reale. Se invece il control plane vive su un mix di hypervisor eterogenei — VMware residuo, Proxmox, KVM sparso — l’autoprovisioning non ti copre e torni a orchestrare le VM a mano prima ancora di arrivare a Kubernetes.
Il trade-off vero: Prime vs vanilla + Fleet/ArgoCD
La scelta non è tecnica prima che economica. RKE2 è già CNCF-certified e gratuito; Fleet e ArgoCD coprono la parte GitOps senza costi di licenza. Cosa compri davvero con Rancher Prime?
- Supporto SUSE enterprise con SLA, indispensabile se il cluster regge servizi critici e serve qualcuno da chiamare alle 3 di notte.
- Un unico piano di controllo multi-cluster con RBAC centralizzato, che con vanilla devi assemblare tu.
- L’integrazione Harvester che, ripeto, è il vero valore aggiunto e non replicabile a costo zero.
Il rovescio è il lock-in operativo verso l’ecosistema SUSE e il costo di sottoscrizione. La mia soglia empirica: sotto i 3-4 cluster gestiti da un team piccolo, RKE2 vanilla + ArgoCD ripaga meglio. Oltre quella dimensione, con più tenant, più ambienti e requisiti di audit, il piano di controllo centralizzato e il supporto iniziano a valere il canone. Con Harvester in casa, la soglia si abbassa ancora perché il ritorno arriva dal giorno uno.
Cosa consiglio di fare PRIMA
Quando un cliente mi chiede se mettere Rancher Prime davanti ai suoi RKE2, la risposta è: prima sistema le fondamenta, poi parliamo di orchestrazione.
- CNI e networking: decidi Cilium o Canal prima del deploy. Cambiarla dopo con cluster in produzione è chirurgia a cuore aperto.
- Storage: definisci la StorageClass e il backend (Longhorn, storage esterno) coerente con i requisiti di persistenza reali.
- Backup del management cluster: il cluster Rancher che governa gli altri è un single point of failure logico. Backup etcd regolari e testati, non solo configurati.
- HA del control plane: almeno tre nodi control plane con etcd distribuito. Su parchi seri, il management cluster va reso HA, non un nodo solo.
E la cosa che sconsiglio attivamente: non affidare a Rancher l’autoprovisioning delle VM fuori dallo scenario Harvester. In produzione questo è il punto dove ti aspetti automazione e trovi buchi. Tienilo su Harvester dove funziona davvero, oppure gestisci il layer VM con lo strumento nativo del tuo hypervisor e lascia a Rancher solo il piano Kubernetes.
Verdetto
Per chi sta costruendo una piattaforma container sovrana on-prem, specie se l’infrastruttura è o diventerà Harvester-based, conviene muoversi ora (1). L’import dei cluster esistenti è indolore, la gestione centralizzata è solida e l’integrazione con l’hypervisor chiude il ciclo di vita in un modo che nessun assemblaggio vanilla replica senza sforzo. Con l’unica avvertenza chiara: non è un layer magico che provisiona VM ovunque. Conoscendone il perimetro — dentro Harvester è un moltiplicatore, fuori è un orchestratore Kubernetes onesto — Rancher Prime + RKE2 regge la produzione. E questo, nel panorama enterprise italiano, è già una risposta rara.