Liste de contrôle des opérations de production pour les classes de stockage Kubernetes avec exemples pratiques

Introduction

Exploiter des classes de stockage Kubernetes en production, c'est garantir que vos charges de travail avec état obtiennent le stockage dont elles ont besoin de manière fiable, sans intervention manuelle, et avec des chemins de récupération clairs en cas de problème. Une classe de stockage abstrait la technologie de stockage sous-jacente (comme AWS EBS, GCE Persistent Disk ou un pilote CSI sur site) et permet aux développeurs de demander du stockage sans en connaître les détails. Mais en production, cette abstraction signifie que les pannes peuvent être subtiles : une PVC peut rester bloquée à l'état Pending, un volume peut ne pas se monter, ou une application peut écrire sur le mauvais niveau de stockage.

Cette liste de contrôle est conçue pour les développeurs, les ingénieurs DevOps et les équipes techniques de startups qui gèrent des clusters Kubernetes. Elle couvre tout le cycle de vie : avant le déploiement, lors du provisionnement, lors de la vérification et lorsqu'il faut récupérer. Chaque section fournit des commandes concrètes, des sorties attendues et des exemples pratiques que vous pouvez exécuter sur votre propre cluster. Nous mettons l'accent sur la sécurité opérationnelle : observer d'abord, apporter des modifications minimales, protéger les secrets et toujours savoir comment revenir en arrière.

Inventaire des versions et de l’environnement

Avant de toucher à quoi que ce soit, vous devez savoir exactement avec quoi vous travaillez. Commencez par identifier la version de Kubernetes, les pilotes CSI installés et les classes de stockage définies dans le cluster. Ces informations sont en lecture seule et vous aideront à éviter des modifications incompatibles avec votre environnement.

Exécutez ces commandes pour capturer l'état actuel :

kubectl version --short
kubectl get storageclass
kubectl get csidrivers

La sortie attendue pour la liste des classes de stockage peut ressembler à ceci :

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

Dans cet exemple, standard est la classe par défaut utilisant le provisionneur AWS EBS intégré (in-tree), tandis que fast utilise le pilote CSI plus récent et prend en charge l'expansion de volume. Savoir laquelle est par défaut est important car une PVC sans storageClassName utilisera la classe par défaut.

Vérifiez l'état des pilotes CSI :

kubectl get csidriver

Exemple de sortie :

NAME               ATTACHREQUIRED   PODINFOONMOUNT   STORAGECAPACITY   TOKENREQUESTS   REQUIRESREPUBLISH
...
ebs.csi.aws.com    true             false            true              false           false

Si un pilote CSI est manquant ou pas prêt, vos PVC peuvent rester bloquées à l'état Pending. Vérifiez que les pods du contrôleur CSI sont en cours d'exécution :

kubectl get pods -n kube-system | grep ebs

Attendu : des pods comme ebs-csi-controller-... et ebs-csi-node-... doivent être Running et Ready.

Documentez les versions du pilote CSI et de tout opérateur lié au stockage (comme la version du pilote AWS EBS CSI). Par exemple, si vous utilisez le pilote AWS EBS CSI, vérifiez son tag d'image avec :

kubectl get deployment ebs-csi-controller -n kube-system -o jsonpath='{.spec.template.spec.containers[0].image}'

Cela peut afficher public.ecr.aws/ebs-csi-driver/aws-ebs-csi-driver:v1.26.0. Gardez une trace de cela car une mise à jour du pilote peut changer le comportement.

Une erreur courante est de vérifier uniquement la classe de stockage et non le pilote CSI. Une classe de stockage peut exister mais être inutilisable si le pilote n'est pas installé ou a planté. Il en va de même pour les composants au niveau des nœuds : exécutez kubectl get pods -n kube-system -l app=ebs-csi-node pour vous assurer que le plugin de nœud est planifié sur tous les nœuds qui ont besoin de stockage.

Avant toute modification, assurez-vous d'avoir un accès en lecture aux namespaces concernés et de ne pas utiliser un compte de service avec des autorisations trop larges. Pour les vérifications en lecture seule, un rôle avec get, list et watch sur les classes de stockage, les PVC et les pods suffit. N'exécutez jamais de commandes cluster-admin depuis un terminal partagé sans confirmer le contexte : kubectl config current-context.

