Orchestration de conteneurs : Kubernetes sur Bare Metal

Tous les services Kubernetes gérés, EKS, GKE, AKS, tournent sur du bare metal. Le plan de contrôle est sur du matériel physique. Vos nœuds de travail sont soit des machines virtuelles qui louent des tranches de serveurs physiques, soit des instances bare metal qui suppriment complètement la couche VM. La valeur du service géré, c'est dans l'automatisation du plan de contrôle et les intégrations de l'écosystème, pas dans un avantage fondamental de l'infrastructure.

Exécuter K8s sur des serveurs bare metal ou dédiés InMotion, ça veut dire que tes pods tournent directement sur du matériel physique sans les frais d'hyperviseur, avec NVMe prévisible pour les volumes persistants et un coût mensuel fixe qui ne dépend pas du nombre d'heures de nœud ou du volume d'appels API.

Table des matières

Le problème de la surcharge de l'hyperviseur dans Cloud K8s

Les nœuds de travail Cloud Kubernetes sont des machines virtuelles. KVM, Xen ou Hyper-V se trouvent entre vos conteneurs et le matériel physique. Ça ajoute deux contraintes de performance que le bare metal élimine :

Charge CPU : les hyperviseurs ajoutent généralement une charge CPU de 5 à 15 % pour les appels système et les changements de contexte. Pour les charges de travail qui font beaucoup d'appels système (services qui utilisent beaucoup le réseau, applis qui dépendent des E/S), ça crée une latence qu'on peut mesurer.
Surcharge mémoire : les hyperviseurs gèrent leurs propres structures mémoire en plus de la mémoire des machines virtuelles. Un nœud de travail cloud de 16 Go a moins de 16 Go de mémoire disponible pour les composants système et les pods Kubernetes après la surcharge de l'hyperviseur et du système d'exploitation invité.

Sur du matériel nu, un serveur de 192 Go offre à Kubernetes la totalité des 192 Go, moins la surcharge du noyau du système d'exploitation (environ 2 à 4 Go). Chaque Go de capacité de nœud est réel, et non nominal.

Options d'architecture en cluster

K8s à nœud unique pour le développement et la mise en scène

Un seul serveur InMotion Hosting qui tourne sous k3s ou kubeadm avec les rôles maître et travailleur combinés, c'est un environnement de test pratique. k3s est super bien pour ça : il utilise une distribution Kubernetes de qualité production avec un seul binaire, SQLite (ou etcd externe pour la haute disponibilité) et un encombrement minimal qui laisse plus de ressources pour les charges de travail.

K8s à nœud unique, c'est pas vraiment l'idéal pour les charges de travail qui ont besoin d'une haute disponibilité (si un nœud plante, tout s'arrête), mais c'est parfait pour refléter les configurations de production en préproduction sans avoir à payer pour plusieurs serveurs.

Clusters de production multi-nœuds

Un cluster Kubernetes de production a besoin d'au moins 3 nœuds de plan de contrôle pour le quorum etcd. En pratique, plein d'équipes utilisent 1 serveur de plan de contrôle dédié plus 2 ou 3 nœuds de travail. Avec les serveurs dédiés InMotion :

Plan de contrôle : niveau avancé (149,99 $/mois), 64 Go de RAM suffisent pour les composants du plan de contrôle K8s sur les clusters de moins de 100 nœuds.
Nœuds de travail : niveau Extreme (349,99 $/mois) par nœud pour les charges de travail gourmandes en mémoire ; niveaux Essential ou Advanced pour les profils de pods plus légers.
Réseau : port 10 Gbit/s sur les nœuds de travail pour le trafic inter-pods dans les maillages de services à haut débit

Planification de la densité des pods sur un matos de 192 Go / 16 cœurs

La densité des pods Kubernetes dépend des demandes de ressources et des limites définies dans les spécifications des pods. Voici un cadre de planification approximatif :

Profil du pod	Demande de CPU	Demande de mémoire	Pods par nœud de 192 Go
Microservice (classique)	100m	256 Mo	Environ 600 pods (limite de mémoire)
Pod d'application web	250m	512 Mo	Environ 300 pods (limite mémoire)
Pod de service API	500m	1GB	Environ 160 pods (limite mémoire)
Base de données sidecar / opérateur	1 noyau	4GB	Environ 40 pods (limité par la mémoire)

