Vertical Pod Autoscaler (VPA) dans Kubernetes : Guide complet de A à Z

1. Introduction

Depuis ses débuts en 2014, Kubernetes a radicalement transformé le déploiement des applications. Cependant, un défi majeur a rapidement émergé : comment attribuer automatiquement la juste quantité de CPU et de mémoire à chaque conteneur ?

La plupart des équipes DevOps procédaient par estimations empiriques :

resources:
  requests:
    cpu: "200m"
    memory: "256Mi"

Cette approche statique mène fréquemment à :

• CPU trop faible → Ralentissements et “throttling” des performances.
• Mémoire trop faible → Pods terminés par OOMKilled.
• CPU trop élevé → Gaspillage de ressources.
• Mémoire trop élevée → Moins de Pods par nœud, coûts cloud superflus.

C’est pour répondre à ce besoin d’optimisation dynamique que Google a développé le Vertical Pod Autoscaler (VPA).

2. Le Problème des Ressources Requests

Pour saisir l’utilité du VPA, il faut d’abord comprendre le rôle des requests.

Chaque Pod déclare ses besoins en ressources :

resources:
  requests:
    cpu: 500m
    memory: 1Gi

Le Scheduler Kubernetes utilise ces valeurs pour décider du nœud d’accueil du Pod. Le problème ? Personne ne peut prédire avec exactitude la consommation future d’une application.

Imaginez une API dont la charge varie :

• 10 utilisateurs aujourd’hui.
• 500 demain.
• 20 000 pendant le Black Friday.

Sans ajustement, deux écueils sont possibles :

🔻 Cas 1 : Sous-dimensionnement

+---------------------------------------+
|   Requests CPU : 200m                  |
|   Utilisation réelle : 900m            |
+---------------------------------------+

Résultat :

• CPU Throttling (goulot d’étranglement).
• Application lente.
• Timeouts et dégradation de l’expérience utilisateur.

🔺 Cas 2 : Sur-dimensionnement

+---------------------------------------+
|   Requests CPU : 4 vCPU                |
|   Utilisation réelle : 100m            |
+---------------------------------------+

Conséquences :

• Le Scheduler réserve 4 CPU inutilisés.
• Aucun autre Pod ne peut utiliser cette capacité.
• Coûts cloud inutilement élevés.

Dans les grandes entreprises, ce gaspillage peut représenter plusieurs centaines de milliers de dollars par an.

3. Origines du VPA : L’Héritage de Google

Le concept du VPA puise ses racines dans Borg, le système d’orchestration interne de Google, qui ajustait déjà dynamiquement les ressources des workloads. Lorsque Kubernetes a été open-sourcé, Google a publié plusieurs projets complémentaires pour enrichir son écosystème :

• Horizontal Pod Autoscaler (HPA)
• Cluster Autoscaler (CA)
• Vertical Pod Autoscaler (VPA)

Le VPA est donc un projet officiel de l’écosystème Kubernetes, maintenu par Google et la communauté Kubernetes Autoscaler.

4. Pourquoi le VPA n’est-il pas intégré nativement ?

Modifier les ressources d’un Pod existant n’est pas anodin. Par exemple, passer de CPU: 200m à 2 vCPU implique souvent de recréer le Pod, ce qui entraîne :

• Une interruption potentielle du service.
• Un redémarrage de l’application.
• Une nouvelle planification sur un nœud.

Les mainteneurs de Kubernetes ont fait le choix de laisser cette fonctionnalité évoluer en dehors du noyau pour :

• Itérer plus rapidement.
• Expérimenter sans risquer de casser des fonctionnalités stables.
• Offrir un cycle de vie indépendant.

5. Horizontal vs Vertical : La Différence Essentielle

6. L’Architecture du VPA : Trois Composants Clés

1. Recommender (Le Cerveau)

• Collecte les métriques d’utilisation (CPU, mémoire) via le Metrics Server.
• Analyse l’historique et calcule les recommandations optimales.
• Utilise des algorithmes pour déterminer les valeurs Target, Lower Bound, Upper Bound.

2. Updater (Le Décideur)

• Compare les ressources actuelles du Pod avec les recommandations.
• Si un écart significatif est détecté, il évince le Pod pour le forcer à recréer.

3. Admission Controller (Le Modificateur)

• Intercepte la création d’un nouveau Pod.
• Mutate (modifie) le manifeste en injectant les nouvelles Requests et Limits calculées par le Recommender.

7. Schéma de Fonctionnement Simplifié

+-------------------+        +-------------------+
|   Metrics Server  |        |  VPA Recommender  |
| (Données CPU/RAM) +-------->  (Analyse & Calcul)|
+-------------------+        +---------+---------+
                                      |
                                      | Recommandations
                                      v
+-------------------+        +---------+---------+
|   VPA Updater     |        |  Admission Ctrl   |
| (Décision/Evict)  +--------> (Injection spec)  |
+-------------------+        +---------+---------+
                                      |
                                      v
                               +-------------------+
                               |    Nouveau Pod    |
                               | (Resources mises  |
                               |       à jour)    |
                               +-------------------+

8. Installation Complète du VPA

Étape 1 : Installer Metrics Server

Le VPA nécessite une source de métriques.

# Vérification
kubectl top pods

Si la commande fonctionne, Metrics Server est opérationnel.

