Présentation

Kubernetes version 1.37 introduit la capacité de Horizontal Pod Autoscaler (HPA) à réduire un workload à zéro pod et à le réactiver automatiquement. Cette fonctionnalité passe en Beta et est activée par défaut, contrairement aux versions antérieures où elle était confinée à un Alpha feature gate. Le premier prototype d’Alpha était disponible dès la version 1.16, mais le SIG Autoscaling attend encore des retours d’exploitation avant d’envisager une graduation en General Availability (GA).

Fonctionnement technique

L’HPA de 1.37 s’appuie sur des métriques externes ou d’objet pour déclencher le scaling. Dès que la charge mesurée tombe en dessous du seuil défini, le contrôleur supprime les pods jusqu’à atteindre zéro. La remise en service s’opère dès qu’une métrique pertinente dépasse le seuil, créant ainsi de nouveaux pods. CPU et mémoire ne sont plus utilisables comme déclencheurs dès l’absence de pods, car ces métriques disparaissent. Il faut donc configurer au moins une métrique d’objet (par ex. longueur d’une file d’attente) ou une métrique externe (par ex. taux d’arrivée de messages) pour garantir le déclenchement du scaling inverse.

Le mécanisme ne nécessite plus d’add‑on supplémentaire ni de flag d’activation, ce qui simplifie le déploiement. Le contrôleur HPA conserve son cycle de réconciliation habituel (30 s par défaut) et utilise les mêmes algorithmes de calcul de cible que pour le scaling traditionnel, mais avec un facteur de minReplicas fixé à zéro.

Implications opérationnelles

Pour les consommateurs de files d’attente et les traitements batch, la possibilité de libérer complètement les ressources réduit le coût d’infrastructure pendant les périodes d’inactivité. En l’absence de pods, le scheduler ne réserve plus de CPU ni de mémoire, ce qui améliore le taux d’utilisation du cluster. Cependant, la dépendance à une métrique externe introduit une nouvelle surface de défaillance : si le serveur de métriques devient indisponible, le HPA ne pourra pas détecter la reprise de la charge et les pods resteront à zéro, entraînant un délai de latence supplémentaire lors du premier traitement.

Le passage en Beta implique que la fonctionnalité est stable pour la plupart des cas d’usage, mais elle n’est pas encore garantie contre les régressions majeures. Les équipes doivent donc tester le comportement de leurs workloads dans un environnement de pré‑production, vérifier la disponibilité des métriques requises et surveiller les événements du contrôleur HPA (par ex. kubectl describe hpa) pour détecter d’éventuels échecs de scaling.

Limites et perspectives

La principale contrainte technique reste la détection de métriques en l’absence de pods. Les solutions courantes consistent à exposer des métriques via des exporters qui continuent de publier des valeurs même quand aucun pod n’est actif, ou à recourir à des systèmes de monitoring externes (Prometheus, Datadog) capables de fournir des mesures agrégées. De plus, le temps de démarrage des pods depuis zéro dépend du image pull et du cold start, ce qui peut impacter les SLA pour des services à latence critique. Enfin, la graduation en GA dépendra de la capacité du SIG Autoscaling à collecter des retours d’expérience suffisants, notamment sur la robustesse des métriques externes et la gestion des scénarios de panne du contrôleur.