Persistance
1. Kubernetes doit offrir à ces 1. Pods des façons d’enregistrer leurs données puisque les Container Runtime offre du storage qui existe uniquement le temps de la vie du container. Il existe plusieurs resources qui permette à des Pods d’accomplir cette tâche.
Volume
Un Volume permet à un container de persister ces données au cours du lifetime du Pod à lequel il appartient. Il est possible d’avoir des volumes qui se partagent entre plusieurs containers sur le même Pod, aucune restriction d’écriture existe. Donc il est possible d’obtenir des cas de données corrompues. Chaque volume doivent être mount dans des répertoire différent, dans le cas de plusieurs volume mount sur un container ils ne peuvent pas être nested.
Dans le manifest d’un Pod, il est possible de définir les volumes et les volumeMounts pour le Pod et les containers. Un exemple de manifest:
apiVersion: v1
kind: Pod
metadata:
name: fordpinto
namespace: default
spec:
containers:
- image: simpleapp
name: gastank
command:
- sleep
- "3600"
volumeMounts:
- mountPath: /scratch
name: scratch-volume
volumes:
- name: scratch-volume
emptyDir: {}Dans ce manifest, on attache le volume scratch-volume qui est de type emptyDir au Pod. Ensuite, on l’attache au container simpleapp dans le sous-répertoire /scratch. Il existe plusieurs type de storage différents, par exemple hostPath, CephFS, ConfigMap, Secret, Fc. Il y a le CSI qui permettrais d’ajouter de nouveau type de storage plus simplement, à l’heure actuelle on dirais que ces toujours en développement.
Les volumes se séparent en deux catégories distinctes. Les volumes éphémères et les volumes persistants.
Éphémères
Les volumes éphémères existent le temps de l’existence du Pod auquel ils sont attachés. Voici quelque type de volume éphémères.
EmptyDir
C’est un type de storage très simple, c’est un volume qui reste pour le lifetime du Pod, mais n’attache pas le storage à l’hôte. Donc toute écriture sur le volume sera perdu si le Pod est détruit. Plusieurs container peuvent attacher le volume en même temps, et peuvent partager des données ainsi.
Persistants
Les volumes persistants existent en dehors de l’existance d’un Pod. Ils doivent donc avoir des mesures supplémentaire afin d’assurer un fonctionnement correcte. La structure est la suivante, il y a des Persistent Volume (PV) et des Persistent Volume Claim (PVC). Les PV définissent des resources dans le cluster (une quantité de storage autorisé). Les PVC sont des demandes pour utiliser les PV. Un PVC peut demander moins de resource que ce qu’un PV offrent, la demande reste valide. Toutefois, la relation entre les deux objets est toujours 1-1, donc si un PVC claim un PV, celui-ci est réserver à ce PVC. Une liste de type de storage se trouve ici.
Lifetime
Ces volumes suivent certaines étapes afin de garder les données valide.
- Provisioning
Le provisioning se fait statiquement ou dynamiquement.
- Statiquement Un administrateur du cluster crée manuellement des PV. Ceux-ci sont disponible pour les utilisateurs.
- Dynamiquement
Si aucun des PV n’est valide pour le PVC, un PV peut être provisionner automatiquement. L’utilisateur doit alors définir le StorageClass à utiliser. Si l’utilisateur ne définit aucun StorageClass le dynamic provisioning sera désactivé pour le claim lui-même. Il est possible de configurer un StorageClass pas défaut avec l’admission controller
DefaultStorageClass.
- Binding L’attachement d’un PVC à un PV. Qu’il soit créer statiquement ou dynamiquement n’a pas d’importance.
- Using Un Pod attachera le claim à un container. Même si le PVC/PV est supprimé, il faut que le Pod termine d’abord.
- Reclaiming
Il y a trois strategy pour la réclamation d’un volume.
- Retain: garde les données intactes. Un administrateur doit faire la réclamation des données manuellement.
- Delete: supprime les resources dans l’API (PV et les assets dans l’infrastructure externe, ex:
AWS EBS). - Recycle: deprecated.