Kubernetes 1.37 : l'autoscaling jusqu'à zéro réplique passe en bêta

Kubernetes v1.37 introduit le support natif de la mise à l'échelle à zéro réplique dans l'API de l'HorizontalPodAutoscaler (HPA, le composant chargé d'ajuster automatiquement le nombre de conteneurs selon la charge). La fonctionnalité passe au statut bêta et se retrouve activée par défaut via l'option d'activation (feature gate) nommée HPAScaleToZero. Auparavant, la mise en veille totale d'une application nécessitait un composant externe spécialisé ou le passage par une option alpha expérimentale.

Métriques externes obligatoires pour le réveil

Le choix des métriques est déterminant dans ce fonctionnement. Un HPA configuré uniquement sur la consommation de processeur (CPU) ou de mémoire vive ne peut pas descendre à zéro : lorsque tous les Pods (la plus petite unité de déploiement dans Kubernetes) sont arrêtés, plus aucun signal système n'est émis pour ordonner au cluster de repartir.

Pour autoriser la valeur minReplicas: 0, l'API Kubernetes exige donc l'utilisation d'une métrique d'objet ou externe, comme la taille d'une file de messages. La longueur d'une file d'attente existe indépendamment des processeurs de tâches (workers) en cours d'exécution. L'adaptateur de métriques peut ainsi continuer à lire ce signal même lorsque l'application est totalement éteinte.

Exemple de configuration HPA

Voici un exemple de manifeste YAML configurant un HPA pour un déploiement nommé queue-worker, basé sur une métrique externe Prometheus queue_consumer_lag :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: queue-worker
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 10
  metrics:
  - type: External
    external:
      metric:
        name: queue_consumer_lag
      selector:
        matchLabels:
          name: worker_tasks
      target:
        type: Value
        value: "30"

Distinction entre pause manuelle et extinction automatique

Afin d'éviter de réveiller un composant qu'un opérateur aurait volontairement interrompu, le contrôleur de Kubernetes trace l'origine de l'extinction. Lorsqu'il réduit la charge à zéro, il enregistre l'état ScaledToZero=True dans le statut de la ressource. Si une application est à zéro sans ce drapeau, Kubernetes considère qu'il s'agit d'une pause manuelle et laisse le composant à l'arrêt.

Cette fonctionnalité vise en priorité les consommateurs de files d'attente et les traitements par lots (batch), afin de libérer des ressources coûteuses (processeurs dédiés ou processeurs graphiques GPU). Le compromis principal réside dans le temps de démarrage à froid (cold start) nécessaire pour planifier et démarrer le Pod lors de l'arrivée d'un nouveau message. Notez également que les services réseau Kubernetes ne conservent pas les requêtes en mémoire tampon : les architectures web HTTP nécessitent toujours une couche de tampon (buffering) séparée en amont.

Migration et prérequis de mise à jour

Lors de la mise à niveau de votre plan de contrôle (control plane, l'ensemble des composants d'administration du cluster), attendez que le serveur d'API (kube-apiserver) et le gestionnaire de contrôleurs (kube-controller-manager) soient tous deux migrés en v1.37 avant de créer des HPA avec minReplicas: 0. Si le gestionnaire de contrôleurs s'exécute dans une version antérieure, il traitera le passage à zéro comme une pause manuelle et refusera de relancer automatiquement vos Pods.