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

Introduction

Le Vertical Pod Autoscaler (VPA) de Kubernetes ajuste les demandes de CPU et de mémoire des pods en cours d'exécution en fonction de l'utilisation observée. Cela permet de dimensionner correctement les charges de travail, de réduire le gaspillage et d'éviter les arrêts pour mémoire insuffisante. Cependant, les modifications apportées par le VPA peuvent être perturbatrices si elles ne sont pas déployées avec précaution. L'automatisation du VPA avec des pipelines CI/CD vous permet de promouvoir des mises à jour sûres, de valider les changements en staging et de revenir rapidement en arrière lorsqu'une recommandation est erronée ou qu'une charge de travail se comporte de manière inattendue.

Ce guide présente une approche pratique pour intégrer le VPA dans votre flux de travail CI/CD. Vous apprendrez à vérifier la version et la compatibilité de votre cluster, à installer le VPA avec un contrôle de version, à configurer les politiques de mise à jour, à construire un pipeline qui déploie les changements par étapes, à vérifier les ajustements avec des commandes réelles et à récupérer des échecs courants. Les exemples supposent un cluster Kubernetes fonctionnel et utilisent des commandes kubectl et Helm standard.

À la fin, vous disposerez d'un processus reproductible qui limite les risques, utilise des variables d'environnement plutôt que des secrets, et documente les étapes de récupération avant d'en avoir besoin.

Inventaire des versions et de l'environnement

Avant d'automatiser le VPA, confirmez que votre cluster et vos outils le prennent en charge.

Prérequis

• Version de cluster Kubernetes 1.24 ou ultérieure (le VPA est disponible dans toutes les versions prises en charge, mais certaines fonctionnalités évoluent).
• Metrics Server installé et en cours d'exécution (le VPA a besoin de métriques pour faire des recommandations).
• Clients kubectl et helm installés localement.
• Accès au cluster avec l'autorisation de créer des CustomResourceDefinitions (CRD) et des déploiements dans l'espace de noms cible.

Vérifier l'état actuel

Exécutez ces commandes en lecture seule pour capturer l'environnement initial :

kubectl version --short
kubectl get nodes -o wide
kubectl get pods -n kube-system | grep metrics-server

Le résultat attendu est la version de Kubernetes, l'état des nœuds et un pod metrics-server en cours d'exécution. Si metrics-server est absent, installez-le avant le VPA. Par exemple, sur de nombreux clusters :

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Identifier les composants du VPA

Le VPA se compose de trois composants :

• Recommender : observe l'utilisation des ressources des pods et suggère de nouvelles demandes.
• Updater : évince les pods qui ont besoin de nouvelles demandes de ressources (si le mode de mise à jour le permet).
• Admission Controller : définit les demandes de ressources initiales lorsqu'un pod est créé.

Notez les versions exactes que vous prévoyez de déployer. La version stable actuelle du VPA est v1.2.0 (au moment de la rédaction). Vous pouvez vérifier les versions disponibles avec :

helm repo add vpa https://charts.fairwinds.com/stable
helm search repo vpa/vpa --versions

Utilisez une version spécifique plutôt que latest pour la reproductibilité.

Chemin de configuration sûr

Un chemin de configuration sûr signifie commencer par l'observation, appliquer un changement minimal et vérifier avant d'étendre. Pour le VPA, cela se traduit par une installation avec une politique de mise à jour conservatrice, en ciblant une seule charge de travail, et en surveillant le comportement avant une adoption plus large.

Installer le VPA avec Helm

Créez un fichier values.yaml pour remplacer les valeurs par défaut :

recommender:
  enabled: true
updater:
  enabled: true
admissionController:
  enabled: true

Installez avec Helm, en épinglant la version :

helm upgrade --install vpa vpa/vpa --version 1.2.0 -n vpa --create-namespace -f values.yaml

Vérifiez que les trois composants sont en cours d'exécution :

kubectl get pods -n vpa -o wide
kubectl logs -n vpa deployment/vpa-updater --tail=20

Attendez-vous à trois pods avec le statut Running et des journaux montrant que l'updater est connecté au serveur API.

Créer un objet VPA avec un mode de mise à jour conservateur

Commencez par updateMode: Off pour obtenir des recommandations sans apporter de modifications. Pour un déploiement nommé my-app :

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
  namespace: default
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: "*"
      minAllowed:
        cpu: 50m
        memory: 100Mi
      maxAllowed:
        cpu: 2
        memory: 2Gi

Appliquez le VPA :

kubectl apply -f vpa-off.yaml
kubectl get vpa my-app-vpa -o yaml

Vérifiez la section status.recommendation. Elle doit afficher le CPU et la mémoire cibles, mais le pod ne doit pas être redémarré. Exemple de sortie :

status:
  recommendation:
    containerRecommendations:
    - containerName: my-app
      lowerBound:
        cpu: 100m
        memory: 200Mi
      target:
        cpu: 150m
        memory: 300Mi
      upperBound:
        cpu: 1
        memory: 1Gi

Observez pendant quelques heures ou jours avant d'activer les mises à jour.

Vérification et diagnostics

La vérification garantit que le VPA fonctionne et que les changements sont sûrs. Utilisez ces commandes pour inspecter les recommandations, les événements d'éviction et l'utilisation réelle des ressources.

Inspecter les recommandations du VPA

Obtenez la recommandation actuelle avec une sortie lisible :

kubectl describe vpa my-app-vpa

Recherchez le bloc Recommendation. Si la cible est beaucoup plus élevée ou plus basse que les demandes actuelles, examinez la charge de travail.

Vérifiez l'utilisation réelle des ressources des pods :

