Autoscaling Kubernetes : HPA, VPA et scaling automatique expliqués

L'autoscaling Kubernetes est la capacité du cluster à ajuster automatiquement les ressources allouées aux workloads en fonction de la demande réelle. Le Horizontal Pod Autoscaler (HPA) augmente ou réduit le nombre de Pods, tandis que le Vertical Pod Autoscaler (VPA) ajuste les requests CPU et mémoire de chaque Pod. Ces mécanismes garantissent performance optimale et maîtrise des coûts sans intervention manuelle.

À retenir : Le scaling automatique cluster Kubernetes repose sur trois piliers : HPA pour le scaling horizontal, VPA pour le scaling vertical, et Cluster Autoscaler pour les nœuds. Maîtrisez ces concepts pour réussir votre certification CKA.

Cette compétence est au cœur de la formation LFS458 Administration Kubernetes.

Qu'est-ce que l'autoscaling dans Kubernetes ?

L'autoscaling désigne l'ensemble des mécanismes permettant à votre cluster d'adapter ses ressources à la charge de travail. Contrairement au scaling manuel où vous ajustez les réplicas ou les limites de ressources, l'autoscaling réagit automatiquement aux métriques observées.

Selon le rapport Spectro Cloud State of Kubernetes 2025, 80% des organisations exécutent Kubernetes en production avec une moyenne de 20+ clusters. À cette échelle, le scaling manuel devient impossible. Vous devez automatiser pour maintenir la disponibilité de vos services.

Kubernetes propose trois types d'autoscaling :

Type	Cible	Action	Cas d'usage
HPA	Pods	Ajuste le nombre de réplicas	Trafic variable
VPA	Pods	Modifie requests/limits	Workloads imprévisibles
Cluster Autoscaler	Nœuds	Ajoute/retire des nodes	Capacité globale

Pour approfondir le déploiement et mise en production Kubernetes, vous devez maîtriser ces trois mécanismes.

Pourquoi le scaling automatique est-il critique en production ?

Vos applications subissent des variations de charge constantes. Sans autoscaling, vous faites face à deux problèmes :

Sous-provisionnement : vos Pods saturent, les latences explosent, vos utilisateurs subissent des erreurs 503. Votre SLA est compromis.

Sur-provisionnement : selon ScaleOps, 65%+ des workloads consomment moins de la moitié de leurs ressources demandées. Vous payez pour des ressources inutilisées.

À retenir : L'autoscaling Kubernetes HPA VPA vous permet d'équilibrer performance et coûts. Configurez-le correctement pour éviter le gaspillage de ressources.

Si vous préparez la certification CKA en tant qu'administrateur système, vous devez savoir configurer le HPA. Cette compétence figure explicitement dans le curriculum. Consultez notre guide complet Formation Kubernetes pour structurer votre préparation.

Comment fonctionne le Horizontal Pod Autoscaler (HPA) ?

Le Horizontal Pod Autoscaler Kubernetes surveille les métriques de vos Pods et ajuste le nombre de réplicas. Voici son fonctionnement :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Décryptez cette configuration :

scaleTargetRef : vous ciblez le Deployment api-server
minReplicas: 2 : même sans charge, vous maintenez 2 Pods pour la haute disponibilité
maxReplicas: 10 : vous limitez le scaling pour contrôler vos coûts
averageUtilization: 70 : le HPA scale up quand l'utilisation CPU dépasse 70%

Le controller HPA interroge le Metrics Server toutes les 15 secondes par défaut. Il calcule le nombre de réplicas nécessaires avec cette formule :

desiredReplicas = ceil(currentReplicas × (currentMetric / desiredMetric))

Pour vérifier que votre HPA fonctionne, exécutez :

kubectl get hpa api-hpa -w

Vous verrez les métriques actuelles et le nombre de réplicas souhaités. Si vous rencontrez des problèmes, consultez notre article sur les problèmes de scaling Kubernetes : diagnostic et solutions.

Comment configurer le Vertical Pod Autoscaler (VPA) ?

Le VPA ajuste les requests et limits de vos conteneurs. Contrairement au HPA, il ne modifie pas le nombre de Pods mais optimise les ressources allouées à chaque Pod.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: "*"
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 2
        memory: 4Gi

Comprenez les modes VPA :

Mode	Comportement	Impact
Off	Recommandations uniquement	Aucun redémarrage
Initial	Applique au démarrage	Nouveaux Pods seulement
Auto	Applique dynamiquement	Redémarre les Pods

À retenir : Le VPA en mode Auto redémarre vos Pods pour appliquer les nouvelles ressources. Assurez-vous que votre application tolère les redémarrages avant d'activer ce mode en production.

L'administrateur système préparant la certification CKA doit comprendre quand privilégier HPA ou VPA. Le monitoring et dépannage Kubernetes vous aide à collecter les métriques nécessaires.

