Comment évaluer un fournisseur de Kubernetes géré en Europe

September 2026 • Comparison

Une page de tarifs de Kubernetes géré ne vous dit pas ce qui se passe quand quelque chose tourne mal la nuit. Cette liste de contrôle couvre les questions qui en décident et, pour chacune, montre ce que plusieurs fournisseurs européens publient réellement. Chaque fait relatif à un fournisseur provient de sa propre documentation ou de sa page de tarifs, lue en septembre 2026, et est référencé dans la section Sources.

1. Demandez ce qui est réellement géré

Les fournisseurs placent la frontière entre leur travail et le vôtre à des endroits différents. L'accord de niveau de service SKS d'Exoscale est explicite : il ne couvre que la disponibilité du plan de contrôle, et non les nœuds de travail, les pods, les volumes, les applications ou les données. Le client reste responsable des charges de travail, du contrôle d'accès au cluster, des données persistantes, des sauvegardes, de la planification de la reprise après sinistre et des procédures de restauration.

D'autres fournisseurs décrivent davantage d'automatisation. IONOS indique que son service géré applique automatiquement les mises à jour et les correctifs de sécurité, et que vous choisissez le moment. Infomaniak indique que vous pouvez mettre à jour le plan de contrôle et les nœuds de travail à tout moment, et qu'il gère tous les composants Kubernetes. Quelle que soit la formulation, obtenez des réponses écrites à ces questions :

• Qui met à niveau le plan de contrôle, qui met à niveau les nœuds de travail, et qui décide du calendrier ?
• Qui applique les correctifs au système d'exploitation des nœuds de travail ?
• Qui est responsable des sauvegardes de l'état du cluster et de vos volumes persistants ?
• Quels modules complémentaires (réseau, ingress, métriques) sont fournis, et qui les maintient à jour ?

2. Vérifiez quel niveau de plan de contrôle vous achetez réellement

Un plan de contrôle gratuit n'est pas le même produit qu'un plan de contrôle payant. Les niveaux gratuits ci-dessous sont partagés et sans SLA, tandis que les niveaux payants ajoutent des répliques, un datastore dédié et un objectif de disponibilité écrit.

Cela compte en raison de la façon dont Kubernetes est conçu. Comme l'explique notre article sur Kubernetes géré et auto-hébergé, la documentation Kubernetes recommande des clusters etcd à plusieurs membres en production, et etcd a besoin d'une majorité de ses membres pour effectuer des modifications. Une seule réplique d'API sur un datastore partagé est un choix raisonnable pour le développement, et un choix fragile pour la production.

3. Lisez le SLA pour savoir ce qu'il couvre