kubectl top pods -l app=my-app

Comparez les colonnes CPU(cores) et MEMORY(bytes) avec la cible du VPA. Elles doivent être proches si le VPA est précis.

Vérifier les journaux des composants du VPA

Si les recommandations sont absentes, vérifiez les journaux :

kubectl logs -n vpa deployment/vpa-recommender --tail=50
kubectl logs -n vpa deployment/vpa-updater --tail=50

Les erreurs courantes incluent un metrics server non prêt ou des problèmes de permissions. Assurez-vous que le compte de service du VPA a les droits de lire les métriques et les pods.

Valider une étape de pipeline CI/CD

Une étape de pipeline typique pour mettre à jour le VPA dans un flux de travail GitOps serait :

1. Le développeur met à jour le manifeste VPA dans le dépôt.
2. Le CI exécute kubectl apply --dry-run=client -f vpa.yaml pour valider la syntaxe.
3. Si la simulation réussit, le CD applique le manifeste au cluster.
4. Après l'application, exécutez un travail de vérification qui attend que l'objet VPA soit prêt et vérifie les recommandations.

Exemple de travail de vérification utilisant kubectl wait :

kubectl wait --for=condition=Available vpa/my-app-vpa --timeout=60s

Si le VPA n'a pas de condition, utilisez un script personnalisé :

REC=$(kubectl get vpa my-app-vpa -o jsonpath='{.status.recommendation.containerRecommendations[0].target.cpu}')
if [ -z "$REC" ]; then
  echo "Aucune recommandation pour le moment"
  exit 1
else
  echo "Recommandation CPU : $REC"
fi

Cela garantit que le VPA fonctionne avant de promouvoir les changements en production.

Modes de défaillance et récupération

Le VPA peut causer des problèmes s'il est mal configuré ou appliqué de manière trop agressive. Voici les modes de défaillance courants et les étapes de récupération.

Des mises à jour trop agressives provoquent des évictions de pods

Si updateMode: Auto et que l'updater évince trop de pods, cela peut perturber le service. Pour atténuer :

• Utilisez updateMode: Initial ou Recreate uniquement après des tests.
• Limitez la politique de mise à jour avec minReplicas si vous utilisez les contrôles d'éviction de l'updater.
• Définissez maxAllowed pour éviter les changements extrêmes.

Récupération : passez immédiatement à Off :

kubectl patch vpa my-app-vpa --type merge -p '{"spec":{"updatePolicy":{"updateMode":"Off"}}}'

Puis mettez à l'échelle le déploiement pour restaurer les pods :

kubectl scale deployment my-app --replicas=3
kubectl rollout status deployment/my-app

Le VPA recommande des ressources trop faibles

Si le VPA recommande des valeurs trop faibles, le pod peut planter. Observez avec :

kubectl describe pod <nom-du-pod> | tail -20

Recherchez OOMKilled dans le dernier état. Pour corriger, augmentez manuellement les demandes dans le déploiement et ajustez le minAllowed du VPA :

minAllowed:
  cpu: 200m
  memory: 400Mi

Appliquez le changement et redémarrez le pod :

kubectl delete pod <nom-du-pod>

Les composants du VPA échouent

Si les pods du recommender ou de l'updater plantent, vérifiez les journaux et les événements :

kubectl describe pod -n vpa <nom-du-pod>
kubectl logs -n vpa <nom-du-pod> --previous

Causes courantes : permissions insuffisantes, incompatibilité de version d'API ou CRD manquantes. Réinstallez les CRD si nécessaire :

kubectl apply -f https://raw.githubusercontent.com/kubernetes/autoscaler/vpa-release-1.2/vertical-pod-autoscaler/deploy/vpa-v1-crd-gen.yaml

Revenir à l'état précédent

Si un pipeline CI/CD a appliqué un mauvais changement de VPA, revenez en arrière via Git revert :

git revert <hash-du-commit>
git push origin main

Le système CD appliquera le manifeste précédent. Alternativement, appliquez manuellement le dernier VPA connu comme bon :

kubectl apply -f good-vpa.yaml

Vérifiez que l'objet VPA est mis à jour et que les pods sont stables.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle avant et après l'application de changements VPA dans un pipeline CI/CD.

Pour chaque élément de la liste de contrôle, enregistrez l'horodatage, la sortie de la commande et la personne qui l'a exécutée. Cette piste d'audit est essentielle pour le débogage et la conformité.

Conclusion

Automatiser le Vertical Pod Autoscaler de Kubernetes avec CI/CD élimine les approximations et prévient le gaspillage de ressources. Vous devez versionner votre installation VPA, utiliser un mode de mise à jour conservateur au départ, vérifier les recommandations avec kubectl, et avoir un plan de rollback avant d'activer les mises à jour automatiques.

Commencez avec un déploiement à faible risque en mode Off. Observez les recommandations du VPA pendant au moins un cycle d'activité complet. Passez ensuite en mode Auto dans un environnement hors production, testez le pipeline et surveillez les évictions. Ce n'est qu'après cela que vous devriez envisager un déploiement en production avec des stratégies de déploiement progressif.

N'oubliez pas : le VPA est un outil pour vous aider, pas un remplacement de l'alerte et de la planification de capacité. Associez-le au Horizontal Pod Autoscaler si vous avez besoin de faire évoluer les réplicas en fonction de la charge, et gardez toujours les demandes et limites de ressources dans des limites raisonnables.

Un flux de travail technique fiable rend les échecs visibles, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision. Avec les commandes et les exemples de ce guide, vous pouvez construire ce flux de travail pour le VPA dès aujourd'hui.