Modes d'accès aux volumes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany)

Comment utiliser le volume ? Définir les règles d'accès

Lorsque nous définissons un PersistentVolume (PV) ou que nous demandons du stockage via une PersistentVolumeClaim (PVC), il ne suffit pas de spécifier la taille. Une question cruciale est de savoir *comment* ce volume pourra être utilisé par les Pods. Un Pod aura-t-il besoin d'écrire des données ? Plusieurs Pods sur différents noeuds auront-ils besoin d'accéder au même volume simultanément ?

Pour répondre à ces questions, Kubernetes utilise les Modes d'Accès (Access Modes). Ils définissent les règles de montage d'un volume, en particulier en ce qui concerne les permissions (lecture/écriture) et la possibilité de montage simultané par plusieurs noeuds ou Pods.

Les modes d'accès sont une partie essentielle du contrat entre le PV (qui offre certaines capacités) et la PVC (qui demande certaines capacités). Le choix du bon mode d'accès dépend à la fois des besoins de l'application et des capacités du système de stockage sous-jacent.

ReadWriteOnce (RWO) : Accès exclusif par noeud

Définition : Le volume peut être monté en lecture-écriture par un seul noeud à la fois.

Implications : Cela signifie que si un Pod sur `noeud-A` monte un volume RWO, aucun autre Pod sur `noeud-B` ne pourra monter ce même volume en lecture-écriture (et souvent, même pas en lecture seule, selon le fournisseur de stockage). Cependant, plusieurs Pods sur le même noeud (`noeud-A`) peuvent potentiellement monter et utiliser le même volume RWO simultanément (si le système de fichiers sous-jacent le permet).

Cas d'usage typiques : C'est le mode d'accès le plus courant et souvent le seul supporté par les volumes de type bloc fournis par les clouds (comme AWS EBS, GCE Persistent Disk, Azure Disk). Ces volumes sont généralement attachés à une seule VM (noeud) à la fois. Idéal pour :

• Bases de données mono-instance.
• Applications stateful qui n'ont pas besoin d'accès concurrent en écriture depuis plusieurs noeuds.
• La plupart des cas d'utilisation des StatefulSets où chaque Pod obtient son propre volume unique (qui sera RWO).

Spécification YAML (dans PV ou PVC `spec.accessModes`) :

accessModes:
  - ReadWriteOnce

ReadOnlyMany (ROX) : Partage en lecture seule

Définition : Le volume peut être monté en lecture seule par plusieurs noeuds simultanément.

Implications : Permet à de nombreux Pods, potentiellement répartis sur différents noeuds du cluster, de lire les données du même volume en même temps. Aucune écriture n'est autorisée via ces montages.

Cas d'usage typiques :

• Partager des données de configuration statiques ou des assets (fichiers CSS/JS, images) entre plusieurs réplicas d'une application web.
• Fournir des données de référence en lecture seule à plusieurs services.
• Monter des volumes contenant des binaires ou des bibliothèques partagées.

La plupart des types de volumes supportent ce mode.

Spécification YAML :

accessModes:
  - ReadOnlyMany

ReadWriteMany (RWX) : Partage complet en lecture-écriture

Définition : Le volume peut être monté en lecture-écriture par plusieurs noeuds simultanément.

Implications : C'est le mode le plus flexible mais aussi le plus complexe à réaliser et souvent le moins performant. Il permet à des Pods sur différents noeuds de lire et d'écrire sur le même volume en même temps. Cela nécessite impérativement un système de stockage sous-jacent capable de gérer l'accès concurrent en écriture et de maintenir la cohérence des données (par exemple, un système de fichiers réseau ou distribué).

Cas d'usage typiques :

• Systèmes de fichiers partagés pour des applications collaboratives (ex: CMS, plateforme de partage de fichiers).
• Certaines applications distribuées qui nécessitent un espace de stockage partagé accessible en écriture par toutes les instances.
• Espace de travail partagé pour des pipelines CI/CD.

Systèmes de stockage supportant RWX : NFS, GlusterFS, CephFS, Azure Files, et certains autres pilotes CSI spécifiques.

Spécification YAML :

accessModes:
  - ReadWriteMany

ReadWriteOncePod (RWOP) : Accès exclusif par Pod (plus récent)

Définition : Le volume peut être monté en lecture-écriture par un seul Pod à la fois, dans tout le cluster.

Implications : C'est une contrainte plus forte que RWO. Même si plusieurs Pods se trouvent sur le même noeud, seul l'un d'entre eux pourra monter le volume. Cela garantit une exclusivité totale au niveau du Pod.

Cas d'usage typiques : Principalement utilisé avec certains pilotes CSI pour des charges de travail stateful spécifiques qui nécessitent une garantie d'accès exclusif par Pod.

Note : Ce mode est plus récent et son support dépend entièrement du pilote CSI utilisé.

Spécification YAML :

accessModes:
  - ReadWriteOncePod

Interaction entre PV, PVC et Pods

• Un PersistentVolume (PV) déclare les modes d'accès qu'il supporte (il peut en supporter plusieurs, par exemple `[ReadWriteOnce, ReadOnlyMany]`).
• Une PersistentVolumeClaim (PVC) déclare les modes d'accès dont l'application a besoin (elle peut en demander un ou plusieurs).
• Pour qu'une PVC puisse être liée (bind) à un PV, le PV doit supporter tous les modes d'accès demandés par la PVC.
• Lorsqu'un Pod monte le volume via la PVC, il le monte en utilisant un seul des modes d'accès autorisés par la PVC et le PV. Par exemple, même si un PV supporte RWO et ROX et que la PVC demande RWO, le Pod montera le volume en mode RWO. Si le Pod spécifie `readOnly: true` dans son `volumeMount`, il le montera en lecture seule, même si le mode d'accès sous-jacent est RWO ou RWX.

Conclusion : adapter l'accès aux besoins et capacités

Les modes d'accès sont une composante essentielle de la spécification du stockage dans Kubernetes. Ils définissent comment les volumes peuvent être partagés et utilisés par les Pods, reflétant à la fois les exigences des applications et les capacités des technologies de stockage sous-jacentes.

Choisir le bon mode d'accès (`ReadWriteOnce`, `ReadOnlyMany`, `ReadWriteMany`, ou `ReadWriteOncePod`) est crucial lors de la définition des PVs et des PVCs pour garantir que les applications fonctionnent correctement et que les contraintes du système de stockage sont respectées. C'est un élément clé pour construire des applications stateful fiables sur Kubernetes.