Optimisation des performances des volumes Kubernetes : guide pratique de mise en œuvre

Introduction

Les problèmes de performances des volumes Kubernetes se cachent souvent à la vue de tous : une base de données qui ralentit sous la charge, un job CI qui expire lors des écritures, ou une application qui bégaie uniquement aux heures de pointe. Sans approche structurée, les opérateurs perdent du temps à deviner les paramètres des StorageClass, à redimensionner les PVC ou à changer de type de nœud sans preuve.

Ce guide vous propose un parcours pratique, fondé sur des preuves, du symptôme à la résolution. Il couvre les concepts fondamentaux des volumes persistants (PV), des demandes de volume persistant (PVC) et des classes de stockage, puis détaille l'observation, l'optimisation et la vérification avec de vraies commandes et les sorties attendues. Vous apprendrez à mesurer la latence et le débit des volumes, à interpréter les signaux du système de fichiers et des périphériques bloc, et à appliquer des modifications en toute sécurité en gardant à l'esprit la possibilité de revenir en arrière.

Le public visé comprend les développeurs, les ingénieurs DevOps et les équipes techniques de startups qui gèrent des clusters Kubernetes en production. 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 le résultat et documenter les procédures de récupération.

Inventaire des versions et de l'environnement

Avant de régler un volume, vous devez savoir exactement ce que vous exécutez. Cette section montre comment capturer les versions du cluster, du fournisseur de stockage, du pilote CSI et du noyau, ainsi que la topologie de stockage pertinente, afin que les recommandations soient reproductibles.

Commencez par un inventaire en lecture seule :

kubectl version --client
kubectl get nodes -o wide
kubectl get storageclass
kubectl get csinodes -o wide  # si des pilotes CSI sont utilisés
kubectl get pv -o wide
kubectl get pvc --all-namespaces

La sortie attendue pour les classes de stockage pourrait ressembler à :

NAME                 PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
gp2 (default)        kubernetes.io/aws-ebs   Delete          Immediate           false                  365d
gp3                  ebs.csi.aws.com         Delete          WaitForFirstConsumer true                  120d
fast-local           kubernetes.io/no-provisioner  Delete    Immediate           false                  90d

Capturez la version du fournisseur et du pilote CSI. Par exemple, avec le pilote CSI AWS EBS :

kubectl -n kube-system get pods -l app=ebs-csi-controller -o jsonpath='{.items[*].spec['initContainers', 'containers'][*].image}'

Sortie :

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

Pour le stockage sur site comme Ceph RBD ou les volumes locaux, vérifiez le noyau et le système de fichiers du nœud :

uname -a
df -hT /var/lib/kubelet/pods

Exemple de sortie :

Linux node-3 5.15.0-102-generic #112-Ubuntu SMP ... x86_64 GNU/Linux
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/nvme1n1   ext4  220G   140G   70G  67% /var/lib/kubelet/pods

Notez le type de système de fichiers (ext4 ou xfs) et les options de montage, car ils affectent les performances du volume et les paramètres d'optimisation.

Vérification pratique de la version et de l'environnement

• Exécutez kubectl get events --all-namespaces --sort-by=.lastTimestamp | tail -20 pour voir les événements récents liés au stockage.
• Pour un PVC spécifique, vérifiez son statut et ses événements :

  kubectl describe pvc my-app-pvc

Attendez-vous à Status: Bound et à un événement récent ProvisioningSucceeded. Si vous voyez ProvisioningFailed, inspectez la classe de stockage et les journaux du fournisseur.

• Vérifiez que le plugin de nœud du pilote CSI s'exécute sur tous les nœuds :

  kubectl -n kube-system get pods -l app=ebs-csi-node -o wide

Chaque nœud doit avoir un pod en cours d'exécution.

Conservez le document d'inventaire de l'environnement dans le même dépôt que vos manifestes, afin que toute personne dépanne plus tard voie les versions exactes.

Chemin de configuration sécurisé

Les volumes sont une infrastructure critique ; une mauvaise modification peut entraîner une perte de données ou une indisponibilité. Suivez un chemin sûr : commencez par une observation en lecture seule, créez un PV/PVC de test dans un espace de noms isolé, appliquez une modification à la fois et ayez toujours un plan de retour en arrière.

