## 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.

Question rapide 1 sur 2 Que devez-vous faire avant de modifier un StorageClass selon l'article ? - Supprimer le StorageClass par défaut - Documenter votre environnement, notamment la version de Kubernetes, le backend de stockage et les versions des pilotes CSI - Modifier immédiatement le StorageClass existant - Créer un nouveau StorageClass sans le tester

L'article recommande de documenter votre environnement avant de modifier un StorageClass, notamment la version de Kubernetes, le backend de stockage et les versions des pilotes 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: Provisioner: ebs.csi.aws.com Parameters: encrypted=true,type=gp3 AllowVolumeExpansion: true MountOptions: ReclaimPolicy: Delete VolumeBindingMode: WaitForFirstConsumer Events: 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é.

Étape	Description	Commande/Vérification
1	Documenter l'environnement actuel	`kubectl version --short`, `kubectl get storageclass`
2	Identifier les StorageClasses en cours d'utilisation	`kubectl get pvc --all-namespaces -o jsonpath='{.items[*].spec.storageClassName}'`
3	Créer une nouvelle StorageClass pour les modifications	`kubectl apply -f new-sc.yaml`
4	Tester avec un PVC temporaire	`kubectl apply -f test-pvc.yaml` et vérifier la liaison
5	Vérifier les paramètres et les événements	`kubectl describe storageclass <name>`, `kubectl describe pvc <name>`
6	Tester l'expansion de volume si activée	Augmenter la taille du PVC et vérifier le statut
7	Tester le montage du pod et l'écriture/lecture	Déployer un pod utilisant le PVC et écrire un fichier de test
8	Planifier le retour en arrière	Garder l'ancien YAML de StorageClass prêt
9	Surveiller après le déploiement	Observer les événements des PVC et les métriques de stockage
10	Mettre à jour la documentation	Enregistrer les modifications et les leçons apprises

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.