Orchestrez vos conteneurs avec Kubernetes

Découvrez le concept de volume

Bon, si je résume, depuis le début de ce cours, vous avez appris à créer votre propre image applicative, déployer cette image dans un cluster Kubernetes et exposer cette application au sein du cluster via un service.

Par défaut, le site web de LiveCorp écrit ses données dans une base de données interne au sein du pod. Si un nouveau pod est créé, déplacé ou même redémarré, les données ne vivront qu’au sein de ce pod et ne seront pas partagées avec les autres pods. Il faut alors trouver un moyen d’assurer la persistance de ces données à l’extérieur du pod afin de ne pas perdre de données en cas de crash ou en cas de redémarrage d’un nouveau pod.

C’est là qu’intervient la notion de volume. Les volumes sont un élément essentiel de Kubernetes pour gérer les données de vos applications. Ils permettent de stocker des données de manière persistante, de les partager entre les conteneurs d'un même pod, et de les gérer indépendamment du cycle de vie des pods.

Il existe plusieurs cas où l'utilisation des volumes est indispensable au sein de Kubernetes. Par exemple, si un conteneur s'arrête ou redémarre, les données qu'il contient sont perdues. Les volumes permettent de stocker les données sur un support de stockage persistant, garantissant ainsi leur survie même si le conteneur est détruit. De plus, les volumes peuvent être partagés entre plusieurs conteneurs d'un même pod, ce qui permet aux conteneurs de collaborer et d'échanger des informations.

Dans le cas du site web de LiveCorp, nous allons utiliser les volumes persistants.

Alors c’est une excellente question ! Les volumes persistants sont indépendants du cycle de vie des pods et peuvent être utilisés pour stocker des données de manière persistante. Afin de déclarer des volumes persistants, il est nécessaire d’utiliser deux types de volumes :

• PersistentVolume (PV): Un volume de stockage persistant qui est provisionné par un administrateur de cluster et peut être utilisé par plusieurs pods ;

• PersistentVolumeClaim (PVC): Une demande de stockage persistant par un utilisateur. Kubernetes associe automatiquement une PVC à un PV disponible.

Il existe aussi deux autres types de volumes que nous allons voir dans la suite du cours :

• ConfigMap et Secret: Des volumes spéciaux pour stocker des données de configuration et des secrets (mots de passe, clés API, etc.).

Dans ce chapitre, nous allons nous attarder sur les PersistentVolume, ainsi que les PersistantVolumeClaim. Dans le chapitre suivant, nous verrons comment stocker de la configuration ou des éléments sensibles dans un ConfigMap et un Secret.

Explorez les volumes dans Kubernetes

Dans Kubernetes, le meilleur moyen de persister de la donnée est via les PV et les PVC.

Le PersistentVolume

Un PersistentVolume (PV) est une ressource de stockage dans Kubernetes qui est provisionnée par un administrateur de cluster, la plupart du temps Charlie, notre Ops. Il représente un morceau de stockage dans le cluster qui a un cycle de vie indépendant des pods qui l'utilisent.

En d'autres termes, un PV est comme un disque dur ou un partage réseau que vous pouvez connecter à vos pods pour stocker des données de manière persistante. Même si le pod est supprimé ou redémarré, les données stockées dans le PV restent intactes.

Comme chaque objet déclaré dans Kubernetes, pour déclarer un PersistentVolume, il va falloir créer un fichier YAML. Un PersistentVolume est défini comme suit :

apiVersion: v1
kind: PersistentVolume
metadata:
name: site-ecommerce-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain

Attardons-nous un peu sur ce fichier YAML. Comme les précédents fichiers YAML déjà écrits, les 4 premières lignes sont identiques. Ici, nous créons un kindPersistentVolume  .

Le champsspec , lui, contient des informations importantes :

• capacity: C’est la taille du volume de stockage ;

• accessModes: C’est le mode d'accès autorisés pour le volume ;

• persistentVolumeReclaimPolicy: C’est une politique de récupération de la donnée.

L’accessModes ici peut prendre plusieurs valeurs :

• ReadWriteOnce (RWO): Le volume peut être monté en lecture/écriture par un seul nœud à la fois ;

• ReadOnlyMany (ROX): Le volume peut être monté en lecture seule par plusieurs nœuds simultanément ;

• ReadWriteMany (RWX): Le volume peut être monté en lecture/écriture par plusieurs nœuds simultanément. 

Dans notre cas, nous utilisons le mode ReadWriteMany car nous voulons que le volume puisse être écrit par plusieurs nœuds simultanément.

Le persistentVolumeReclaimPolicy peut prendre 3 valeurs :

• Retain : la donnée est gardée au sein du PV ;

• Recycle : le contenu du PV est effacé ;

• Delete : le PV est supprimé du cluster.

Dans les deux derniers cas, la donnée est définitivement perdue. Ici, nous utilisons la politique Retain car les données doivent être gardées.

Il existe aussi un champ supplémentaire qui peut être utilisé, le storageClassName, qui est le nom du StorageClass à utiliser si le provisionnement était dynamique.

Un StorageClass dans Kubernetes sert à gérer le approvisionnement dynamique de volumes persistants. Il agit comme un modèle qui définit les paramètres de stockage à utiliser lors de la création d'un PV. Généralement, les StorageClass sont déclarés par les Ops sur le cluster lors de sa création.

