Comment la distribution du volume persistant se fait-elle à travers différentes zones pour assurer l'accès au stockage pour différents domaines et zones?

Lors de l'utilisation de Kubernetes et de clouds publics (par exemple, AWS, GCP, Azure), la répartition des volumes persistants (PV) par zones est effectuée au niveau du fournisseur de cloud et de l'association PV à des nœuds:

1. Création de PV : Le volume persistant (PersistentVolume) est créé par l'administrateur ou automatiquement via StorageClass. Lors de sa création, les paramètres de stockage sont spécifiés : type (EBS, GCE Persistent Disk, Azure Disk), taille, mode d'accès.
2. Conscience de la zone/région : StorageClass pour certains types de stockage dans le cloud peut être configuré avec un support pour les zones de disponibilité. Lors de la création d'un PV via un tel StorageClass, le fournisseur cloud peut placer la ressource physique de stockage (par exemple, un disque) dans une zone spécifique ou la rendre redondante en zones (selon le type de stockage et les configurations). L'utilisation de StorageClass avec le paramètre volumeBindingMode: WaitForFirstConsumer permet de différer la liaison du PV au PVR jusqu'à ce que le premier pod utilisant ce PVR soit programmé sur un nœud dans une zone spécifique.
3. PersistentVolumeClaim (PVC) : L'utilisateur crée un PersistentVolumeClaim (PVC) en demandant un volume avec des caractéristiques spécifiques.
4. Liaison PV à PVC : Kubernetes lie le PVC à un PV approprié. Si WaitForFirstConsumer est utilisé, la liaison se produit lorsque le premier pod utilisant ce PVC est programmé sur un nœud.
5. Placement du Pod sur le Nœud : Le planificateur Kubernetes (Scheduler) détermine sur quel nœud le pod sera lancé. Divers critères sont pris en compte, y compris les exigences en ressources, l'affinité/anti-affinité, Taints/Tolerations.
6. Liaison PV au Nœud : Si le pod utilisant le PVC (qui est lié au PV) est programmé sur un nœud dans une zone spécifique, Kubernetes (plus précisément, le Contrôleur de Volume et le fournisseur cloud) garantit que le PV sera accessible (monté) sur ce nœud. Les disques cloud sont généralement liés aux machines virtuelles dans la même zone. Kubernetes considère la zonalité du PV lors de la planification des pods pour éviter d'essayer de monter un PV d'une zone sur un nœud d'une autre zone.

Exemple de StorageClass avec mode zone-aware :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: regional-storage
provisioner: kubernetes.io/aws-ebs # ou gce-pd, microsoft.com/azure-disk, etc.
parameters:
 type: gp2 # ou ssd, pd-standard, etc.
 fsType: ext4
 volumeBindingMode: WaitForFirstConsumer # Paramètre important pour la planification zonale
reclaimPolicy: Retain
allowVolumeExpansion: true

Lors de l'utilisation de volumeBindingMode: WaitForFirstConsumer, Kubernetes attend que le pod soit programmé sur un nœud dans une zone spécifique (par exemple, us-east-1a) avant de lier définitivement le PVC au PV et de créer le disque cloud correspondant dans cette zone.

La répartition par domaines (au sens large, comme une séparation logique des applications ou des équipes) est réalisée non pas par la distribution physique des PV, mais par le mécanisme RBAC (Contrôle d'Accès basé sur les Rôles), les quotas de ressources (Resource Quotas) et l'isolation dans les espaces de noms (Namespaces):

• Namespaces : Différents domaines/équipes peuvent utiliser leurs propres espaces de noms pour isoler les ressources, y compris PVC et pods.
• RBAC : Définit quels utilisateurs ou groupes ont le droit de créer, lire, mettre à jour ou supprimer des PVC et autres ressources dans certains espaces de noms.
• Quotas de ressources : Limitent la quantité totale de ressources (y compris le volume de stockage persistant) pouvant être utilisée dans chaque espace de noms, assurant une utilisation équitable entre "domaines".