Creer son propre Cloud avec Kubernetes

Chez Xbit, nous avons une profonde affection pour Kubernetes et rêvons que toutes les technologies modernes commencent bientôt à utiliser ses remarquables modèles.

Les gourvernements et entreprises privees revent de construire leur propre infrastructure cloud. Mais est-il possible de le faire en utilisant uniquement des technologies et des approches modernes, sans quitter l'écosystème confortable de Kubernetes ? Notre expérience dans le développement de Xstack nous a obligés à nous y plonger profondément.

Vous pourriez arguer que Kubernetes n'est pas destiné à cet usage et pourquoi ne pas simplement utiliser OpenStack pour les serveurs bare metal et exécuter Kubernetes à l'intérieur comme prévu. Mais ce faisant, vous transféreriez simplement la responsabilité de vos mains à celles des administrateurs d'OpenStack. Cela ajouterait au moins un autre système énorme et complexe à votre écosystème.

Pourquoi compliquer les choses ? - Après tout, Kubernetes a déjà tout ce qu'il faut pour faire fonctionner des clusters Kubernetes locataires à ce stade.

Nous partageons ici notre expérience dans le développement d'une plateforme cloud basée sur Kubernetes, en mettant en avant les projets open-source que nous utilisons nous-mêmes et qui, selon nous, méritent votre attention.
Vous découvrirez ici la façon dont nous préparons Kubernetes géré à partir de bare metal en utilisant uniquement des technologies open-source. En commençant par le niveau de base de la préparation du centre de données, l'exécution de machines virtuelles, l'isolation des réseaux, la mise en place d'un stockage tolérant aux pannes jusqu'au provisionnement de clusters Kubernetes complets avec provisionnement dynamique de volume, équilibreurs de charge et mise à l'échelle automatique.

Dans cet article, nous entamons une série composée de plusieurs parties :

• Partie 1 : Préparer le terrain pour votre cloud. Les défis rencontrés lors de la préparation et de l'exploitation de Kubernetes on bare metal et une recette toute faite pour le provisionnement de l'infrastructure.
• Partie 2 : Mise en réseau, stockage et virtualisation. Comment transformer Kubernetes en un outil de lancement de machines virtuelles et ce qui est nécessaire pour cela.
• Partie 3 : API de cluster et comment commencer à provisionner des clusters Kubernetes en appuyant sur un bouton. Comment fonctionne l'autoscaling, le provisionnement dynamique des volumes et les load balancers.

Nous essaierons de décrire les différentes technologies de la manière la plus indépendante possible, tout en partageant notre expérience et en expliquant pourquoi nous avons opté pour une solution ou une autre.

Pour commencer, comprenons le principal avantage de Kubernetes et comment il a changé l'approche de l'utilisation des ressources du cloud.

Il est aussi important de comprendre que l'utilisation de Kubernetes dans le nuage et sur le métal nu diffère.

Kubernetes dans le cloud

Lorsque vous utilisez Kubernetes dans le nuage, vous n'avez pas à vous soucier des volumes persistants, des équilibreurs de charge du nuage ou du processus de provisionnement des nœuds. Tout cela est géré par votre fournisseur de cloud, qui accepte vos demandes sous la forme d'objets Kubernetes. En d'autres termes, le côté serveur vous est complètement caché, et vous ne voulez pas vraiment savoir comment le fournisseur de cloud met en œuvre exactement, car ce n'est pas dans votre domaine de responsabilité.

Kubernetes offre des abstractions pratiques qui fonctionnent de la même manière partout, ce qui vous permet de déployer votre application sur n'importe quel Kubernetes dans n'importe quel cloud.



Dans le cloud, vous avez très souvent plusieurs entités distinctes : le plan de contrôle Kubernetes, les machines virtuelles, les volumes persistants et les équilibreurs de charge en tant qu'entités distinctes. En utilisant ces entités, vous pouvez créer des environnements hautement dynamiques.

Grâce à Kubernetes, les machines virtuelles ne sont plus considérées que comme une entité utilitaire permettant d'utiliser les ressources du cloud. Vous ne stockez plus de données à l'intérieur des machines virtuelles. Vous pouvez supprimer toutes vos machines virtuelles à tout moment et les recréer sans casser votre application. Le plan de contrôle Kubernetes continuera à contenir des informations sur ce qui doit s'exécuter dans votre cluster. L'équilibreur de charge continuera à envoyer du trafic à votre charge de travail, en changeant simplement le point de terminaison pour envoyer du trafic à un nouveau nœud. Et vos données seront stockées en toute sécurité dans des volumes persistants externes fournis par le cloud.

