Vertical Pod Autoscaler

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	Selon le mode, voir plus bas

Glissez pour voir

À 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. Recreate, le mode par défaut

C'est le mode appliqué si vous ne déclarez rien. Le VPA affecte les ressources à la création du pod et met à jour les pods existants en les évinçant dès que l'écart avec la recommandation devient significatif, en respectant les PodDisruptionBudgets s'il en existe.

La documentation amont conseille de l'utiliser rarement, et uniquement si vous avez besoin que les pods redémarrent à chaque changement de ressources.

2. InPlace et InPlaceOrRecreate, sans éviction

Ce sont les modes à viser aujourd'hui, et ils s'appuient sur une capacité devenue standard dans Kubernetes : le redimensionnement d'un conteneur à chaud, sans le recréer. Ils diffèrent sur ce qu'ils font en cas d'échec.

InPlaceOrRecreate tente le redimensionnement à chaud et, s'il n'aboutit pas, bascule sur l'éviction. InPlace ne bascule jamais : si l'opération est impossible pour l'instant, il réessaiera plus tard quand les conditions du cluster auront changé. C'est le mode recommandé quand aucune interruption n'est acceptable.

3. Auto, déprécié

Historiquement le mode « autonome », Auto est aujourd'hui équivalent à Recreate et marqué déprécié : il sera retiré d'une future version de l'API. Vous le rencontrerez dans des manifestes existants et dans beaucoup de tutoriels ; remplacez-le par le mode explicite qui correspond à votre besoin.

4. 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.

5. 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	Met à jour les pods existants ?	Les évince ?
Recreate (défaut)	Oui	Oui
InPlaceOrRecreate	Oui	Seulement si le redimensionnement à chaud échoue
InPlace	Oui	Jamais, il réessaie plus tard
Initial	Non, uniquement à la création	Non
Off	Non, il se contente de recommander	Non
Auto (déprécié)	Oui, équivalent à Recreate	Oui

Glissez pour voir

La colonne qui compte est la seconde. C'est elle qui décide si le VPA est utilisable sur une application qui ne tolère pas d'interruption, et c'est elle qui a changé avec l'arrivée des deux modes en place.

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

• L'éviction n'est plus obligatoire, mais elle reste le défaut : le mode Recreate, appliqué si vous ne déclarez rien, évince les pods pour appliquer une nouvelle recommandation. Les modes InPlace et InPlaceOrRecreate y échappent, mais il faut les demander explicitement et disposer d'une version du VPA qui les propose.

• 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.

Le redimensionnement à chaud, éprouvé

Les deux modes sans éviction reposent sur une capacité du kubelet, pas du VPA : depuis Kubernetes 1.35, le redimensionnement d'un conteneur en cours d'exécution est stable et activé par défaut. Vous pouvez le déclencher à la main, sans VPA, et c'est le meilleur moyen de comprendre ce que les modes en place automatisent.

Le conteneur doit d'abord déclarer qu'il accepte d'être redimensionné sans redémarrer, par un resizePolicy :

pod-redimensionnable.yaml

apiVersion: v1
kind: Pod
metadata:
  name: redim
spec:
  containers:
    - name: app
      image: nginx:1.30@sha256:d5792f71a9496b833bc08ea834a758c46e2b6a6306c10f4be926f38a656cdc1c
      resizePolicy:
        - resourceName: cpu
          restartPolicy: NotRequired
        - resourceName: memory
          restartPolicy: NotRequired
      resources:
        requests: {cpu: "50m", memory: "64Mi"}
        limits:   {cpu: "100m", memory: "128Mi"}

La modification passe par une sous-ressource dédiée, resize, et non par un kubectl apply ordinaire :

kubectl patch pod redim --subresource resize \
  --patch '{"spec":{"containers":[{"name":"app","resources":{
    "requests":{"cpu":"200m","memory":"256Mi"},
    "limits":{"cpu":"400m","memory":"512Mi"}}}]}}'

Sortie

pod/redim patched

Le résultat est vérifiable sur trois plans, et c'est ce triplet qui prouve qu'il ne s'agit pas d'une recréation déguisée :

kubectl get pod redim -o jsonpath='{.status.containerStatuses[0].restartCount}{"\n"}{.metadata.uid}{"\n"}'
kubectl exec redim -- cat /sys/fs/cgroup/memory.max

Sortie

0
db876d78-f110-4163-a112-e2665db0f53d
536870912

Le compteur de redémarrages reste à zéro, l'uid du pod est inchangé, et le conteneur voit sa limite mémoire passer de 134217728 octets, soit 128 Mio, à 536870912, soit 512 Mio. Le processus n'a jamais été interrompu.

Un détail d'usage qui coûte du temps : le patch doit être stratégique, la forme par défaut. Avec --type=merge, le tableau containers est remplacé en entier au lieu d'être fusionné, et l'API refuse avec un message déroutant, only cpu and memory resources are mutable, alors que vous n'avez touché qu'à ces deux-là.

Contrôle de connaissances

Sept questions sur ce qui a changé récemment et que beaucoup de tutoriels n'intègrent pas encore : quel mode s'applique si vous n'en déclarez aucun, lequel évince vos Pods, et lequel ne les évince jamais.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

90% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

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

×

📖 Voir la documentation →