Pour les tests locaux, créez une petite PVC et un pod qui l'utilise, puis supprimez les deux et confirmez le nettoyage. Cela valide le chemin complet sans impacter les charges de production. Exemple de manifeste de test :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: fast
---
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: app
    image: busybox
    command: ["sh", "-c", "echo 'Le stockage fonctionne' > /data/test.txt && sleep 3600"]
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: test-pvc

Appliquez-le, vérifiez les journaux du pod, puis nettoyez avec kubectl delete -f test-manifest.yaml.

Chemin de configuration sûr

La configuration d'une classe de stockage détermine comment les volumes sont provisionnés, quels paramètres sont transmis au provisionneur et la politique de récupération. Une classe de stockage mal configurée peut entraîner une perte de données (par exemple, reclaimPolicy: Delete sur une classe utilisée pour des données critiques) ou des frais inattendus.

Voici un exemple de classe de stockage bien annotée pour AWS EBS avec le pilote CSI :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "3000"
  throughput: "125"
  encrypted: "true"
  kmsKeyId: "arn:aws:kms:us-east-1:123456789012:key/abcd1234-..."
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Points clés :

• provisioner doit correspondre exactement au nom du pilote CSI. Une faute de frappe ici entraînera l'échec des PVC avec une erreur provisioner not found.
• Les parameters sont transmis au pilote CSI. Pour AWS EBS, type peut être gp2, gp3, io1, io2, etc. Les paramètres iops et throughput ne sont valides que pour certains types ; les spécifier pour gp2 provoquera une erreur.
• reclaimPolicy doit être Retain pour tout volume contenant des données dont vous pourriez avoir besoin après la suppression de la PVC. Avec Delete, le volume cloud sous-jacent est supprimé immédiatement, souvent sans sauvegarde.
• volumeBindingMode: WaitForFirstConsumer est recommandé pour les clusters multi-AZ car cela retarde la création du volume jusqu'à ce qu'un pod soit planifié, garantissant que le volume est créé dans la même AZ que le nœud. Sans cela, vous pourriez obtenir un volume dans une AZ différente et le pod échouera à s'attacher.
• allowVolumeExpansion: true permet d'augmenter la taille d'une PVC. C'est utile mais pas pris en charge par tous les pilotes.

Pour modifier une classe de stockage existante, vous pouvez l'éditer avec kubectl edit storageclass fast-ssd. Cependant, la plupart des paramètres sont immuables après la création. Vous pouvez ajouter de nouveaux paramètres ou changer allowVolumeExpansion, mais changer le provisionneur ou le mode de liaison de volume nécessite de créer une nouvelle classe et de migrer les charges de travail.

Lors de la création d'une nouvelle classe de stockage, suivez une convention de nommage qui reflète les performances et la durabilité des données, comme fast-ssd-encrypted ou standard-hdd. Évitez d'utiliser la classe par défaut pour la production à moins de la définir explicitement sur une configuration sûre. Vous pouvez voir quelle classe est par défaut avec :

kubectl get storageclass

La classe par défaut est marquée avec (default) à côté de son nom dans la sortie. Si vous avez besoin d'une extraction programmatique, utilisez :

kubectl get storageclass -o jsonpath='{.items[?(@.metadata.annotations.storageclass\.kubernetes\.io/is-default-class=="true")].metadata.name}'

Si vous devez changer la classe par défaut, désactivez l'ancienne et activez la nouvelle :

kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
kubectl patch storageclass fast-ssd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Soyez prudent : changer la classe par défaut affecte toutes les futures PVC qui ne spécifient pas de classe. Les PVC existantes ne sont pas affectées.

Testez toujours une nouvelle classe de stockage avec une petite PVC dans un namespace de staging avant de l'utiliser pour des charges de production. Utilisez kubectl get events pour voir les erreurs de provisionnement. Par exemple, un paramètre invalide peut produire un événement comme :

Warning  ProvisioningFailed  2m (x5 over 10m)  ebs.csi.aws.com_ebs-csi-controller-...  failed to provision volume with StorageClass "fast-ssd": rpc error: code = InvalidArgument desc = Invalid parameter: iops

Vérification et diagnostics

Après avoir configuré une classe de stockage et lié une PVC, vous devez vérifier que le volume fonctionne réellement comme prévu. Cela signifie vérifier l'état de la PVC, le PersistentVolume sous-jacent et le chemin de données réel.

Commencez par vérifier la PVC :

kubectl get pvc

Sortie attendue :

NAME      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-pvc  Bound    pvc-1234abcd-5678-efgh-ijkl-1234567890ab   1Gi        RWO            fast-ssd       5m

