Sauvegarde et restauration du Horizontal Pod Autoscaler Kubernetes : guide pratique

Introduction

La sauvegarde et la restauration du Horizontal Pod Autoscaler (HPA) Kubernetes sont souvent reléguées au second plan, jusqu'à ce qu'une mauvaise configuration ou une suppression accidentelle impose une reconstruction manuelle. Une approche structurée transforme un problème observé en un résultat vérifié. Ce guide se concentre sur des procédures pratiques et reproductibles pour sauvegarder et restaurer les configurations HPA à travers les clusters et les espaces de noms.

Nous couvrons l'inventaire des versions et de l'environnement, les chemins de configuration sûrs, la vérification et les diagnostics, les modes de défaillance et la récupération, ainsi qu'une liste de contrôle opérationnelle. Chaque section comprend des commandes concrètes, des sorties attendues et des exemples concrets. L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des variables de substitution plutôt que des secrets, vérifier les résultats et documenter la récupération avant qu'un incident ne survienne.

Ce guide s'adresse aux développeurs, consultants DevOps et équipes de startups techniques qui gèrent des charges de travail Kubernetes et souhaitent protéger les configurations d'autoscaling dans le cadre de leur stratégie de reprise après sinistre.

Inventaire des versions et de l'environnement

Avant de sauvegarder ou de restaurer des HPA, vous devez avoir une vision claire de la version de votre cluster, des versions de l'API HPA et des objets HPA actuels. Commencez par des observations en lecture seule.

Identifier les versions de Kubernetes et de l'API HPA

Exécutez les commandes suivantes :

kubectl version --short
kubectl api-versions | grep autoscaling

La sortie attendue comprend des lignes comme :

autoscaling/v1
autoscaling/v2beta2
autoscaling/v2

Depuis Kubernetes 1.23, autoscaling/v2 est stable et prend en charge la mise à l'échelle basée sur des métriques. Si votre cluster n'affiche que autoscaling/v1, vous êtes limité à la mise à l'échelle basée sur le CPU. Cela affecte le format de sauvegarde : les HPA v2 peuvent inclure plusieurs métriques et configurations de comportement non représentables en v1.

Capturer l'inventaire actuel des HPA

Listez tous les HPA dans tous les espaces de noms :

kubectl get hpa --all-namespaces -o wide

Exemple de sortie :

NAMESPACE   NAME          REFERENCE            TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
prod        web-hpa      Deployment/web       cpu: 50%/80%    2         10        4          12d
dev         api-hpa      Deployment/api       memory: 60%     1         5         2          3d

Enregistrez cette sortie avec un horodatage. Pour une sauvegarde complète, exportez chaque HPA en YAML :

kubectl get hpa web-hpa -n prod -o yaml > web-hpa-backup-$(date +%Y%m%d).yaml

Répétez l'opération pour tous les HPA. Conservez ces fichiers dans un système de contrôle de version, pas seulement en local.

Prérequis pour des opérations HPA sûres