Bonne question ! Au lieu de créer manuellement des PV, un StorageClass permet de les provisionner automatiquement en fonction des besoins des applications. Les développeurs n'ont pas besoin de connaître les détails de l'infrastructure de stockage sous-jacente. Ils peuvent simplement demander un volume avec certaines caractéristiques (taille, type de stockage, etc.), et Kubernetes se charge du reste.

Le PersistentVolumeClaim

Un PersistentVolumeClaim (PVC) est une demande de stockage par un utilisateur. Grâce à cette abstraction, les utilisateurs peuvent demander du stockage sans connaître les détails de l'infrastructure.

En d'autres termes, une PVC est comme une commande passée à Kubernetes pour obtenir un volume de stockage avec certaines caractéristiques (taille, mode d'accès, etc.). Kubernetes se charge ensuite de trouver un PersistentVolume (PV) correspondant à cette demande et de le lier à la PVC.

Une PVC est définie par un fichier YAML avec les sections suivantes :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: site-ecommerce-pvc
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 10Gi
selector:
matchLabels:
name: site-ecommerce-pv

Comme dans tous les fichiers YAML écrits précédemment, les 4 premières lignes précisent la version de l’API utilisée ainsi que le kind que vous voulez créer. Ici, vous allez créer un objet de type PersistentVolumeClaim.

La section spec  ensuite est propre au kind PersistentVolumeClaim :

• accessModes: C’est le même mode d’accès que le PersistentVolume (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) ;

• storage: C’est la taille de stockage demandée ;

• selector: Ce sont les labels pour sélectionner un PV spécifique (optionnel si vous utilisez un StorageClass).

Ici, vous allez demander un volume persistant à Kubernetes avec comme taille 10Go et qui s’appelle  site-ecommerce-pv . Kubernetes se chargera ensuite de lier le PV et le PVC.

Écrivez un fichier YAML avec l’API PersistentVolume

Maintenant que vous en savez un peu plus sur les volumes dans Kubernetes, il est temps de modifier le déploiement du site web de LiveCorp afin de persister les données dans un volume et de ne pas perdre de données s’il arrive quelque chose aux pods.

Vous allez devoir écrire deux fichiers YAML (un pour le PersistentVolume, l’autre pour le PersistentVolumeClaim), les appliquer sur le cluster et modifier le fichier de déploiement pour prendre en compte le PV.

Tout d’abord, créez les deux fichiers suivants :

apiVersion: v1
kind: PersistentVolume
metadata:
name: site-ecommerce-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: site-ecommerce-pvc
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 10Gi
selector:
matchLabels:
name: site-ecommerce-pv

Puis appliquez-les sur le cluster Kubernetes :

kubectl apply -f site-ecommerce-pv.yaml
kubectl apply -f site-ecommerce-pvc.yaml

Vous pouvez ensuite vérifier que les deux fichiers ont été correctement appliqués :

kubectl get pv
kubectl get pvc

Il va falloir maintenant modifier le fichier de déploiement que vous aviez créé précédemment pour ajouter le PVC utilisable par les pods :

apiVersion: apps/v1
kind: Deployment
metadata:
name: site-ecommerce-deployment
spec:
replicas: 5
selector:
matchLabels:
app: site-ecommerce
template:
metadata:
labels:
app: site-ecommerce
spec:
containers:
- name: site-ecommerce
image: site-ecommerce:1.2.0
        volumeMounts:
          - name: site-ecommerce-volume
             mountPath: /etc/todos
ports:
- containerPort: 8080
        volumes:
          - name: site-ecommerce-volume
            persistentVolumeClaim:
              claimName: site-ecommerce-pvc

Les parties à changer sont dansvolumeMountsetvolumesdans le déploiement. Cela va indiquer à Kubernetes d’utiliser un volume quand un pod voudra écrire dans  /etc/todos

Vous allez maintenant appliquer la modification sur le cluster Kubernetes :

kubectl apply -f site-ecommerce-deployment.yml

Vous pouvez vérifier que le pod utilise bien le volume :

kubectl describe deploy/site-ecommerce-deployment

Et voilà ! Vos données sont maintenant persistées !

Dans ce screencast, vous avez :

• créé un PersistentVolume ;

• crée un PersistentVolumeClaim ;

• modifié votre déploiement pour prendre en compte le PV et le PVC.

À vous de jouer

Contexte

Alice : Je crois que nous avons un problème sur le site web. À chaque fois que Charlie, notre ops, applique un nouveau déploiement, les données ne sont pas sauvegardées. Peux-tu trouver un moyen pour que l’application récupère les données à chaque déploiement ?

Consignes

• Créez un PersistentVolume pour persister les données ;

• Créez un PersistentVolumeClaim afin que l’application puisse utiliser le PV ;

• Vérifiez que le PV et le PVC sont bien créé ;

• Modifiez le Deployment afin de tirer parti des deux nouvelles ressources ;

• Redémarrez l’application ;

• Vérifiez que les données sont bien persistées.

En résumé

• Un volume est un moyen pour partager ou persister les données entre pods.

• Un PersistentVolume est un volume associé au cluster Kubernetes.

• Un PersistentVolumeClaim est une demande par les pods d’accéder aux PV.

• Les PV sont associés à des StorageClass.

• Les StorageClass sont créés par les ops du cluster.

Dans le prochain chapitre, vous allez apprendre à configurer votre application via des variables d’environnements !