Une PVC à l'état Pending signifie que le provisionneur n'a pas créé de volume. Raisons courantes : aucune classe de stockage avec ce nom, le pilote CSI n'est pas en cours d'exécution, ou les paramètres sont invalides. Décrivez la PVC pour voir les événements :

kubectl describe pvc test-pvc

Regardez les événements en bas. Si vous voyez waiting for a volume to be created, either by external provisioner "ebs.csi.aws.com" or manually created by system administrator, alors le provisionneur est peut-être en panne ou mal configuré. Vérifiez les journaux du provisionneur :

kubectl logs -n kube-system deployment/ebs-csi-controller -c ebs-plugin

Pour une PVC liée, vérifiez le PersistentVolume :

kubectl get pv pvc-1234abcd-5678-efgh-ijkl-1234567890ab

Notez la RECLAIM POLICY et le STATUS. Le PV doit être Bound à votre PVC. Si la politique de récupération est Delete, supprimer la PVC supprimera également le PV et le stockage sous-jacent.

Pour vérifier qu'un pod peut réellement utiliser le volume, attachez un pod et écrivez un fichier. Voici un exemple de pod qui écrit et relit :

apiVersion: v1
kind: Pod
metadata:
  name: storage-verify
spec:
  containers:
  - name: verifier
    image: alpine
    command: ["/bin/sh", "-c"]
    args:
      - |
        echo "$(date): test de stockage" > /data/testfile.txt
        cat /data/testfile.txt
        sleep 3600
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: test-pvc

Vérifiez les journaux :

kubectl logs storage-verify

Il devrait afficher la date et la chaîne de test. Si le volume est en lecture seule ou le montage est incorrect, vous verrez des erreurs de permission.

Les diagnostics doivent également inclure des vérifications de performance si votre application est sensible aux E/S. Vous pouvez utiliser un outil comme fio dans un pod pour tester la bande passante et les IOPS. Exemple :

apiVersion: v1
kind: Pod
metadata:
  name: fio-test
spec:
  containers:
  - name: fio
    image: ljishen/fio
    command: ["fio"]
    args:
      - --name=test
      - --filename=/data/testfile
      - --size=100M
      - --rw=randwrite
      - --bs=4k
      - --ioengine=libaio
      - --iodepth=32
      - --direct=1
      - --numjobs=1
      - --runtime=60
      - --time_based
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: test-pvc

Exécutez-le et examinez la sortie pour les IOPS et la latence. Comparez avec les performances attendues pour votre type de stockage (par exemple, la base de gp3 est de 3000 IOPS et 125 Mo/s). Si vous voyez des chiffres bien inférieurs, vérifiez la limitation (par exemple, les crédits de burst épuisés sur gp2) ou des problèmes de réseau.

Enfin, vérifiez que l'expansion de volume fonctionne si vous avez activé allowVolumeExpansion. D'abord, augmentez la taille de la PVC :

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

Ensuite, vérifiez que la PVC affiche finalement la nouvelle capacité et que le pod peut voir le système de fichiers agrandi. Notez que certains pilotes nécessitent de redémarrer le pod pour redimensionner le système de fichiers. Pour AWS EBS CSI, le système de fichiers est redimensionné en ligne si le pod est en cours d'exécution.

Modes de défaillance et récupération

Les défaillances de stockage dans Kubernetes peuvent être largement classées en échecs de provisionnement (PVC bloquée en Pending), échecs de liaison (PVC ne se lie pas à un PV approprié), échecs d'attachement/montage (le pod ne peut pas démarrer car le volume ne peut pas être attaché) et problèmes d'intégrité des données (corruption ou suppression accidentelle). Ici, nous couvrons les scénarios les plus courants et les étapes de récupération.

Échec de provisionnement

Symptôme : La PVC reste Pending et les événements montrent des erreurs comme failed to provision volume ou provisioner not found.

Cause : Nom de provisionneur incorrect dans la classe de stockage, pilote CSI non opérationnel ou paramètres invalides.

Récupération :

1. Vérifiez la classe de stockage : kubectl get storageclass <name> -o yaml pour voir le provisionneur.
2. Vérifiez les pods du pilote CSI : kubectl get pods -n kube-system | grep <driver>.
3. Si les pods du pilote sont en crash-loop, vérifiez les journaux : kubectl logs -n kube-system <pod-name> --previous.
4. Corrigez le problème (par exemple, fournissez les autorisations IAM correctes au contrôleur CSI, réparez le déploiement du pilote).
5. Si la classe de stockage elle-même est incorrecte et immuable, créez-en une nouvelle et mettez à jour la PVC pour l'utiliser (vous devrez peut-être supprimer et recréer la PVC, mais soyez prudent avec les données).