Étape 1 : Observer les performances actuelles du volume

Utilisez kubectl top pour le CPU et la mémoire du pod, mais pour les E/S de stockage, vous avez besoin d'outils au niveau du nœud. Exécutez un pod de débogage éphémère avec fio (testeur d'E/S flexible) sur un volume existant. Exemple :

Tout d'abord, créez un PVC pour les tests, ou utilisez-en un existant. Si vous avez besoin d'un nouveau PVC :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: perf-test-pvc
  namespace: perf-test
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: gp3

Appliquez-le :

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

Sortie attendue :

NAME           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
perf-test-pvc  Bound    pvc-abcdefgh-1234-5678-ijkl-mnopqrstuvwx  10Gi       RWO            gp3            5s

Exécutez maintenant un job fio dans un pod utilisant ce PVC :

apiVersion: v1
kind: Pod
metadata:
  name: fio-tester
  namespace: perf-test
spec:
  containers:
  - name: fio
    image: ljishen/fio:latest
    command: ["sleep", "3600"]
    volumeMounts:
    - mountPath: /test-volume
      name: test-volume
  volumes:
  - name: test-volume
    persistentVolumeClaim:
      claimName: perf-test-pvc

Appliquez et exécutez une commande dans le pod :

kubectl apply -f fio-pod.yaml
kubectl -n perf-test exec -it fio-tester -- bash

Dans le pod, exécutez un test d'écriture séquentielle de base :

fio --name=write-test --filename=/test-volume/fio-test-file --size=1G --bs=4k --iodepth=32 --rw=write --direct=1 --ioengine=libaio --runtime=60 --time_based --group_reporting

Exemple de sortie :

write: IOPS=12.5k, BW=48.8MiB/s (51.2MB/s)(2930MiB/60001msec)
  slat (usec): min=2, max=1000, avg= 5.00, stdev= 3.00
  clat (usec): min=100, max=5000, avg=250, stdev=100
  lat (usec): 99.99th=[  500]

Enregistrez ces mesures de référence : IOPS, bande passante et centiles de latence.

Étape 2 : Identifier le goulot d'étranglement

Si la latence est élevée (par exemple, centile 99,99 > 10 ms pour des volumes SSD), vérifiez les paramètres de la classe de stockage. Pour gp3, vous pouvez définir indépendamment les IOPS et le débit. Pour gp2, les IOPS évoluent avec la taille du volume. Comparez vos IOPS observés avec la limite théorique.

Par exemple, un volume gp2 de 100 Gio a une base de 300 IOPS avec des rafales jusqu'à 3000. Si votre charge de travail nécessite constamment 5000 IOPS, gp2 est insuffisant. Passer à gp3 avec iops=5000 pourrait résoudre le problème, mais c'est une modification.

Étape 3 : Appliquer la plus petite modification avec retour en arrière

Exemple : changer la classe de stockage de gp2 à gp3 pour un nouveau PVC. Vous ne pouvez pas modifier directement la classe de stockage d'un PVC existant. Vous devez créer un nouveau PVC, copier les données, puis basculer le déploiement.

Créez une nouvelle StorageClass :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3-high-iops
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "5000"
  throughput: "500"
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Appliquez-la et créez un nouveau PVC utilisant cette classe. Ensuite, migrez les données à l'aide de rsync ou d'un outil comme velero.

Pour revenir en arrière, supprimez le nouveau PVC et gardez l'ancien intact. Prenez toujours un instantané avant la migration :

kubectl -n myapp create -f volume-snapshot.yaml

Exemple d'instantané :

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: myapp-snapshot-before-migration
spec:
  volumeSnapshotClassName: ebs-snapclass
  source:
    persistentVolumeClaimName: myapp-pvc

Liste de contrôle de configuration sécurisée

• [ ] Observation en lecture seule terminée et mesures de référence enregistrées.
• [ ] PVC de test dans un espace de noms isolé fonctionne comme prévu.
• [ ] Instantané ou sauvegarde existant avant toute modification.
• [ ] La modification est limitée à une nouvelle ressource, pas à la modification d'une ressource existante.
• [ ] Procédure de retour en arrière documentée et testée.

Vérification et diagnostics