En gros, Kubernetes garde des ressources pour les pods système (espace de noms kube-system), le système d'exploitation du nœud et la marge d'éviction. La mémoire qu'on peut allouer sur un nœud de 192 Go est généralement d'environ 175 à 180 Go après ces réservations. Les chiffres ci-dessus sont des maxima théoriques ; les clusters réels tournent à 60-70 % de la densité max pour garder une marge de planification.

Le processeur EPYC à 16 cœurs gère facilement la planification des pods jusqu'à environ 500 pods actifs avant que le processeur ne devienne un frein. La plupart des clusters réels avec 100 à 300 pods sont loin d'atteindre cette limite.

Profitez des performances AMD pour vos tâches

Le serveur dédié Extreme d'InMotion combine un processeur AMD EPYC 4545P avec 192 Go de RAM DDR5 et une bande passante extensible à 10 Gbit/s. Il est conçu pour le streaming, les API et les applications CRM qui ont besoin d'une capacité extensible.

Optez pour l'hébergement entièrement géré avec Premier Care pour une administration experte ou pour un serveur physique autogéré pour un contrôle total.

Découvre le plan Extreme

Stockage : volumes persistants sur NVMe

Fournisseur de chemin local

La configuration la plus simple pour un volume persistant pour un stockage à nœud unique ou par nœud utilise le provisionneur local-path (géré par Rancher, inclus par défaut dans k3s). Ça crée des PersistentVolumeClaims soutenus par des répertoires sur le NVMe du nœud.

Pour les charges de travail qui n'ont pas besoin de stockage pour survivre aux pannes de nœuds (applications sans état avec bases de données externes, tâches utilisant un espace de travail temporaire), le chemin d'accès local sur NVMe le débit de stockage le plus élevé possible sans aucune surcharge réseau. Un PostgreSQL sur un chemin d'accès local NVMe exactement comme PostgreSQL directement sur le même NVMe .

Longhorn pour le stockage répliqué

Longhorn (aussi de Rancher) est une solution de stockage native dans le cloud qui copie les volumes sur plusieurs nœuds de cluster. Pour les clusters à plusieurs nœuds où la planification des pods doit être indépendante de l'emplacement du stockage, Longhorn copie les données PVC sur 2 ou 3 nœuds.

La surcharge liée à la réplication sur NVMe acceptable : le chemin d'accès aux données de Longhorn ajoute environ 10 à 20 % de latence par rapport au chemin d'accès local, ce qui reste plus rapide que le stockage en blocs dans le cloud connecté via le réseau. Pour les bases de données de production dans Kubernetes, Longhorn offre une résilience que le chemin d'accès local ne peut pas fournir.

Choix de la classe de stockage en fonction de la charge de travail

local-path : pods sans état , caches de compilation CI/CD, volumes temporaires pour les tâches par lots. Performances maximales, pas de réplication.
Longhorn (1 réplique) : pour les déploiements à nœud unique qui veulent gérer les PVC sans avoir à fixer l'affinité des nœuds.
Longhorn (2-3 répliques) : bases de données de production , services avec état qui ont besoin d'une haute disponibilité même si des nœuds tombent en panne.

Sélection de plugins CNI pour Bare Metal

Cloud Kubernetes utilise des plugins CNI spécifiques aux fournisseurs (VPC CNI pour EKS, etc.) qui s'intègrent aux primitives de réseau cloud pas disponibles sur le bare metal. Pour K8s bare metal, trois plugins couvrent la plupart des cas d'utilisation :

Flannel : simple superposition VXLAN, super facile à utiliser, performances correctes pour la plupart des charges de travail. C'est le choix par défaut dans k3s. Il manque juste l'application des politiques réseau.
Calico : réseau basé sur BGP avec prise en charge complète de NetworkPolicy. Recommandé pour les clusters de production qui ont besoin d'isoler le trafic entre les pods dans les espaces de noms.
Cilium : basé sur eBPF , le plus faible overhead des trois, remplace iptables par un traitement des paquets au niveau du noyau. Meilleures performances pour les maillages de services à haut débit. Plus complexe sur le plan opérationnel.

Pour la plupart des équipes qui commencent avec K8s bare metal, Calico offre le bon équilibre : prise en charge complète de NetworkPolicy pour la segmentation de la sécurité, fonctionnement stable et bonne documentation. Cilium vaut le coup d'être évalué quand le cluster gère un trafic est-ouest à haut débit où la surcharge iptables dans Calico devient mesurable.

