## 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 : ```bash 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 : ```bash 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 : ```bash 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 : ```bash 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 : ```bash 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 : ```bash kubectl patch hpa web-hpa -n prod --patch '{"spec":{"maxReplicas":15}}' ``` Vérifiez le changement : ```bash kubectl get hpa web-hpa -n prod -o yaml | grep maxReplicas ``` Sortie attendue : ```yaml maxReplicas: 15 ``` Vérifiez que le HPA correspond toujours aux pods du déploiement : ```bash 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 : ```bash 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 : ```bash 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 : ```bash kubectl describe hpa web-hpa -n prod ``` Recherchez les conditions `AbleToScale` et `ScalingActive` : ```yaml 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 : ```bash kubectl get deployment web -n prod -o jsonpath='{.spec.template.spec.containers[0].resources}' ``` La sortie devrait inclure quelque chose comme : ```json {"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 : ```bash 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 : ```bash 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 : ```bash 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 : ```bash kubectl get hpa -n prod ``` La sortie ne contient pas `web-hpa`. Récupération : ```bash kubectl apply -f web-hpa-backup-2025-03-15.yaml ``` Vérification : ```bash 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 : ```bash 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 : ```bash kubectl get hpa web-hpa -n prod -o yaml | grep -A10 status ``` Recherchez des conditions comme : ```yaml 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 : ```bash 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 -n ` pour confirmer que l'objet existe. - [ ] Exécutez `kubectl describe hpa -n ` 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 : ```bash 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" ``` 2. Effectuez une modification : augmentez `minReplicas` de 2 à 3. ```bash kubectl patch hpa web-hpa -n prod --patch '{"spec":{"minReplicas":3}}' ``` 3. Vérifiez l'état immédiat : ```bash kubectl get hpa web-hpa -n prod -o yaml | grep minReplicas ``` Attendu : `minReplicas: 3` 4. Simulez une charge et surveillez la mise à l'échelle : ```bash kubectl get hpa web-hpa -n prod --watch ``` 5. Si quelque chose ne va pas, revenez en arrière : ```bash kubectl apply -f web-hpa-2025-03-15.yaml ``` 6. Vérifiez le retour en arrière : ```bash 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.