Cette approche est fondamentale lors de l'utilisation de Kubernetes dans les nuages. La raison en est évidente : plus le système est simple, plus il est stable, et c'est pour cette simplicité que vous achetez Kubernetes dans le nuage.

Kubernetes sur du bare metal (Serveurs nus)

L'utilisation de Kubernetes dans les nuages est vraiment simple et pratique, ce qui n'est pas le cas des installations bare metal. Dans le monde du bare metal, Kubernetes, au contraire, devient insupportablement complexe. Tout d'abord, parce que l'ensemble du réseau, le stockage dorsal, les équilibreurs de nuages, etc. sont généralement exécutés non pas à l'extérieur, mais à l'intérieur de votre cluster. Par conséquent, un tel système est beaucoup plus difficile à mettre à jour et à maintenir.

Jugez-en par vous-même : dans le nuage, pour mettre à jour un nœud, vous supprimez généralement la machine virtuelle (ou même utilisez kubectl delete node) et vous laissez votre outil de gestion des nœuds en créer un nouveau, sur la base d'une image immuable. Le nouveau nœud rejoindra le cluster et « fonctionnera simplement » en tant que nœud, selon un schéma très simple et couramment utilisé dans le monde Kubernetes. De nombreux clusters commandent de nouvelles machines virtuelles toutes les quelques minutes, simplement parce qu'ils peuvent utiliser des instances ponctuelles moins chères. Cependant, lorsque vous avez un serveur physique, vous ne pouvez pas simplement le supprimer et le recréer, tout d'abord parce qu'il exécute souvent certains services du cluster, stocke des données, et son processus de mise à jour est significativement plus compliqué.

Il existe différentes approches pour résoudre ce problème, allant des mises à jour sur place, comme le font kubeadm, kubespray et k3s, à l'automatisation complète du provisionnement des nœuds physiques via Cluster API et Metal3.

J'aime l'approche hybride proposée par Talos Linux, où l'ensemble du système est décrit dans un seul fichier de configuration. La plupart des paramètres de ce fichier peuvent être appliqués sans redémarrer ou recréer le nœud, y compris la version des composants du plan de contrôle Kubernetes. Toutefois, cette approche conserve la nature déclarative maximale de Kubernetes. Cette approche minimise l'impact inutile sur les services de cluster lors de la mise à jour des nœuds en métal nu. Dans la plupart des cas, vous n'aurez pas besoin de migrer vos machines virtuelles et de reconstruire le système de fichiers du cluster lors de mises à jour mineures.

Préparer une base pour votre future Cloud

Supposons que vous ayez décidé de construire votre propre nuage. Pour commencer, vous avez besoin d'une couche de base. Vous devez réfléchir non seulement à la façon dont vous installerez Kubernetes sur vos serveurs, mais aussi à la façon dont vous le mettrez à jour et le maintiendrez. Considérez le fait que vous devrez penser à des choses comme la mise à jour du noyau, l'installation des modules nécessaires, ainsi que des paquets et des correctifs de sécurité. Vous devez maintenant penser à beaucoup plus de choses dont vous n'avez pas à vous soucier lorsque vous utilisez un Kubernetes prêt à l'emploi dans le cloud.

Bien sûr, vous pouvez utiliser des distributions standard comme Ubuntu ou Debian, ou vous pouvez envisager des distributions spécialisées comme Flatcar Container Linux, Fedora Core et Talos Linux. Chacune a ses avantages et ses inconvénients.

Nous utilisons plusieurs modules spécifiques du noyau comme ZFS, DRBD et OpenvSwitch. Nous avons donc décidé de former une image système avec tous les modules nécessaires à l'avance. Dans ce cas, Talos Linux s'est avéré être la solution la plus pratique pour nous. Par exemple, une telle configuration est suffisante pour construire une image système avec tous les modules du noyau nécessaires :

arch: amd64

platform: metal

secureboot: false

version: v1.6.4

input:

kernel:

  path: /usr/install/amd64/vmlinuz

initramfs:

  path: /usr/install/amd64/initramfs.xz

baseInstaller:

  ImageRef: ghcr.io/siderolabs/installer:v1.6.4

