CI/CD des pilotes CSI Kubernetes : guide pratique d'automatisation

Introduction

L'automatisation du CI/CD des pilotes CSI Kubernetes avec des exemples pratiques doit aider les opérateurs à passer d'un problème observé à un résultat vérifié. Cet article se concentre sur le CI/CD des pilotes CSI Kubernetes pour les développeurs, les consultants DevOps et les équipes techniques de startups. Il relie l'automatisation, le déploiement, le pipeline et le retour arrière des pilotes CSI Kubernetes à des commandes concrètes, des sorties attendues, des signaux d'échec et des décisions de récupération.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des variables fictives au lieu de secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint. Tout au long de l'article, nous utilisons un exemple cohérent : un pilote CSI AWS EBS s'exécutant dans un cluster sur AWS, avec une StorageClass nommée ebs-sc et un PVC nommé data-pvc. Remplacez ces éléments par les spécificités de votre environnement.

Inventaire des versions et de l'environnement

Avant tout changement CI/CD, capturez l'état actuel du pilote CSI et de ses dépendances. Cet inventaire empêche que des mises à niveau ou des changements de configuration ne cassent les volumes ou les applications existants.

Identification des composants

Identifiez le nom du pilote CSI, l'espace de noms, la version et la version de Kubernetes prise en charge. Pour le pilote CSI AWS EBS, les pods du contrôleur et du nœud s'exécutent généralement dans l'espace de noms kube-system. Vérifiez la version installée avec :

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

Exemple de sortie attendue :

public.ecr.aws/ebs-csi-driver/aws-ebs-csi-driver:v1.35.0

Notez la version v1.35.0. Les notes de version du pilote spécifient les versions minimales de Kubernetes et la compatibilité. Par exemple, la version v1.35.0 nécessite Kubernetes 1.21 ou ultérieur.

Observation en lecture seule

Exécutez ces commandes pour observer le système sans rien modifier :

kubectl get pods -n kube-system -l app=ebs-csi-controller -o wide
kubectl get pods -n kube-system -l app=ebs-csi-node -o wide
kubectl get csidriver
kubectl get storageclass ebs-sc -o yaml

Vérifiez que tous les pods du contrôleur et du nœud sont Running et READY. L'objet csidriver indique si le pilote est enregistré ; pour EBS, il affiche ebs.csi.aws.com avec attachRequired: true et podInfoOnMount: false. Cela vous indique que le pilote nécessite une attache du volume avant le montage.

Dépendances et prérequis

Vérifiez que les secrets et les comptes de service requis existent. Pour le CSI EBS, le contrôleur a besoin d'autorisations IAM via IRSA ou un secret. Vérifiez :

kubectl get sa ebs-csi-controller-sa -n kube-system
kubectl get secret aws-secret -n kube-system -o yaml

Si vous utilisez IRSA, confirmez que l'annotation sur le compte de service pointe vers l'ARN du rôle IAM correct. Enregistrez ces éléments avant les modifications, car les pipelines CI/CD les écrasent souvent.

Plus petit changement justifié

Une fois l'état actuel documenté, définissez le plus petit changement. Pour une mise à niveau du pilote, cela peut être la mise à jour de l'étiquette d'image dans le déploiement du contrôleur. Mais avant de modifier, enregistrez le manifeste de déploiement actuel pour le retour arrière :

kubectl get deployment ebs-csi-controller -n kube-system -o yaml > ebs-csi-controller-backup-$(date +%Y%m%d-%H%M%S).yaml

Cette sauvegarde est votre artefact de retour arrière. Stockez-la dans un emplacement sûr accessible à votre pipeline.

Question rapide 1 sur 2

Quelle est la sortie attendue lors de l'exécution de 'kubectl get deployment ebs-csi-controller -n kube-system -o jsonpath='{.spec.template.spec.containers[0].image}' ?

L'article indique que l'exemple de sortie attendue pour vérifier la version installée est 'public.ecr.aws/ebs-csi-driver/aws-ebs-csi-driver:v1.35.0'.

Chemin de configuration sûr

Cette section montre comment implémenter un changement de configuration en toute sécurité, en utilisant un pipeline CI/CD avec une stratégie de déploiement canari.

Étape 1 : Construire et tester la nouvelle configuration du pilote

