HPA, VPA, KEDA et Karpenter donnent cinq réponses contradictoires au même problème de dimensionnement
Sur un même déploiement Kubernetes, quatre contrôleurs d’autoscaling peuvent exiger en même temps 3, 11 ou 24 réplicas, chacun agissant sur une variable isolée. Les quatre collisions qui en résultent ne se règlent pas avec un cinquième contrôleur, mais en traitant le dimensionnement comme une équation unique et couplée.
24 octobre 2026. Un billet publié sur The New Stack décrit un cas d’école : un service checkout-api déclaré en Helm avec replicas: 3, cpu: 1000m et memory: 2Gi. Le cluster raconte une tout autre histoire : le HPA a monté le service à 11 réplicas sur la charge CPU, le VPA recommande de réduire la demande à 350m, KEDA exige 24 réplicas après un pic de lag Kafka, et Karpenter provisionne deux nouveaux nœuds. Cinq sources, cinq réponses contradictoires.
Pour une équipe plateforme, le diagnostic tient en une phrase : chaque contrôleur agit logiquement, isolément, et aucun ne voit l’image complète. C’est une défaillance architecturale, pas un bug de configuration.
La philosophie Unix poussée au-delà de sa logique
Kubernetes a été construit sur le principe Unix : de petits outils modulaires qui font une chose et la font bien. grep et awk composent proprement parce qu’ils traitent séquentiellement des flux de texte immuables : l’un termine, puis passe sa sortie au suivant.
Les contrôleurs d’autoscaling ne fonctionnent pas ainsi. Ils s’exécutent concurremment, sur la même charge de travail, et mutent les mêmes champs d’API : .spec.replicas, .resources.requests et le pool de nœuds sous-jacent. Chacun tourne dans une boucle de réconciliation indépendante et suppose qu’il détient le contrôle exclusif du dimensionnement. Or, déterminer la capacité d’une charge de travail est une équation mathématique unique et couplée : la découper entre des contrôleurs découplés produit du thrashing, pas de l’efficacité.
Quatre contrôleurs, quatre questions étroites
Chacun des quatre outils répond à une question précise, et c’est là le nœud du problème. Le Horizontal Pod Autoscaler (HPA) répond « combien de réplicas pour tenir la charge CPU ? » en comparant l’usage réel aux requests déclarées. Le Vertical Pod Autoscaler (VPA) répond « quelle taille de requests pour un pod ? » en observant l’usage historique et en recommandant de nouveaux resources.requests. KEDA répond « combien de réplicas pour drainer la file d’attente ? » en s’appuyant sur des scalers événementiels, de Kafka à Prometheus. Karpenter répond « quels nœuds provisionner pour héberger ces pods ? » en optimisant l’offre physique contre les demandes déclarées.
La clé est que ces quatre questions portent sur des variables qui se répondent les unes aux autres. Le nombre de réplicas (HPA, KEDA) dépend de la taille des pods (VPA), qui dépend elle-même des nœuds disponibles (Karpenter), qui dépendent à leur tour des demandes agrégées. Les quatre contrôleurs manipulent donc le même système d’équations sans jamais le résoudre ensemble — et chacun croit en être le seul propriétaire.
Les quatre collisions
Quand des boucles de contrôle indépendantes manipulent des variables interdépendantes, les boucles de rétroaction se déstabilisent selon quatre modes de défaillance récurrents.
1. La spirale mortelle HPA–VPA. Le HPA calcule ses réplicas cibles à partir de l’utilisation CPU en pourcentage des requests déclarées : métrique = usage total ÷ requests déclarées. Le dénominateur, ce sont les requests. Quand le VPA abaisse ces requests pour supprimer le gaspillage, il rétrécit le dénominateur : une hausse de trafic mineure pousse alors le pourcentage au-dessus du seuil du HPA, qui scale horizontalement. Les pods se partagent le trafic, l’usage par pod chute, le VPA réduit encore les requests — et la charge entre dans une spirale de conteneurs microscopiques toujours plus nombreux.
2. La course à deux écrivains, HPA contre KEDA. Quand on combine le scaling par file d’attente de KEDA avec le HPA CPU standard, deux contrôleurs ciblent la même sous-ressource /scale du même déploiement. Un pic d’événements fait monter KEDA pour drainer le backlog, mais si les pods workers sont I/O-lourds à faible CPU, le HPA juge l’app sur-provisionnée et redescend. L’API server enregistre des rescalings alternés pendant que le débit réel stagne.
3. Le ping-pong GitOps. Les moteurs GitOps imposent le dépôt Git comme source de vérité. Quand le HPA scale un déploiement pendant un pic, Argo CD le signale OutOfSync ; si l’auto-sync est actif, il réinitialise le déploiement à sa baseline, privant l’application de capacité au pire moment. Ignorer les différences de réplicas casse l’infrastructure déclarative : Git ne reflète plus la production, et les futurs rollouts risquent de restaurer silencieusement des baselines obsolètes.
4. L’effet multiplicateur au niveau des nœuds. Les autoscalers de nœuds comme Karpenter prennent leurs décisions sur les requests déclarées, pas sur la consommation réelle. Un conteneur qui demande 1000m mais consomme 150m fait réserver un cœur entier ; Karpenter provisionne donc des instances physiques pour une demande fantôme. À l’échelle d’un parc, l’utilisation CPU moyenne des clusters flirte avec 8 % malgré un provisionnement lourd.
Automatisé n’est pas autonome
La conclusion du billet mérite d’être lue au-delà de son origine : il s’agit d’un post sponsorisé par la CNCF, écrit par Nikhil Kurup, VP ingénierie chez Sedai, un éditeur de droitsizing autonome. Le plaidoyer pour un « plan de contrôle unifié » sert donc un intérêt commercial — mais le diagnostic des quatre collisions reste vérifiable indépendamment.
La distinction utile est lexicale. Les autoscalers actuels sont automatisés : comme des réflexes biologiques, ils mesurent un signal isolé et déclenchent une réponse prédéfinie. Quand cinq réflexes indépendants tirent sur le même membre, le système tremble. L’autonomie exigerait une boucle fermée qui observe l’environnement entier, comprend l’arbitrage performance–coût et assume la responsabilité de bout en bout du résultat.
La proposition finale a le mérite de la retenue : HPA, VPA, KEDA et Karpenter devraient continuer à exécuter les mutations d’API pour lesquelles ils ont été conçus. Ce qui manque à Kubernetes, ce n’est pas un cinquième actuateur, c’est la couche d’intelligence centrale qui décide de ce que ces actuateurs doivent faire.
Comment détecter les collisions chez vous
Le symptôme le plus visible est une succession de rescalings contradictoires dans l’historique du déploiement : kubectl describe hpa montre le HPA monter puis descendre sans pic de trafic, pendant que les recommandations du VPA baissent les requests. Vérifiez aussi si deux contrôleurs écrivent sur la même sous-ressource /scale — c’est le cas dès que KEDA et le HPA visent le même objet. Enfin, comparez les requests déclarées à l’usage réel : un écart massif et persistant entre resources.requests et la consommation mesurée est le signe que Karpenter provisionne pour une demande fantôme, et que la facture cloud absorbe des cœurs jamais utilisés.
Verdict
Si vous exécutez HPA et VPA ensemble sur la même charge de travail, ne le faites pas : la spirale mortelle décrite plus haut est structurelle, pas accidentelle. Choisissez l’un ou l’autre selon que votre goulot est le CPU ou le dimensionnement des requests.
Si vous combinez KEDA et HPA sur le même déploiement, désactivez l’un des deux ou isolez-les par charge de travail : deux écrivains sur /scale produisent des rescalings alternés qui tuent le débit.
Si vous utilisez GitOps avec l’autoscaling, décidez explicitement qui détient le champ replicas — le dépôt ou le contrôleur — et documentez l’arbitrage, sinon vous restaurez des baselines mortes à chaque pic.
Et face à tout vendeur qui promet un « sizing autonome », posez la seule question qui compte : qui a la vision complète du dimensionnement, et ce système a-t-il déjà fait ses preuves sur votre propre métrique SLO plutôt que sur un benchmark maison.