Comment fonctionne le Horizontal Pod Autoscaler, et quel est son rapport avec le Cluster Autoscaler ?

Question

IT Interview Practice · Accepted Answer

Le **Horizontal Pod Autoscaler (HPA)** ajoute ou retire des **replicas de Pods** selon des métriques observées (CPU, mémoire ou personnalisées). Le **Cluster Autoscaler (CA)** ajoute ou retire des **nodes** quand des Pods ne peuvent pas être planifiés ou que des nodes sont sous-utilisés. Ils opèrent à des couches différentes et travaillent ensemble.

## Deux autoscalers, deux couches

```text
HPA  → met à l'échelle les PODS  (plus/moins de replicas d'un Deployment)     — réagit à la CHARGE
CA   → met à l'échelle les NODES (agrandit/réduit les machines du cluster)     — réagit aux Pods PENDING
VPA  → (bonus) ajuste les requests/limits d'un Pod                             — réagit au dimensionnement

Flux typique : la charge monte → le HPA ajoute des Pods → les Pods ne tiennent plus → le CA ajoute un node →
              les Pods se planifient. La charge baisse → le HPA retire des Pods → node inactif → le CA le retire.
```

## Comment fonctionne la boucle de contrôle du HPA

```text
Toutes les ~15s le controller HPA :
  1. lit la métrique actuelle (ex. CPU moyen sur les Pods) depuis metrics-server / API personnalisée
  2. calcule :  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. met le Deployment à l'échelle vers cette valeur (bornée par minReplicas/maxReplicas)
Exemple : 4 Pods à 80% CPU, cible 50% → 4 * 80/50 = 6,4 → 7 replicas.
Les fenêtres de stabilisation amortissent le flapping (surtout au scale-down).
```

## Un manifest de HPA

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60      # garder le CPU moyen ~60% de la REQUEST
  behavior:                           # optionnel : régler la vitesse de scale up/down
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # métrique actuelle/cible, nombre de replicas
kubectl top pods                      # nécessite metrics-server
```

## Dépendances & mises en garde importantes

```text
• Le HPA sur CPU/mémoire NÉCESSITE metrics-server installé ; l'utilisation est relative aux REQUESTS
  → si les requests sont absentes/fausses, le calcul du HPA n'a aucun sens. Réglez correctement les requests.
• Les métriques personnalisées/externes (RPS, profondeur de file) nécessitent un adapter (Prometheus Adapter, KEDA).
• Le HPA et un `replicas` manuel entrent en conflit — laissez le HPA posséder le nombre de replicas.
• Le Cluster Autoscaler a aussi besoin de requests correctes : il regarde les REQUESTS des Pods Pending pour
  décider du scaling des nodes. Le scale-up d'un node prend des minutes (provisioning), gardez donc de la marge.
```

## Pourquoi c'est important

L'autoscaling est ce qui permet à Kubernetes d'ajuster automatiquement la capacité à la demande, et comprendre les deux couches est une connaissance de niveau senior qui distingue les clusters économiques et résilients de ceux sur- ou sous-provisionnés. Le modèle mental clé est que le **HPA met à l'échelle les Pods** en réponse à la charge (ajustant le nombre de replicas à partir du CPU, de la mémoire ou de métriques personnalisées observés) tandis que le **Cluster Autoscaler met à l'échelle les nodes** en réponse à la pression de scheduling (ajoutant des machines quand des Pods sont Pending, les retirant quand des nodes sont inactifs) — ils opèrent à des couches différentes et coopèrent : le HPA ne peut ajouter des Pods que s'il y a de la place, et le CA fournit cette place. Comprendre la boucle de contrôle du HPA — la formule `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, la réconciliation périodique et les fenêtres de stabilisation qui empêchent le flapping — vous permet de le configurer et de le déboguer plutôt que de le traiter comme de la magie. Les mises en garde sont là où se montre le jugement senior : le HPA sur CPU/mémoire **nécessite metrics-server** et calcule l'utilisation **relativement aux requests**, donc des requests incorrectes ou absentes rendent son calcul dénué de sens ; les métriques personnalisées (requêtes par seconde, profondeur de file) nécessitent un adapter comme Prometheus Adapter ou KEDA ; et le scale-up d'un node prend des minutes, donc la marge compte. Parce que le bon dimensionnement de la capacité affecte directement la fiabilité lors des pics de trafic et les dépenses cloud durant les périodes calmes, et parce que les deux autoscalers dépendent de resource requests correctement réglées, maîtriser le HPA et le Cluster Autoscaler est fondamental pour exploiter Kubernetes en production de façon efficace et fiable.

Deux autoscalers, deux couches

Comment fonctionne la boucle de contrôle du HPA

Un manifest de HPA

Dépendances & mises en garde importantes

Pourquoi c'est important

Questions connexes