Come valutare un provider di Managed Kubernetes in Europa

September 2026 • Comparison

Una pagina dei prezzi di Managed Kubernetes non ti dice cosa succede quando qualcosa va storto di notte. Questa checklist affronta le domande che lo decidono e, per ciascuna, mostra ciò che diversi provider europei pubblicano davvero. Ogni dato sui provider proviene dalla documentazione o dalla pagina dei prezzi del provider stesso, letta a settembre 2026, ed è collegato nella sezione Fonti.

1. Chiedi che cosa viene effettivamente gestito

I provider tracciano il confine tra il proprio compito e il tuo in punti diversi. Lo SLA di Exoscale SKS è esplicito: copre solo la disponibilità del control plane, non nodi worker, pod, volumi, applicazioni o dati. Il cliente resta responsabile di carichi di lavoro, controllo degli accessi al cluster, dati persistenti, backup, pianificazione del disaster recovery e procedure di ripristino.

Altri provider descrivono una maggiore automazione. IONOS dichiara che il suo servizio gestito gestisce automaticamente aggiornamenti e correzioni di sicurezza e che sei tu a scegliere quando eseguirli. Infomaniak dichiara che puoi aggiornare il control plane e i nodi worker in qualsiasi momento e che gestisce tutti i componenti Kubernetes. Qualunque sia la formulazione, ottieni risposte scritte a queste domande:

• Chi aggiorna il control plane, chi aggiorna i nodi worker e chi decide i tempi?
• Chi applica le patch al sistema operativo dei nodi worker?
• A chi spettano i backup dello stato del cluster e dei tuoi volumi persistenti?
• Quali add-on (rete, ingress, metriche) sono forniti e chi li mantiene aggiornati?

2. Verifica quale livello di control plane stai davvero acquistando

Un control plane gratuito non è lo stesso prodotto di uno a pagamento. I livelli gratuiti qui sotto sono condivisi e non hanno SLA, mentre i livelli a pagamento aggiungono repliche, un datastore dedicato e un obiettivo di disponibilità scritto.

Questo conta per il modo in cui è costruito Kubernetes stesso. Come spiega il nostro articolo su Kubernetes managed vs. self-hosted, la documentazione di Kubernetes raccomanda per la produzione cluster etcd a più membri, e etcd ha bisogno della maggioranza dei suoi membri per apportare modifiche. Una singola replica dell'API su un datastore condiviso è una scelta ragionevole per lo sviluppo e debole per la produzione.

3. Leggi lo SLA per capire che cosa copre