Après avoir appliqué une modification de configuration, vous devez vérifier que les performances se sont améliorées et qu'aucune régression n'est survenue. Utilisez le même test fio et comparez les métriques.

Comparaison avant et après modification

Exécutez le test fio avec des paramètres identiques sur le nouveau volume. Comparez les IOPS, la bande passante et la latence. Exemple avant et après :

Si les nouvelles valeurs répondent aux exigences de votre application, continuez. Sinon, approfondissez l'enquête.

Surveillance réelle de la charge de travail

Les benchmarks synthétiques ne racontent pas toute l'histoire. Surveillez le comportement réel du pod. Vérifiez le CPU, la mémoire et l'utilisation du système de fichiers du pod :

kubectl top pod my-database-pod

Sortie :

NAME              CPU(cores)   MEMORY(bytes)
my-database-pod   1200m        1.5Gi

Pour les E/S de stockage, si votre nœud dispose de iotop ou de pidstat, vous pouvez obtenir les E/S par processus à l'intérieur du pod. Sinon, utilisez kubectl exec pour exécuter iostat si l'image du pod le contient. De nombreuses images de base ne l'ont pas, envisagez donc d'utiliser un sidecar ou des outils au niveau du nœud.

Utilisation des E/S au niveau du nœud :

ssh node-1 'iostat -x 1 10'

Extrait de sortie :

Device            r/s     w/s     rkB/s     wkB/s   await  %util
nvme1n1         1200.00  500.00  12000.00  8000.00   2.50  55.00

Un %util élevé proche de 100 % indique une saturation. Un await élevé (>10 ms pour un SSD) indique des problèmes de latence.

Commandes de diagnostic pour des fournisseurs spécifiques

• Pilote CSI AWS EBS : Vérifiez les journaux du contrôleur pour les erreurs de provisionnement :

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

• Ceph RBD : Vérifiez si le client RBD est connecté et les performances à l'aide de rbd perf image sur le nœud.
• Volumes locaux : Comparez les performances entre les nœuds ; si un nœud est plus lent, vérifiez la santé du disque avec smartctl -a /dev/sdX.

Liste de contrôle de vérification

• [ ] Mesures de référence enregistrées avant la modification.
• [ ] Même test exécuté après la modification dans les mêmes conditions.
• [ ] L'amélioration correspond aux attentes ; aucune régression dans d'autres métriques.
• [ ] La surveillance réelle de la charge de travail montre des performances améliorées soutenues dans le temps.
• [ ] Aucun événement ou erreur lié au stockage dans les événements du cluster.

Modes de défaillance et récupération

Même des modifications prudentes peuvent échouer. Cette section couvre les modes de défaillance courants pour l'optimisation des volumes et comment récupérer.

Défaillance : PVC bloqué en attente (Pending)

Si un PVC ne se lie pas, vérifiez les événements :

kubectl describe pvc my-pvc

Raisons courantes :

• Aucun PV correspondant si la classe de stockage n'est pas dynamique.
• Le fournisseur ne s'exécute pas.
• Contraintes de sélecteur de nœud ou de zone non satisfaites pour WaitForFirstConsumer.

Récupération : Pour le provisionnement dynamique, assurez-vous que le pod du fournisseur est en cours d'exécution. Pour WaitForFirstConsumer, assurez-vous qu'un pod est planifié sur le nœud consommateur. En cas de non-correspondance de zone, ajustez l'affinité du nœud.

Défaillance : Performances inférieures aux attentes

Si vous êtes passé à un volume avec des IOPS plus élevés mais que les performances ne se sont pas améliorées, envisagez :

• Le système de fichiers n'utilise pas les E/S directes pour fio ; définissez --direct=1.
• Le volume n'est pas entièrement attaché ou monté ; vérifiez mount à l'intérieur du pod.
• Les limites de CPU du pod Kubernetes limitent les E/S ; augmentez la limite de CPU.
• Le stockage attaché au réseau (par exemple, EBS) utilise la bande passante de l'instance EC2 ; le type d'instance peut limiter le débit. Vérifiez les limites de bande passante EBS de l'instance.

Récupération : Augmentez la limite de CPU, utilisez une instance plus grande avec plus de bande passante EBS, ou utilisez le stockage d'instance pour des besoins éphémères de hautes performances.

