Construire un cloud privé sur bare metal avec Kubernetes et Talos Linux

Dans un article publié sur le blog de Kubernetes en avril 2024, Andrei Kvapil d'Ænix a exposé une méthode pour construire une infrastructure de cloud privé en utilisant uniquement des technologies open source. Le guide se concentre sur la préparation de serveurs bare metal pour héberger des clusters Kubernetes gérés, s'éloignant des couches de virtualisation traditionnelles comme OpenStack.

Ce qui s'est passé

Kvapil a décrit le processus de création de Cozystack, une plateforme conçue pour exécuter des clusters Kubernetes destinés aux locataires directement sur du matériel physique. Cette approche remet en question la pratique courante consistant à utiliser OpenStack pour gérer les serveurs bare metal avant d'y installer Kubernetes. Au lieu de cela, elle exploite Kubernetes lui-même pour gérer la complexité de l'infrastructure, visant ainsi à réduire le nombre de systèmes complexes dans l'écosystème.

L'article constitue la première partie d'une série détaillant cette architecture. Il couvre les travaux préliminaires nécessaires pour préparer les centres de données, notamment l'exécution de machines virtuelles, l'isolation des réseaux et la mise en place d'un stockage tolérant aux pannes. L'objectif est de provisionner des clusters Kubernetes complets prenant en charge le provisionnement dynamique de volumes, les équilibreurs de charge et l'autoscaling sans dépendre de fournisseurs cloud externes.

Comment cela fonctionne

La distinction fondamentale réside dans le fonctionnement de Kubernetes dans le cloud par rapport au bare metal. Dans les clouds publics, des services tels que les volumes persistants, les équilibreurs de charge et le provisionnement des nœuds sont gérés en externe par le fournisseur. Cela permet de traiter les nœuds comme des utilitaires éphémères pouvant être supprimés et recréés facilement. Sur du bare metal, ces services doivent s'exécuter à l'intérieur du cluster, ce qui rend les mises à jour et la maintenance considérablement plus complexes, car les serveurs physiques ne peuvent pas être simplement supprimés et remplacés comme des machines virtuelles.

Pour répondre à ce défi, le guide recommande d'utiliser Talos Linux, un système d'exploitation spécialisé conçu pour Kubernetes. Talos permet de définir toute la configuration du système dans un seul fichier. Cette approche déclarative permet de mettre à jour les modules du noyau et les composants Kubernetes sans nécessiter la recréation complète des nœuds ni la migration des services. L'équipe d'Ænix utilise cette méthode pour intégrer les modules du noyau nécessaires, tels que ZFS et DRBD, dans une image système personnalisée.

Pour le déploiement, le processus utilise le démarrage PXE. Des serveurs DHCP et PXE temporaires s'exécutent dans des conteneurs pour livrer l'image Talos Linux personnalisée aux nœuds physiques. Un script de bootstrap initialise ensuite les nœuds et établit le plan de contrôle Kubernetes initial. Une fois le cluster de base opérationnel, des outils GitOps comme FluxCD sont utilisés pour installer et gérer les composants système, garantissant que le cluster maintient son état souhaité via des charts Helm déclaratifs.

Détails clés

• Le guide prône le remplacement d'OpenStack par une approche native Kubernetes afin de réduire la complexité de l'écosystème.
• Talos Linux est utilisé comme système d'exploitation de base en raison de son modèle de configuration immuable et déclaratif.
• Des images système personnalisées sont construites à l'aide de Docker pour inclure des modules spécifiques du noyau tels que ZFS, DRBD et OpenvSwitch.
• Le démarrage PXE est employé pour livrer l'image OS aux serveurs bare metal lors du provisionnement initial.
• FluxCD est recommandé plutôt qu'ArgoCD pour gérer les composants système et maintenir l'uniformité du cluster via GitOps.
• Le processus de bootstrap initial peut déployer un cluster Kubernetes fonctionnel sur du bare metal en environ cinq minutes.

Pourquoi c'est important

Pour les équipes d'ingénierie qui gèrent leur propre matériel, cette approche offre une voie vers une agilité comparable au cloud sans la surcharge liée à la maintenance de plateformes de virtualisation distinctes. En traitant l'infrastructure comme du code et en utilisant des systèmes d'exploitation immuables, les équipes peuvent réduire le risque de dérive de configuration et simplifier le processus de mise à jour. Cela est particulièrement pertinent pour les organisations qui ont besoin d'un contrôle strict sur leurs données et leur matériel tout en souhaitant bénéficier des avantages opérationnels de Kubernetes.

Cependant, cette méthode transfère une responsabilité significative à l'équipe d'infrastructure. Contrairement aux services cloud managés, les ingénieurs doivent gérer eux-mêmes le réseau, le stockage et les correctifs de sécurité. La complexité passe de la gestion de multiples systèmes disparates à une compréhension approfondie de l'interaction entre Kubernetes, le système d'exploitation sous-jacent et le matériel physique. Cela nécessite un niveau d'expertise plus élevé, mais peut aboutir à une infrastructure plus rationalisée et rentable pour les déploiements à grande échelle.

Ce que vous pouvez faire

• Évaluez Talos Linux comme système d'exploitation de base pour vos clusters Kubernetes bare metal afin de simplifier la gestion des nœuds.
• Mettez en œuvre des pratiques GitOps en utilisant FluxCD pour gérer déclarativement les composants système et les charts Helm.
• Configurez un environnement pilote pour tester le processus de bootstrap et valider la livraison des images via PXE.