Bare metal pour conteneurs
Kubernetes sur bare metal signifie que chaque nœud de votre cluster est un serveur dédié complet, sans hyperviseur entre vos pods et le matériel. Primcast loue ces serveurs au mois avec un accès root et un port non mesuré, pour que vous puissiez installer Docker, k3s, RKE2 ou kubeadm et piloter votre cluster à votre façon.
Un serveur déjà en baie est remis environ 30 minutes après validation de votre commande. Sans engagement : vous payez un mois à la fois.
01Pourquoi le bare metal
Les conteneurs partagent déjà un noyau, donc une machine virtuelle en dessous ajoute une seconde couche qui ne vous apporte rien. Sur un serveur dédié, vos charges de travail accèdent directement au processeur, à la mémoire, aux disques et à la carte réseau.
AAucune couche virtuelle
Aucun hyperviseur ne prélève une part du processeur ni ne s’interpose sur le chemin des disques et du réseau. Ce que vous mesurez sur le nœud est ce que vos conteneurs obtiennent, ce qui simplifie le réglage des requêtes et des limites.
BUn seul locataire
Personne d’autre n’exécute quoi que ce soit sur votre serveur. Un inconnu très actif ne peut pas saturer la file d’attente des disques ni la bande passante mémoire sur lesquelles comptait votre pod de base de données, et la latence reste là où vous l’aviez laissée.
CFacture fixe
Chaque serveur est livré avec un port non mesuré qui n’est pas partagé, à 1 Gbit/s ou 500 Mbit/s selon la ligne. Les pulls d’images, la réplication entre nœuds et le trafic vers vos utilisateurs n’apparaissent jamais comme un coût au gigaoctet.
DContrôle total
Vous disposez du root sur chaque serveur et pouvez réinstaller le système depuis le panneau de contrôle sans frais. Les serveurs en rack et les lames offrent aussi une console navigateur avec gestion de l’alimentation, pour le jour où un changement réseau vous enferme dehors.
02Choisissez votre parcours
Partez du besoin. Une poignée de services sur une seule machine se contente de Docker, rien de plus. Plusieurs machines qui doivent se réparer elles-mêmes exigent Kubernetes, et la question devient alors : qui s’occupe du plan de contrôle ?
| Parcours | Idéal pour | Plan de contrôle | Où aller |
|---|---|---|---|
| Docker sur un serveur dédié | Quelques applications avec Docker Compose, un runner de build, une copie de staging de la production | Aucun nécessaire | N’importe quel serveur ci-dessous |
| Votre propre cluster Kubernetes | Les équipes qui veulent choisir la distribution, le plugin réseau et les dates de mise à niveau | Vous le gérez, sur vos propres serveurs | Cette page |
| Kubernetes managé | Les équipes qui veulent kubectl et leurs propres workers, sans s’occuper d’etcd | Nous le gérons ; vos serveurs sont les workers | Kubernetes managé |
Besoin d’une seule petite machine ? Un Cloud VPS fait tourner Docker aussi. Vous voulez des machines virtuelles et des conteneurs côte à côte sur votre propre matériel ? Découvrez les serveurs Proxmox.
03Dimensionnement
La documentation kubeadm fixe le minimum : 2 Go de mémoire sur chaque machine et au moins 2 cœurs de processeur sur un nœud du plan de contrôle. Tout serveur dédié dépasse facilement ce seuil, alors dimensionnez en fonction de vos charges de travail et prévoyez trois nœuds de plan de contrôle si le cluster doit survivre à la perte de l’un d’eux.
| Rôle | Minimum | Ports à ouvrir entre vos nœuds |
|---|---|---|
| Plan de contrôle | 2 cœurs, 2 Go de mémoire | 6443, 2379-2380, 10250, 10257, 10259 |
| Worker | 2 Go de mémoire | 10250, 10256, 30000-32767 |
| Chaque nœud | Un nom d’hôte, une adresse MAC et un UUID de produit uniques | Une connectivité réseau complète vers les autres nœuds |
Un nœud de plan de contrôle et deux workers suffisent pour apprendre et pour faire tourner un environnement de staging. Placez etcd sur des serveurs équipés de disques SSD : il est sensible à la latence d’écriture du disque, et un disque lent ralentit chaque changement dans le cluster.
Trois nœuds de plan de contrôle maintiennent etcd en quorum lorsque l’un d’eux tombe en panne. Ajoutez des workers pour la capacité et placez des serveurs GPU dans le même cluster pour les tâches d’inférence ou d’encodage, en les isolant des autres pods à l’aide de labels et de taints.
04Mise en place
Voici l’ordre habituel des opérations avec kubeadm. k3s et RKE2 regroupent les étapes 2 et 3 dans un seul script d’installation, et le reste demeure identique.
Choisissez des serveurs dans la liste ci-dessous et sélectionnez une image Ubuntu ou Debian récente lors du paiement. Les serveurs en rack arrivent environ 30 minutes après l’approbation ; un serveur construit selon vos spécifications prend de 4 à 24 heures lorsque les pièces sont en stock.
Installez un runtime de conteneurs tel que containerd, gardez les horloges synchronisées et désactivez le swap, sauf si vous avez configuré la kubelet pour le gérer. Installez ensuite kubeadm, kubelet et kubectl depuis le dépôt de paquets Kubernetes.
Exécutez kubeadm init sur le premier serveur du plan de contrôle, puis la ligne kubeadm join qu’il affiche sur chaque worker. Votre kubeconfig se trouve sur ce premier serveur.
Les pods ne peuvent pas communiquer tant qu’un plugin réseau n’est pas installé. Cilium, Calico et Flannel sont les choix habituels ; Cilium et Calico appliquent également les NetworkPolicy.
N’autorisez les ports du tableau ci-dessus que depuis les adresses de vos propres nœuds, et gardez le port de l’API ouvert uniquement aux personnes qui administrent le cluster.
Le bare metal n’a pas de load balancer cloud, donc un outil comme MetalLB attribue aux Services de type LoadBalancer des adresses IPv4 supplémentaires commandées avec vos serveurs. Un contrôleur d’ingress sert ensuite vos sites sur les ports 80 et 443.
Vous n’avez besoin que de Docker ? Installez Docker Engine depuis le dépôt officiel de Docker pour votre distribution, vérifiez-le avec docker run hello-world, puis exécutez votre stack avec Docker Compose. C’est toute la configuration nécessaire.
05Serveurs
Chaque serveur ci-dessous peut être un hôte Docker ou un nœud dans un cluster Kubernetes autogéré. Les prix et les spécifications proviennent directement du catalogue ; ouvrez-en un pour voir ses options et le commander.
06Avant de commander
Sur cette offre, nous nous occupons du matériel et du réseau, et vous vous occupez de tout ce qui se trouve au-dessus du système d’exploitation. Voici où se situe la limite.
07Questions
En général, oui, car rien ne s’interpose entre vos pods et le matériel. Une machine virtuelle ajoute un hyperviseur sur le chemin du processeur, du disque et du réseau, et partage souvent l’hôte avec d’autres clients. Sur un serveur dédié, vos conteneurs disposent de toute la machine, et leurs performances ne changent pas lorsque quelqu’un d’autre est très actif.
Oui. Vous disposez d’un accès root : vous installez donc Docker Engine depuis le dépôt de Docker pour votre distribution et vous exécutez immédiatement vos conteneurs ou une pile Docker Compose. Beaucoup commencent ainsi et ajoutent Kubernetes une fois qu’ils ont plus d’un serveur.
Pas sur les serveurs de cette page : vous choisissez la distribution et vous gérez le cluster vous-même. Si vous préférez ne pas vous occuper du plan de contrôle, notre Kubernetes managé l’exécute pour vous à New York, tandis que vos serveurs dédiés restent les workers, avec un accès root conservé sur chacun.
Un seul serveur peut exécuter un cluster à nœud unique avec k3s ou kubeadm, ce qui convient au développement. Pour un cluster qui continue de fonctionner lorsqu’une machine tombe en panne, utilisez trois nœuds de plan de contrôle afin qu’etcd conserve son quorum, plus autant de workers que vos charges de travail l’exigent.
Il n’y a pas de répartiteur de charge cloud à appeler : vous en installez donc un dans le cluster. MetalLB est le choix courant : il attribue à chaque Service de type LoadBalancer l’une des adresses IPv4 supplémentaires que vous avez commandées avec vos serveurs et l’annonce sur le réseau.
Non. Rien ne compte le trafic sur un serveur dédié. Chacun possède son propre port, 1 Gbps ou 500 Mbps selon la ligne, et les téléchargements d’images, la réplication et le trafic utilisateur passent tous par ce port pour le même prix mensuel.
Un serveur déjà en rack est prêt environ 30 minutes après l’approbation de votre commande, avec le système d’exploitation que vous avez choisi. Un serveur construit selon vos propres spécifications prend de 4 à 24 heures lorsque nous avons les pièces. L’approbation elle-même, le paiement et les vérifications antifraude interviennent d’abord et constituent la partie variable.
Notre chat IA répond en quelques secondes et peut vérifier votre compte et vos serveurs à votre place, et une personne prend le relais dès que vous le demandez. Nous résolvons les problèmes de matériel et de réseau ; les questions internes à votre cluster vous reviennent, mais nous sommes heureux de vous orienter dans la bonne direction.
Louez les serveurs au mois, conservez un accès root sur chacun et exécutez Docker ou Kubernetes comme vous le souhaitez. Sans contrat, sans trafic comptabilisé.