Deux fournisseurs peuvent afficher un même pourcentage en voulant dire des choses très différentes. Demandez ce qui est mesuré (disponibilité de l'API du plan de contrôle, disponibilité des nœuds, ou les deux), sur quelle période, ce qui est exclu, et ce que vous recevez si l'objectif n'est pas atteint. Exoscale, par exemple, crédite 50 % des frais mensuels des ressources concernées lorsque la disponibilité tombe entre 99,95 % et 98,3 %, et 100 % en dessous. Il exclut aussi les défaillances des nœuds, volumes et pods, car son SLA s'applique au plan de contrôle.

Il est aussi utile de traduire le pourcentage en durée. Sur un mois de 30 jours :

Scaleway indique 99,5 % pour ses plans de contrôle Kapsule dédiés, Infomaniak indique 99,9 % pour ses niveaux dédiés, et Exoscale indique au moins 99,95 % pour son offre Pro. Ces chiffres ne sont comparables que si les définitions concordent : lisez donc les définitions avant de comparer les chiffres.

4. Demandez si les vCPU sont dédiés

Les vCPU partagés sont planifiés sur des cœurs physiques que plusieurs machines virtuelles utilisent en même temps. La documentation de Scaleway en décrit clairement la conséquence : lors des pics de demande de charges voisines, vos charges de travail peuvent ralentir à cause de la contention CPU, appelée CPU steal. Les vCPU dédiés donnent un accès exclusif aux cœurs physiques et des performances constantes. Les propres recommandations de Scaleway citent les nœuds de travail des clusters Kubernetes parmi les usages typiques des instances partagées, ce qui est un choix acceptable pour le développement et un vrai compromis pour la production.

IONOS vous laisse choisir entre cœurs dédiés et vCPU pour les nœuds de travail de son Kubernetes géré. De nombreux fournisseurs n'indiquent pas lequel vous obtenez avec une offre donnée. Si la documentation est muette, posez la question par écrit, car cela change à la fois les performances et le prix auquel vous devez vous attendre.

5. Vérifiez la réplication du stockage, et où se trouvent les copies

Les volumes persistants sont l'endroit où un cluster Kubernetes conserve les données que vous ne pouvez pas reconstruire ; demandez donc comment ils sont protégés :

• Le stockage bloc d'Exoscale conserve deux copies des données sur des serveurs distincts, répliquées au sein de la même zone, avec 5 000 IOPS par volume.
• Le stockage bloc de Scaleway (volumes NVMe) est répliqué trois fois avec un SLA de 99,99 %, et sa FAQ précise que les IOPS peuvent fluctuer lors des pics de charge.
• Le stockage bloc d'Infomaniak repose sur un cluster Ceph chiffré avec trois répliques sur NVMe, et annonce jusqu'à 4 000 IOPS garantis.
• Hikube indique répliquer les données de façon synchrone sur trois datacenters suisses.

La réplication protège contre la perte d'un disque ou d'un serveur. Ce n'est pas une sauvegarde, car une suppression accidentelle est elle aussi répliquée, et des copies au sein d'une même zone ou d'un même site ne vous protègent pas de la perte de cette zone ou de ce site. Demandez où se trouve chaque copie, et prévoyez une sauvegarde distincte, hors site, pour tout ce que vous ne pouvez pas vous permettre de perdre.

6. Lisez les conditions de support, pas le titre

« Support 24h/24 et 7j/7 » peut recouvrir des réalités très différentes. Le tableau montre ce que chaque fournisseur indique comme inclus sans frais supplémentaires et ce que coûte la couverture plus rapide ou permanente.

Notez bien ce que sont ces chiffres. Ce sont des objectifs de première réponse, pas de résolution. OVHcloud le dit lui-même : son délai de prise en charge s'arrête lorsque l'équipe commence à traiter le ticket, et non lorsque l'incident est résolu, et il ne garantit pas d'atteindre ces objectifs. Lorsque vous comparez des fournisseurs, demandez l'objectif de résolution, le circuit d'escalade, les canaux et les langues, et vérifiez si le support est facturé en pourcentage de vos dépenses.

7. Cherchez les frais de trafic et les postes de coûts cachés

Le prix mensuel d'un nœud est rarement toute la facture. Interrogez-vous sur le trafic sortant, les adresses IPv4 publiques, les équilibreurs de charge, les instantanés, les requêtes de stockage objet et les frais de support. Infomaniak indique que la bande passante est gratuite, sauf pour le stockage objet au-delà de 10 To de bande passante consommée, et UpCloud indique n'avoir aucun frais de trafic sortant. Plusieurs fournisseurs tarifent leurs niveaux de support plus rapides en pourcentage de vos dépenses mensuelles, comme le montre le tableau ci-dessus : ce poste augmente donc avec votre utilisation.

8. Demandez où résident les données, y compris les sauvegardes et les journaux

La localisation des données ne se limite pas à la base de données principale. Demandez où sont stockés les sauvegardes, les journaux et les données de supervision, quelle entité exploite l'infrastructure, et quel droit national s'applique à cette entité. Hikube donne un exemple de réponse précise : il indique qu'aucune donnée ne transite par des serveurs étrangers, y compris les sauvegardes, les journaux et les métriques de supervision, et que des attestations de résidence des données sont disponibles sur demande pour les auditeurs. Exigez le même niveau de détail par écrit de la part de n'importe quel fournisseur.

9. Vérifiez la sortie avant d'entrer

Kubernetes lui-même est portable : l'enfermement vient donc de tout ce qui l'entoure. Demandez si le cluster est du Kubernetes standard en amont avec un kubeconfig normal, si les outils Terraform, Helm et GitOps fonctionnent avec lui, comment vous exportez vos données et volumes, et combien de temps les ressources sont conservées après la résiliation. Un fournisseur qui répond clairement à ces questions est un fournisseur que vous pouvez quitter, ce qui le rend plus facile à croire tant que vous restez.

10. Menez un test de deux semaines avant de vous engager

Demandez un essai ou une offre à faible engagement, et testez ce qui compte plutôt que la démonstration de la console :

• Délai avant le premier cluster. Créez un cluster et chronométrez-le.
• Données avec état. Déployez une application avec un volume persistant, supprimez le pod, et vérifiez que les données survivent.
• Une mise à niveau. Mettez le cluster à niveau d'une version mineure et notez ce que vous avez dû faire vous-même.
• Une restauration. Restaurez depuis une sauvegarde ou un instantané vers un nouveau cluster. Une sauvegarde que vous n'avez pas restaurée n'est qu'une hypothèse.
• Le support. Ouvrez un ticket la nuit, classez-le comme urgent, et relevez à la fois le délai de première réponse et le délai de résolution.
• Les performances sous charge. Exécutez une tâche gourmande en CPU sur un nœud de travail et surveillez le CPU steal, puis testez le disque avec un benchmark intensif en fsync.

Deux commandes couvrent le dernier point. Sur un nœud de travail, vmstat 1 10 affiche une colonne nommée st pour le temps de vol (steal) ; des valeurs non nulles soutenues pendant l'exécution de votre tâche signifient que d'autres tenants vous prennent du CPU. Pour les disques, la documentation de performance d'etcd explique que la latence d'une requête est bornée par le temps d'aller-retour réseau plus le temps dont fdatasync a besoin pour valider les données sur un stockage permanent, et situe la latence typique de fdatasync à environ 10 ms pour un disque rotatif et souvent sous 1 ms pour un SSD. Une façon courante de la mesurer est fio avec des écritures synchrones et fdatasync :

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

Le rapport inclut des percentiles de latence de fdatasync. Les recommandations etcd de Red Hat considèrent qu'une latence fsync au 99e percentile inférieure à 10 ms est le seuil pour un disque pouvant héberger etcd : utilisez-la comme point de repère lorsque vous comparez des fournisseurs.

Où en est Kube-DC

Voici comment Cloud Acropolis Kube-DC répond aux mêmes questions. Nous indiquons ce qui est documenté et ce qui ne l'est pas, afin que vous puissiez le tester avec votre propre liste de contrôle.

Sources (consultées en septembre 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

À lire aussi

• Kubernetes géré vs auto-hébergé : la réalité technique

Passez Kube-DC au crible de la liste de contrôle

Chaque point ci-dessus peut être testé sur un forfait Kube-DC : vCPU dédiés, stockage NVMe reposant sur Ceph, une IPv4 publique dédiée, un stockage objet compatible S3, vos propres clusters Kubernetes administrés par le tenant, et un support 24h/24 et 7j/7 avec un objectif de résolution de 4 heures. Commandez dans un portail en libre-service, menez le test de deux semaines, et jugez-nous sur les résultats.