Kubernetes : Volume de stockage partagé entre plusieurs pods sur Amazon.

Le partage de fichiers entre pods semble être une tâche facile à première vue, mais c'est tout le contraire. C'est pourquoi j'ai décidé d'écrire cet article pour partager la façon dont nous avons abordé cette question à Abyssale .

Solution de stockage sur Amazon :

Sur Amazon, vous pouvez trouver 3 types de stockage que vous pouvez utiliser pour vos dosettes de production :

• S3 : Simple Storage Service
• EBS : Elastic Block Store
• EFS : Elastic File System

Je ne partagerai pas les informations sur Glacier et Snowball qui sont respectivement un stockage à froid et un outil de transfert/stockage.

Simple Storage Service(S3) :

S3 est un service de stockage d'objets. Il peut être utilisé comme stockage partagé via s3fs. Il permet de monter un bucket via FUSE (Filesystem in Userspace interface). Je ne l'ai pas essayé mais les performances lorsque vous utilisez S3 comme un système de fichiers classique semblent assez faibles et la limitation en lecture/écriture assez élevée. D'un autre côté, c'est la solution la moins chère.

Elastic Block Store(EBS):

EBS est un stockage en bloc persistant avec une taille définie (il est toutefois possible de la modifier ultérieurement). Il est entièrement configurable et pourrait être la solution la plus performante d'Amazon. L'inconvénient majeur est qu'il ne peut être monté que sur une seule instance EC2. Cela signifie également qu'il ne peut pas être partagé entre plusieurs pods.

Système de fichiers élastique(EFS) :

EFS est un système de stockage de fichiers partagé avec une élasticité dynamique et des performances évolutives. Il s'agit essentiellement d'un système de fichiers réseau (NFS).

Ce qui veut dire :

• Performances supérieures à 10 Go/sec et jusqu'à 500 000 IOPS.
• Le stockage du système de fichiers augmente ou diminue au fur et à mesure que vous supprimez ou ajoutez de nouveaux fichiers. Selon la documentation, il n'y a pas de limite de capacité. Seulement une taille maximale pour un seul fichier : 47,9 TiB. La plupart des utilisateurs devraient s'accommoder de ces limitations.
• 400 cibles de montage pour chaque nuage privé virtuel.

Nos besoins :

Deux pods doivent accéder au même stockage. Un pod est toujours en train d'écrire de nouveaux fichiers et l'autre est en train de les lire. À l'adresse Abyssale, nous avons besoin d'obtenir les meilleures performances possibles, car nos utilisateurs bénéficient des résultats de nos produits.

À première vue, la solution EFS semblait répondre à nos besoins, mais sa mise en œuvre était décourageante. C'est la raison pour laquelle j'ai écrit le tutoriel suivant.

Configurez la pile :

1. Exigences :

Afin de poursuivre ce tutoriel, il est nécessaire de préparer et/ou d'avoir déjà mis en place certaines exigences de base, telles que :

• J'ai déjà une EKS opérationnelle.
• AWS EFS doit être disponible dans votre région.
• L'EKS et l'EFS doivent se trouver dans la même région.

Vérifiez le tableau des régions pour plus d'informations.

Le deuxième point est très important à vérifier. Nous avons dû migrer notre infrastructure de production de Paris vers l'Irlande car EFS n'était pas disponible dans la région.

2. Créez le système de fichiers Elastic :

Créez d'abord un"Groupe de sécurité" :

• Le VPC doit être le même que celui de l'EKS. Vous trouverez les informations nécessaires sur la page du cluster EKS.
• Remplissez les champs Inbound et Outbound comme suit :

Ensuite, allez sur la page de création de l'EFS:

• Choisissez à nouveau le même VPC.
• Ajoutez le groupe de sécurité que nous avons créé précédemment.

Ensuite, étape suivante, créer le système de fichiers.

3. Déployez l'efs-provisioner :

Le efs-provisioner permet de monter le stockage EFS comme PersistentVolumes dans Kubernetes. (N'oubliez pas de changer l'espace de noms avec le vôtre).

Déployer efs-provisioner :

Remplacez ces valeurs par les vôtres :

MON_FILE_SYSTEM_ID: Vous pouvez le trouver sur la page de création de l'EFS. Par exemple : fs-xxx
MY_AWS_REGION: La région où vous avez créé votre EFS. par exemple : eu-west-1
MON_NOM_DE_PROVISIONNEUR: Choisissez un nom qui sera réutilisé plus tard.
MON_EFS_DNS_NAME: Vous pouvez le trouver sur la page de création de l'EFS.
ex : fs-xx.eu-west-1.amazonaws.com

Un serviceAccount fournit une identité pour les processus qui s'exécutent dans un Pod. Nous lions le pod précédemment créé avec un nom (efs-provisioner). Il sera utilisé plus tard dans RBAC pour lier les rôles et le pod.

‍

Le contrôle d'accès basé sur les rôles (RBAC) est activé par défaut sur l'EKS. Il faut s'autoriser efs-provisioner pour accéder aux ressources.

StorageClass est utilisé pour lier le efs-provisioner avec le PersistentVolumeClaim. PersistentVolumeClaim est une demande de stockage.

Nous lions le PersistentVolumeClaim avec le Classe de stockage (aws-efs). Comme l'EFS n'a pas de limite de stockage, la limite de stockage n'a pas d'importance.

Modifiez la valeur suivante :

MON_NOM_DE_PROVISIONNEUR: Le nom que vous avez donné dans le formulaire efs-provisioner

4. Utilisez le volume persistant dans vos pods :

Maintenant vous pouvez utiliser le volume persistant dans plusieurs pods.
Nous utilisons le claimeName PersistentVolumeClaim (efs). Vous pouvez utiliser le PersistentVolumeClaim dans plusieurs Deployment.

Conclusion et retour d'expérience :

J'ai eu du mal à déployer l'ensemble de la solution en raison des points suivants :

• Au début, j'ai mal configuré le groupe de sécurité.
• La documentation RBAC pour efs-provisioner n'était pas complète. J'ai dû chercher dans les problèmes de github pour trouver la réponse.

Nous sommes vraiment satisfaits de cette solution car les performances répondent à nos attentes. Le fait que le stockage soit extensible est également un bon aspect. Enfin, vous pouvez également configurer une option de sauvegarde.

Si vous avez des questions ou si vous avez besoin d'aide pour mettre en place votre solution EFS, n'hésitez pas à me contacter sur Twitter @LemRemy.

Si vous avez apprécié cette histoire, partagez-la pour que d'autres la trouvent !