Vertical Pod Autoscaler

Mise à jour : 29/03/2025

Après avoir vu le Horizontal Pod Autoscaler (HPA), qui ajuste dynamiquement le nombre de pods en fonction de la charge, il est temps de découvrir le Vertical Pod Autoscaler (VPA). Ce mécanisme ajuste automatiquement les ressources CPU et mémoire allouées aux conteneurs en se basant sur leur consommation réelle. Contrairement au HPA, le VPA ne scale pas horizontalement mais adapte chaque pod individuellement. C’est une solution idéale pour éviter le gaspillage de ressources ou les limitations de performance. À mon avis, c’est un outil à ne pas négliger pour affiner l’allocation des ressources dans un cluster Kubernetes.

Présentation du Vertical Pod Autoscaler (VPA)

Le Vertical Pod Autoscaler, ou VPA, est un composant de Kubernetes conçu pour ajuster automatiquement les demandes et limites en CPU et en mémoire des conteneurs. Il se base sur l’analyse de leur consommation réelle pour proposer ou appliquer des modifications.

Le fonctionnement est simple : le VPA observe comment chaque pod utilise ses ressources sur la durée, puis il émet des recommandations pour optimiser cette allocation. Ces recommandations peuvent ensuite être appliquées automatiquement, manuellement, ou simplement consultées sans action directe.

Le but principal du VPA est de garantir que les conteneurs disposent des ressources suffisantes pour bien fonctionner, sans pour autant être surprovisionnés. Cela permet de réduire les coûts liés à l’infrastructure tout en maintenant un niveau de performance optimal.

Il existe plusieurs cas où l’usage du VPA est particulièrement pertinent :

Pour les applications à charge stable (comme les batchs ou les workers).
Pour démarrer une application sans savoir encore quelles ressources lui attribuer.
Pour détecter les goulots d’étranglement dus à une sous-allocation.

À mon avis, le VPA est surtout utile lorsqu’on cherche à rationaliser les ressources d’un cluster et qu’on veut automatiser ce qui est souvent une tâche manuelle et fastidieuse. Pour les clusters complexes, il peut devenir un allié précieux dans la gestion fine des performances.

Différences entre VPA et HPA

Il est fréquent de confondre le Vertical Pod Autoscaler (VPA) avec le Horizontal Pod Autoscaler (HPA), car tous deux sont conçus pour adapter dynamiquement les ressources dans Kubernetes. Pourtant, leur approche est fondamentalement différente.

Le HPA ajuste le nombre de pods d’un déploiement en fonction de métriques comme l’utilisation du CPU, de la mémoire ou d’autres indicateurs personnalisés. Il est particulièrement efficace pour les applications scalables horizontalement, comme les APIs web ou les services frontend qui doivent encaisser des pics de trafic soudains.

À l’inverse, le VPA ajuste les ressources allouées à chaque pod (CPU et mémoire), sans changer leur nombre. Il agit sur les valeurs de requests et limits définies dans les spécifications des conteneurs. Cela permet d’optimiser l’usage des ressources à l’intérieur d’un pod unique.

Voici un petit résumé comparatif :

Caractéristique	HPA	VPA
Type d’autoscaling	Horizontal (nb de pods)	Vertical (ressources par pod)
Métriques utilisées	CPU, mémoire, metrics custom	Historique d’utilisation
Action principale	Ajoute/retire des pods	Modifie les requests/limits
Cas d’usage	Charges variables et scalables	Charges stables ou prédictibles
Redémarrage des pods	Non	Oui, si modification appliquée

À mon avis, le choix entre HPA et VPA ne devrait pas être exclusif. Les deux peuvent coexister, mais avec certaines précautions. Il est notamment déconseillé d’utiliser le VPA en mode automatique avec le HPA sur la même ressource, car leurs ajustements peuvent entrer en conflit. Une solution consiste à utiliser le VPA uniquement pour la phase d’observation et de recommandation, et d’appliquer ensuite les valeurs manuellement.

Composants du VPA

Le Vertical Pod Autoscaler repose sur trois composants clés qui travaillent ensemble pour surveiller, recommander et appliquer les ajustements de ressources aux pods. Chacun joue un rôle bien défini dans le processus d’autoscaling vertical.

1. Recommender

C’est le cerveau du VPA. Il analyse l’historique d’utilisation des ressources (CPU et mémoire) pour chaque conteneur, puis calcule les valeurs optimales pour les champs requests et limits. Ces recommandations sont mises à jour régulièrement, en fonction des données collectées par metrics-server.

Le Recommender ne modifie pas les pods directement, il se contente de générer des suggestions.

2. Updater

