Évitez ces erreurs de configuration des StorageClasses Kubernetes : guide pratique

Introduction

Les StorageClasses Kubernetes sont la pierre angulaire du provisionnement dynamique de stockage persistant. Une StorageClass mal configurée peut entraîner des échecs de provisionnement de volumes, des pertes de données ou des coûts imprévus. Dans ce guide, nous explorerons les erreurs de configuration courantes, telles que les noms de provisionneurs incorrects, les paramètres manquants et les politiques de récupération inappropriées. Vous apprendrez à valider votre configuration en toute sécurité, à mettre en œuvre des stratégies de retour en arrière et à résoudre les problèmes à l'aide d'exemples pratiques. À la fin, vous disposerez d'une liste de contrôle claire pour garantir la robustesse et la fiabilité de vos StorageClasses.

Inventaire de la version et de l'environnement

Avant de modifier une StorageClass, documentez votre environnement. Déterminez votre version de Kubernetes, le backend de stockage (par exemple, AWS EBS, GCE PD, NFS, Ceph) et les versions des pilotes CSI le cas échéant. Cet inventaire vous aide à comprendre la compatibilité et les fonctionnalités disponibles.

Par exemple, vérifiez la version de votre cluster avec :

kubectl version --short

Sortie attendue (exemple pour Kubernetes 1.25) :

Client Version: v1.25.3
Server Version: v1.25.3

Listez les StorageClasses existantes :

kubectl get storageclass

Exemple de sortie :

NAME                 PROVISIONER            RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
standard (default)   kubernetes.io/aws-ebs  Delete          Immediate              false                  30d
fast                 ebs.csi.aws.com        Delete          WaitForFirstConsumer  true                   15d

Identifiez la StorageClass par défaut (marquée avec (default) dans la sortie). Notez les noms des provisionneurs et les paramètres. Si vous utilisez un pilote CSI, assurez-vous qu'il est installé et en cours d'exécution :

kubectl get pods -n kube-system | grep csi

Vérifiez également si des PersistentVolumeClaims (PVC) utilisent ces StorageClasses :

kubectl get pvc --all-namespaces

Cet inventaire guidera vos décisions de configuration et vous aidera à anticiper l'impact des modifications. Par exemple, si vous constatez que de nombreux PVC utilisent la StorageClass standard avec un provisionneur intégré, vous pouvez planifier une migration vers un pilote CSI.

Chemin de configuration sûr

Lors de la modification des StorageClasses, évitez de changer celles qui sont déjà utilisées, car de nombreux champs sont immuables. Créez plutôt une nouvelle StorageClass avec un nom différent et testez-la soigneusement avant de migrer les charges de travail. Cette approche limitée minimise les risques.

Par exemple, supposons que vous souhaitiez mettre à jour le provisionneur d'un plugin intégré vers un pilote CSI. Créez une nouvelle StorageClass :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-csi
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  encrypted: "true"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Appliquez-la :

kubectl apply -f fast-csi.yaml

Ensuite, créez un PVC de test référençant la nouvelle StorageClass :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-csi
  resources:
    requests:
      storage: 1Gi

Si le PVC se lie avec succès et que le pod qui l'utilise peut démarrer, la nouvelle StorageClass fonctionne. Ensuite seulement, envisagez de migrer les charges de travail de production. N'oubliez jamais de ne pas supprimer ou modifier une StorageClass activement utilisée par des PVC, car cela peut entraîner des échecs de provisionnement ou des problèmes d'accès aux données. Par exemple, la suppression d'une StorageClass référencée par des PVC ne supprimera pas les volumes existants, mais les nouveaux PVC qui la spécifient échoueront à se provisionner.

Vérification et diagnostics

Après avoir appliqué une StorageClass, vérifiez qu'elle est correctement configurée à l'aide de kubectl describe. Vérifiez les erreurs dans les événements et assurez-vous que les paramètres sont conformes aux attentes.

Décrivez la StorageClass :

kubectl describe storageclass fast-csi

La sortie attendue inclut :

Name:            fast-csi
IsDefaultClass:  No
Annotations:     <none>
Provisioner:     ebs.csi.aws.com
Parameters:      encrypted=true,type=gp3
AllowVolumeExpansion: true
MountOptions:    <none>
ReclaimPolicy:   Delete
VolumeBindingMode: WaitForFirstConsumer
Events:          <none>

Testez le provisionnement dynamique en créant un PVC et en surveillant sa liaison :

kubectl apply -f test-pvc.yaml
kubectl get pvc test-pvc

Le statut attendu doit être Bound après quelques secondes. Si vous utilisez WaitForFirstConsumer, le PVC peut rester Pending jusqu'à ce qu'un pod le consomme. S'il reste Pending, vérifiez les événements :

