Editions ENI Livres | Vidéos | e-Formations
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.