Supposons que vous deviez mettre à jour un paramètre du pilote, comme activer l'expansion de volume ou modifier le nombre de réplicas du contrôleur. Dans votre pipeline, créez une nouvelle branche et modifiez les valeurs Helm ou le manifeste YAML. Par exemple, pour augmenter les réplicas du contrôleur de 2 à 3, modifiez le déploiement :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ebs-csi-controller
  namespace: kube-system
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: ebs-plugin
        image: public.ecr.aws/ebs-csi-driver/aws-ebs-csi-driver:v1.35.0
        args:
          - --endpoint=$(CSI_ENDPOINT)
          - --logtostderr
          - --v=4
          - --enable-volume-scheduling=true
          - --enable-volume-resizing=true
          - --enable-volume-snapshots=true

Ici, --enable-volume-resizing=true permet l'expansion du PVC. Vérifiez que les arguments sont pris en charge par la version du pilote ; consultez la documentation du pilote pour les indicateurs.

Étape 2 : Valider les manifestes dans le CI

Avant d'appliquer au cluster, exécutez une validation statique. Utilisez kubeconform ou kubectl apply --dry-run=client :

kubectl apply -f ebs-csi-controller.yaml --dry-run=client

Sortie attendue :

deployment.apps/ebs-csi-controller configured (dry run)

Cela détecte les erreurs de syntaxe. Exécutez également kubectl diff -f ebs-csi-controller.yaml pour voir les modifications qui seraient appliquées.

Étape 3 : Déployer dans un espace de noms canari ou un groupe de nœuds

Au lieu de déployer sur tous les nœuds en une seule fois, utilisez une approche canari. Pour les plugins de nœud CSI, qui s'exécutent en DaemonSets, vous pouvez utiliser un sélecteur de nœud pour cibler un sous-ensemble de nœuds. Pour le contrôleur, vous pouvez créer un déploiement séparé avec un nom différent dans le même espace de noms, mais cela peut entrer en conflit. Mieux : utilisez une version Helm avec un espace de noms de test. Pour plus de simplicité, nous déployons dans un espace de noms de test csi-test :

kubectl create namespace csi-test
helm upgrade --install ebs-csi-driver-test aws-ebs-csi-driver \
  --namespace csi-test \
  --set controller.replicaCount=1 \
  --set node.enable=false

Cela déploie uniquement le composant contrôleur en test, pas le plugin de nœud. Exécutez des tests d'intégration contre un PVC de test dans cet espace de noms :

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

Appliquez et attendez la liaison :

kubectl apply -f test-pvc.yaml
kubectl get pvc test-pvc -n csi-test --watch

Sortie attendue après quelques secondes :

NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-pvc   Bound    pvc-1234abcd-5678-efgh-ijkl-mnopqrstuvwx   1Gi        RWO            ebs-sc         10s

Si le PVC reste Pending, vérifiez les événements :

kubectl describe pvc test-pvc -n csi-test

Étape 4 : Promouvoir en production

Après le succès des tests, promouvez le changement dans l'espace de noms de production (kube-system ou votre espace dédié). Utilisez votre outil CD (Argo CD, Flux, Jenkins). Par exemple, avec kubectl set image :

kubectl set image deployment/ebs-csi-controller -n kube-system ebs-plugin=public.ecr.aws/ebs-csi-driver/aws-ebs-csi-driver:v1.35.0

Vérifiez l'état du déploiement :

kubectl rollout status deployment/ebs-csi-controller -n kube-system

Sortie attendue :

deployment "ebs-csi-controller" successfully rolled out

Pour le plugin de nœud (DaemonSet), utilisez kubectl rollout status daemonset/ebs-csi-node -n kube-system.

Étape 5 : Vérifier que les volumes persistants fonctionnent toujours

Après le déploiement, créez ou vérifiez un PVC existant. Utilisez un secret fictif, jamais de véritables informations d'identification, dans les journaux du pipeline. Si vous utilisez AWS, assurez-vous que les autorisations du rôle IAM sont inchangées. Vérifiez en créant un pod de test qui monte le volume et écrit un fichier.

Vérification et diagnostic

Après avoir déployé ou modifié le pilote CSI, vérifiez que les opérations de stockage fonctionnent de bout en bout.

Santé des pods et du pilote

Exécutez les commandes suivantes :

kubectl get pods -n kube-system -l app=ebs-csi-controller
kubectl get pods -n kube-system -l app=ebs-csi-node
kubectl logs deployment/ebs-csi-controller -n kube-system --tail=50

Recherchez des erreurs comme failed to provision volume, unauthorized ou context deadline exceeded. Si les journaux du contrôleur montrent des erreurs IAM, vérifiez la liaison du rôle IAM du compte de service.

Test de provisionnement de volume

Créez un PVC et un pod qui l'utilise. Utilisez un pod busybox simple :

apiVersion: v1
kind: Pod
metadata:
  name: test-ebs-pod
