La mise à l'échelle

On distingue deux façons de « mettre à l'échelle » une application :

• Horizontalement (scale out / scale in) : on ajoute ou retire des réplicas (des Pods identiques). C'est la méthode privilégiée pour les applications sans état.
• Verticalement (scale up / scale down) : on donne plus ou moins de ressources (CPU, mémoire) à un container. Cela nécessite généralement un redémarrage du Pod.

Cette page se concentre sur le scaling horizontal, le plus courant dans Kubernetes.

Le scaling horizontal

Manuellement

On fixe soi-même le nombre de réplicas, soit dans le manifeste (spec.replicas), soit via kubectl scale :

kubectl scale deployment web --replicas=5

Quand le faire ?

• la charge est stable ou prévisible (ex. une application utilisée aux heures de bureau) ;
• on veut garantir un nombre de base de réplicas, quitte à y ajouter du HPA ensuite ;
• on n'a pas de métriques fiables pour décider automatiquement ;
• en développement / test, ou pour des applications difficiles à paralléliser (état local, singleton…).

Avantages : simple, prévisible, aucun composant supplémentaire à maintenir. Inconvénients : ne réagit pas à la charge réelle — on sur-provisionne (coût) ou on sous-provisionne (saturation).

Automatiquement : le HorizontalPodAutoscaler (HPA)

Le HPA est un contrôleur qui ajuste automatiquement spec.replicas d'une cible (Deployment, ReplicaSet, StatefulSet) en fonction de métriques observées.

Quand le faire ?

• la charge est variable et peu prévisible (pic d'audience, promotions, jobs nocturnes…) ;
• l'application est sans état et peut être répliquée sans problème ;
• on veut suivre la demande au plus près (et donc maîtriser les coûts).

Prérequis : le Metrics Server doit être installé dans le cluster, sinon le HPA ne dispose d'aucune métrique CPU / mémoire.

Comment ça marche ?

Le HPA fonctionne comme une boucle de contrôle, exécutée périodiquement (toutes les ~15 secondes) :

1. il lit la métrique courante (ex. l'utilisation CPU moyenne des Pods) via le Metrics Server ou une API de métriques custom/external ;

2. il compare cette valeur à la cible (averageUtilization) ;

3. il calcule le nombre de réplicas désiré :

   réplicas désirés = ceil( réplicas actuels × métrique actuelle / métrique cible )
   

4. il borne le résultat entre minReplicas et maxReplicas ;

5. il met à jour le nombre de réplicas de la cible, qui crée ou supprime des Pods.

[!IMPORTANT] Pour une cible de type Utilization, le pourcentage est calculé par rapport aux requests des containers. Sans requests définies, le HPA ne peut ni calculer l'utilisation ni agir. Toujours définir des requests.

Le lissage (behavior)

Pour éviter les oscillations (thrashing), le HPA applique par défaut :

• un scale-up réactif : dès que la charge dépasse la cible, des réplicas sont ajoutés rapidement ;
• un scale-down lissé : le HPA attend une fenêtre de stabilisation (5 minutes par défaut) avant de retirer des réplicas, pour ne pas redescendre sur un simple pic momentané.

Ces comportements sont configurables via spec.behavior.

Un manifeste HPA

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300

Les limites du HPA

• il dépend d'un Metrics Server (ou d'une stack de métriques) ;
• le CPU n'est pas toujours un bon indicateur : pour une application orientée I/O, on préfère des métriques personnalisées (requêtes/seconde, taille de file d'attente…) via un adaptateur (Prometheus Adapter, KEDA) ;
• il ne peut rien faire si l'application ne peut pas être répliquée (singleton, état local) ;
• si les noeuds sont pleins, les nouveaux Pods restent Pending : il faut alors un Cluster Autoscaler (voir plus bas).

Le scaling vertical : le VerticalPodAutoscaler (VPA)

Le VPA ajuste automatiquement les requests et limits d'un container, au lieu de changer le nombre de réplicas.

• Modes : Off (recommande seulement), Initial (applique au démarrage), Auto / Recreate (met à jour, avec redémarrage du Pod).
• Quand l'utiliser ? pour dimensionner correctement les ressources d'un app sans tâtonner, ou pour des applications qui ne peuvent pas être répliquées (bases de données…).
• Attention : le VPA redémarre les Pods pour appliquer de nouvelles valeurs, et il ne faut pas le combiner avec un HPA sur la même métrique.

Et si les noeuds sont pleins ? Le Cluster Autoscaler

• Le HPA ajoute des Pods ; le Cluster Autoscaler ajoute des noeuds.
• Quand plus aucun noeud n'a de capacité, les nouveaux Pods restent Pending.
• Le Cluster Autoscaler ajoute alors un noeud pour les accueillir, et retire les noeuds sous-utilisés.

En résumé

• Charge stable ou prévisible → scaling manuel.
• Charge variable, application sans état → HPA.
• Dimensionner les ressources / application non répliquable → VPA.
• Plus de capacité au niveau des noeuds → Cluster Autoscaler.

Les commandes principales

• Mettre à l'échelle manuellement : kubectl scale deployment web --replicas=5
• Créer un HPA (impératif) : kubectl autoscale deployment web --min=2 --max=10 --cpu-percent=70
• Lister les HPA : kubectl get hpa
• Détails d'un HPA : kubectl describe hpa web
• Consommation des Pods : kubectl top pods
• Consommation des noeuds : kubectl top nodes