Kubernetes est généralement un service loué à un fournisseur cloud, avec un plan de contrôle, un équilibreur de charge et des classes de stockage préconfigurés. L’exécuter sur des serveurs dédiés change la donne. Vous êtes responsable de chaque couche située sous l’API, et de chaque décision que le fournisseur prenait auparavant à votre place.
Ce guide explique pourquoi les entreprises exploitent des clusters sur bare metal, comment organiser le plan de contrôle, l’équilibrage de charge, le stockage, les mises à niveau et l’observabilité, et dans quels cas l’effort n’en vaut pas la peine.
Pourquoi exécuter Kubernetes sur des serveurs dédiés
La première raison est la performance sans couche de virtualisation. Les pods d’un nœud bare metal utilisent directement le CPU, la mémoire et les disques NVMe, sans ordonnancement par un hyperviseur et sans voisin bruyant sur le même hôte. Pour les bases de données, les fermes de build et les tâches de traitement de données, le gain se traduit par une latence de queue plus faible et un débit plus régulier plutôt que par un pic plus élevé.
Un serveur dédié représente un montant mensuel fixe pour une configuration connue, alors que les clusters cloud sont facturés à l’heure de nœud, à l’équilibreur de charge, au gigaoctet stocké et au gigaoctet de trafic sortant. Un port de 1 Gbps à pleine charge transfère environ 10 TB par jour, et sur un port en trafic illimité ce trafic ne modifie pas la facture.
Vous choisissez le noyau, la génération de CPU, l’organisation des disques et le pays où se trouve chaque nœud, ce qui compte pour la résidence des données et pour les licences liées aux cœurs physiques.
Organisation du plan de contrôle
Le plan de contrôle comprend le serveur d’API, le scheduler, le controller manager et etcd. Sur bare metal, vous les exploitez vous-même : leur disposition détermine donc le comportement du cluster lorsqu’une machine tombe en panne.
etcd utilise un protocole de consensus et a besoin de la majorité de ses membres pour accepter les écritures. Trois membres tolèrent la perte d’un seul ; cinq tolèrent la perte de deux. Pour la plupart des clusters de production, trois nœuds de plan de contrôle constituent le bon point de départ.
- etcd empilé. etcd fonctionne sur les trois mêmes nœuds que le serveur d’API. C’est la configuration par défaut courante : elle nécessite moins de machines et elle est bien prise en charge par kubeadm et la plupart des distributions.
- etcd externe. etcd fonctionne sur ses propres nœuds. Cela isole le magasin de données de la charge de l’API et simplifie la planification de capacité des très grands clusters, au prix d’un plus grand nombre de serveurs à exploiter.
- Nœuds dédiés au plan de contrôle. Tenez les pods applicatifs à l’écart du plan de contrôle grâce aux taints. Une charge incontrôlée ne doit jamais pouvoir priver etcd de disque ou de mémoire.
- Disque local rapide pour etcd. etcd est sensible à la latence d’écriture, car chaque modification est synchronisée sur disque. Le NVMe local convient bien ; les disques lents ou partagés sont une cause fréquente d’élections de leader et d’expirations de l’API.
- Un point d’accès API stable. Les workers et les clients ont besoin d’une adresse unique pour le serveur d’API. Sur du bare metal, il s’agit généralement d’une IP virtuelle qui se déplace entre les nœuds du plan de contrôle, fournie par un outil comme keepalived ou kube-vip, ou d’une paire de répartiteurs de charge placés devant les nœuds.
Placez les trois nœuds du plan de contrôle dans des baies différentes, ou au moins sur des alimentations électriques distinctes lorsque le site le permet.
Réseau : équilibreurs de charge, BGP et MetalLB
Dans un cloud, un Service de type LoadBalancer appelle l’API du fournisseur et obtient une adresse IP externe. Sur bare metal, rien ne répond à cet appel, et le Service reste en attente (pending) jusqu’à ce que vous installiez un composant qui le fasse.
MetalLB est la solution open source la plus répandue. Il surveille les Services de type LoadBalancer, attribue une adresse IP issue d’un pool que vous définissez et rend cette adresse joignable depuis le réseau. Il fonctionne selon deux modes principaux.
- Mode couche 2. Un nœud répond aux requêtes ARP (ou NDP en IPv6) pour l’IP du service, et le trafic destiné à cette IP est acheminé vers ce nœud. Ce mode ne nécessite aucune configuration des routeurs et fonctionne sur un réseau plat simple. En contrepartie, tout le trafic d’un service entre par un seul nœud à la fois, et la bascule dépend de la capacité des clients et des commutateurs à détecter le changement.
- Mode BGP. Les nœuds établissent des sessions BGP avec les routeurs amont et annoncent les IP de service sous forme de routes. Les routeurs peuvent répartir le trafic sur plusieurs nœuds grâce au routage multichemin à coût égal (ECMP), et la bascule suit la convergence normale du routage. Ce mode nécessite des routeurs qui acceptent les sessions BGP de vos nœuds et une coordination avec l’exploitant du réseau.
Certains plugins CNI peuvent annoncer directement les routes des services via BGP, ce qui supprime un composant.
Dimensionnez les CIDR des pods et des services en prévision de la croissance, car les modifier plus tard implique généralement de reconstruire le cluster. Placez un contrôleur ingress ou une passerelle derrière les adresses IP de l’équilibreur de charge pour le trafic HTTP, et conservez une atténuation DDoS en amont devant les adresses publiques.
Stockage : NVMe local, CSI et stockage répliqué
C’est sur le stockage que les clusters bare metal gagnent le plus en performance et prennent le plus de risques. Kubernetes communique avec le stockage via la Container Storage Interface (CSI), et le pilote choisi détermine ce qu’il advient des données lorsqu’un nœud tombe en panne.
- Volumes NVMe locaux. Les volumes persistants locaux lient un pod à un disque d’un nœud précis. Vous obtenez la meilleure latence et le meilleur débit possibles. Le pod ne peut pas changer de nœud sans perdre ces données : cette option convient donc aux charges qui répliquent au niveau applicatif, comme les bases de données distribuées, les clusters de recherche et les files de messages dotées de leur propre réplication.
- Stockage logiciel répliqué. Des systèmes comme Ceph (souvent exploité via Rook), Longhorn ou des plateformes similaires fondées sur CSI copient chaque volume sur plusieurs nœuds. Un pod peut redémarrer ailleurs et rattacher son volume. Le prix à payer : un trafic réseau supplémentaire à chaque écriture, une capacité disque supplémentaire (trois copies triplent l’usage brut) et un système de stockage qui exige sa propre expertise d’exploitation.
- Stockage bloc réseau. Des volumes servis par une plateforme de stockage distincte via le réseau. L’état reste ainsi hors des nœuds de calcul, le remplacement d’un nœud est simple et la capacité évolue indépendamment du calcul.
La plupart des clusters de production combinent ces approches : bases de données avec réplication intégrée sur NVMe local, autres services avec état sur stockage répliqué ou réseau.
Sauvegardez etcd et les volumes persistants séparément. Un snapshot etcd restaure les objets du cluster, mais pas les données contenues dans les volumes. Des outils comme Velero peuvent capturer à la fois les ressources et les snapshots de volumes, et la procédure de restauration doit être répétée selon un calendrier, et non rédigée une fois puis oubliée.
Mises à niveau et cycle de vie des nœuds
Kubernetes publie une nouvelle version mineure environ trois fois par an, et chaque version mineure reçoit des correctifs pendant environ quatorze mois. Un cluster qui n’est pas mis à niveau sort du support en un an et demi environ. Sur bare metal, personne ne le met à niveau à votre place.
Les mises à niveau se font une version mineure à la fois : le plan de contrôle d’abord, puis les workers. Une procédure prévisible se présente ainsi.
- Avant la mise à niveau, vérifiez manifestes et charts Helm au regard des API supprimées.
- Prenez un snapshot etcd et vérifiez qu’il peut être restauré.
- Mettez à niveau les nœuds du plan de contrôle un à un ; vérifiez l’API à chaque fois.
- Isolez (cordon) et videz (drain) chaque worker, mettez à niveau le kubelet et le runtime de conteneurs, puis remettez-le en service (uncordon). Utilisez des PodDisruptionBudgets pour qu’un drain ne mette jamais hors service tous les réplicas d’un service.
- Corrigez l’OS hôte et les firmwares au même rythme : un Kubernetes à jour sur un noyau non corrigé reste exposé.
De nombreuses équipes remplacent les nœuds plutôt que de les réparer : réinstallation à partir d’une image connue, intégration au cluster, retrait de l’ancienne machine. Conservez au moins un nœud de réserve par pool afin qu’un drain ne laisse jamais le cluster à court de capacité.
Observabilité
Sur bare metal, vous surveillez aussi les signaux matériels que le cloud masque.
- Métriques. Prometheus avec node exporter et kube-state-metrics constitue la base courante. Ajoutez pour chaque serveur les données SMART et d’usure NVMe, les températures, l’état des alimentations et les erreurs des cartes réseau.
- Journaux. Expédiez les journaux des conteneurs, du kubelet et du système hors du nœud, vers un magasin central. Un nœud défaillant emporte ses journaux locaux avec lui.
- Santé du plan de contrôle. Alertez sur les changements de leader etcd, la latence fsync, la taille de la base et les taux d’erreur du serveur d’API. Ce sont les premiers signes d’un cluster en mauvaise santé.
- Capacité. Suivez le CPU et la mémoire demandés par rapport à la consommation réelle, pour chaque pool de nœuds. Sur du bare metal, la capacité s’ajoute par serveurs entiers : il faut donc anticiper avant que le cluster ne soit à court.
Placez la pile de supervision hors du cluster qu’elle surveille, ou au moins répliquez les alertes vers un système externe. Un cluster qui a perdu son quorum ne peut pas vous signaler qu’il a perdu son quorum.
Quand l’effort n’en vaut pas la peine
Kubernetes sur bare metal convient aux charges de travail stables, à fort trafic et sensibles aux performances, exploitées par des équipes qui maîtrisent déjà bien Linux. Il est mal adapté dans les cas suivants :
- Charges de travail petites ou irrégulières. Si le cluster tournerait sur deux ou trois petits nœuds, ou si le trafic varie d’un ordre de grandeur au cours d’une journée, la capacité d’un cloud infogéré est généralement moins chère et plus simple.
- Pas d’équipe plateforme. Quelqu’un doit prendre en charge etcd, les mises à niveau, le stockage et l’astreinte. Si ce n’est le travail de personne, le cluster finira par sortir du périmètre supporté.
- Recours intensif aux services managés. Lorsque l’application dépend des files d’attente, des bases de données et des services d’identité d’un fournisseur, ne déplacer que le calcul ajoute de la latence et de la complexité sans grande économie.
- Les charges de travail qui n’ont pas besoin de Kubernetes. Quelques services sur une poignée de serveurs fonctionnent bien avec des conteneurs et un outil de gestion de configuration. Kubernetes devient rentable avec de nombreux services et des déploiements fréquents.
Checklist pour un cluster bare metal
- 3 ou 5 nœuds de plan de contrôle répartis par baie ou alimentation ; etcd sur NVMe local.
- Une IP virtuelle ou une paire de répartiteurs de charge pour le point d’accès de l’API.
- Des snapshots etcd automatisés et testés, stockés hors du cluster.
- MetalLB ou CNI BGP, avec pools IP et filtres routeur convenus.
- CIDR des pods et des services dimensionnés pour la croissance et documentés.
- Classes de stockage par charge, chacune testée en perte de nœud.
- Sauvegardes des volumes vers un stockage objet distant ; restaurations répétées.
- Runbook de mise à niveau, PodDisruptionBudgets sur les pods critiques, correctifs OS et firmware réguliers.
- Métriques matériel, cluster et plan de contrôle ; alertes hors cluster.
- Capacité de réserve d’au moins un nœud par pool.
- Console à distance, remplacement des nœuds documenté.
- Atténuation DDoS en amont des adresses IP publiques des services.
Comment Vonahost peut vous aider
Vonahost fournit des serveurs dédiés monolocataires AMD EPYC (4e et 5e génération) adaptés à l’architecture décrite ici : NVMe local (2 x 960 GB) pour etcd et les volumes sensibles à la latence, ou stockage bloc réseau jusqu’à 1 PB pour les charges de travail avec état, un port dédié de 1 Gbps en trafic illimité sur une fabric réseau de 100/200 Gbps et l’atténuation DDoS Arbor devant les adresses publiques. Les serveurs sont provisionnés en quelques minutes sous AlmaLinux ou Ubuntu, dans la région de votre choix, ce qui facilite l’approche consistant à remplacer plutôt qu’à réparer dans le cycle de vie des nœuds.
Chaque proposition indique la configuration, l’emplacement, les responsabilités et le prix mensuel en dollars américains, afin que vous sachiez quelles parties du cluster vous exploitez et lesquelles nous exploitons. Vous choisissez le pays de chaque serveur, et les données ne sont pas déplacées sans votre accord.