spec:
  containers:
  - name: app
    image: busybox
    command: ["/bin/sh"]
    args: ["-c", "echo hello > /data/test.txt && sleep 3600"]
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: test-pvc

Appliquez et vérifiez :

kubectl apply -f test-pod.yaml
kubectl get pod test-ebs-pod

Si le pod est Running, exécutez une commande pour vérifier le fichier :

kubectl exec test-ebs-pod -- cat /data/test.txt

Sortie attendue : hello

Si le pod est bloqué en ContainerCreating, exécutez kubectl describe pod test-ebs-pod et recherchez des événements comme FailedAttachVolume ou FailedMount. Vérifiez les journaux du plugin de nœud sur le nœud concerné :

kubectl logs -n kube-system daemonset/ebs-csi-node -c ebs-plugin --tail=50

Vérifications spécifiques au pilote CSI

Pour le CSI EBS, vérifiez que l'objet CSI Driver existe :

kubectl get csidriver ebs.csi.aws.com -o yaml

Vérifiez attachRequired: true, podInfoOnMount: false et volumeLifecycleModes inclut Persistent. Si ces valeurs sont incorrectes, les volumes peuvent ne pas s'attacher ou se monter.

Utilisez les tests csi-sanity si disponibles, ou exécutez la validation propre au pilote. De nombreux pilotes CSI incluent un mode --check ou un plugin kubectl csi (du CSI cert-manager ou similaire) pour tester les points de terminaison gRPC.

Question rapide 2 sur 2

Quelle commande est utilisée pour vérifier l'état du déploiement (rollout status) après la mise en production ?

Dans l'étape de mise en production, la commande pour vérifier l'état du déploiement (rollout status) est 'kubectl rollout status deployment/ebs-csi-controller -n kube-system'.

Modes de défaillance et récupération

Le CI/CD des pilotes CSI doit inclure des procédures de retour arrière et de récupération pour les scénarios de défaillance courants.

Scénario 1 : La mise à niveau du pilote casse les PVC existants

Si après la mise à niveau, les PVC existants ne se montent pas (pods bloqués en ContainerCreating avec Volume not attached), vérifiez d'abord si la version du pilote est incompatible avec la version de Kubernetes. La solution consiste à revenir à l'image précédente.

Utilisez le YAML de sauvegarde créé précédemment ou votre historique git. Par exemple :

kubectl apply -f ebs-csi-controller-backup-20250101-120000.yaml
kubectl rollout status deployment/ebs-csi-controller -n kube-system --timeout=60s

Si le retour arrière du déploiement échoue, utilisez kubectl rollout undo :

kubectl rollout undo deployment/ebs-csi-controller -n kube-system

Ensuite, vérifiez les pods et les PVC. Si les volumes ont été modifiés de manière incorrecte, vous devrez peut-être restaurer à partir de snapshots. Assurez-vous d'avoir activé et testé les snapshots de volume.

Scénario 2 : Le DaemonSet du plugin de nœud échoue sur les nouveaux nœuds

Un problème courant après l'ajout de nouveaux nœuds est que le pod du plugin de nœud CSI ne s'exécute pas sur le nouveau nœud. Vérifiez avec :

kubectl get pods -n kube-system -l app=ebs-csi-node -o wide | grep <new-node-name>

S'il est absent, vérifiez les teintes et tolérances du nœud. Le DaemonSet doit tolérer les teintes du nœud. Vérifiez et mettez à jour les tolérances dans le manifeste du DaemonSet. Par exemple, ajoutez une tolérance pour node.kubernetes.io/not-ready :

tolerations:
- key: node.kubernetes.io/not-ready
  operator: Exists
  effect: NoExecute

Appliquez et vérifiez. Vérifiez également que le nœud dispose des autorisations IAM nécessaires si vous utilisez des profils d'instance.

Scénario 3 : Paramètres de StorageClass incompatibles

Si un nouveau paramètre de StorageClass provoque un échec de provisionnement, par exemple, définir type: io2 alors qu'il n'est pas disponible dans la région, vous verrez des erreurs dans les journaux du contrôleur :

Failed to create volume: InvalidParameterValue: The parameter type is invalid

Revenez sur le changement de StorageClass :

kubectl apply -f storageclass-backup.yaml

Ensuite, supprimez le PVC en échec et recréez-le, ou attendez que le contrôleur réessaie.

Scénario 4 : Secrets ou rôles IAM mal configurés