C’est ce composant qui applique les recommandations… mais pas n’importe comment. Il surveille les pods existants et vérifie si leurs spécifications sont cohérentes avec les recommandations du Recommender. Si ce n’est pas le cas, il peut décider de supprimer un pod, pour que Kubernetes en recrée un nouveau avec les bonnes ressources.

À noter : cette suppression n’est possible que si la politique de mise à jour du VPA le permet (on y reviendra plus tard).

3. Admission Controller

Il intervient au moment de la création d’un nouveau pod. Lorsqu’un pod est lancé, l’Admission Controller intercepte sa requête et injecte les ressources recommandées dans la définition du conteneur, en s’appuyant sur les calculs du Recommender.

Ce mécanisme évite de redémarrer des pods existants, puisque les nouveaux pods démarrent directement avec les bonnes ressources.

Ces trois composants permettent au VPA de fonctionner de manière fluide et adaptable. À mon avis, c’est cette architecture modulaire qui rend le VPA aussi souple : on peut l’utiliser uniquement pour observer, ou aller jusqu’à une application automatique des ressources selon le besoin.

Modes de fonctionnement du VPA

Le Vertical Pod Autoscaler offre plusieurs modes de fonctionnement, qu’on peut définir grâce au champ updatePolicy dans l’objet VPA. Ces modes déterminent comment (et si) les recommandations seront appliquées aux pods.

1. Auto

Dans ce mode, le VPA applique automatiquement les recommandations de ressources en redémarrant les pods si nécessaire. C’est le mode le plus « autonome » : dès qu’un écart est détecté entre la configuration actuelle et la recommandation, l’Updater supprime le pod concerné pour qu’il soit relancé avec les nouvelles valeurs.

Ce mode convient aux applications stateless ou tolérantes aux redémarrages.

2. Recreate

Ce mode est similaire à Auto, mais il suppose que les pods sont manuellement supprimés par un autre processus (comme un pipeline de déploiement). Le VPA ne déclenche pas lui-même la recréation des pods, mais applique les nouvelles valeurs lors du redémarrage.

Pratique pour les déploiements contrôlés ou planifiés, notamment en production.

3. Initial

Le VPA applique les recommandations seulement lors de la création initiale d’un pod. Ensuite, il n’intervient plus. Cela permet d’éviter les redémarrages automatiques tout en bénéficiant de recommandations dès le départ.

Ce mode est utile pour fixer une baseline intelligente à la création des pods, sans modifier le comportement en cours de route.

4. Off

C’est le mode d’observation. Le VPA ne change rien mais continue de collecter des métriques et de produire des recommandations. C’est le mode idéal pour la phase d’analyse, ou si l’on souhaite appliquer manuellement les ressources via des mises à jour YAML.

Je trouve ce mode particulièrement intéressant pour tester le VPA sans impact sur la production.

Voici un résumé rapide :

Mode	Applique les recommandations ?	Redémarre les pods ?
Auto	Oui	Oui
Recreate	Oui (à la recréation)	Non
Initial	Oui (à la création)	Non
Off	Non	Non

Le choix du mode dépend vraiment du type d’application et de sa tolérance aux interruptions. À mon avis, commencer en mode Off est souvent une bonne approche pour comprendre le comportement du VPA avant d’activer des actions automatiques.

Guide pratique : Configuration du VPA

Mettre en place le Vertical Pod Autoscaler dans un cluster Kubernetes est assez simple, à condition de suivre les bonnes étapes. Voici un guide pas à pas pour l’installer, le configurer et commencer à exploiter ses recommandations.

1. Prérequis

Avant de commencer, assurez-vous d’avoir :

Un cluster Kubernetes opérationnel (local ou cloud).
Les droits d’accès nécessaires pour déployer des ressources (CRDs, pods, etc.).
Le metrics-server installé et fonctionnel, car le VPA en dépend pour collecter les métriques d’utilisation des ressources.
Un déploiement existant sur lequel appliquer le VPA (par exemple, une application web, un worker, etc.).

2. Installer le VPA

Le VPA n’est pas inclus par défaut dans Kubernetes, il faut donc le déployer manuellement. Voici les commandes à exécuter :

kubectl apply -f https://github.com/kubernetes/autoscaler/releases/latest/download/vertical-pod-autoscaler-crd.yaml
kubectl apply -f https://github.com/kubernetes/autoscaler/releases/latest/download/vertical-pod-autoscaler.yaml

Ces deux fichiers déploient les Custom Resource Definitions (CRDs) ainsi que les composants principaux : Recommender, Updater et Admission Controller.

Assurez-vous que metrics-server est déjà déployé dans le cluster, car le VPA en dépend pour collecter les métriques.

2. Créer un objet VPA

Voici un exemple minimal d’objet VPA à appliquer à un déploiement nommé mon-app :

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: mon-app-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
    name:       mon-app
  updatePolicy:
    updateMode: "Off"  # Peut être "Auto", "Initial", "Recreate"

