Les autoscalers Kubernetes entrent en conflit faute d'un plan de contrôle unifié

Lorsque les ingénieurs de fiabilité des sites (SRE) demandent la taille correcte d'un service comme checkout-api, ils obtiennent des réponses contradictoires provenant de leur propre infrastructure. Le Horizontal Pod Autoscaler (HPA) peut exiger onze répliques en raison de la charge CPU, tandis que le Vertical Pod Autoscaler (VPA) affirme que les pods sont surdimensionnés. Simultanément, KEDA demande vingt-quatre répliques pour épuiser l'arrière-plan Kafka, et Karpenter ajoute de nouveaux nœuds basés sur des demandes de ressources gonflées. Ce chaos survient parce que cinq contrôleurs différents agissent logiquement de manière isolée, sans qu'aucun ne possède une vue complète des besoins réels du système.

Ce qui s'est passé

Les opérations modernes sur Kubernetes reposent sur une suite d'outils spécialisés construits selon la philosophie Unix : des composants petits et modulaires qui accomplissent bien une seule tâche. HPA gère l'élasticité horizontale, VPA s'occupe du dimensionnement vertical, KEDA fait le pont entre les sources d'événements et le nombre de répliques, et les autoscalers de nœuds comme Karpenter gèrent la capacité physique. Les outils GitOps tels qu'Argo CD appliquent les états de référence issus du contrôle de version. Dans les pipelines Unix traditionnels, les outils traitent les données séquentiellement, transmettant une sortie immuable d'une étape à la suivante. Cependant, les autoscalers Kubernetes fonctionnent en parallèle, modifiant les mêmes champs de l'API tels que .spec.replicas et .resources.requests sans visibilité sur les actions des autres.

Cette lacune architecturale crée une situation où la détermination de la capacité de charge devient un processus fragmenté. Au lieu de résoudre une seule équation mathématique couplée pour une performance et un coût optimaux, le système divise le problème entre des contrôleurs découplés. Chaque contrôleur suppose avoir le contrôle exclusif sur son domaine spécifique, entraînant du thrashing plutôt que de l'efficacité. Le résultat est un cluster où aucune entité unique ne comprend les compromis entre latence, coût et capacité, causant une instabilité opérationnelle.

Comment cela fonctionne

Le conflit naît parce que des boucles de contrôle indépendantes manipulent des variables interdépendantes, créant quatre modes de défaillance courants. Premièrement, HPA et VPA entrent en collision via un effondrement du dénominateur. HPA calcule les répliques cibles en divisant l'utilisation réelle par les demandes de ressources déclarées. Lorsque VPA réduit ces demandes pour diminuer le gaspillage, le dénominateur se contracte. Même de légères augmentations du trafic poussent alors les pourcentages d'utilisation au-delà des seuils HPA, déclenchant une mise à l'échelle agressive vers l'extérieur. À mesure que plus de pods partagent la charge, l'utilisation par pod diminue, incitant VPA à réduire davantage les demandes, créant une spirale mortelle de conteneurs microscopiques.

Deuxièmement, HPA natif et KEDA entrent dans une condition de course multi-écriveurs. Si une file d'attente d'événements connaît un pic, KEDA augmente la mise à l'échelle du déploiement pour vider l'arrière-plan. Cependant, si les pods de travail sont lourds en E/S avec une faible utilisation CPU, HPA voit une faible utilisation et réduit la mise à l'échelle du déploiement. Le serveur API enregistre des événements de remise à l'échelle alternés tandis que le débit réel de traitement stagne. Troisièmement, les moteurs GitOps créent un ping-pong de dérive. Lorsque HPA met à l'échelle un déploiement pendant un pic, les outils GitOps signalent l'application comme désynchronisée. Si la synchronisation automatique est activée, le système réinitialise le déploiement à sa référence, affamant l'application de capacité lors des pics de demande.