Étape 2 : Cloner le dépôt officiel

git clone https://github.com/kubernetes/autoscaler.git

Étape 3 : Se positionner

cd autoscaler/vertical-pod-autoscaler

Étape 4 : Lancer l’installation

./hack/vpa-up.sh

Cette commande déploie le Recommender, l’Updater, l’Admission Controller et les CRDs nécessaires.

Vérification :

kubectl get pods -n kube-system | grep vpa

Résultat attendu :

vpa-admission-controller-xxx   1/1     Running
vpa-recommender-xxx            1/1     Running
vpa-updater-xxx                1/1     Running

Étape 5 : Vérifier les CRDs

kubectl get crd | grep vertical

verticalpodautoscalers.autoscaling.k8s.io
verticalpodautoscalercheckpoints.autoscaling.k8s.io

9. Premier Manifeste VPA

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: nginx-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  updatePolicy:
    updateMode: Auto  # Mode de mise à jour automatique

Application :

kubectl apply -f vpa.yaml

10. Les Modes de Mise à Jour (Update Modes)

🔹 Off

• Action : Aucune modification.
• Utilité : Observer les recommandations en sécurité.
• Commande : kubectl describe vpa ... pour voir les suggestions.

🔸 Initial

• Action : Applique les ressources uniquement lors de la création du Pod.
• Utilité : Éviter les interruptions tout en optimisant les nouveaux déploiements.

⚙️ Auto (Recommandé)

• Action : Calcule, évince et recrée les Pods automatiquement.
• Utilité : Ajustement dynamique continu.

🔄 Recreate

• Action : Historiquement explicite pour la recréation de Pods. Aujourd’hui, Auto couvre ce comportement dans la plupart des cas.

11. Découverte des Recommandations

kubectl describe vpa nginx-vpa

Exemple de sortie :

Recommendation:
  Container Recommendations:
    Container Name:  nginx
    Lower Bound:
      Cpu:     500m
      Memory:  500Mi
    Target:
      Cpu:     750m
      Memory:  900Mi
    Upper Bound:
      Cpu:     1200m
      Memory:  1.5Gi

• Lower Bound : Seuil minimal.
• Target : Valeur idéale recommandée.
• Upper Bound : Seuil maximal avant de forcer une éviction pour sur-utilisation.

12. VPA, HPA et Cluster Autoscaler : Le Trio Gagnant

13. Scénarios d’Utilisation Réels en Entreprise

1. Banque (Plateforme Java)

• Problème : Développeurs réservent 4 CPU / 8 Go RAM par sécurité.
• Résultat VPA : Utilisation réelle ~ 700m CPU / 1,5 Go RAM.
• Bénéfice : Réduction massive des coûts et meilleure densité des nœuds.

2. Plateforme CI/CD (Jenkins)

• Problème : Compilations aux besoins très variables (500Mi à plusieurs Go).
• Résultat VPA : Ajuste dynamiquement, évite les OOMKilled et le surprovisionnement.

3. Plateforme SaaS (Microservices)

• Problème : Chaque équipe sur-dimensionne ses services.
• Résultat VPA : Standardisation des Requests, optimisation de la facture cloud.

4. Data Analytics (Spark Jobs)

• Problème : Besoins en mémoire fluctuants selon la taille des datasets.
• Résultat VPA : Ajuste les ressources pour chaque job, améliorant la fiabilité.

14. Limitations et Pièges à Éviter

• Redémarrage Nécessaire : Historiquement, la modification des ressources CPU/Mémoire nécessitait une recréation du Pod (bien que des travaux sur l’In-Place Resize soient en cours).
• Conflits HPA : Éviter de combiner HPA basé sur CPU/Mémoire avec VPA, car les métriques du HPA sont souvent relatives aux Requests que le VPA modifie.
• Dépendance à Metrics Server : Nécessite des métriques précises et un historique.
• Pas de Magic : Ne résout pas les problèmes de code ou de latence applicative.
• Pas de réduction du nombre de Pods : Ce n’est pas son rôle.

15. Bonnes Pratiques en Production

1. Démarrer en mode Off : Observez les recommandations pendant 1 à 2 semaines.
2. Tester en Préprod : Validez l’impact avant de passer en production.

3. Utiliser les PDB (PodDisruptionBudgets) : Évitez les évictions massives.

   yaml apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: app-pdb spec: minAvailable: 2 selector: matchLabels: app: mon-app

4. Surveiller : Mettez en place des dashboards (Grafana) pour suivre les recommandations et l’utilisation réelle.

5. Prévoir les Capacités : Assurez-vous que le Cluster Autoscaler est actif pour répondre aux besoins en nœuds si les Pods deviennent plus gros.

16. Conclusion

Le Vertical Pod Autoscaler est un outil incontournable de l’écosystème Kubernetes pour l’optimisation des ressources. Il ne remplace ni le HPA ni le Cluster Autoscaler, mais les complète parfaitement :

• VPA : Dimensionne les Pods.
• HPA : Adapte le nombre de Pods.
• CA : Adapte le nombre de nœuds.

Utilisé avec discernement et les bonnes pratiques, le VPA permet de réduire drastiquement les coûts, d’améliorer la stabilité des applications et de simplifier la gestion des ressources à grande échelle. Il est aujourd’hui largement adopté dans les architectures cloud modernes.
```