kubectl describe pvc test-pvc

Recherchez des messages tels que provisioning failed ou no volume plugin matched. Ceux-ci indiquent des problèmes avec le provisionneur ou les paramètres. Par exemple, l'événement peut indiquer :

Warning  ProvisioningFailed  2s (x2 over 5s)  ebs.csi.aws.com_aws-ebs-csi-driver-node-xxxx  failed to provision volume with StorageClass "fast-csi": rpc error: code = InvalidArgument desc = Volume type "gp4" is not supported

Pour confirmer que le volume sous-jacent a été créé, listez les PersistentVolumes :

kubectl get pv | grep test-pvc

Vous devriez voir un PV avec le même nom que le PVC et le statut Bound. Par exemple :

pvc-1234abcd-56ef-7890-ghij-klmnopqrstuv   1Gi   RWO   Delete   Bound   default/test-pvc   fast-csi   2m

Si votre StorageClass prend en charge l'expansion de volume, testez-la en augmentant la taille du PVC (si autorisé) et en vérifiant que le PVC affiche la nouvelle capacité après un redimensionnement. Par exemple :

kubectl patch pvc test-pvc -p '{"spec":{"resources":{"requests":{"storage":"2Gi"}}}}'

Surveillez ensuite le statut du PVC ; il devrait éventuellement afficher 2Gi en capacité.

Modes de défaillance et récupération

Les modes de défaillance courants incluent des provisionneurs mal configurés, des paramètres incorrects (par exemple, un mauvais type de volume), un pilote CSI manquant ou des autorisations insuffisantes. Lorsqu'un PVC ne parvient pas à se provisionner, la première étape consiste à vérifier les événements. Ensuite, examinez les journaux du contrôleur CSI le cas échéant.

Par exemple, si vous voyez :

failed to provision volume with StorageClass "fast-csi": rpc error: code = InvalidArgument desc = Volume type "gp4" is not supported

alors vous avez une faute de frappe dans le paramètre. Pour récupérer, créez une StorageClass corrigée et mettez à jour votre PVC pour l'utiliser. Notez que les paramètres d'une StorageClass sont immuables, vous ne pouvez donc pas modifier une existante ; vous devez en créer une nouvelle.

Si vous supprimez accidentellement une StorageClass en cours d'utilisation, les PVC existants continueront de fonctionner, mais les nouveaux PVC qui la référencent échoueront. Pour récupérer, recréez la StorageClass avec le même nom et les mêmes paramètres. Cependant, si les PVC ont le nom de la StorageClass dans leur spécification et que la StorageClass est supprimée, le PVC peut rester bloqué. Vous pouvez patcher le PVC pour supprimer le champ storageClassName ou le pointer vers une nouvelle StorageClass valide si le volume existe déjà.

Par exemple, pour supprimer le storageClassName d'un PVC :

kubectl patch pvc test-pvc -p '{"spec":{"storageClassName":null}}'

Stratégie de retour en arrière : Conservez toujours la définition de la StorageClass précédente dans le contrôle de version. Si une nouvelle StorageClass cause des problèmes, vous pouvez la supprimer et recréer l'ancienne. Pour les PVC déjà liés à des PV provisionnés par la nouvelle StorageClass, vous devrez peut-être migrer manuellement les données ou effectuer des sauvegardes.

Exemple de retour en arrière : Supprimez le PVC problématique (après avoir sauvegardé les données) et recréez-le avec l'ancienne StorageClass.

kubectl delete pvc test-pvc
kubectl apply -f old-test-pvc.yaml

Testez toujours les procédures de retour en arrière dans un espace de noms non productif d'abord.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle avant et après avoir apporté des modifications aux StorageClasses pour garantir la cohérence et la sécurité.

Examinez régulièrement les StorageClasses pour supprimer celles qui sont inutilisées et assurez-vous que les politiques de récupération répondent à vos exigences de conservation des données. Par exemple, si vous avez une StorageClass avec reclaimPolicy: Retain pour une base de données de production, assurez-vous que les volumes orphelins sont nettoyés périodiquement pour éviter les dépassements de coûts.

Conclusion

Les erreurs de configuration des StorageClasses Kubernetes peuvent perturber vos applications et vos données. En suivant les pratiques décrites dans ce guide, vous pouvez éviter les pièges courants tels que les modifications de champs immuables, les provisionneurs incorrects et le manque de validation. Créez toujours de nouvelles StorageClasses pour les modifications, testez soigneusement et ayez un plan de retour en arrière. Utilisez les commandes et la liste de contrôle fournies pour vérifier et maintenir votre configuration de stockage. Avec une gestion prudente, vous pouvez garantir un stockage persistant fiable et efficace dans vos clusters Kubernetes.