Échec de liaison avec WaitForFirstConsumer

Symptôme : La PVC est Pending même si le provisionneur fonctionne, mais le pod qui la référence n'est pas planifié.

Cause : volumeBindingMode: WaitForFirstConsumer signifie que Kubernetes ne provisionnera pas tant qu'un pod utilisant la PVC n'est pas planifié sur un nœud. Si le pod ne peut pas être planifié (ressources insuffisantes, sélecteur de nœud incompatibilité), la PVC reste en attente.

Récupération : Vérifiez les événements du pod : kubectl describe pod <pod-name>. Résolvez le problème de planification. Si vous avez besoin du volume immédiatement indépendamment de la planification du pod, utilisez volumeBindingMode: Immediate à la place (mais soyez conscient des problèmes inter-AZ).

Pod bloqué dans ContainerCreating

Symptôme : Le pod est dans l'état ContainerCreating pendant longtemps ; kubectl describe pod montre Multi-Attach error ou FailedAttachVolume.

Cause : Le volume est déjà attaché à un autre nœud (peut-être qu'un pod précédent ne s'est pas détaché proprement) ou le nœud ne peut pas atteindre le backend de stockage.

Récupération :

1. Vérifiez l'état des nœuds : kubectl get nodes.
2. Vérifiez les objets d'attachement de volume : kubectl get volumeattachment.
3. Si un attachement de volume est bloqué, vous devrez peut-être forcer le détachement en supprimant l'objet VolumeAttachment : kubectl delete volumeattachment <name> (seulement après vous être assuré que le pod qui l'utilise a disparu).
4. Redémarrez le plugin de nœud CSI sur le nœud affecté : kubectl delete pod -n kube-system -l app=ebs-csi-node --field-selector spec.nodeName=<node>.

Perte de données due à la politique de récupération Delete

Symptôme : Une PVC a été supprimée et les données sous-jacentes ont disparu.

Cause : La classe de stockage a reclaimPolicy: Delete, qui supprime automatiquement le volume cloud lorsque la PVC est supprimée.

Récupération : Si vous avez une sauvegarde ou un instantané, restaurez à partir de celui-ci. Sinon, les données sont probablement irrécupérables. Pour éviter cela, définissez reclaimPolicy: Retain pour les données importantes et mettez en œuvre une stratégie de sauvegarde. Notez que changer la politique de récupération d'une classe de stockage existante n'affectera pas les PV existants ; vous devez patcher le PV : kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'.

Corruption de volume ou lecture seule

Symptôme : L'application échoue à écrire, les journaux du pod montrent read-only file system ou des erreurs d'E/S.

Cause : Corruption du système de fichiers, disque plein ou le volume a été monté en lecture seule en raison d'erreurs.

Récupération :

1. Vérifiez l'utilisation du système de fichiers : kubectl exec <pod> -- df -h /data.
2. Si plein, augmentez la taille de la PVC ou nettoyez les fichiers.
3. Si corrompu, vous devrez peut-être exécuter fsck sur le volume. Cela nécessite généralement de détacher le volume du nœud et d'exécuter un pod de réparation avec le volume attaché. Pour les volumes cloud, vous pouvez souvent prendre un instantané d'abord, puis réparer ou restaurer.

Pour chaque défaillance, vérifiez toujours les événements Kubernetes en premier : kubectl get events --all-namespaces --sort-by='.lastTimestamp'. Les événements contiennent souvent le message d'erreur exact du pilote CSI.

Liste de contrôle des opérations

Cette section est une liste de contrôle concise que vous pouvez utiliser lors des opérations quotidiennes. Elle est organisée par fréquence et inclut le responsable de chaque élément. Dans une équipe de startup, la responsabilité peut être partagée, mais chaque élément devrait avoir une seule personne responsable pour éviter l'ambiguïté. Les fréquences de révision supposent une petite équipe avec quelques applications avec état ; ajustez si nécessaire.

Contrôles quotidiens (Responsable : Ingénieur DevOps de garde – par exemple, Alex Johnson, DevOps Lead)