Défaillance : Problème d'intégrité des données après migration

Si vous avez copié des données et qu'après la bascule, l'application signale des erreurs, revenez immédiatement en arrière :

1. Prenez un instantané du nouveau PVC avant la copie.
2. Rebasculez le déploiement sur l'ancien PVC (gardez l'ancien PVC jusqu'à vérification).
3. Vérifiez la cohérence du système de fichiers avec fsck (pour les volumes bloc) avant de remonter.

Exemple de commande de retour en arrière :

kubectl -n myapp set volume deployment/my-app --add --name=old-volume --mount-path=/data --claim-name=old-pvc

Ensuite, supprimez le nouveau volume.

Exercice de récupération

Au moins une fois, simulez une défaillance dans un cluster de préproduction : créez un PVC, prenez un instantané, supprimez le PVC, restaurez à partir de l'instantané et vérifiez les données. Documentez les étapes exactes.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour toute tâche d'optimisation des performances des volumes. Imprimez-la, partagez-la et adaptez-la à votre environnement.

Préparation

• [ ] Identifiez l'application et ses exigences de stockage (IOPS, débit, latence).
• [ ] Enregistrez les noms et paramètres actuels de la classe de stockage, du PV et du PVC.
• [ ] Prenez une sauvegarde ou un instantané du volume si possible.
• [ ] Créez un espace de noms de test et un PVC pour les benchmarks (pas de données de production).
• [ ] Informez les parties prenantes d'un éventuel impact bref sur les performances.

Exécution

• [ ] Exécutez un benchmark de référence avec fio ou un test de charge spécifique à l'application.
• [ ] Analysez le goulot d'étranglement : classe de stockage, type de nœud, système de fichiers, réseau, CPU.
• [ ] Déterminez la plus petite modification : nouvelle classe de stockage, augmentation des IOPS, autre fournisseur, etc.
• [ ] Appliquez la modification à une nouvelle ressource, pas à une existante.
• [ ] Migrez les données si nécessaire, en vérifiant les sommes de contrôle.
• [ ] Basculez la charge de travail vers le nouveau volume progressivement (par exemple, une réplique à la fois).

Vérification

• [ ] Exécutez à nouveau le benchmark dans les mêmes conditions.
• [ ] Comparez les métriques ; confirmez l'amélioration.
• [ ] Surveillez la charge de travail réelle pendant au moins 24 heures (ou un cycle complet d'activité).
• [ ] Vérifiez les événements du cluster pour les erreurs de stockage.
• [ ] Documentez la nouvelle configuration et les chiffres de performance.

Plan de retour en arrière

• [ ] Gardez l'ancien PVC et le PV jusqu'à ce que le nouveau volume soit prouvé stable.
• [ ] Sachez comment rebasculer le déploiement vers l'ancien volume (commande kubectl set volume).
• [ ] Ayez un instantané/restauration testé.
• [ ] Communiquez les critères de retour en arrière à l'équipe.

Surveillance continue

• [ ] Configurez des alertes pour les métriques de stockage : utilisation du PV supérieure à 80 %, latence élevée, attente d'E/S élevée.
• [ ] Utilisez les métriques Prometheus de kubelet (kubelet_volume_stats_*) pour suivre l'utilisation et les performances des volumes.
• [ ] Planifiez des audits de performance réguliers, surtout après les mises à niveau du cluster.

Conclusion

L'optimisation des performances des volumes Kubernetes n'est pas une correction ponctuelle mais un processus continu de mesure, d'analyse et de modification contrôlée. En suivant l'approche structurée de ce guide, vous évitez les réglages par imitation et prenez des décisions fondées sur des preuves.

Commencez par une vérification à faible risque : exécutez un test fio de référence sur un volume existant à l'aide du pod fourni, enregistrez les métriques et comparez-les aux performances attendues pour votre classe de stockage. Ensuite, si nécessaire, apportez une modification petite et réversible, et vérifiez le résultat avec une surveillance réelle de la charge de travail.

Un réglage fiable des performances rend les défaillances visibles, protège les données, limite les modifications aux ressources prévues et définit la récupération avant qu'un incident ne force la décision. Votre futur vous, et votre rotation d'astreinte, vous remercieront.