Clusters Kubernetes dans des centres de données Tier III de l'EU avec options single-node et HA
Kubernetes mono-noeud, préinstallé au premier démarrage, sans surprises!
Infrastructure de niveau entreprise avec garantie de disponibilité 99.9% dans les emplacements UE
Obtenez vos serveurs et ressources en ligne en heures, pas en jours. Aucuns frais d'installation
Vous pouvez upgrader ou downgrader votre serveur cloud en ligne en utilisant le panneau personnel sur notre site web
Vous choisissez la taille des nœuds et le cluster est construit puis remis prêt à l'emploi : plan de contrôle, runtime de conteneurs, réseau CNI, un contrôleur d'ingress et une classe de stockage adossée au même NVMe que toutes les autres machines ici. Le kubeconfig se télécharge depuis votre panneau dès que le cluster est en route.
C'est un vrai cluster sur de vraies VM dans nos propres centres de données, pas une abstraction managée au-dessus de l'API d'un tiers. kubectl, Helm et tout ce qui parle à l'API Kubernetes fonctionnent exactement comme ailleurs, parce qu'il n'y a rien d'inhabituel au milieu.
Partez de ce qui tournera sur le cluster plutôt que d'un nombre de nœuds. Additionnez les demandes de CPU et de mémoire de tout ce que vous comptez ordonnancer, ajoutez la charge du plan de contrôle et des pods système, puis laissez assez de marge pour qu'un nœud puisse tomber sans que les autres refusent ses pods.
Trois petits nœuds valent généralement mieux qu'un gros dès que la disponibilité compte, car un nœud unique n'est qu'à un redémarrage de l'indisponibilité. Pour le développement et la CI, un nœud suffit et coûte bien moins cher.
Vous payez les nœuds - aux mêmes tarifs CPU, RAM et NVMe que n'importe quel serveur cloud - plus un petit forfait de gestion pour le cluster lui-même. Les clusters Kubernetes démarrent à 22 EUR par mois.
Autrement dit, un cluster n'est jamais mystérieusement plus cher que les machines qui le composent, et le mettre à l'échelle relève de la même arithmétique que tout le reste ici.
Des parcs de microservices devenus trop grands pour un seul hôte Docker, des applications qui exigent des déploiements progressifs sans fenêtre de maintenance, et des charges de CI ou d'agents qui montent en charge puis disparaissent.
Les runners CI auto-hébergés forment un duo fréquent : un cluster leur donne où déborder et garde les artefacts de build et le code source dans votre propre infrastructure européenne.
GitLab Runner· GitHub Actions Runner· Runners d'agents dans l'UE
Si vous voulez bâtir le cluster vous-même - une distribution précise, un CNI particulier, une topologie inhabituelle -, commandez de simples serveurs cloud et traitez-les comme des nœuds. Rien ici ne vous en empêche, et les machines sont identiques.
Prenez l'option managée si vous préférez ne pas passer la première semaine sur le plan de contrôle, et si un ingress et une classe de stockage fonctionnels dès le premier jour valent plus que de choisir chaque composant vous-même.
Les nœuds peuvent être ajoutés ou redimensionnés quand la demande change, exactement comme un serveur cloud. Les montées de version du cluster sont coordonnées avec vous plutôt qu'appliquées sous vos pieds, car une version mineure de Kubernetes est un changement d'API et quelque chose dans vos manifestes finit généralement par le remarquer.
Migrer relève surtout du travail sur les manifestes : pointer Helm vers le nouveau cluster, restaurer les volumes persistants depuis vos propres sauvegardes, puis basculer le DNS dès que le nouvel ingress répond correctement.
Questions fréquentes
Un cluster Kubernetes fonctionnel sur des VM cloud dans notre propre centre de données : plan de contrôle, runtime de conteneurs, réseau CNI, un contrôleur d'ingress et une classe de stockage par défaut sur NVMe. Le kubeconfig se télécharge depuis votre panneau dès que le cluster est en route
Un seul nœud convient pour le développement, la CI et tout ce que vous pouvez vous permettre de perdre le temps d'un redémarrage. Choisissez plusieurs nœuds dès qu'une indisponibilité compte : avec trois nœuds, le cluster peut en perdre un et replanifier ses pods sur les deux autres
Téléchargez le kubeconfig depuis votre panneau de gestion et pointez kubectl ou Helm dessus. Rien n'est encapsulé ni passé par un proxy : c'est un point d'accès standard de l'API Kubernetes, donc tout outil qui parle à Kubernetes fonctionne sans modification
Vous payez les nœuds aux mêmes tarifs CPU, RAM et NVMe que n'importe quel serveur cloud, plus un petit forfait de gestion pour le cluster lui-même. Mettre un cluster à l'échelle coûte exactement ce que coûterait l'ajout des serveurs équivalents
Oui. Les nœuds peuvent être ajoutés, retirés ou redimensionnés quand la demande change, comme n'importe quel serveur cloud : le disque s'agrandit sur place, et les changements de CPU et de RAM ne demandent qu'un redémarrage de ce nœud
Les montées de version sont coordonnées avec vous plutôt qu'appliquées sous vos pieds. Une version mineure de Kubernetes est un changement d'API et, dans un vrai jeu de manifestes, quelque chose finit généralement par le remarquer : nous convenons donc d'une fenêtre et vous pouvez tester avant
Oui, et les machines sont identiques : commandez des serveurs cloud et traitez-les comme des nœuds si vous voulez une distribution, un CNI ou une topologie précis. L'option managée existe pour qu'un ingress et une classe de stockage fonctionnels dès le premier jour soient le problème de quelqu'un d'autre
Si vous avez besoin d'aide ou avez des questions supplémentaires, veuillez contacter les managers ou écrire à l'équipe de support à support@dcxv.com
