Pour tous ceux qui ont rencontré n'importe quel type de plate-forme d'orchestration de conteneurs, le plus souvent Kubernetes, il est généralement connu que la gestion du stockage peut être une véritable douleur. Non pas à cause de la complexité ou du nombre de composants sous-jacents, mais à cause de la nature dynamique de l'architecture d'une telle plateforme.
Tout en fonctionnant à l'intérieur d'un cluster distribué, Kubernetes peut manipuler les conteneurs et les pods de toutes sortes de manières: les créer, les détruire, les répliquer, les mettre à l'échelle automatiquement, etc. Et en tant que mainteneur, vous ne saurez souvent pas de quelle machine physique (ou virtuelle) ils vont être placé sur. Par conséquent, pour accéder au stockage persistant, un certain type de services d'approvisionnement de données externes doit être utilisé.
Kubernetes a le concept de volume persistant, qui peut être implémenté de nombreuses manières . Maintenant, l'un des plus simples et des plus couramment utilisés est bien sûr NFS . Tout ce dont vous avez besoin est d'installer le graphique Helm et d'utiliser la StorageClass créée dans toute revendication de volume. Mais en dépit d'être si simple et facile à démarrer, une telle pratique n'est malheureusem*nt pas aussi efficace et flexible qu'elle peut parfois être nécessaire.
La limitation cruciale à laquelle j'ai été confrontée était l'incapacité de fournir un stockage partagé aux pods dans différents espaces de noms. Et même si je pouvais négliger la séparation logique et combiner les espaces de noms, ce problème, associé à une mauvaise efficacité de mise à l'échelle, a été le facteur décisif pour trouver un remplaçant.
Lors de la recherche d'un système de fichiers distribué ou en cluster , le choix se résume finalement à quelques options. Aujourd'hui, les plus remarquables sont bien sûr GlusterFS et CephFS . Cependant, je ne recommande pas de faire un choix en se basant uniquement sur cet article. Faites vos propres recherches. Parce qu'en plus de celles-ci, de nombreuses autres options telles que GFS 2 , Lustre , MinIO , MooseFS , etc. sont également disponibles. Je recommande également de consulter Rook, qui n'est pas en fait un DFS en soi, mais plutôt l' orchestrateur de stockage cloud natif conçu pour étendre le potentiel de gestion du stockage Kubernetes.
GlusterFS et CephFS sont des systèmes de stockage défini par logiciel (SDN) open source qui fournissent respectivement un stockage de blocs et d'objets distribué, hautement évolutif et hautement disponible. Les deux présentent certains avantages par rapport aux solutions propriétaires. La vraie différence entre eux commence à se manifester à mesure que la taille de stockage augmente. Gluster fonctionne bien à des échelles plus élevées qui pourraient se multiplier de téraoctets à pétaoctets en peu de temps. D'autre part, Ceph, en raison de son format de stockage, fournit un stockage à plus court terme plus efficace auquel les utilisateurs accèdent plus fréquemment.
La solution de système de fichiers Gluster à un niveau d'abstraction plus élevé comprend trois composants principaux:
- Serveurs Gluster installés comme briques de stockage sur les nœuds K8s par le DaemonSet
- Les clients Gluster installés directement sur les machines physiques et se connectent aux serveurs via des protocoles tels que TCP / IP et socket direct
- API de gestion pour extraire la manipulation des volumes de bas niveau
Cependant, je pense que cela rendra le processus d'utilisation encore plus compliqué. En revanche, l'API de gestion fournit une interface automatisée pour la création, le redimensionnement et la suppression de PV à l'aide de K8s StorageClass. Ainsi, vous n'avez vraiment besoin de vous soucier du déploiement et de la configuration qu'une seule fois. Si vous me demandez, je dis que c'est une manière beaucoup plus attrayante et élégante.
C'est pourquoi, dans ce didacticiel, nous utiliserons Heketi - un cadre de gestion de volume basé sur RESTful écrit principalement en Go qui rend l'utilisation de GlusterFS un jeu d'enfant.
Avant de commencer, il convient de mentionner que je vais l'écrire de manière plus spécifique au Kubernetes géré par DigitalOcean car c'est mon fournisseur d'infrastructure cloud de choix. Bien sûr, il y aura des parties communes à tous les fournisseurs - en fait, la plupart le sont. Donc, si vous utilisez quelque chose, comme GKE ou Amazon EKS , vous êtes tout à fait invité à rester.
D'accord, si tout cela est réglé, commençons enfin!
Afin de déployer d'abord GlusterFS, vous devez créer une partition de périphérique de disque, en raison de sa nature de bas niveau, Gluster ne peut pas fonctionner sur le système de fichiers préexistant et nécessite un périphérique de disque complètement brut ou sa partition.
Les nœuds DigitalOcean K8s fonctionnent sur le système d'exploitation Debian 10 (Buster) et avant tout, vous devez y avoir accès. Étant donné que les nœuds K8 sous le capot sont également des gouttelettes de DO (nom de code pour VPS géré), vous pouvez le faire à partir de l'onglet dédié de la console de gestion des gouttelettes.
Une fois que vous y êtes, préparez-vous à copier et coller (ou à taper manuellement si vous le souhaitez vraiment) beaucoup de commandes, car cela peut parfois être assez frustrant compte tenu de l'extrême convivialité de DO Web-console.
Nous utiliserons le système live amorçable GRML pour réduire la partition de disque existante. Installez-le via l' apt-getutilitaire:
$ apt-get install grml-rescueboot$ cd /boot/grml$ wget http://download.grml.org/grml64-small_2020.06.iso$ update-grub$ lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTvda 254:0 0 80G 0 disk ├─vda1 254:1 0 79.9G 0 part /└─vda2 254:2 0 2M 0 part vdb 254:16 0 446K 0 diskUne fois que vous avez une carte de partition, redémarrez votre système en tapant reboot. Lors du démarrage, choisissez rapidement ces options:
Grml Rescue Systemgrml64-small — advance optionsgrml64-small — copy Grml to RAM
Utilisez resize2fspour réduire le système de fichiers existant:
$ fsck.ext4 -f /dev/vda1$ resize2fs -M /dev/vda1$ parted /dev/vda$ resizepart 1 30G # shrink vda1 to 30 Gb$ mkpart gluster 30001 100% # create vda3 where vda1 ends$ set 3 lvm on # optionally setup logical volumes$ print # verify results$ quit$ fdisk -l /dev/vdaDevice Start End Sectors Size Type /dev/vda1 6144 62920671 62914528 50G Linux filesystem /dev/vda2 2048 6143 4096 2M BIOS boot /dev/vda3 62920672 1667770111 104857546 30G Linux filesystemLa prochaine étape importante consiste à définir un lien symbolique ( symlink) pour identifier la partition nouvellement créée en tant que périphérique de stockage GlusterFS. Il n'est pas recommandé d'utiliser des noms de périphériques, par exemple /dev/vda3, car le nom peut changer entre les redémarrages du système. Pour ce faire, vous avez la possibilité d'utiliser des liens symboliques générés par le système ou de créer manuellement les vôtres.
Pour obtenir des liens symboliques préexistants, utilisez simplement:
$ ls -altr /dev/disk/* | grep <device>La méthode manuelle est un peu plus difficile mais vous pouvez spécifier n'importe quel nom personnalisé. Dans mon cas, c'est /dev/disk/gluster-disk. Pour ce faire, vous devez d'abord obtenir les attributs de certains périphériques à l'aide de l' udevadmutilitaire spécifiant le périphérique source:
$ udevadm info --root --name=/dev/vda3P: /devices/pci0000:00/0000:00:06.0/virtio3/block/vda/vda3N: vda3E: DEVNAME=/dev/vda3E: DEVPATH=/devices/pci0000:00/0000:00:06.0/virtio3/block/vda/vda3E: DEVTYPE=partitionE: MAJOR=254E: MINOR=3E: SUBSYSTEM=blockE: TAGS=:systemd:E: USEC_INITIALIZED=1942797...ENV{DEVTYPE}=="partition", ENV{SUBSYSTEM}=="block", ENV{DEVPATH}=="/devices/pci0000:00/0000:00:06.0/virtio3/block/vda/vda3" SYMLINK+="disk/gluster-disk"$ nano /lib/udev/rules.d/10-custom-icp.rules$ udevadm control --reload-rules$ udevadm trigger --type=devices --action=change$ ls -ltr /dev/disk/gluster-*lrwxrwxrwx 1 root root 7 Oct 21 16:20 /dev/disk/gluster-disk -> ../vda3Enfin, vous pouvez installer de loin la partie la plus importante de toute cette mascarade qui est bien sûr - Gluster Native Client . Juste après avoir configuré le dm_thin_poolmodule du noyau. Rien de gênant là-bas car c'est en fait assez simple:
$ modprobe dm_thin_pool$ echo dm_thin_pool | tee -a /etc/modulesdm_thin_pool # verify outputTout d'abord, ajoutez la clé GPG à apt:
$ wget -O - https://download.gluster.org/pub/gluster/glusterfs/7/rsa.pub | apt-key add - # install certificate$ echo deb [arch=amd64] https://download.gluster.org/pub/gluster/glusterfs/7/7.1/Debian/buster/amd64/apt buster main > /etc/apt/sources.list.d/gluster.list$ apt-get update$ apt-get install glusterfs-client$ /usr/sbin/glusterfs --versionglusterfs 7.1Et c'est tout! Vous pouvez maintenant fermer cette console maladroite et enfin retourner à votre terminal génial. C'est, bien sûr, si un nœud de stockage est suffisant pour votre infrastructure souhaitée, mais cela est douteux. Sinon, vous devriez refaire la même chose pour tous les autres nœuds jusqu'à ce que vous en soyez satisfait ou fatigué. J'ai les deux après l'avoir fait trois fois.
À ce stade, le plus dur est terminé. Il ne reste plus qu'à configurer et déployer les deux derniers composants - Gluster Server et Heketi API. De toute évidence, après tout le travail que vous avez fait dans les étapes précédentes, vous méritez une sorte de moyen simple et simple de terminer les choses. Et quoi de plus simple que d'utiliser un graphique Helm préconfiguré ?
Il existe même des options pour cela:
- Charte officielle IBM directement depuis ArtifactHub
- AcalephStorage a terminé la fourche de la carte d' incubateur de Helm autrefois
Toutes ces solutions ont en commun qu'elles utilisent toutes Heketi en tant qu'API de gestion. Par conséquent, toutes doivent être traitées avec une configuration de topologie de nœuds de stockage prédéfinie . Et bien que cela puisse sembler un peu écrasant, ce processus se résume en fait à exécuter une commande et à écrire quelques adresses IP. Voici à quoi cela ressemble:
Fondamentalement, tout ce dont vous avez besoin est l'adresse IP interne, le nom et le nom du périphérique de stockage de chaque nœud que vous avez créés à la dernière étape. Si vous avez suivi les instructions avec précision, le nom de l'appareil serait /dev/disk/gluster-disk.
Pour obtenir les parties restantes du puzzle, tapez simplement cette commande:
$ kubectl get nodes -o wideNAME STATUS AGE VERSION INTERNAL-IP kicksware-k8s-3pkt4 Ready 38h v1.18.8 10.114.0.5 kicksware-k8s-3pkt8 Ready 38h v1.18.8 10.114.0.3 kicksware-k8s-3pktw Ready 38h v1.18.8 10.114.0.4En outre, en fonction de la méthode choisie (à part celle d'IBM), vous devrez peut-être saisir manuellement l'adresse IP du cluster du service Heketi dans la configuration de la classe de stockage et le tableau de mise à niveau:
$ kubectl get services -lrelease=<RELEASE_NAME>NAME TYPE CLUSTER-IP PORT(S) AGEgluster-heketi ClusterIP 10.245.189.193 8080/TCP 1mNe vous ai-je pas dit qu'au final, ce serait du gâteau! Et maintenant c'est enfin ça. Bon travail!
Encore une chose, si vous exécutez Kubernetes basé sur RBAC, assurez-vous de fournir un RoleBinding approprié pour l'application Heketi. Sinon, il ne pourra pas charger la topologie et vous recevrez ce message d'erreur étrange:
Unable to create node: New Node doesn't have glusterd runningEn raison de sa nature hautement dynamique, presque éphémère, le paradigme de gestion du stockage Kubernetes peut parfois être déroutant et même écrasant. La plupart des services déployés sont, par défaut, sans état . Cependant, les scénarios de production réels exigent souvent qu'ils soient avec état , c'est-à-dire qu'ils disposent d'une sorte de stockage externe. Pour cela, Kubernetes propose nativement certaines solutions: options éphémères , volumes persistants, revendications de volume persistant, classes de stockage ou StatefulSets .
En outre, la fourniture de stockage diffère en fonction des méthodes statiques et dynamiques de le faire. La statique nécessite que les administrateurs réfléchissent et configurent PV à l'avance, ce qui va en quelque sorte à l'encontre de l'état d'esprit de Kubernetes en termes de traitement des ressources (CPU, mémoire et stockage) comme accordées dynamiquement. Par conséquent, une manière dynamique, considérée comme plus appropriée et élégante, consiste à déléguer la responsabilité de la gestion du stockage au moteur K8 et cela se fait via StorageClasses.
StorageClassrésume un processus compliqué de gestion du stockage distribué, le rendant aussi simple que d'écrire quelques lignes sur la configuration YAML. Cependant, le StorageClassparadigme doit initialement être implémenté en utilisant un service externe. Et bien que certains d'entre eux soient également faciles à utiliser, il existe des options qui nécessitent d'abord une procédure de déploiement complexe.
Cet article était dédié à la découverte des détails et des pièges du déploiement de GlusterFS en fournissant un ensemble complet d'instructions sur la façon de le faire avec la spécification prévue sur l'environnement géré Kubernetes.
En tant qu'auteur, j'espère vraiment que cela vous sera utile. Parce qu'à l'époque où j'explorais ce formidable outil, il n'y avait pas de telles ressources et j'ai dû passer beaucoup de temps à m'attaquer aux moyens de résoudre un tas de problèmes locaux.
En tant que développeur, je suis très fier de notre communauté pour être si utile et si utile de manière à être suivie par n'importe qui. C'est donc mon effort pour contribuer à ce mouvement.
Appréciez votre attention.
Joyeux DevOpsing!
