Automatisation CI/CD des Persistent Volume Claims Kubernetes : guide pratique de mise en œuvre

Introduction

La gestion des applications avec état (stateful) sur Kubernetes exige une manipulation rigoureuse des Persistent Volume Claims (PVC). Automatiser le cycle de vie des PVC dans les pipelines CI/CD peut réduire les erreurs manuelles, accélérer les déploiements et garantir des environnements cohérents. Toutefois, l'automatisation comporte des risques : supprimer le mauvais PVC peut entraîner une perte de données, et une classe de stockage mal configurée peut rendre les pods non planifiables. Ce guide propose une approche pratique, étape par étape, pour intégrer la gestion des PVC dans vos pipelines CI/CD, avec des commandes concrètes, des extraits YAML et des stratégies de récupération.

Nous aborderons l'inventaire des versions et de l'environnement, les chemins de configuration sécurisés, la vérification et le diagnostic, les modes de défaillance et une liste de contrôle opérationnelle. Chaque section comprend des exemples concrets et des pièges à éviter. L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés plutôt que des secrets, vérifier les résultats et documenter les procédures de récupération.

Inventaire des versions et de l'environnement

Avant d'automatiser les opérations sur les PVC, vous devez connaître votre environnement Kubernetes. Identifiez la version du cluster, les classes de stockage et les PVC existants. Utilisez les commandes suivantes pour recueillir les informations :

# Version du serveur Kubernetes
kubectl version --short

# Lister les classes de stockage
kubectl get storageclass

# Lister tous les PVC dans tous les namespaces
kubectl get pvc --all-namespaces

# Vérifier la classe de stockage par défaut
kubectl get storageclass -o jsonpath='{.items[?(@.metadata.annotations.storageclass\.kubernetes\.io/is-default-class=="true")].metadata.name}'

La sortie attendue pour kubectl get storageclass peut ressembler à ceci :

NAME                 PROVISIONER            RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
standard (default)   kubernetes.io/gce-pd   Delete          Immediate           false                  30d
fast                 kubernetes.io/gce-pd   Delete          Immediate           true                   10d

Enregistrez l'état actuel avant d'apporter des modifications. Par exemple, sauvegardez un instantané des PVC :

kubectl get pvc --all-namespaces -o yaml > pvc-backup-$(date +%Y%m%d).yaml

Prérequis : Assurez-vous que kubectl est installé et configuré pour le cluster cible. Vérifiez que vous disposez des autorisations nécessaires pour créer, mettre à jour et supprimer des PVC. Vérifiez si vous pouvez accéder au cluster :

kubectl cluster-info

Piège : Ne pas vérifier la classe de stockage par défaut. Si aucune valeur par défaut n'est définie, les PVC sans classe de stockage resteront en attente (Pending). Vérifiez avec :

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

Si la sortie est vide, définissez une classe par défaut :

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

Responsable : L'ingénieur plateforme ou le responsable DevOps doit être chargé de maintenir l'inventaire de l'environnement. Révisez cet inventaire chaque mois ou après toute mise à niveau du cluster.

Chemin de configuration sécurisé

Un chemin de configuration sécurisé pour l'automatisation des PVC consiste à utiliser des manifestes YAML versionnés et à les appliquer via CI/CD. Commencez par un manifeste PVC minimal :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
  namespace: production
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard

Appliquez-le en utilisant le mode dry-run de kubectl pour valider :

kubectl apply -f pvc.yaml --dry-run=client

S'il n'y a pas d'erreur, appliquez pour de vrai :

kubectl apply -f pvc.yaml

Vérifiez l'état du PVC :

kubectl get pvc app-data -n production

Sortie attendue lorsque le PVC est lié :

NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
app-data   Bound    pvc-12345678-abcd-1234-abcd-1234567890ab   5Gi        RWO            standard       10s

Piège : Utiliser une classe de stockage inexistante. Si vous spécifiez storageClassName: fast mais qu'elle n'existe pas, le PVC reste en attente. Listez toujours les classes de stockage au préalable. Récupérez en corrigeant le manifeste ou en créant la classe de stockage.

Piège : Oublier de définir les demandes de ressources. Sans taille spécifiée, le PVC peut se lier à une taille inattendue. Spécifiez toujours les demandes de stockage.