Si les journaux du contrôleur affichent AccessDenied ou NoCredentialProviders, vérifiez la configuration du secret ou de l'IRSA. Pour IRSA, vérifiez l'annotation du compte de service et la politique de confiance IAM. Pour les secrets, restaurez à partir de la sauvegarde ou recréez-les. Exemple pour vérifier les clés du secret :

kubectl get secret aws-secret -n kube-system -o jsonpath='{.data.key_id}' | base64 -d

N'imprimez jamais les valeurs complètes des secrets dans les journaux CI ; utilisez une sortie masquée.

Vérification de la récupération

Après toute récupération, exécutez les étapes de vérification de la section précédente. Créez un nouveau PVC et un pod de test pour vous assurer que le pilote fonctionne. Documentez l'incident et mettez à jour les procédures.

Liste de contrôle des opérations

Utilisez cette liste de contrôle avant, pendant et après tout changement CI/CD des pilotes CSI Kubernetes. Chaque élément comprend un exemple concret.

Liste de contrôle avant changement

[ ] Enregistrer la version et l'image actuelles du pilote : kubectl get deployment ebs-csi-controller -n kube-system -o jsonpath='{.spec.template.spec.containers[0].image}' (par exemple, v1.34.0)
[ ] Sauvegarder le manifeste de déploiement actuel : kubectl get deployment ebs-csi-controller -n kube-system -o yaml > backup-$(date +%s).yaml
[ ] Vérifier la compatibilité de version du cluster : kubectl version --short (par exemple, Server Version: v1.28.5)
[ ] Vérifier les PVC et StorageClasses existants : kubectl get pvc --all-namespaces et kubectl get sc
[ ] Confirmer que les rôles IAM ou les secrets sont valides et testés : kubectl get sa ebs-csi-controller-sa -n kube-system -o yaml | grep eks.amazonaws.com/role-arn
[ ] Définir les critères de retour arrière : par exemple, « Si plus de 5 % des PVC ne se lient pas dans les 2 minutes, revenir en arrière. »

Liste de contrôle pendant le déploiement

[ ] Appliquer le changement en utilisant des manifestes déclaratifs ou Helm, pas des commandes impératives lorsque c'est possible.
[ ] Surveiller le déploiement : kubectl rollout status deployment/ebs-csi-controller -n kube-system --timeout=120s
[ ] Regarder les journaux en temps réel : kubectl logs -f deployment/ebs-csi-controller -n kube-system
[ ] Si vous utilisez un canari, vérifiez l'espace de noms de test avant la production.
[ ] Vérifier les redémarrages de pods inattendus : kubectl get pods -n kube-system -l app=ebs-csi-controller -w

Liste de contrôle de vérification post-déploiement

[ ] Créer un PVC de test et vérifier qu'il se lie : kubectl apply -f test-pvc.yaml && kubectl get pvc test-pvc -n default -> doit afficher Bound
[ ] Créer un pod de test et écrire/lire des données : kubectl exec test-ebs-pod -- cat /data/test.txt -> doit renvoyer hello
[ ] Valider que les PVC existants sont toujours sains : kubectl get pvc --all-namespaces | grep -v Bound (doit être vide)
[ ] Vérifier l'objet CSI Driver : kubectl get csidriver ebs.csi.aws.com -o yaml
[ ] Examiner les événements pour les erreurs : kubectl get events -n kube-system --sort-by=.lastTimestamp | tail -20

Liste de contrôle de retour arrière et de récupération

[ ] Si un retour arrière est nécessaire, appliquer le YAML de sauvegarde : kubectl apply -f backup-<timestamp>.yaml
[ ] Pour les versions Helm, helm rollback <release> <revision>
[ ] Vérifier le retour arrière : kubectl rollout status deployment/ebs-csi-controller -n kube-system
[ ] Exécuter à nouveau les tests de vérification.
[ ] Mettre à jour la documentation de l'incident et étiqueter le changement en échec dans votre système CI/CD.

Conclusion

L'automatisation du CI/CD des pilotes CSI Kubernetes avec des exemples pratiques n'est utile que si chaque recommandation est délimitée par version, observable et réversible lorsque la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue n'est pas une procédure d'exploitation.

Comme prochaine étape, choisissez une vérification à faible risque pour le CI/CD des pilotes CSI Kubernetes, enregistrez l'état actuel, exécutez la vérification documentée, comparez le résultat au signal attendu et examinez les dépendances telles que la Storage Class, le Persistent Volume et le Persistent Volume Claim.

Un flux de travail technique fiable rend les échecs visibles, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de la récupération avant qu'un incident ne force la décision. Mettez en œuvre ces pratiques dans votre pipeline et vous déploierez les changements de pilote CSI en toute confiance.