Ce fichier YAML indique au VPA de cibler un déploiement existant, mais sans appliquer automatiquement les recommandations (mode Off).

3. Vérifier les recommandations

Une fois le VPA déployé et configuré, vous pouvez consulter les recommandations via :

kubectl describe vpa mon-app-vpa

Dans la section Recommendation, vous verrez les valeurs suggérées pour cpu et memory, comme :

Recommendation:
  Container Recommendations:
    Container Name:  mon-container
    Lower Bound:
      Cpu:     50m
      Memory:  100Mi
    Target:
      Cpu:     200m
      Memory:  256Mi
    Upper Bound:
      Cpu:     500m
      Memory:  512Mi

Ces données vous permettent d’ajuster manuellement vos ressources, ou de passer en mode automatique une fois que vous êtes prêt.

À mon avis, la configuration en mode Off est idéale pour une phase d’observation. Elle permet de prendre confiance dans les recommandations du VPA avant de l’autoriser à modifier les pods en production.

Avantages et limitations du VPA

Le Vertical Pod Autoscaler apporte des bénéfices clairs en matière d’optimisation des ressources, mais il n’est pas exempt de contraintes. Avant de l’adopter, il est essentiel d’en connaître les forces et les faiblesses, pour l’utiliser à bon escient.

Avantages du VPA

Optimisation automatique des ressources : le VPA ajuste les valeurs de requests et limits en fonction de l’usage réel, évitant les surestimations ou sous-estimations.
Réduction du gaspillage : en ajustant précisément les ressources, on limite la sur-allocation et donc les coûts associés, notamment sur les clusters cloud.
Simplicité de configuration initiale : il peut fournir une baseline intelligente pour les pods nouvellement créés, même sans connaissances précises sur les besoins de l’application.
Suivi précis des performances : le mode Off permet de récolter des données sur la consommation réelle, utile pour l’audit ou le tuning manuel.
Complémentarité avec le Cluster Autoscaler : en ajustant les besoins réels, il aide indirectement à libérer ou réattribuer des nœuds plus efficacement.

Limitations du VPA

Redémarrage obligatoire des pods : sauf en mode Initial ou Off, l’application des recommandations nécessite souvent un redémarrage, ce qui peut impacter la disponibilité.
Incompatibilité avec le HPA sur les mêmes ressources : le HPA et le VPA peuvent entrer en conflit, car ils essaient tous deux d’ajuster les paramètres dynamiquement. Il est déconseillé de les utiliser ensemble pour les mêmes métriques (cpu, memory).
Moins adapté aux charges fluctuantes : contrairement au HPA, le VPA ne répond pas en temps réel aux pics de charge courts. Il s’appuie sur une analyse historique, ce qui le rend moins réactif.
Nécessite des outils de collecte métrique : le VPA dépend de la présence de metrics-server, ce qui peut nécessiter une configuration préalable dans certains clusters.

À mon avis, le VPA est un excellent outil pour rationaliser les ressources dans un cluster Kubernetes, notamment pour les charges prédictibles ou constantes. Mais il faut bien en comprendre les limites pour l’intégrer intelligemment, sans risquer de perturber les déploiements ou de provoquer des effets de bord.

Contrôle de connaissances

Pourquoi ce contrôle ?

Cet contrôle va vous permettre de valider vos connaissances sur le sujet abordé dans le guide. Il comporte des QCM, des questions vrai/faux et des réponses ouvertes à un mot.

🕒 Le chronomètre commence dès que vous cliquez sur Démarrer le test. Vous devrez terminer l’examen avant la fin du temps imparti.

🎯 Pour réussir, vous devez obtenir au moins 90% de bonnes réponses.

💡 Je ne fournis pas directement les réponses aux questions. Cependant, si certaines sont complexes, des pistes d’explication pourront être proposées dans le guide ou après l’examen.

Bonne chance ! 🚀

Conclusion

Le Vertical Pod Autoscaler s’impose comme un allié précieux pour gérer finement les ressources dans un cluster Kubernetes. Là où le HPA agit sur la scalabilité horizontale, le VPA complète le tableau en assurant une allocation verticale intelligente, en fonction de la consommation réelle des conteneurs.

Il offre un vrai confort pour :

Éviter les surprovisionnements coûteux,
Réduire les redémarrages dus à un manque de mémoire ou de CPU,
Et surtout, pour automatiser une tâche souvent empirique et fastidieuse.

À mon avis, le VPA est un outil que tout administrateur ou ingénieur DevOps devrait tester. Il ne remplace pas les autres mécanismes d’autoscaling, mais les renforce intelligemment. En commençant par une phase d’observation, on peut en tirer des bénéfices rapidement, sans risque pour la production.

Plus d’infos

documentation officielle ↗