Due provider possono entrambi pubblicizzare una percentuale e intendere cose molto diverse. Chiedi che cosa viene misurato (disponibilità dell'API del control plane, disponibilità dei nodi o entrambe), su quale periodo, che cosa è escluso e che cosa ricevi se l'obiettivo non viene raggiunto. Exoscale, per esempio, riconosce il 50% dei canoni mensili per le risorse interessate quando l'uptime è compreso tra il 99,95% e il 98,3%, e il 100% al di sotto di tale soglia. Esclude inoltre i guasti di nodi, volumi e pod, perché il suo SLA si applica al control plane.

Aiuta anche tradurre la percentuale in tempo. In un mese di 30 giorni:

Scaleway indica il 99,5% per i suoi control plane Kapsule dedicati, Infomaniak indica il 99,9% per i suoi livelli dedicati ed Exoscale indica almeno il 99,95% per il suo piano Pro. Questi numeri sono confrontabili solo se le definizioni coincidono, quindi leggi le definizioni prima di confrontare i numeri.

4. Chiedi se le vCPU sono dedicate

Le vCPU condivise sono pianificate su core fisici che più macchine virtuali usano contemporaneamente. La documentazione di Scaleway descrive la conseguenza in modo chiaro: durante i picchi di domanda dei carichi di lavoro vicini, i tuoi carichi possono rallentare per contesa della CPU, nota come CPU steal. Le vCPU dedicate offrono accesso esclusivo ai core fisici e prestazioni costanti. Le indicazioni di Scaleway elencano i nodi worker dei cluster Kubernetes tra gli usi tipici delle istanze condivise, il che è una scelta ragionevole per lo sviluppo e un compromesso reale per la produzione.

IONOS ti permette di scegliere tra core dedicati e vCPU per i nodi worker del suo Kubernetes gestito. Molti provider non indicano quale ottieni con un determinato piano. Se la documentazione tace, chiedi per iscritto, perché cambia sia le prestazioni sia il prezzo che dovresti aspettarti.

5. Verifica la replica dello storage e dove si trovano le copie

I volumi persistenti sono il luogo in cui un cluster Kubernetes conserva i dati che non puoi ricostruire, quindi chiedi come sono protetti:

• Il block storage di Exoscale conserva due copie dei dati su server distinti, replicate all'interno della stessa zona, con 5.000 IOPS per volume.
• Il block storage di Scaleway (volumi NVMe) è replicato tre volte con uno SLA del 99,99% e le sue FAQ rilevano che gli IOPS possono variare durante i picchi di carico.
• Il block storage di Infomaniak funziona su un cluster Ceph cifrato con tre repliche su NVMe e dichiara fino a 4.000 IOPS garantiti.
• Hikube dichiara di replicare i dati in modo sincrono su tre data center svizzeri.

La replica protegge dalla perdita di un disco o di un server. Non è un backup, perché anche una cancellazione per errore viene replicata, e le copie all'interno di una zona o di un sito non ti proteggono dalla perdita di quella zona o di quel sito. Chiedi dove si trova ogni copia e pianifica un backup separato, off-site, per tutto ciò che non puoi permetterti di perdere.

6. Leggi le condizioni di supporto, non il titolo

"Supporto 24/7" può significare cose molto diverse. La tabella mostra che cosa ciascun provider dichiara come incluso senza costi aggiuntivi e quanto costa la copertura più rapida o h24.

Considera che cosa sono queste cifre. Sono obiettivi per la prima risposta, non per la risoluzione. OVHcloud lo dice esplicitamente: il tempo di gestione termina quando il team inizia a elaborare il ticket, non quando l'incidente è risolto, e non offre alcuna garanzia di rispettare gli obiettivi. Quando confronti i provider, chiedi l'obiettivo di risoluzione, il percorso di escalation, i canali e le lingue, e verifica se il supporto viene fatturato come percentuale della tua spesa.

7. Cerca costi di traffico e voci nascoste

Il prezzo mensile di un nodo raramente è l'intero conto. Chiedi di traffico in uscita, indirizzi IPv4 pubblici, load balancer, snapshot, richieste di object storage e costi di supporto. Infomaniak dichiara che la banda è gratuita, tranne l'object storage oltre i 10 TB di banda consumata, e UpCloud dichiara di non avere costi per il traffico in uscita. Diversi provider fatturano i livelli di supporto più rapidi come percentuale della tua spesa mensile, come mostra la tabella sopra, quindi quella voce cresce con il tuo utilizzo.

8. Chiedi dove risiedono i dati, compresi backup e log

La posizione dei dati riguarda più del database primario. Chiedi dove sono archiviati backup, log e dati di monitoraggio, quale entità gestisce l'infrastruttura e la legge di quale Paese si applica a quell'entità. Hikube offre un esempio di risposta specifica: dichiara che nessun dato passa attraverso server stranieri, compresi backup, log e metriche di monitoraggio, e che le attestazioni di residenza dei dati sono disponibili su richiesta per i revisori. Chiedi a qualsiasi provider lo stesso livello di dettaglio per iscritto.

9. Verifica l'uscita prima di entrare

Kubernetes in sé è portabile, quindi il vincolo nasce da tutto ciò che lo circonda. Chiedi se il cluster è Kubernetes upstream standard con un normale kubeconfig, se Terraform, Helm e gli strumenti GitOps funzionano su di esso, come esporti i tuoi dati e volumi e per quanto tempo le risorse vengono conservate dopo la cessazione. Un provider che risponde chiaramente a queste domande è uno che puoi lasciare, e questo rende più facile fidarsi finché si resta.

10. Esegui un test di due settimane prima di impegnarti

Chiedi una prova o un piano a basso impegno e testa ciò che conta, non la demo della console:

• Tempo al primo cluster. Crea un cluster e misura il tempo.
• Dati stateful. Distribuisci un'applicazione con un volume persistente, elimina il pod e verifica che i dati sopravvivano.
• Un aggiornamento. Aggiorna il cluster di una versione minor e annota che cosa hai dovuto fare da solo.
• Un ripristino. Ripristina da un backup o da uno snapshot in un nuovo cluster. Un backup da cui non hai ripristinato è un'ipotesi.
• Supporto. Apri un ticket di notte, classificalo come urgente e registra sia il tempo di prima risposta sia il tempo di risoluzione.
• Prestazioni sotto carico. Esegui un job intensivo di CPU su un nodo worker e verifica la presenza di CPU steal, e testa il disco con un benchmark intensivo di fsync.

Due comandi coprono l'ultimo punto. Su un nodo worker, vmstat 1 10 stampa una colonna chiamata st per il tempo di steal; valori costantemente diversi da zero mentre il tuo job è in esecuzione indicano che altri tenant ti stanno sottraendo CPU. Per i dischi, la documentazione sulle prestazioni di etcd spiega che la latenza di una richiesta è limitata dal tempo di round-trip di rete più il tempo necessario a fdatasync per scrivere i dati nello storage permanente, e indica una latenza tipica di fdatasync di circa 10 ms per un disco rotante e spesso inferiore a 1 ms per un SSD. Un modo comune per misurarla è fio con scritture sincrone e fdatasync:

fio --name=disk-latency --directory=/mnt/test --rw=write --ioengine=sync --fdatasync=1 --size=22m --bs=2300

Il report include i percentili di latenza di fdatasync. Le indicazioni di Red Hat su etcd considerano una latenza di fsync al 99° percentile inferiore a 10 ms come la soglia per un disco in grado di ospitare etcd, quindi usala come punto di riferimento quando confronti i provider.

Dove si colloca Kube-DC

Ecco come Cloud Acropolis Kube-DC risponde alle stesse domande. Elenchiamo ciò che è documentato e ciò che non lo è, così puoi metterlo alla prova con la tua checklist.

Fonti (lette a settembre 2026)

• Exoscale: SKS service-level agreement
• Exoscale: support plans
• Exoscale: SKS product page
• Exoscale: block storage
• Infomaniak: managed Kubernetes service
• Infomaniak: Public Cloud
• Infomaniak: premium support guide
• Scaleway: containers pricing (Kapsule)
• Scaleway: support plans
• Scaleway: shared vs dedicated vCPUs
• Scaleway: block storage FAQ
• OVHcloud: support levels
• OVHcloud: Standard support
• OVHcloud: Business support
• IONOS: Managed Kubernetes
• UpCloud
• Hikube by Hidora
• etcd: performance
• Red Hat: recommended etcd practices
• Kube-DC platform datasheet

Letture correlate

• Kubernetes managed vs. self-hosted: la realtà tecnica

Metti Kube-DC alla prova con la checklist

Ogni punto qui sopra può essere testato su un pacchetto Kube-DC: vCPU dedicate, storage NVMe basato su Ceph, un IPv4 pubblico dedicato, object storage compatibile S3, i tuoi cluster Kubernetes amministrati dal tenant e supporto 24/7 con un obiettivo di risoluzione di 4 ore. Ordina in un portale self-service, esegui il test di due settimane e giudicaci in base ai risultati.