• Version de kubectl compatible avec votre cluster (à une version mineure près).
• Permissions pour lire (get, list) les HPA dans les espaces de noms cibles (en lecture seule) et pour créer/mettre à jour lors de la restauration.
• Un emplacement de sauvegarde (dépôt git, stockage d'objets) accessible en cas de sinistre.
• Une compréhension claire des noms de ressources Déploiement ou Pod dépendants, car le HPA les référence par nom.

Plus petit changement justifié

Avant toute tentative de sauvegarde ou de restauration, vérifiez que le HPA cible existe et fonctionne normalement. Utilisez :

kubectl describe hpa web-hpa -n prod

Recherchez des événements comme :

Events:
  Type    Reason             Age   From                       Message
  ----    ------             ----  ----                       -------
  Normal  SuccessfulRescale  10m   horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target

Si aucun événement récent n'apparaît, le HPA peut ne pas être en train de mettre à l'échelle activement. Comparez avec la sortie de kubectl get hpa pour voir les métriques actuelles.

Chemin de configuration sûr

Un chemin de configuration sûr signifie apporter des modifications incrémentales et réversibles aux paramètres du HPA, en s'appuyant sur une version antérieure connue comme bonne.

Sauvegarder avant toute modification

Exportez toujours le manifeste actuel du HPA avant de le modifier. Par exemple :

kubectl get hpa web-hpa -n prod -o yaml > web-hpa-2025-03-15.yaml

Ce fichier est votre point de restauration.

Exemple : Modifier les réplicas min et max

Supposons que vous vouliez augmenter maxReplicas de 10 à 15 pour web-hpa dans prod. Voici un patch minimal :

kubectl patch hpa web-hpa -n prod --patch '{"spec":{"maxReplicas":15}}'

Vérifiez le changement :

kubectl get hpa web-hpa -n prod -o yaml | grep maxReplicas

Sortie attendue :

maxReplicas: 15

Vérifiez que le HPA correspond toujours aux pods du déploiement :

kubectl get pods -l app=web -n prod

Si le HPA tente de mettre à l'échelle au-delà de la capacité du cluster, vous verrez des événements dans kubectl describe hpa indiquant un échec de mise à l'échelle dû à des ressources insuffisantes.

Utiliser kubectl Apply avec un manifeste modifié

Sinon, modifiez le fichier YAML exporté, changez le champ souhaité, puis appliquez :

kubectl apply -f web-hpa-updated.yaml

Conservez toujours le fichier de sauvegarde original intact.

Maintenir un historique versionné

Stockez les manifestes HPA dans git avec des messages de commit significatifs. Par exemple :

git add web-hpa-*.yaml
git commit -m "Backup HPA web-hpa before maxReplicas change to 15"

Cela vous donne une piste d'audit et un retour en arrière facile en utilisant kubectl apply -f avec la version précédente.

Vérification et diagnostics

Après toute modification ou restauration d'un HPA, vérifiez qu'il fonctionne comme prévu. Ne supposez pas le succès à partir du code de sortie de la commande.

Vérifier l'état et les événements du HPA

Exécutez :

kubectl describe hpa web-hpa -n prod

Recherchez les conditions AbleToScale et ScalingActive :

Conditions:
  Type            Status  Reason            Message
  ----            ------  ------            -------
  AbleToScale     True    ReadyForNewScale  recommended size matches current size
  ScalingActive   True    ValidMetricFound  the HPA was able to successfully calculate a replica count from cpu resource utilization

Si ScalingActive est False, vérifiez la raison. Les problèmes courants incluent des métriques manquantes ou des demandes de ressources incorrectes.

Valider les sources de métriques

Pour un HPA basé sur le CPU, assurez-vous que vos pods ont des demandes de CPU définies :

kubectl get deployment web -n prod -o jsonpath='{.spec.template.spec.containers[0].resources}'

La sortie devrait inclure quelque chose comme :

{"requests":{"cpu":"100m"},"limits":{"cpu":"500m"}}

Pour un HPA basé sur la mémoire, vérifiez les demandes de mémoire. Pour les métriques personnalisées, assurez-vous que le serveur de métriques ou l'adaptateur Prometheus fonctionne :

kubectl get pods -n kube-system | grep metrics-server

Simuler une charge pour déclencher la mise à l'échelle

Pour vérifier le comportement de mise à l'échelle de manière contrôlée, augmentez temporairement la charge sur le déploiement. Par exemple, utilisez un outil de génération de charge comme hey ou ab contre un point de terminaison de service. Ensuite, surveillez le HPA :

kubectl get hpa web-hpa -n prod --watch

Après quelques minutes, vous devriez voir REPLICAS augmenter. Ensuite, arrêtez la charge et observez la réduction d'échelle.

Comparer l'état actuel avec la sauvegarde

Après avoir restauré un HPA à partir d'une sauvegarde, comparez le manifeste actuel avec le fichier de sauvegarde :

diff <(kubectl get hpa web-hpa -n prod -o yaml) web-hpa-backup.yaml

Toute différence doit être intentionnelle. C'est une étape de validation cruciale.

Modes de défaillance et récupération

Les HPA peuvent échouer de plusieurs manières. Voici les modes de défaillance courants, comment les détecter et comment récupérer à l'aide de sauvegardes.

Mode de défaillance 1 : Suppression accidentelle d'un HPA

Si quelqu'un exécute kubectl delete hpa web-hpa -n prod, le déploiement continuera de fonctionner avec son nombre actuel de réplicas, mais ne sera plus mis à l'échelle automatiquement.

Détection :

kubectl get hpa -n prod

La sortie ne contient pas web-hpa.

Récupération :

kubectl apply -f web-hpa-backup-2025-03-15.yaml

Vérification :

kubectl get hpa web-hpa -n prod

Mode de défaillance 2 : Le HPA cible un déploiement inexistant

Si le déploiement référencé est supprimé ou renommé, le HPA signalera une erreur de mise à l'échelle.

Détection :

kubectl describe hpa web-hpa -n prod | grep -A5 Events

Recherchez des messages comme :

Warning  FailedGetScale  horizontal-pod-autoscaler  deployments/scale.apps "web" not found

Récupération :

• Restaurez le déploiement s'il a été supprimé.
• Ou mettez à jour le scaleTargetRef du HPA avec le nom correct en utilisant kubectl edit hpa ou un patch.

Mode de défaillance 3 : Configuration de métrique invalide

Si vous modifiez le type de métrique ou spécifiez incorrectement un nom de ressource, le HPA peut échouer à récupérer les métriques.

Détection :

kubectl get hpa web-hpa -n prod -o yaml | grep -A10 status

Recherchez des conditions comme :

conditions:
- type: ScalingActive
  status: "False"
  reason: FailedGetResourceMetric
  message: missing request for cpu

Récupération :

• Assurez-vous que les pods ont des demandes de CPU ou de mémoire comme requis.
• Ou revenez au manifeste de sauvegarde précédent qui fonctionnait.

Mode de défaillance 4 : Conflit du HPA avec le Cluster Autoscaler ou les quotas de ressources

Si le cluster ne peut pas provisionner de nouveaux nœuds ou si un ResourceQuota limite les pods, la mise à l'échelle du HPA échouera.

Détection :

kubectl describe hpa web-hpa -n prod | tail -20

Recherchez des événements FailedRescale :

Warning  FailedRescale  horizontal-pod-autoscaler  New size: 6; reason: exceeded quota in namespace prod

Récupération :

• Ajustez le ResourceQuota ou la capacité des nœuds.
• Ou réduisez temporairement maxReplicas du HPA à un nombre réalisable en utilisant la sauvegarde comme référence.

Procédure générale de récupération

1. Identifiez la défaillance à partir des événements et conditions du HPA.
2. Récupérez la dernière sauvegarde connue comme bonne depuis le contrôle de version.
3. Appliquez la sauvegarde avec kubectl apply -f.
4. Vérifiez avec kubectl get hpa et kubectl describe hpa.
5. Documentez l'incident et la correction.

Liste de contrôle opérationnelle

Utilisez la liste de contrôle suivante avant et après toute sauvegarde, restauration ou modification d'un HPA.

Avant le changement

• [ ] Exécutez kubectl version --short et notez la version du cluster.
• [ ] Exécutez kubectl api-versions | grep autoscaling pour confirmer les versions de l'API HPA prises en charge.
• [ ] Listez tous les HPA : kubectl get hpa --all-namespaces -o wide
• [ ] Exportez le YAML actuel du HPA pour l'espace de noms cible avec un horodatage, par exemple hpa-backup-prod-web-2025-03-15.yaml.
• [ ] Stockez le fichier de sauvegarde dans un dépôt sous contrôle de version.
• [ ] Vérifiez que le déploiement référencé existe et que les pods ont des demandes de ressources si vous utilisez des métriques de ressources.
• [ ] Enregistrez le nombre actuel de réplicas et les métriques.

Pendant le changement

• [ ] Appliquez les modifications avec kubectl apply -f ou kubectl patch, jamais avec une édition en ligne qui contourne la sauvegarde de fichier.
• [ ] Effectuez un seul changement ciblé à la fois (par exemple, uniquement maxReplicas).
• [ ] Notez la commande exacte utilisée et le résultat attendu.

Après le changement ou la restauration

• [ ] Exécutez kubectl get hpa <name> -n <namespace> pour confirmer que l'objet existe.
• [ ] Exécutez kubectl describe hpa <name> -n <namespace> et vérifiez que les conditions AbleToScale=True et ScalingActive=True sont remplies.
• [ ] Vérifiez les événements d'erreur dans la description du HPA.
• [ ] Comparez le manifeste actuel avec la sauvegarde (si restauration).
• [ ] Surveillez au moins un cycle de mise à l'échelle (par exemple, 10 à 15 minutes) pour vous assurer que le HPA peut augmenter et diminuer l'échelle.
• [ ] Si une étape échoue, revenez immédiatement au manifeste de sauvegarde précédent.

Exemple de scénario concret

Voici un exemple complet de sauvegarde et de restauration pour un HPA nommé web-hpa dans l'espace de noms prod.

1. Sauvegarde :

   kubectl get hpa web-hpa -n prod -o yaml > web-hpa-2025-03-15.yaml
   git add web-hpa-2025-03-15.yaml && git commit -m "Backup HPA before change"

1. Effectuez une modification : augmentez minReplicas de 2 à 3.

   kubectl patch hpa web-hpa -n prod --patch '{"spec":{"minReplicas":3}}'

1. Vérifiez l'état immédiat :

   kubectl get hpa web-hpa -n prod -o yaml | grep minReplicas

Attendu : minReplicas: 3

1. Simulez une charge et surveillez la mise à l'échelle :

   kubectl get hpa web-hpa -n prod --watch

1. Si quelque chose ne va pas, revenez en arrière :

   kubectl apply -f web-hpa-2025-03-15.yaml

1. Vérifiez le retour en arrière :

   kubectl get hpa web-hpa -n prod -o yaml | grep minReplicas

Attendu : minReplicas: 2

Conclusion

La sauvegarde et la restauration des HPA Kubernetes sont une partie essentielle des opérations de cluster. En suivant une approche structurée — inventaire des versions, capture des manifestes HPA, modifications petites et réversibles, vérification avec des diagnostics, et un plan de récupération clair — vous pouvez prévenir les pannes d'autoscaling et récupérer rapidement des erreurs.

Stockez toujours les sauvegardes HPA dans un contrôle de version, pas seulement sur un disque local. Testez les procédures de restauration dans un espace de noms hors production avant une panne réelle. Rendez la défaillance visible en surveillant les événements et conditions du HPA. Protégez les valeurs sensibles en utilisant des variables de substitution et des secrets plutôt que de les coder en dur. Limitez les modifications à la ressource prévue et vérifiez les résultats.

Un flux de travail technique fiable rend la défaillance visible, 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. Commencez dès aujourd'hui par une sauvegarde HPA à faible risque, documentez les étapes et assurez-vous que votre équipe sait comment la restaurer.