Faut-il exécuter Kubernetes sur bare metal ou sur des VM ?

Quand le bare metal est-il le meilleur endroit pour Kubernetes ?

Lorsque vous avez au moins trois serveurs et que vos charges de travail veulent le matériel lui-même. Trois machines donnent trois membres etcd sur trois domaines de défaillance distincts. Les pods atteignent les disques NVMe sans couche de disque virtuel, ce qui convient aux bases de données sur volumes locaux. Il y a un seul noyau à patcher et une seule pile réseau à déboguer.

Le réseau reste simple aussi. Chaque nœud détient l'IPv4 propre à son serveur, donc k3s ServiceLB ou un contrôleur d'ingress répond sur de vraies adresses. Notre guide sur comment exécuter Kubernetes sur des serveurs bare metal en détaille les étapes.

Le point faible, c'est la récupération. Il n'y a pas de console IPMI ni KVM-over-IP pour les clients : vous demandez les redémarrages et les réinstallations dans le tableau de bord et l'équipe les exécute. Une mauvaise modification réseau sur un nœud bare peut se terminer par une réinstallation. Un serveur de remplacement arrive vite, en moins d'une heure, mais reconstruire un nœud reste du travail. Gardez assez de capacité pour perdre un nœud pendant des heures, pas des minutes.

Quand les VM sont-elles le meilleur choix ?

Quand vous avez une ou deux machines, plusieurs clusters à faire tourner, ou Talos en tête. Un hôte Proxmox transforme un serveur en cluster de staging, en cluster de production et en banc de test. Chaque VM peut être snapshottée avant une mise à niveau et restaurée après un échec.

• Talos Linux. Il ne démarre que depuis sa propre ISO, son script PXE ou son image disque. Une VM Proxmox monte l'ISO, donc Talos ne fonctionne ici qu'en VM.
• Une console de dernier recours. L'hôte n'en a pas, mais chaque VM en a une dans l'interface web Proxmox. Un réseau invité cassé se répare depuis cette console, pas par une réinstallation.
• Densité de pods. Kubernetes v1.37 est conçu pour 110 pods par nœud au maximum. Répartir Lumen 32 (32 cœurs / 64 threads) en VM donne à chaque VM ses propres 110.

Le guide Proxmox de Sidero dimensionne les VM de control plane Talos à 2 cœurs ou plus et 4 GB. Les workers reçoivent 4 cœurs ou plus et 8 GB. Il règle le type de CPU sur host pour AVX-512 et x86-64-v2, et note que cela bloque la migration à chaud.

Un cluster de trois VM sur un seul serveur est-il hautement disponible ?

Non : il survit à une VM plantée, pas à un serveur mort. etcd garde le quorum tant que deux membres sur trois tournent, donc une VM peut tomber. Quand l'hôte tombe, les trois membres tombent en même temps.

Le guide de haute disponibilité Kubernetes nomme ce risque pour les control planes empilés : perdre un nœud fait perdre un membre etcd et une instance de control plane d'un coup. Sur un seul hôte, ce nœud, c'est tout le cluster. Trois VM sur une seule machine sont un quorum, pas de la redondance. Utilisez-les pour le staging, les labs et les essais Talos, et gardez la production sur trois machines.

Puis-je combiner les deux : des VM Kubernetes sur un cluster Proxmox ?

Oui : trois hôtes Proxmox avec une VM de control plane chacun est la conception la plus flexible. Chaque hôte est son propre domaine de défaillance, et les VM gardent leurs snapshots et leurs consoles. Le prix à payer, ce sont deux couches de clustering, corosync pour Proxmox et etcd pour Kubernetes, et les deux veulent une faible latence. Gardez les trois hôtes dans une même ville.

Des VM sur des hôtes différents ont besoin d'un réseau partagé. Proxmox SDN en construit un avec une zone VXLAN, mais sa documentation prévient que VXLAN seul n'a pas de chiffrement. Faites-le passer sur WireGuard ou un autre VPN entre les hôtes. VXLAN prend aussi 50 octets par paquet, donc les invités utilisent un MTU de 1450.

Notre guide sur la construction d'un cluster Proxmox avec des serveurs dédiés loués couvre le quorum et corosync sur des adresses publiques.

Un hyperviseur ralentit-il Kubernetes ?

Il ajoute une couche, et Lumenfer n'a rien mesuré, donc nous ne donnons aucun chiffre. Une VM voit des CPU virtuels, un disque virtuel et une carte réseau virtuelle. Les fonctionnalités du CPU n'atteignent l'invité que si le type de CPU les fait passer. La mémoire attribuée à une VM est perdue pour les autres et pour l'hôte.

Testez votre propre déploiement sur un nœud bare metal et sur une VM avant de vous engager. Notre guide pour trouver des benchmarks honnêtes explique comment mesurer vous-même un serveur loué.

Quels plans Lumenfer conviennent à chaque conception ?

Le bare metal demande trois serveurs ; les VM peuvent commencer avec un seul gros. Les prix sont par serveur ; les engagements de 6 et 12 mois coûtent moins par mois.

13 des 18 hébergeurs crypto sans KYC, dans la vérification de Lumenfer sur 30 October 2026, vendaient un serveur dédié avec un CPU de 2022 ou plus récent et du NVMe uniquement. Ces serveurs représentaient 113 des 229 plans comparables. Chaque plan figure sur combien coûte un serveur Lumenfer, et le cas de migration est traité dans faut-il passer d'AWS au bare metal.