Provisionnement dynamique avec les StorageClasses

Le défi du provisionnement statique : l'intervention manuelle

Nous avons vu le modèle PV/PVC qui découple la demande de stockage de sa fourniture. Dans le scénario de provisionnement statique, un administrateur de cluster doit créer manuellement un certain nombre de PersistentVolumes (PVs) à l'avance. Ces PVs représentent des ressources de stockage existantes (un volume EBS créé manuellement, un partage NFS configuré, etc.). Ensuite, lorsqu'une PersistentVolumeClaim (PVC) est créée par un utilisateur, Kubernetes tente de trouver un PV statique existant qui correspond aux exigences de la PVC (taille, mode d'accès, etc.) pour la lier.

Bien que fonctionnel, ce modèle statique présente des inconvénients majeurs, surtout dans des environnements dynamiques ou à grande échelle :

• Charge administrative : L'administrateur doit anticiper les besoins en stockage et pré-provisionner manuellement chaque PV, ce qui est fastidieux et ne s'adapte pas bien aux demandes fluctuantes.
• Lenteur : Les utilisateurs doivent attendre qu'un administrateur crée un PV approprié si aucun n'est disponible.
• Gestion complexe : Le suivi et la gestion d'un grand nombre de PVs statiques peuvent devenir compliqués.

Pour surmonter ces limitations, Kubernetes introduit le concept de provisionnement dynamique, rendu possible par un autre objet API : la StorageClass.

StorageClass : décrire les "types" de stockage disponibles

Une StorageClass est un objet API qui permet aux administrateurs de définir des "classes" ou des "profils" de stockage disponibles dans le cluster. Au lieu de représenter un volume spécifique (comme le fait un PV), une StorageClass décrit les propriétés et les caractéristiques du stockage qui *sera* créé lorsqu'il sera demandé.

Pensez à une StorageClass comme à un modèle ou une recette pour créer des PVs. Elle spécifie quel provisionneur (un plugin logiciel spécifique au fournisseur de stockage) doit être utilisé pour créer dynamiquement le volume sous-jacent, ainsi que les paramètres à passer à ce provisionneur (par exemple, le type de disque – SSD ou HDD, la zone de disponibilité, les options de chiffrement, etc.).

En définissant différentes StorageClasses (par exemple, `fast-ssd`, `cheap-hdd`, `replicated-storage`), les administrateurs peuvent offrir aux utilisateurs un catalogue de différents types de stockage, chacun avec ses propres caractéristiques de performance, de coût et de disponibilité, sans avoir à pré-créer les volumes eux-mêmes.

Le mécanisme de provisionnement dynamique

Le provisionnement dynamique est déclenché lorsqu'une PersistentVolumeClaim (PVC) est créée et qu'elle spécifie une `storageClassName` particulière (ou si une StorageClass par défaut est définie dans le cluster et que la PVC n'en spécifie aucune).

Le processus se déroule comme suit :

1. Un utilisateur crée une PVC demandant une certaine quantité de stockage et spécifiant une `storageClassName` (ex: `fast-ssd`).
2. Le Control Plane de Kubernetes (via le contrôleur PersistentVolume) voit cette PVC et la StorageClass associée (`fast-ssd`).
3. Il détermine quel provisionneur est spécifié dans la StorageClass (`provisioner: kubernetes.io/aws-ebs`, `provisioner: kubernetes.io/gce-pd`, `provisioner: csi-driver-name`...).
4. Il invoque ce provisionneur (qui est souvent un Pod s'exécutant dans le cluster ou un composant du cloud-controller-manager) en lui passant les paramètres définis dans la StorageClass (`parameters`) ainsi que les détails de la PVC (taille, modes d'accès...).
5. Le provisionneur effectue alors l'appel API nécessaire à l'infrastructure de stockage sous-jacente (ex: créer un volume EBS sur AWS, un Persistent Disk sur GCP...) pour créer un nouveau volume physique correspondant aux spécifications.
6. Une fois le volume physique créé avec succès, le provisionneur crée un objet PersistentVolume (PV) correspondant dans Kubernetes pour représenter ce nouveau volume. Ce PV est automatiquement configuré avec la bonne capacité, les bons modes d'accès, la bonne `storageClassName`, et une `persistentVolumeReclaimPolicy` (souvent `Delete` par défaut pour les volumes dynamiques).
7. Kubernetes lie alors automatiquement ce PV nouvellement créé à la PVC qui a déclenché le processus. La PVC passe à l'état `Bound`.
8. Le Pod de l'utilisateur peut maintenant monter et utiliser la PVC comme d'habitude.

Ce processus est entièrement automatisé. L'administrateur n'a qu'à définir les StorageClasses une fois, et les utilisateurs obtiennent le stockage dont ils ont besoin à la demande en créant simplement des PVCs.

Structure d'une StorageClass

Voici un exemple de manifeste YAML pour une StorageClass utilisant le provisionneur EBS d'AWS :

apiVersion: storage.k8s.io/v1 # API group pour StorageClass
kind: StorageClass
metadata:
  name: gp2-standard # Nom de la classe de stockage
provisioner: kubernetes.io/aws-ebs # Quel plugin utiliser pour créer le volume
parameters: # Paramètres spécifiques au provisionneur
  type: gp2 # Type de volume EBS (General Purpose SSD)
  fsType: ext4 # Système de fichiers à créer sur le volume
  encrypted: "true"
reclaimPolicy: Retain # Politique pour les PVs créés (Retain ou Delete)
volumeBindingMode: Immediate # Quand lier le PV à la PVC (Immediate ou WaitForFirstConsumer)
allowVolumeExpansion: true # Autoriser l'expansion de la taille des volumes après création

Champs clés :

• `provisioner` (obligatoire) : Identifie le plugin de volume responsable du provisionnement dynamique. Chaque système de stockage (AWS EBS, GCE PD, Azure Disk, NFS, Ceph, pilotes CSI...) a son propre identifiant de provisionneur.
• `parameters` (optionnel) : Un dictionnaire de paramètres opaques passés au provisionneur lors de la création du volume. Le contenu dépend entièrement du provisionneur (ex: type de disque, zone, pool de stockage, options de montage...).
• `reclaimPolicy` (optionnel) : Définit la `persistentVolumeReclaimPolicy` qui sera appliquée aux PVs créés dynamiquement par cette classe. Si omis, la valeur par défaut est souvent `Delete`.
• `volumeBindingMode` (optionnel) : Contrôle quand le provisionnement et la liaison du volume doivent se produire.
  • `Immediate` (par défaut) : Le provisionnement et la liaison se font dès que la PVC est créée.
  • `WaitForFirstConsumer` : Le provisionnement et la liaison sont retardés jusqu'à ce qu'un Pod qui utilise la PVC soit créé et planifié sur un noeud. C'est très utile pour les stockages locaux ou sensibles à la topologie (zone d'un cloud) car cela garantit que le volume est créé au bon endroit (sur le même noeud ou dans la même zone que le Pod).
• `allowVolumeExpansion` (optionnel) : Si mis à `true`, permet aux utilisateurs d'augmenter la taille d'une PVC après sa création (si le provisionneur et le volume sous-jacent le supportent).
• `mountOptions` (optionnel) : Options de montage à appliquer au volume lorsqu'il est monté sur un noeud.

Utiliser une StorageClass dans une PVC

Pour demander un volume provisionné dynamiquement, une PVC doit spécifier le nom de la StorageClass souhaitée dans le champ `spec.storageClassName` :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ma-pvc-rapide
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
  storageClassName: gp2-standard # Demande à utiliser la StorageClass nommée 'gp2-standard'

StorageClass par défaut : Un administrateur peut marquer une StorageClass comme étant celle par défaut pour le cluster en ajoutant une annotation spécifique à sa définition : `storageclass.kubernetes.io/is-default-class: "true"`. Si une PVC est créée sans spécifier de `storageClassName`, Kubernetes utilisera automatiquement la StorageClass par défaut (s'il y en a une) pour tenter un provisionnement dynamique. S'il n'y a pas de StorageClass par défaut et que la PVC n'en spécifie pas, seuls les PVs statiques sans `storageClassName` seront considérés pour la liaison.

Gérer les StorageClasses avec `kubectl`

• Lister les StorageClasses : `kubectl get storageclasses` (ou `kubectl get sc`)
• Inspecter une StorageClass : `kubectl describe storageclass [NOM_STORAGECLASS]`
• Supprimer une StorageClass : `kubectl delete storageclass [NOM_STORAGECLASS]` (Attention : cela n'affecte pas les PVs déjà créés par cette classe, mais empêche la création de nouveaux volumes via celle-ci).

Conclusion : l'automatisation et le self-service du stockage

Les StorageClasses et le provisionnement dynamique qu'elles permettent révolutionnent la gestion du stockage dans Kubernetes. Elles transforment une tâche potentiellement lourde et manuelle (création de PVs) en un processus automatisé et en libre-service pour les utilisateurs.

En définissant des classes de stockage adaptées aux besoins et à l'infrastructure sous-jacente, les administrateurs offrent une flexibilité et une agilité considérables aux équipes de développement, qui peuvent obtenir le stockage persistant dont elles ont besoin rapidement et sans intervention manuelle, simplement en créant une PVC.

Le provisionnement dynamique via les StorageClasses est devenu la méthode standard pour gérer le stockage dans la plupart des environnements Kubernetes modernes, en particulier dans le cloud.