Automatiser le Horizontal Pod Autoscaler Kubernetes avec CI/CD : guide pratique

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 :

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 :

kubectl describe hpa <nom-hpa> -n <namespace>

Enregistrez la sortie. Identifiez le déploiement contrôlé par le HPA et son nombre de réplicas actuel :

kubectl get deployment <nom-deploiement> -n <namespace> -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 :

date > hpa_baseline.txt
kubectl get hpa -n <namespace> -o yaml >> hpa_baseline.txt
kubectl get deployment <nom-deploiement> -n <namespace> -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 :

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 :

kubectl apply -f webapp-hpa.yaml --dry-run=client

Si aucune erreur, appliquez au staging :

kubectl apply -f webapp-hpa.yaml -n staging

Surveillez ensuite l'état du HPA :

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 <unknown>. 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 :

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 :

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 :

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 <unknown> 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 :

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 :

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 :

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.

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.