Commandable dès maintenant · New York
Kubernetes upstream, construit avec RKE2, où le serveur d’API, le scheduler et etcd sont à notre charge et où chaque nœud worker est un serveur dédié que vous louez chez nous. Pas d’hyperviseur sous vos pods, pas de voisin sur vos cœurs, et vous conservez l’accès SSH root, la console et le mode rescue sur chaque nœud.
Des questions avant de commander ? . Notre IA répond en quelques secondes et peut consulter votre compte et vos serveurs ; un ingénieur prend le relais dès que vous le demandez. Pas de chat ? Écrivez-nous depuis la page de contact.
La division du travail
De nombreux services Kubernetes managés gardent les nœuds hors de votre portée. Ici, la ligne est tracée au niveau du plan de contrôle : tout ce qui se trouve au-dessus relève de notre responsabilité, chaque machine en dessous reste la vôtre.
Pourquoi les workers sont en bare metal
Un pod sur une VM cloud tourne sur un noyau invité par-dessus un noyau hôte. Sur un nœud dédié, il n’y a qu’un seul noyau, directement sur le matériel : les cœurs et la mémoire que vous louez servent à vos pods, et non à un second système d’exploitation en dessous.
La charge de travail de personne d’autre ne partage la machine, ses disques ou sa bande passante mémoire. Un benchmark lancé le lundi n’est pas faussé par le job batch de quelqu’un d’autre le vendredi.
Les serveurs worker sont facturés au forfait mensuel, sans frais par gigaoctet sortant du cluster. Servir du trafic ne se transforme pas en seconde facture.
Kubernetes est un projet open source de la CNCF sous licence Apache 2.0, et RKE2 l’exécute en amont. Les manifests qui tournent ici tournent sur n’importe quel cluster conforme : partir vous coûte une migration, pas une réécriture.
La pile
| Couche | Ce que c'est |
|---|---|
| Distribution | RKE2, Kubernetes conforme CNCF en amont |
| Plan de contrôle | Exploité par nos soins : 1 nœud pour le développement, 3 nœuds pour la haute disponibilité |
| État du cluster | etcd intégré, sauvegardé toutes les 6 heures |
| Nœuds de travail | Serveurs dédiés sur votre compte, choisis un par un dans le stock de New York et pris tels quels, déjà sous Ubuntu 24.04 ou 26.04 (pas de réinstallation, pas de frais d'installation) ; de 1 à 10 par commande, d'autres ajoutés plus tard jusqu'à 10 |
| Planification | Un seul pool, chaque nœud étiqueté pool=general ; étiquettes et marques supplémentaires définies par vous avec kubectl (cluster-admin) |
| Réseau des pods | Cilium, avec application de Kubernetes NetworkPolicy ; pas de chiffrement entre les nœuds, utilisez donc TLS ou mTLS dans vos applications, ou un maillage de services, là où le trafic doit être chiffré |
| Équilibreurs de charge | MetalLB : un Service de type LoadBalancer prend l'une des adresses IPv4 supplémentaires sur vos serveurs de travail |
| Réseau des nœuds | Les adresses publiques des nœuds, avec un pare-feu qui n'admet que les propres nœuds du cluster ; pas de VLAN privé |
| Accès | Téléchargement du kubeconfig ; SSH root, console et mode de secours sur chaque nœud de travail |
| Mises à niveau | Lancées par vous ; d'abord le plan de contrôle, puis les nœuds un par un |
| Emplacement | New York |
Voici comment chaque cluster que nous construisons à New York est assemblé. Si une couche change, ce tableau change avec elle.
Nœuds de calcul
Une commande comprend de 1 à 10 serveurs de calcul, chacun choisi parmi les machines de New York disponibles immédiatement, et le tableau de bord en ajoute d’autres par la suite, jusqu’à 10 au total. Chaque nœud de calcul rejoint un pool et porte le label pool=general. Vous disposez du rôle cluster-admin : séparer les machines GPU de la couche web n’est qu’à un kubectl label et un kubectl taint près.
pool=general vous appartiennent ; nous n’ajoutons aucune règle de planification propre$ kubectl label node k8s-250123-w3 gpu=true
$ kubectl taint node k8s-250123-w3 gpu=true:NoSchedule
apiVersion: v1
kind: Pod
metadata: name: inference
spec: nodeSelector: gpu: "true" tolerations: - key: gpu operator: Exists effect: NoSchedule containers: - name: model image: ghcr.io/example/model:1.0Questions
Managé. Nous opérons le plan de contrôle, y compris etcd et ses snapshots, et nous pilotons les mises à niveau lorsque vous en lancez une. Vos serveurs dédiés rejoignent le cluster comme nœuds worker, et vous n'avez jamais à opérer le plan de contrôle vous-même.
RKE2, une distribution conforme CNCF qui fournit Kubernetes upstream. Vos manifests, charts Helm et opérateurs fonctionnent comme sur n'importe quel autre cluster conforme.
Oui. Chaque worker est un serveur dédié sur votre compte, avec SSH root, la console et le mode rescue, exactement comme lorsqu'il ne fait pas partie d'un cluster. C'est la principale différence avec la plupart des Kubernetes managés, où les nœuds vous sont souvent fermés.
MetalLB leur attribue les adresses IPv4 supplémentaires de vos serveurs worker, de sorte que l'adresse devant votre Service est une adresse que vous détenez déjà plutôt qu'une adresse prêtée depuis un pool partagé.
Non, il n'y a pas de VLAN privé par cluster. Les nœuds communiquent entre eux via leurs adresses publiques sur notre réseau, et un pare-feu sur chaque nœud n'admet que les nœuds du cluster lui-même. Le trafic entre nœuds n'est pas chiffré par le cluster : les politiques réseau Cilium contrôlent quels pods peuvent communiquer, et pour un trafic chiffré entre services, utilisez TLS ou mTLS dans vos applications, ou un service mesh.
Oui. Vous choisissez chaque serveur worker parmi les machines de New York disponibles immédiatement, donc les serveurs GPU et CPU peuvent rejoindre le même cluster. Ils démarrent tous dans un pool étiqueté pool=general ; avec cluster-admin, vous étiquetez et appliquez des taints aux nœuds GPU vous-même, et les workloads choisissent entre eux avec des node selectors et des tolérances.
Vous choisissez le moment. Nous mettons d'abord à niveau le plan de contrôle, puis les nœuds worker un par un, de sorte qu'un workload exécutant plus d'un replica continue de servir pendant que le cluster passe à la nouvelle version.
Oui, à New York. Sur la page de commande, vous choisissez un plan de contrôle Dev ou HA et de un à dix serveurs worker parmi les machines de New York disponibles immédiatement ; le cluster est construit une fois les premières factures payées, et son kubeconfig vous attend dans votre tableau de bord.
Choisissez un plan de contrôle, nommez le cluster et sélectionnez de un à dix serveurs worker. Les workers sont livrés exactement tels qu’ils sont en stock, déjà sous Ubuntu 24.04 ou 26.04, sans frais d’installation ; ils rejoignent le cluster dès la livraison, une fois leurs premières factures réglées. Le kubeconfig apparaît dans votre tableau de bord dès que le cluster est prêt.
Vous préférez gérer Kubernetes vous-même ? Consultez le bare metal pour conteneurs. Besoin d’une seule petite machine plutôt que d’un cluster ? Un Cloud VPS est une machine virtuelle KVM ; la page des serveurs dédiés liste les machines pouvant servir de worker.