Services LoadBalancer sans fournisseur de cloud : MetalLB

Cloud Kubernetes configure automatiquement un équilibreur de charge cloud quand tu crées un service de type LoadBalancer. Sur une infrastructure physique, il n'y a pas de fournisseur cloud pour configurer cet équilibreur de charge. Les services restent bloqués indéfiniment dans l'état « En attente ».

MetalLB règle ce problème. Il marche comme un contrôleur dans le cluster et attribue des adresses IP à partir d'un pool configuré aux services LoadBalancer. En mode L2 (plus simple), MetalLB répond aux requêtes ARP pour les adresses IP des services à partir du nœud où se trouve le point de terminaison du service. En mode BGP, il annonce les routes directement aux routeurs en amont pour une bonne répartition de la charge.

Pour la plupart des déploiements de serveurs dédiés InMotion qui utilisent K8s, MetalLB en mode L2 avec un petit pool d'adresses IP (même un sous-réseau /30 d'adresses IP supplémentaires) suffit pour exposer les services à l'extérieur. Ajoute un contrôleur Nginx sur MetalLB pour gérer le routage HTTP/HTTPS sans utiliser une adresse IP dédiée par service.

K8s sur métal nu vs K8s sur cloud géré : quand chacun l'emporte

Facteur	K8s sur métal nu	EKS / GKE / AKS
Coût mensuel d'un nœud de travail	99-350 $ (dédié)	100 à 800 $+ (nœuds VM)
Coût du plan de contrôle	Autogéré (gratuit)	72 à 150 $/mois (frais de gestion)
Latence de stockage	NVMe (~0,1 ms)	Bloc réseau (~1-5 ms)
Auto-scaling	Auto-ajustement manuel ou en grappe	Autoscaler cloud natif
Régions du monde	Los Angeles, Amsterdam	Plus de 30 régions dans le monde
Frais généraux de gestion	Moyen (kubeadm/k3s)	Faible (plan de contrôle géré)
Coût mensuel prévisible	Oui	Variable (en fonction de l'utilisation)

K8s sur métal nu est top pour le coût et les performances de stockage quand il s'agit de charges de travail stables. K8s géré dans le cloud est top pour sa simplicité d'utilisation et sa distribution mondiale. Le bon choix dépend si vos charges de travail ont des exigences de distribution géographique et si votre équipe peut gérer un plan de contrôle.

Docker Swarm, une alternative plus simple

Toutes les charges de travail conteneurisées n'ont pas besoin de Kubernetes. Docker Swarm sur un seul serveur dédié gère des dizaines de services conteneurisés avec une complexité opérationnelle bien moindre que celle de K8s. Si votre architecture compte moins de 10 à 15 services distincts et ne nécessite pas de fonctionnalités spécifiques à K8s (définitions de ressources personnalisées, contraintes de planification complexes, outils de l'écosystème Helm), Swarm sur un serveur dédié InMotion se déploie en un après-midi.

Le modèle de réseau de Docker Swarm sur un seul nœud est plus simple que celui de K8s : réseaux superposés pour la découverte des services, ports publiés pour l'accès externe, Traefik ou Nginx l'entrée. Pas de plugins CNI. Pas de MetalLB. Pour les équipes qui trouvent que la charge opérationnelle de K8s dépasse les avantages architecturaux de leur charge de travail, Swarm est un choix de production valable.

Pour commencer

Commande un serveur bare metal ou dédié, niveau Extreme pour les nœuds de travail K8s de production.
Installez k3s pour les clusters à nœud unique ou multi-nœuds légers ; kubeadm pour un contrôle total sur la configuration du cluster.
Configurez Calico CNI pour la prise en charge de NetworkPolicy dès le premier jour.
Installe MetalLB en mode L2 pour que le service LoadBalancer marche bien.
Configurez le provisionneur local-path pour les PVC de développement ; Longhorn pour les charges de travail avec état en production.
Ajoutez Premier Care pour gérer le système d'exploitation de l'hôte bare metal.

Les équipes qui paient actuellement 800 $ ou plus par mois pour des nœuds de travail Kubernetes gérés récupèrent généralement ce coût dès le premier cycle de facturation après avoir transféré leurs charges de travail stables vers du matériel nu. L'investissement opérationnel dans la gestion d'un plan de contrôle est réel, mais c'est un coût de configuration unique, pas une dépense récurrente proportionnelle à tes dépenses informatiques.

Partager cet article