• [ ] Vérifier toute PVC dans un état Pending ou Lost : kubectl get pvc --all-namespaces | grep -v Bound
• [ ] Vérifier les pods bloqués dans ContainerCreating ou CrashLoopBackOff liés au stockage : kubectl get pods --all-namespaces | grep -E 'ContainerCreating|CrashLoopBackOff'
• [ ] Examiner les événements des dernières 24 heures pour les avertissements liés au stockage : kubectl get events --all-namespaces --field-selector type=Warning | grep -i -E 'storage|volume|disk'

Contrôles hebdomadaires (Responsable : Ingénieur plateforme – par exemple, Priya Shah, Ingénieure plateforme senior)

• [ ] Examiner l'utilisation des classes de stockage et s'assurer que la classe par défaut est correcte : kubectl get storageclass
• [ ] Vérifier les journaux du pilote CSI pour les erreurs : kubectl logs -n kube-system deployment/ebs-csi-controller -c ebs-plugin --since=48h | grep -i error
• [ ] Vérifier que tous les nœuds ont le plugin de nœud CSI en cours d'exécution : kubectl get pods -n kube-system -l app=ebs-csi-node -o wide (s'assurer qu'il y en a un par nœud)
• [ ] Tester un provisionnement et une suppression d'une PVC d'exemple dans un namespace de test pour s'assurer que le provisionneur fonctionne de bout en bout.

Contrôles mensuels (Responsable : Directeur de l'ingénierie – par exemple, Carlos Rodriguez, Directeur de l'ingénierie)

• [ ] Examiner les coûts de stockage dans la console du fournisseur cloud. Rechercher les volumes orphelins (volumes non attachés à un nœud mais toujours facturés).
• [ ] Vérifier les volumes qui ne sont pas gérés par Kubernetes (par exemple, des volumes EBS créés manuellement) et décider s'ils doivent être importés.
• [ ] Examiner les politiques de sauvegarde pour les PersistentVolumeClaims. S'assurer que toutes les PVC critiques ont des instantanés ou des sauvegardes.
• [ ] Tester la restauration à partir d'un instantané ou d'une sauvegarde dans un environnement de staging.

Contrôles trimestriels (Responsable : Tech Lead – par exemple, Emma Wilson, Tech Lead)

• [ ] Examiner la liste des classes de stockage et supprimer celles qui ne sont pas utilisées. Ne garder que les classes activement utilisées.
• [ ] Mettre à jour les versions des pilotes CSI après les avoir testés dans un cluster de staging.
• [ ] Examiner les limites de ressources pour les pods du contrôleur CSI afin d'éviter les OOM kills sous charge.
• [ ] Revoir les politiques de récupération de toutes les classes de stockage et PV. S'assurer que Retain est utilisé pour tout ce qui est important.

Chaque élément de la liste de contrôle doit avoir un runbook documenté. Par exemple, le runbook pour « PVC bloquée en Pending » devrait inclure des étapes comme :

1. Vérifier si la classe de stockage existe : kubectl get sc <name>
2. Décrire la PVC : kubectl describe pvc <name>
3. Vérifier les journaux du provisionneur : kubectl logs -n kube-system deployment/<provisioner>
4. Vérifier si les pods du pilote CSI sont en cours d'exécution
5. Vérifier si le fournisseur cloud a un quota suffisant pour le type de stockage
6. Escalader vers le support du fournisseur de stockage si le problème persiste

Pièges courants et comment les éviter

Les pièges dans les opérations de stockage proviennent souvent d'une mauvaise compréhension du cycle de vie du provisionnement dynamique ou de l'ignorance de paramètres spécifiques au cluster. Voici les erreurs les plus fréquentes et leurs remèdes.

Utilisation d'une classe de stockage inexistante dans une PVC

Pourquoi cela arrive : Les développeurs copient des manifestes PVC à partir d'exemples sans vérifier si la classe de stockage existe dans le cluster.

Comment éviter : Avant d'appliquer une PVC, vérifiez le nom de la classe de stockage : kubectl get storageclass. Si vous voulez utiliser une classe par défaut, omettez storageClassName entièrement ou définissez-le sur "" (chaîne vide) si vous voulez désactiver le provisionnement dynamique.

Récupération : Créez la classe de stockage ou corrigez la PVC pour utiliser une classe existante. Dans certains cas, vous pouvez patcher le champ storageClassName de la PVC si elle n'est pas encore liée, mais une fois liée, vous ne pouvez pas le changer.