Quand utiliser HPA versus VPA ?

Vous devez choisir le bon mécanisme selon votre workload :

Utilisez le HPA quand :

Votre application est stateless et scale horizontalement
Vous gérez du trafic web avec des pics prévisibles
Vos Pods démarrent rapidement (< 30 secondes)

Utilisez le VPA quand :

Votre application est stateful ou mono-instance
Vous ne connaissez pas les besoins en ressources à l'avance
Vos Pods ont des temps de démarrage longs

Combinez HPA et VPA avec précaution. Comme l'explique le guide ScaleOps, les deux peuvent entrer en conflit si vous scalez sur les mêmes métriques. Utilisez le HPA sur des métriques custom et le VPA sur CPU/mémoire.

Pour les déploiements progressifs, combinez l'autoscaling avec les stratégies de Canary Deployment sur Kubernetes.

Comment intégrer l'autoscaling dans votre pipeline CI/CD ?

Votre configuration autoscaling doit être versionnée et déployée via GitOps. Voici un workflow recommandé :

# Validez votre HPA avant déploiement
kubectl apply --dry-run=client -f hpa.yaml

# Déployez via ArgoCD ou Flux
argocd app sync mon-application

Intégrez les tests de charge dans votre pipeline pour valider les seuils de scaling :

# pipeline-ci.yaml (exemple GitHub Actions)
- name: Load test
  run: |
    k6 run --vus 100 --duration 5m loadtest.js
    kubectl get hpa -o wide

Consultez notre guide mettre en place un pipeline CI/CD pour Kubernetes pour automatiser vos déploiements.

Pour aller plus loin dans l'approche GitOps, explorez GitOps et Kubernetes : principes, outils et mise en œuvre et notre guide de migration vers une architecture GitOps.

Quelles métriques surveiller pour un autoscaling efficace ?

Le Metrics Server fournit CPU et mémoire par défaut. Mais vous pouvez scaler sur des métriques custom :

Métrique	Source	Cas d'usage
CPU/Mémoire	Metrics Server	Scaling basique
Requests/seconde	Prometheus	API Gateway
Queue depth	CloudWatch/Stackdriver	Workers async
Connexions actives	Custom metrics	WebSockets

Selon CNCF Annual Survey 2025, 82% des utilisateurs de conteneurs exécutent Kubernetes en production. À cette échelle, vous devez instrumenter finement vos applications.

L'autoscaling devient crucial pour les workloads IA/ML avec leur consommation de ressources variable.

À retenir : Définissez vos métriques de scaling en fonction de vos SLOs. Un scaling sur CPU ne convient pas à tous les workloads. Mesurez ce qui compte pour vos utilisateurs.

Quelles sont les erreurs courantes à éviter ?

Voici les pièges que vous devez contourner :

1. Oublier les requests de ressources Le HPA utilise les requests pour calculer l'utilisation. Sans requests définies, le scaling ne fonctionne pas.

# Mauvais - pas de requests
resources:
  limits:
    cpu: 1

# Bon - requests explicites
resources:
  requests:
    cpu: 200m
  limits:
    cpu: 1

2. Seuils trop agressifs Un targetUtilization à 90% laisse peu de marge. Préférez 60-70% pour absorber les pics.

3. Ignorer le cooldown Le HPA attend 5 minutes avant de scale down par défaut. Ajustez --horizontal-pod-autoscaler-downscale-stabilization si nécessaire.

4. Conflits HPA/VPA Ne scalez jamais HPA et VPA sur la même métrique. Vous créez une boucle instable.

Passez à l'action : formez-vous au scaling Kubernetes

L'autoscaling est une compétence clé pour tout administrateur système visant la certification CKA. Selon la Linux Foundation, l'examen CKA dure 2 heures avec un score de passage de 66%. Les questions pratiques incluent la configuration de HPA.

Comme le note un témoignage sur TechiesCamp : "The CKA exam tested practical, useful skills. It wasn't just theory - it matched real-world situations you'd actually run into when working with Kubernetes."

Préparez-vous efficacement avec SFEIR Institute :

LFS458 Administration Kubernetes : 4 jours intensifs couvrant l'autoscaling, le troubleshooting et la préparation CKA
LFD459 Kubernetes pour les développeurs : 3 jours pour maîtriser les Deployments, ConfigMaps et le scaling applicatif
Kubernetes, les fondamentaux : 1 journée pour découvrir les concepts essentiels si vous débutez

La certification CKA est valide 2 ans (source Linux Foundation). Avec plus de 104 000 personnes ayant passé l'examen selon les rapports CNCF (croissance de 49% par an), cette certification reste un différenciateur majeur sur le marché.

Contactez nos conseillers sur notre page contact pour planifier votre formation et accélérer votre préparation CKA.

Points clés