Dans CI/CD, définissez une étape de pipeline pour appliquer les manifestes PVC uniquement après validation. Exemple d'extrait GitLab CI :

deploy_pvc:
  stage: deploy
  script:
    - kubectl apply -f pvc.yaml --dry-run=client
    - kubectl apply -f pvc.yaml
    - kubectl wait --for=condition=Bound pvc/app-data -n production --timeout=60s
  only:
    - main

La commande kubectl wait garantit que le PVC est lié avant de poursuivre.

Responsable : Le responsable de l'équipe applicative est propriétaire des modifications du manifeste PVC. Les modifications doivent être examinées via une pull request et fusionnées uniquement après le passage réussi de l'intégration continue.

Vérification et diagnostic

Après avoir appliqué un PVC, vérifiez qu'il est lié et attaché au pod prévu. Utilisez ces commandes :

# Obtenir les détails du PVC
kubectl describe pvc app-data -n production

# Vérifier les événements pour le PVC
kubectl get events -n production --field-selector involvedObject.name=app-data --sort-by=.metadata.creationTimestamp

# Vérifier le pod utilisant le PVC
kubectl get pods -n production -o json | jq '.items[] | select(.spec.volumes[].persistentVolumeClaim.claimName=="app-data") | .metadata.name'

La sortie attendue de kubectl describe pvc doit montrer Status: Bound et Volume: pvc-....

Si le PVC est en attente, diagnostiquez :

kubectl describe pvc app-data -n production

Recherchez des événements comme Failed to provision volume with StorageClass "standard" ou No PersistentVolume available for this claim.

Piège : Incompatibilité de mode d'accès. Si le PVC demande ReadWriteMany mais que la classe de stockage ne prend en charge que ReadWriteOnce, l'approvisionnement échoue. Corrigez en modifiant les modes d'accès ou en utilisant une autre classe de stockage.

Piège : Quota insuffisant. Si le namespace a des quotas de ressources, le PVC peut être rejeté. Vérifiez les quotas :

kubectl get resourcequota -n production

Ajustez le quota ou la taille du PVC.

Vérification automatisée dans le pipeline :

kubectl wait --for=condition=Bound pvc/app-data -n production --timeout=60s && echo "PVC lié avec succès" || (echo "PVC non lié" && exit 1)

Responsable : L'ingénieur DevOps de garde est responsable du diagnostic des problèmes de PVC pendant le déploiement. Documentez les étapes de diagnostic dans les procédures opérationnelles.

Modes de défaillance et récupération

Modes de défaillance courants pour l'automatisation des PVC :

PVC bloqué en attente (Pending) : Causé par l'absence de classe de stockage correspondante, une capacité insuffisante ou un mode d'accès non pris en charge. Récupération :

Vérifiez la disponibilité de la classe de stockage : kubectl get storageclass
Décrivez le PVC pour les événements : kubectl describe pvc <name> -n <namespace>
Ajustez le manifeste et réappliquez.

Perte de données due à la politique de récupération Delete : Si la politique de récupération de la classe de stockage est Delete, supprimer un PVC supprime le volume sous-jacent. Pour éviter une perte de données accidentelle, définissez la politique de récupération sur Retain pour les données importantes ou créez une sauvegarde avant la suppression :

Modifiez la classe de stockage : kubectl patch storageclass standard -p '{"reclaimPolicy":"Retain"}' (uniquement possible si le fournisseur le prend en charge).
Avant de supprimer un PVC, prenez un instantané du PersistentVolume : vérifiez les options d'instantané du fournisseur cloud.

Le pod ne peut pas monter le volume après la recréation du PVC : Si un PVC est supprimé et recréé, il peut obtenir un nouveau volume, entraînant une perte de données. Au lieu de cela, conservez le même nom de PVC et utilisez le clonage de volume ou la restauration à partir d'une sauvegarde.

Rollback d'un déploiement avec PVC : Le rollback d'un déploiement ne ramène pas les modifications de PVC si le PVC est externe au déploiement. Utilisez des manifestes PVC séparés et gérez le cycle de vie indépendamment. Si vous devez revenir sur la taille ou la classe de stockage, créez un nouveau PVC et migrez les données.