Enfin, les autoscalers de nœuds amplifient ces inefficacités. Des outils comme Karpenter provisionnent des instances physiques strictement sur la base des demandes de conteneurs déclarées, et non de la consommation réelle. Si un conteneur demande un cœur CPU mais n'utilise que 150 millicœurs, le planificateur réserve le cœur entier. Cela multiplie les erreurs de dimensionnement en amont en factures cloud massives, laissant l'utilisation moyenne du CPU du cluster autour de huit pour cent malgré un provisionnement lourd.

Détails clés

• Cinq contrôleurs distincts (HPA, VPA, KEDA, Karpenter, GitOps) fournissent souvent des recommandations de dimensionnement contradictoires pour la même charge de travail.
• HPA et VPA entrent en conflit car VPA réduit les demandes de ressources, ce qui gonfle artificiellement le pourcentage d'utilisation utilisé par HPA.
• KEDA et HPA se disputent l'écriture sur la même sous-ressource /scale, causant des oscillations du nombre de répliques lorsque l'utilisation CPU ne correspond pas à la profondeur de la file d'attente.
• Les outils GitOps peuvent annuler les changements dynamiques de mise à l'échelle effectués par HPA, restaurant des configurations de référence incapables de gérer les charges de trafic actuelles.
• Les autoscalers de nœuds provisionnent la capacité sur la base des demandes déclarées plutôt que de l'utilisation réelle, conduisant à un surprovisionnement significatif et à une faible utilisation du cluster.
• Les autoscalers actuels fonctionnent comme des réflexes automatisés dépourvus d'un système nerveux central pour coordonner leurs actions.

Pourquoi c'est important

Pour les ingénieurs logiciels et les équipes de plateforme, ces conflits se traduisent directement par des services peu fiables et des coûts gonflés. Le thrashing causé par les contrôleurs concurrents entraîne des pics de latence lors des surcharges de demande, car la mise à l'échelle réactive attend que les seuils soient franchis avant d'agir. Cette nature réactive signifie que les nouvelles ressources de calcul sont initialisées seulement après que les performances ont déjà dégradé, violant les objectifs de niveau de service (SLO). De plus, l'incapacité de GitOps à refléter précisément la réalité de production rompt les principes d'infrastructure déclarative, rendant les futures mises à jour risquées et difficiles à auditer.

L'impact financier est tout aussi sévère. Parce que les autoscalers de nœuds dépendent de demandes déclarées souvent gonflées pour prévenir les conflits HPA-VPA, les clusters fonctionnent avec de vastes quantités de capacité inutilisée. Les ingénieurs passent beaucoup de temps à ajuster manuellement les seuils et à réconcilier les diffs Git au lieu de se concentrer sur le développement de fonctionnalités. L'absence d'un plan de contrôle unifié signifie que chaque décision de mise à l'échelle est une optimisation locale qui peut nuire à l'état global du système, empêchant les équipes d'atteindre simultanément l'efficacité des coûts et la haute disponibilité.

Ce que vous pouvez faire

• Auditez votre cluster pour détecter les contrôleurs concurrents ciblant les mêmes ressources, vérifiant spécifiquement l'utilisation simultanée de HPA et VPA sur les mêmes déploiements.
• Évaluez si les politiques de synchronisation automatique GitOps annulent des événements de mise à l'échelle légitimes, et envisagez de configurer soigneusement l'ignorance des différences pour les nombres de répliques.
• Surveillez le ratio entre les demandes de ressources déclarées et l'utilisation réelle pour identifier où les autoscalers de nœuds provisionnent une capacité excédentaire.
• Consolidiez les signaux de mise à l'échelle en utilisant exclusivement la mise à l'échelle pilotée par événements pour les charges de travail basées sur des files d'attente, en désactivant HPA basé sur le CPU pour ces services spécifiques.
• Implémentez des stratégies de mise à l'échelle prédictive qui analysent les modèles de consommation historiques pour préchauffer la capacité avant que les pics de trafic ne surviennent.
• Recherchez des solutions offrant un plan de contrôle unifié capable d'ingérer plusieurs signaux et de prendre des décisions conjointes sur le dimensionnement horizontal et vertical.