Blog ENI : Toute la veille numérique !
-25€ dès 75€ sur les livres en ligne, vidéos... avec le code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Kubernetes
  3. Persistance des données
Extrait - Kubernetes Gérez la plateforme de déploiement de vos applications conteneurisées (2e édition)
Extraits du livre
Kubernetes Gérez la plateforme de déploiement de vos applications conteneurisées (2e édition)
1 avis
Revenir à la page d'achat du livre

Persistance des données

Objectifs du chapitre et prérequis

Ce chapitre présente la persistance des données dans Kubernetes. En effet, le contenu d’un container n’a pas vocation à perdurer. Ce mécanisme est là pour permettre de conserver une information lorsque c’est nécessaire (bases de données, serveurs de fichiers, etc.).

Le chapitre abordera deux points de vue :

  • L’utilisateur faisant appel aux volumes persistants.

  • L’administrateur mettant en place ce mécanisme.

Persistance des données

1. Origine du besoin

Dans ce qui a précédé, vous avez pu aborder le cycle de vie du container dans Kubernetes. Un point important à retenir est qu’un container a une durée de vie relativement courte et, qu’en l’état, il n’est pas possible de conserver de la donnée.

Pour répondre à ce besoin, Kubernetes peut mettre à disposition des espaces de stockage externes au cluster. Ce mécanisme s’appuie sur la notion de volume de données persistant (Persistent Volume).

2. Utilisation d’un volume persistant externe

L’utilisation d’un volume persistant se fait au sein de la déclaration d’un pod. Une première solution pourrait être de passer par un service externe comme avec un point de montage NFS.

Cette déclaration de persistance de données se définira en deux parties :

  • Un référencement au niveau du pod dans le champ volumes.

  • une indication de l’emplacement du montage au sein du container.

Le référencement d’un volume NFS au niveau d’un pod se présentera sous la forme suivante :

spec: 
 volumes: 
   - name: nfs 
     nfs: 
       # URL for the NFS server 
       server: 192.168.0.1 
       path: / 

Le montage au niveau du container se présentera ainsi :

spec: 
 containers: 
   - name: mailhog 
     image: mailhog/mailhog 
 
     # Mount the NFS volume in the container 
     volumeMounts: 
       - name: nfs 
         mountPath: /maildir 

3. Volumes persistants

a. Structure du volume persistant

En plus de faire appel à des services externes, il est possible de référencer des objets de type volume persistant (Persistent Volume). Ces derniers ont la structure suivante :

  • Une version et un type (apiVersion et kind).

  • Des métadonnées (champ metadata).

  • Une spécification contenant :

  • le type d’accès,

  • la capacité de stockage,

  • la classe du volume persistant (positionner à manual pour l’exemple),

  • les caractéristiques du stockage.

Ci-dessous un exemple...

Classes de stockage

1. Origine du besoin

La section précédente a permis d’aborder le travail nécessaire à la mise en place d’un volume persistant :

  • Une déclaration pour indiquer que de l’espace disque est disponible.

  • Une déclaration pour pouvoir s’accaparer un espace disque.

  • Une action manuelle pour positionner les droits sur les répertoires.

Heureusement pour l’administrateur, ce travail de déclaration n’est pas nécessaire. Il est possible de passer par un gestionnaire automatique de volume persistant : les objets StorageClass (ou son raccourci sc).

Ces objets vont se charger d’intercepter les demandes de volumes persistants (PersistentVolumeClaim) et de réaliser automatiquement les actions suivantes :

  • Création de l’objet PersistentVolume.

  • Attribution des droits ad-hoc.

Autre point, un cluster Kubernetes peut faire appel à plusieurs classes de stockage offrant plusieurs niveaux de services, comme par exemple :

  • une classe ssd pour des disques rapides de type SSD,

  • une classe hdd pour des disques durs classiques de type HDD,

  • une classe nfs pour pouvoir partager un espace disque entre plusieurs pods.

Charge à vous ensuite de créer le type de disque nécessaire en fonction des besoins des utilisateurs.

Ainsi, une application réclamant des disques rapides pourra demander des disques SSD, tandis qu’une autre prendra des disques traditionnels afin de réduire les coûts de stockage.

2. Liste des classes de stockage

Sur Minikube, une classe de stockage est présente à l’installation.

 Pour récupérer cette déclaration, lancez la commande kubectl avec les options suivantes :

  • Le verbe get.

  • Le type à récupérer (storageclass ou son raccourci sc).

Ci-dessous la commande à lancer :

$ kubectl get storageclass 

Et le résultat attendu :

NAME                 PROVISIONER                AGE 
standard (default)   k8s.io/minikube-hostpath   30d 

Une classe de stockage porte le nom standard et cette dernière est définie par défaut. Autre point, le mécanisme d’approvisionnement porte le nom de k8s.io/minikube-hostpath.

3. Détail d’une classe...