Exemple de récupération : Recréer un PVC supprimé par erreur

Si un PVC a été supprimé accidentellement et que la politique de récupération est Retain, le PV sous-jacent existe toujours mais est à l'état Released. Pour récupérer :

# Trouver le PV qui était lié au PVC (vérifiez l'ancien nom du PV)
kubectl get pv
# Si le PV est Released, modifiez-le pour supprimer claimRef
kubectl edit pv <pv-name>  # supprimez spec.claimRef
# Ensuite, recréez le PVC avec le même nom et les mêmes spécifications
kubectl apply -f pvc.yaml
# Le PVC devrait se lier au PV existant

Piège : Ne pas sauvegarder les données avant la suppression d'un PVC. Assurez-vous toujours qu'une politique de sauvegarde est en place pour les applications avec état.

Responsable : L'administrateur de base de données ou de stockage est propriétaire des procédures de récupération. Les exercices de récupération doivent être effectués trimestriellement.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle avant et après l'exécution de l'automatisation des PVC dans CI/CD :

[ ] Confirmer que la version du cluster et les classes de stockage sont compatibles avec le manifeste PVC.
[ ] Sauvegarder les données PVC existantes en cas de risque de suppression.
[ ] Valider le manifeste avec kubectl apply --dry-run=client.
[ ] Appliquer le PVC et attendre la condition Bound.
[ ] Vérifier que le pod applicatif monte correctement le volume.
[ ] Surveiller les alertes (par exemple, l'utilisation du PVC approchant de la capacité).
[ ] Documenter les modifications dans le système de gestion des changements.
[ ] Planifier une revue trimestrielle des tailles de PVC et des classes de stockage.

Responsable : Le responsable des mises en production s'assure que tous les éléments de la liste de contrôle sont complétés. La liste de contrôle est revue après chaque déploiement en production.

Pièges courants et comment les éviter

Voici un résumé des pièges au-delà de ceux mentionnés :

Utiliser la classe de stockage par défaut sans le savoir : Si vous omettez storageClassName, Kubernetes utilise la valeur par défaut. Cela peut différer selon les environnements. Spécifiez toujours la classe de stockage explicitement dans les manifestes.
Coder en dur les noms de PVC à plusieurs endroits : Les modèles de pods peuvent référencer des noms de PVC. Si le nom du PVC change, les pods échouent. Utilisez les valeurs Helm ou Kustomize pour gérer les noms de manière cohérente.
Ignorer les limites de capacité : La taille d'un PVC est fixe ; le redimensionnement dépend de la classe de stockage et de allowVolumeExpansion. Vérifiez ALLOWVOLUMEEXPANSION dans la classe de stockage. Pour redimensionner, modifiez le PVC :

  kubectl patch pvc app-data -n production -p '{"spec":{"resources":{"requests":{"storage":"10Gi"}}}}'

Cela ne fonctionne que si l'expansion est autorisée.

Ne pas définir de quotas de ressources : Sans quotas, un processus incontrôlé peut créer de nombreux PVC, consommant le stockage. Définissez une ResourceQuota dans le namespace.
Oublier de nettoyer les PVC inutilisés : Surveillez et supprimez les PVC non utilisés par un pod pour économiser des coûts, mais vérifiez d'abord.

Conclusion

L'automatisation de la gestion des PVC Kubernetes dans CI/CD exige une planification minutieuse pour éviter la perte de données et les temps d'arrêt. En suivant les pratiques de ce guide — commencer par l'inventaire de l'environnement, appliquer les manifestes en toute sécurité, vérifier minutieusement et se préparer aux défaillances — vous pouvez obtenir des déploiements fiables d'applications avec état. Versionnez toujours vos manifestes, testez en dry-run et documentez les étapes de récupération.

Comme prochaine étape, implémentez un pipeline d'automatisation de PVC simple pour une application de test. Surveillez son comportement, puis étendez progressivement à la production avec des garde-fous appropriés. Révisez votre utilisation des PVC chaque trimestre et ajustez les classes de stockage et les tailles si nécessaire. Grâce à ces mesures, vous pouvez gérer en toute confiance le stockage persistant dans vos clusters Kubernetes.