Hoe wordt de persistent volume verdeeld over verschillende zones om toegang tot opslag voor verschillende domeinen en zones te garanderen?

Bij het gebruik van Kubernetes en openbare clouds (bijvoorbeeld AWS, GCP, Azure), wordt de verdeling van persistent volumes (PV) over zones uitgevoerd op het niveau van de cloud provider en de koppeling van PV aan knooppunten:

1. Aanmaken van PV: Het Persistent Volume (PersistentVolume) wordt door de beheerder of automatisch via StorageClass aangemaakt. Bij het aanmaken worden opslagparameters gespecificeerd: type (EBS, GCE Persistent Disk, Azure Disk), grootte, toegangsmodus.
2. Zone/regio-bewustzijn: StorageClass voor bepaalde opslagtypen in de cloud kan worden geconfigureerd met ondersteuning voor beschikbaarheidszones. Bij het aanmaken van een PV via zo'n StorageClass kan de cloudprovider de fysieke opslagbron (bijvoorbeeld een schijf) in een specifieke zone plaatsen of deze redundantie in zones maken (afhankelijk van het opslagtype en de instellingen). Het gebruik van StorageClass met de parameter volumeBindingMode: WaitForFirstConsumer stelt Kubernetes in staat om de binding van PV aan PVR uit te stellen totdat de eerste pod die deze PVR gebruikt, gepland is op een knooppunt in een specifieke zone.
3. PersistentVolumeClaim (PVC): De gebruiker maakt een PersistentVolumeClaim (PVC) aan met een verzoek om een bepaald volume en kenmerken.
4. Binding van PV aan PVC: Kubernetes koppelt de PVC aan een geschikte PV. Als WaitForFirstConsumer wordt gebruikt, gebeurt de binding wanneer de eerste pod die deze PVC gebruikt, gepland wordt op een knooppunt.
5. Locatie van de Pod op het knooppunt: De Kubernetes scheduler bepaalt op welk knooppunt de pod wordt uitgevoerd. Er worden verschillende criteria in overweging genomen, waaronder resource-eisen, affiniteit/anti-affiniteit, Taints/Tolerations.
6. Binding van PV aan het knooppunt: Als de pod die de PVC gebruikt (die op zijn beurt gekoppeld is aan PV) gepland wordt op een knooppunt in een specifieke zone, zorgt Kubernetes (meer precies, de Volume Controller en de cloudprovider) ervoor dat PV beschikbaar (gemount) is op dat knooppunt. Cloud-schijven worden meestal gekoppeld aan virtuele machines in dezelfde zone. Kubernetes houdt rekening met de zone-kenmerken van PV bij het plannen van pods, om te voorkomen dat geprobeerd wordt PV's uit één zone te monteren op een knooppunt in een andere zone.

Voorbeeld van StorageClass met zone-aware modus:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: regional-storage
provisioner: kubernetes.io/aws-ebs # of gce-pd, microsoft.com/azure-disk, etc.
parameters:
 type: gp2 # of ssd, pd-standard, etc.
 fsType: ext4
 volumeBindingMode: WaitForFirstConsumer # Belangrijke parameter voor zoneplanning
reclaimPolicy: Retain
allowVolumeExpansion: true

Bij gebruik van volumeBindingMode: WaitForFirstConsumer wacht Kubernetes tot de pod gepland is op een knooppunt in een specifieke zone (bijvoorbeeld us-east-1a) voordat de PVC definitief gekoppeld wordt aan PV en de bijbehorende cloud-schijf in die zone wordt aangemaakt.

De verdeling over domeinen (in brede zin, als logische scheiding van applicaties of teams) wordt niet bereikt door fysieke verdeling van PV's, maar door het RBAC-mechanisme (Role-Based Access Control), resource-quotas (Resource Quotas) en isolatie binnen namespaces:

• Namespaces: Verschillende domeinen/teams kunnen hun eigen namespaces gebruiken om resources te isoleren, inclusief PVC en pods.
• RBAC: Bepaalt welke gebruikers of groepen het recht hebben om PVC's en andere resources te maken, lezen, bijwerken of verwijderen in bepaalde namespaces.
• Resource-quotas: Beperken de totale hoeveelheid resources (inclusief volume van persistent geheugen) die in elke namespace gebruikt kunnen worden, en zorgen voor eerlijk gebruik tussen "domeinen".