Kubernetes HPA et VPA : autoscaling horizontal et vertical

Scaler manuellement le nombre de pods en production est une opération à risque et chronophage. Kubernetes propose plusieurs mécanismes d’autoscaling — comprendre lequel utiliser et comment le configurer correctement évite les surprises en production.

HPA : scaler sur le CPU et la mémoire

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2     # jamais moins de 2 (haute disponibilité)
  maxReplicas: 20    # jamais plus de 20 (coût et capacité du cluster)
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # scaler si CPU moyen > 70%
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300   # attendre 5min avant de scale down
      policies:
        - type: Percent
          value: 25           # réduire de max 25% à la fois
          periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0    # scale up immédiat
      policies:
        - type: Percent
          value: 100          # doubler si besoin
          periodSeconds: 30

HPA sur métriques custom avec Prometheus

# Scaler sur le nombre de requêtes par seconde
metrics:
  - type: External
    external:
      metric:
        name: nginx_ingress_controller_requests_per_second
        selector:
          matchLabels:
            service: api
      target:
        type: AverageValue
        averageValue: "100"   # 100 req/s par pod

Nécessite l’installation d’un adapter de métriques (prometheus-adapter ou keda).

KEDA : event-driven autoscaling

KEDA permet de scaler depuis zéro sur des sources d’événements — queues SQS, topics Kafka, queues RabbitMQ.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: worker-scaler
spec:
  scaleTargetRef:
    name: order-worker
  minReplicaCount: 0      # scale to zero possible !
  maxReplicaCount: 50
  pollingInterval: 30
  cooldownPeriod: 300
  triggers:
    - type: aws-sqs-queue
      metadata:
        queueURL: https://sqs.eu-west-1.amazonaws.com/123/orders
        queueLength: "5"   # 1 pod par 5 messages en queue
        awsRegion: eu-west-1

Avec KEDA, les workers ne consomment aucune ressource quand la queue est vide — économie significative en dehors des heures de pointe.

VPA : rightsizing automatique des requests/limits

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  updatePolicy:
    updateMode: "Auto"   # applique les recommandations en redémarrant les pods
  resourcePolicy:
    containerPolicies:
      - containerName: api
        minAllowed:
          cpu: 100m
          memory: 128Mi
        maxAllowed:
          cpu: 4
          memory: 4Gi

Attention : HPA et VPA ne peuvent pas s’utiliser simultanément sur le même metric CPU. Utilisez HPA pour le scaling et VPA en mode "Off" (recommandations seulement) pour le rightsizing initial.

Notre formation Kubernetes couvre l’autoscaling avec des ateliers sur des clusters de production.