systemExtensions:

  - imageRef: ghcr.io/siderolabs/amd-ucode:20240115

  - imageRef: ghcr.io/siderolabs/amdgpu-firmware:20240115

  - imageRef: ghcr.io/siderolabs/bnx2-bnx2x:20240115

  - imageRef: ghcr.io/siderolabs/i915-ucode:20240115

  - imageRef: ghcr.io/siderolabs/intel-ice-firmware:20240115

  - imageRef: ghcr.io/siderolabs/intel-ucode:20231114

  - imageRef: ghcr.io/siderolabs/qlogic-firmware:20240115

  - imageRef: ghcr.io/siderolabs/drbd:9.2.6-v1.6.4

  - imageRef: ghcr.io/siderolabs/zfs:2.1.14-v1.6.4

output:

 kind: installer

 outFormat: raw

Usage de Docker

1. Ensuite, nous utilisons l'outil de ligne de commande Docker pour construire une image du système d'exploitation :
   

cat config.yaml | docker run --rm -i -v /dev:/dev --privileged "ghcr.io/siderolabs/imager:v1.6.4" -

Nous obtenons ainsi une image de conteneur Docker contenant tout ce dont nous avons besoin, que nous pouvons utiliser pour installer Talos Linux sur nos serveurs. Vous pouvez faire de même ; cette image contiendra tous les modules de firmware et de noyau nécessaires.

Mais la question se pose de savoir comment livrer l'image fraîchement formée à vos nœuds ?

Nous avons l'idée de l'amorçage PXE pendant un certain temps.  Mais malheureusement, cela ne vous aide pas à déployer votre tout premier cluster parent qui contiendra les autres. Vous avez donc préparé une solution qui vous aidera à faire la même chose en utilisant l'approche PXE.

Essentiellement, tout ce que vous avez à faire est d'exécuter des serveurs DHCP et PXE temporaires à l'intérieur des conteneurs. Ensuite, vos nœuds s'amorceront à partir de votre image, et vous pouvez utiliser un simple script à la sauce Debian pour vous aider à amorcer vos nœuds.

Les sources du script talos-bootstrap sont disponibles sur GitHub.

Ce script permet de déployer Kubernetes sur du métal nu en cinq minutes et d'obtenir un kubeconfig pour y accéder. Cependant, de nombreuses questions non résolues restent à résoudre.

Livraison des composants du système

À ce stade, vous disposez déjà d'un cluster Kubernetes capable d'exécuter diverses charges de travail. Cependant, il n'est pas encore totalement fonctionnel. En d'autres termes, vous devez configurer le réseau et le stockage, et installer les extensions de cluster nécessaires, comme KubeVirt pour exécuter des machines virtuelles, ainsi que la pile de surveillance et d'autres composants à l'échelle du système.

Traditionnellement, cela est résolu en installant les cartes Helm dans votre cluster. Vous pouvez le faire en exécutant les commandes helm install localement, mais cette approche devient peu pratique lorsque vous voulez suivre les mises à jour, et si vous avez plusieurs clusters et que vous voulez les garder uniformes. En fait, il existe de nombreuses façons de le faire de manière déclarative. Pour résoudre ce problème, je recommande d'utiliser les meilleures pratiques GitOps. Je veux parler d'outils comme ArgoCD et FluxCD.

Alors qu'ArgoCD est plus pratique pour le développement avec son interface graphique et un plan de contrôle central, FluxCD, en revanche, est mieux adapté à la création de distributions Kubernetes. Avec FluxCD, vous pouvez spécifier quels tableaux avec quels paramètres doivent être lancés et décrire les dépendances. FluxCD s'occupe ensuite de tout pour vous.

Il est conseillé d'effectuer une installation unique de FluxCD dans votre cluster nouvellement créé et de lui fournir la configuration. Cela permettra d'installer tout ce qui est nécessaire et d'amener le cluster à l'état prévu.

En effectuant une installation unique de FluxCD dans votre cluster nouvellement créé et en le configurant en conséquence, vous lui permettez de déployer automatiquement tous les éléments essentiels. Cela permettra à votre cluster de se mettre à niveau et d'atteindre l'état souhaité. Par exemple, après l'installation de notre plateforme, vous verrez les prochains tableaux Helm préconfigurés avec les composants du système .

Conclusion

Vous obtenez ainsi un environnement hautement reproductible que vous pouvez fournir à n'importe qui, en sachant qu'il fonctionne exactement comme prévu. C'est ce que fait le projet Xstack, que vous pouvez tester gratuitement.

Contactez Xbit pour plus d'informations sur nos expertises et offres