Ne pas définir le mode de liaison de volume sur WaitForFirstConsumer dans les clusters multi-AZ

Pourquoi cela arrive : Le volumeBindingMode par défaut est Immediate, ce qui crée le volume dès que la PVC est créée, souvent dans une AZ aléatoire. Si le pod est planifié dans une AZ différente, le volume ne peut pas s'attacher.

Comment éviter : Utilisez toujours WaitForFirstConsumer pour les classes de stockage utilisées dans les clusters multi-AZ, en particulier pour le stockage en blocs comme EBS. Vérifiez l'AZ de vos nœuds avec kubectl get nodes -L topology.kubernetes.io/zone.

Récupération : Pour les PVC existantes, si le volume est dans la mauvaise AZ, vous devez supprimer la PVC (et éventuellement le PV) et la recréer avec la classe correcte. Pour éviter la perte de données, prenez d'abord un instantané du volume, créez un nouveau volume à partir de l'instantané dans la bonne AZ, puis liez-le manuellement.

Ignorer la politique de récupération

Pourquoi cela arrive : La politique de récupération par défaut dans de nombreuses classes de stockage de fournisseurs cloud est Delete, et les équipes ne réalisent pas que supprimer une PVC supprimera également les données.

Comment éviter : Pour toute donnée de production, utilisez une classe de stockage avec reclaimPolicy: Retain. Si vous devez utiliser Delete, assurez-vous d'avoir des sauvegardes. De plus, mettez en place des alertes pour les événements de suppression de PVC.

Récupération : Si vous avez accidentellement supprimé une PVC avec une politique Delete, vérifiez si le fournisseur cloud a une fonction de corbeille ou de poubelle (certains fournisseurs conservent les volumes supprimés pendant une courte période). Sinon, restaurez à partir de la sauvegarde.

Agrandir un volume sans vérifier le support du pilote

Pourquoi cela arrive : Un utilisateur définit allowVolumeExpansion: true mais le pilote CSI ne prend pas en charge l'expansion, ou le pod ne prend pas en charge le redimensionnement en ligne.

Comment éviter : Vérifiez la capacité du pilote en consultant sa documentation ou en exécutant kubectl get csidriver -o yaml et en cherchant supportsVolumeExpansion (bien que pas toujours présent). Testez l'expansion dans un environnement de staging d'abord.

Récupération : Si l'expansion échoue, vérifiez les événements et les journaux du pilote. Pour certains pilotes, vous devrez peut-être redémarrer le pod pour déclencher le redimensionnement du système de fichiers. Si le volume est corrompu, restaurez à partir d'un instantané.

Ne pas surveiller la santé du pilote CSI

Pourquoi cela arrive : Les équipes supposent que le pilote CSI est toujours en cours d'exécution, mais il peut planter, être expulsé ou ne pas démarrer après un redémarrage du nœud.

Comment éviter : Mettez en place des alertes pour les redémarrages du pod du contrôleur CSI et les échecs du pod du plugin de nœud. Utilisez kubectl get pods -n kube-system -l app=<driver> dans vos tableaux de bord de surveillance.

Récupération : Si le pilote est en panne, les PVC échoueront à provisionner et les pods peuvent ne pas démarrer. Redémarrez le déploiement ou le daemonset, et vérifiez les journaux pour la cause première.

Conclusion

Les classes de stockage Kubernetes sont une abstraction puissante, mais elles nécessitent une discipline opérationnelle minutieuse. En suivant cette liste de contrôle, vous pouvez éviter la plupart des problèmes courants, diagnostiquer rapidement les problèmes et récupérer des échecs avec une perte de données minimale. Rappelez-vous les principes fondamentaux : observer avant de changer, utiliser des commandes en lecture seule pour le diagnostic, apporter un changement ciblé à la fois et toujours avoir un plan de retour en arrière.

Comme prochaine étape, choisissez une vérification à faible risque de cet article et exécutez-la dans votre cluster. Par exemple, vérifiez si votre classe de stockage par défaut a reclaimPolicy: Retain pour les charges de travail importantes. Sinon, créez une nouvelle classe avec des paramètres plus sûrs et migrez progressivement vos applications avec état.

Un flux de travail d'opérations de stockage fiable garantit que les défaillances sont visibles tôt, que les données sensibles sont protégées et que les étapes de récupération sont documentées avant d'en avoir besoin. Cette liste de contrôle vous donne la base ; adaptez-la au backend de stockage spécifique de votre équipe et à sa maturité opérationnelle.