## Introduction Le Horizontal Pod Autoscaler (HPA) de Kubernetes ajuste dynamiquement le nombre de réplicas de pods dans un Deployment, StatefulSet ou autre charge de travail en fonction de l'utilisation du CPU, de la mémoire ou de métriques personnalisées. Automatiser la configuration du HPA via des pipelines CI/CD garantit que le comportement de mise à l'échelle automatique est versionné, testé et appliqué de manière cohérente dans tous les environnements. Ce guide présente les étapes pratiques pour automatiser les manifestes HPA, les valider dans la CI, les déployer sur Kubernetes et récupérer des échecs courants. Le public cible comprend les ingénieurs DevOps, les équipes plateforme et les développeurs qui gèrent des clusters Kubernetes en production. Avant d'effectuer des modifications, comprenez votre environnement actuel : version de Kubernetes, version de l'API HPA, disponibilité du metrics-server et objets HPA existants. Observez toujours l'état actuel, apportez des modifications petites et réversibles, puis vérifiez le résultat avant de continuer. Les exemples utilisent `kubectl`, `jq` et des outils CI courants comme GitHub Actions ou GitLab CI, mais les concepts s'appliquent à tout pipeline. ## Inventaire des versions et de l'environnement Déterminez d'abord la version de votre cluster Kubernetes et la version de l'API HPA à utiliser. Le HPA est disponible dans `autoscaling/v1` (CPU uniquement) et `autoscaling/v2` (prend en charge les métriques personnalisées et multiples). La plupart des clusters modernes utilisent `autoscaling/v2`. Exécutez les commandes en lecture seule suivantes pour recueillir des informations : ```bash kubectl version --short kubectl api-versions | grep autoscaling kubectl get hpa --all-namespaces kubectl get metrics-server --all-namespaces ``` La sortie attendue pour `kubectl api-versions` inclut `autoscaling/v1` et `autoscaling/v2beta2` ou `autoscaling/v2`. Si le metrics-server n'est pas en cours d'exécution, le HPA ne peut pas se mettre à l'échelle sur le CPU ou la mémoire. Installez-le si nécessaire, mais notez que le HPA basé sur des métriques personnalisées peut nécessiter Prometheus ou d'autres adaptateurs. Vérifiez les objets HPA actuels avec leurs cibles et métriques actuelles : ```bash kubectl describe hpa -n ``` Enregistrez la sortie. Identifiez le déploiement contrôlé par le HPA et son nombre de réplicas actuel : ```bash kubectl get deployment -n -o wide ``` Comprendre la base de référence vous permet de détecter les modifications non intentionnelles après l'application de nouvelles configurations HPA. Conservez un fichier texte local avec ces sorties pour une comparaison ultérieure. Utilisez des horodatages : ```bash date > hpa_baseline.txt kubectl get hpa -n -o yaml >> hpa_baseline.txt kubectl get deployment -n -o jsonpath='{.spec.replicas}' >> hpa_baseline.txt ``` Vous disposez maintenant d'un instantané. Ne procédez à la modification du HPA qu'après avoir confirmé les prérequis : le cluster prend en charge la version HPA prévue, la source de métriques fonctionne et vous avez la permission de créer/mettre à jour des objets HPA. ## Chemin de configuration sûr Considérez la configuration HPA comme du code stocké dans votre dépôt Git. Le chemin sûr consiste à gérer les manifestes HPA sous contrôle de version, à examiner les modifications via des pull requests et à les appliquer via des pipelines CI/CD. Commencez par un manifeste HPA existant ou créez-en un nouveau. Voici un exemple utilisant `autoscaling/v2` basé sur le CPU et la mémoire : ```yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: webapp-hpa namespace: production spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: webapp minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 70 behavior: scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 50 periodSeconds: 60 scaleUp: stabilizationWindowSeconds: 60 policies: - type: Pods value: 2 periodSeconds: 60 - type: Percent value: 50 periodSeconds: 60 selectPolicy: Max ``` Ce HPA garantit que le déploiement webapp a entre 2 et 10 réplicas, ciblant 60 % d'utilisation CPU et 70 % d'utilisation mémoire. Il monte en charge rapidement (jusqu'à 2 pods ou 50 % des réplicas actuels chaque minute) et réduit plus prudemment (50 % chaque minute après une fenêtre de stabilisation de 5 minutes). Pour tester en toute sécurité, appliquez d'abord le HPA à un namespace de staging ou à un cluster. Utilisez `kubectl apply --dry-run=client` pour valider la syntaxe sans appliquer : ```bash kubectl apply -f webapp-hpa.yaml --dry-run=client ``` Si aucune erreur, appliquez au staging : ```bash kubectl apply -f webapp-hpa.yaml -n staging ``` Surveillez ensuite l'état du HPA : ```bash kubectl get hpa webapp-hpa -n staging --watch ``` Observez la colonne TARGETS qui finit par afficher `50%/60%, 60%/70%` (utilisation actuelle / cible). Si les métriques ne sont pas disponibles, elle peut afficher ``. Examinez les problèmes de metrics-server ou d'adaptateur. Ce n'est qu'après que le comportement de staging correspond aux attentes que vous pouvez promouvoir en production via la CI/CD. ## Intégration au pipeline CI/CD Automatisez le déploiement HPA à l'aide d'un pipeline CI/CD. Le pipeline doit : - Valider la syntaxe YAML du HPA - Exécuter un dry-run sur le cluster cible - Appliquer le HPA au cluster - Vérifier l'état et les métriques du HPA - Effectuer un rollback en cas d'échec Exemple de workflow GitHub Actions : ```yaml name: Deploy HPA on: push: paths: - 'hpa/**' branches: [ main ] jobs: deploy-hpa: runs-on: ubuntu-latest environment: production steps: - name: Checkout code uses: actions/checkout@v4 - name: Setup kubectl uses: azure/setup-kubectl@v3 with: version: 'v1.28.0' - name: Set up kubeconfig run: | mkdir -p $HOME/.kube echo "${{ secrets.KUBE_CONFIG }}" > $HOME/.kube/config - name: Validate HPA manifests run: | for file in hpa/*.yaml; do kubectl apply -f $file --dry-run=client if [ $? -ne 0 ]; then echo "Validation failed for $file" exit 1 fi done - name: Apply HPA run: kubectl apply -f hpa/ - name: Verify HPA status run: | sleep 30 kubectl get hpa -n production -o yaml | tee /tmp/hpa_status.yaml # Check that HPA has metrics and is not in error state if kubectl get hpa -n production -o jsonpath='{.items[?(@.metadata.name=="webapp-hpa")].status.conditions[?(@.type=="AbleToScale")].status}' | grep -q False; then echo "HPA unable to scale; rolling back" kubectl rollout undo deployment/webapp -n production exit 1 fi ``` Ce pipeline applique le HPA, attend 30 secondes et vérifie une condition. Si la mise à l'échelle n'est pas possible, il annule le déploiement (bien que le rollback du HPA soit séparé ; voir Modes de défaillance). Meilleure vérification : vérifiez que le HPA a des métriques actuelles dans un délai raisonnable. Par exemple : ```bash kubectl get hpa webapp-hpa -n production -o jsonpath='{.status.currentMetrics}' | jq . ``` Attendez-vous à une liste non vide de valeurs de métriques. ## Vérification et diagnostics Après le déploiement, vérifiez que le HPA fonctionne correctement. Commandes clés : ```bash kubectl describe hpa webapp-hpa -n production ``` Recherchez les événements indiquant une mise à l'échelle réussie ou des erreurs. Problèmes courants : - **Métriques non disponibles** : L'état du HPA affiche `` pour les cibles. Cause : metrics-server non en cours d'exécution ou pas de trafic. Correctif : installer/vérifier le metrics-server, générer de la charge. - **Le HPA ne peut pas récupérer les métriques de ressource** : Vérifiez si les demandes de ressources sont définies sur les pods. Le HPA utilise les demandes pour le pourcentage d'utilisation. Sans demandes, l'utilisation du CPU ne peut pas être calculée. - **La montée en charge ne se produit pas** : Vérifiez les `status.conditions` du HPA pour `ScalingActive` ou `ScalingLimited`. Utilisez `kubectl get hpa -o yaml` pour inspecter. - **La réduction est trop lente** : Ajustez les politiques `behavior.scaleDown`. Générez une charge de test pour déclencher la mise à l'échelle. Par exemple, en utilisant un générateur de charge simple : ```bash kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://webapp-service; done" ``` Ensuite, surveillez le HPA : ```bash kubectl get hpa webapp-hpa -n production --watch ``` Vous devriez voir les métriques actuelles dépasser les cibles et le nombre de réplicas augmenter. Attendez puis arrêtez la charge ; le nombre de réplicas devrait éventuellement diminuer après la fenêtre de stabilisation. Utilisez `kubectl top pods` pour voir l'utilisation réelle des ressources : ```bash kubectl top pods -n production -l app=webapp ``` Si le metrics-server n'est pas installé, `kubectl top` échoue. ## Modes de défaillance et récupération Défaillances courantes du HPA et comment récupérer : 1. **Configuration HPA invalide** : Erreurs de syntaxe ou référence à un déploiement inexistant. Récupération : exécutez `kubectl apply --dry-run=client` avant d'appliquer. Si déjà appliqué, corrigez le manifeste et réappliquez. 2. **Le HPA passe à zéro ou au maximum de manière inattendue** : En raison de seuils de métriques incorrects ou de demandes de ressources manquantes. Récupération : ajustez les seuils, définissez des min/max appropriés et vérifiez les demandes de ressources. 3. **Le HPA ne se met pas à l'échelle en raison d'une panne du metrics-server** : Récupération : corrigez le metrics-server, puis le HPA reprend son fonctionnement normal. 4. **Annulation des modifications du HPA** : Comme le HPA ne fait pas partie du rollout du Deployment, `kubectl rollout undo` ne restaure pas le HPA. Au lieu de cela, maintenez les manifestes HPA dans Git et annulez le commit/PR. Réappliquez ensuite la configuration HPA précédente. 5. **Le HPA entre en conflit avec la mise à l'échelle manuelle** : Si vous définissez manuellement `kubectl scale deployment`, le HPA peut le remplacer. Évitez la mise à l'échelle manuelle ou suspendez temporairement le HPA en définissant `minReplicas` et `maxReplicas` au nombre souhaité. Vérification de la récupération : après correction, vérifiez que `kubectl get hpa` affiche les cibles attendues et que `kubectl describe hpa` ne montre aucun événement d'erreur. Confirmez également que le nombre de pods correspond aux attentes. ## Pièges courants Voici les pièges rencontrés par de nombreuses équipes : - **Ne pas définir les demandes de ressources sur les pods** : Le HPA ne peut pas calculer les pourcentages d'utilisation. Définissez toujours des demandes pour les conteneurs. Sinon, le HPA signale des cibles inconnues. - **Utiliser uniquement le CPU** : Des métriques basées sur la mémoire ou personnalisées peuvent être nécessaires. Envisagez d'utiliser plusieurs métriques. - **Ignorer les fenêtres de stabilisation** : Sans stabilisation, le flapping du HPA peut provoquer des montées/descentes rapides. Utilisez `behavior` pour stabiliser. - **Coder en dur le namespace dans les manifestes** : Utilisez des modèles (Helm, Kustomize) pour paramétrer le namespace et d'autres valeurs. - **Pas de validation CI/CD** : Appliquer manuellement le HPA conduit à des dérives. Intégrez la validation et le déploiement dans le pipeline. - **Oublier de vérifier la version du cluster** : Les fonctionnalités HPA `v2` peuvent ne pas être disponibles dans les Kubernetes plus anciens. Assurez-vous que le cluster prend en charge la version d'API souhaitée. - **Ne pas surveiller les événements HPA** : Configurez des alertes pour les conditions d'échec du HPA. Pour éviter : incluez les manifestes HPA dans la revue de code, automatisez les tests et surveillez les métriques. ## Liste de contrôle opérationnelle Utilisez cette liste de contrôle pour chaque déploiement ou mise à jour HPA. Attribuez un responsable unique par élément et suivez la réalisation. | # | Tâche | Commande / Outil | Résultat attendu | Responsable | Fréquence de revue | |---|------|----------------|-----------------|-------|----------------| | 1 | Vérifier les versions de Kubernetes et de l'API HPA | `kubectl version`, `kubectl api-versions` | Cluster >=1.23, `autoscaling/v2` disponible | Ingénieur plateforme (ex. Alex Chen) | Trimestrielle | | 2 | Vérifier que le metrics-server est en cours d'exécution | `kubectl get pods -n kube-system \| grep metrics-server` | Pod metrics-server en cours d'exécution | Ingénieur plateforme | Mensuelle | | 3 | Valider la syntaxe du manifeste HPA | `kubectl apply -f hpa.yaml --dry-run=client` | Aucune erreur | Responsable DevOps (ex. Maria Garcia) | À chaque PR | | 4 | Appliquer le HPA au staging | `kubectl apply -f hpa.yaml -n staging` | HPA créé | Responsable DevOps | À chaque PR | | 5 | Vérifier les métriques HPA dans le staging | `kubectl describe hpa -n staging` | Les métriques actuelles affichent des valeurs | Responsable DevOps | Après application | | 6 | Générer un test de charge | `kubectl run load-generator ...` | Le HPA monte en charge | Ingénieur QA (ex. John Smith) | Hebdomadaire | | 7 | Promouvoir en production via le pipeline | `git push` (CI/CD) | Le pipeline réussit | Responsable DevOps | À chaque release | | 8 | Vérifier le HPA en production | `kubectl get hpa -n production` | Les cibles ne sont pas `` | Responsable DevOps | Immédiatement après le déploiement | | 9 | Surveiller les événements/alertes HPA | Alertes Prometheus/Grafana | Aucune alerte critique | SRE (ex. Emily Johnson) | Continue | | 10 | Documenter les modifications HPA dans le runbook | Wiki d'équipe | Runbook mis à jour | Rédacteur technique (ou DevOps) | Après chaque modification | Chaque élément doit être revu comme indiqué. Par exemple, l'ingénieur plateforme revoit la compatibilité des versions d'API trimestriellement ou lors d'une mise à niveau du cluster. ## Conclusion Automatiser le HPA Kubernetes avec la CI/CD apporte cohérence et sécurité à la configuration de la mise à l'échelle automatique. En suivant les pratiques décrites—inventaire des versions, chemins de configuration sûrs, intégration au pipeline, vérification et récupération—vous pouvez éviter les pièges courants et maintenir une mise à l'échelle automatique fiable. Commencez par une vérification à faible risque : choisissez un HPA existant, enregistrez son état actuel, exécutez un dry-run sur une copie avec une modification mineure et observez l'impact dans un environnement de staging. À mesure que la confiance augmente, intégrez-le à votre pipeline et étendez-le à d'autres charges de travail. N'oubliez pas : la sécurité opérationnelle signifie observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés pour les secrets, vérifier les résultats et documenter les étapes de récupération avant qu'elles ne soient nécessaires.