Kubernetes v1.32 active QueueingHint pour optimiser le débit de planification des pods

Dans un article publié sur le Kubernetes Blog en décembre 2024, Kensei Nakada de Tetrate.io a détaillé une amélioration interne significative du planificateur Kubernetes introduite dans la version 1.32. Cette mise à jour stabilise et active par défaut le mécanisme QueueingHint, une fonctionnalité conçue pour réduire la charge de traitement inutile du planificateur en gérant intelligemment les tentatives de replanification des pods non planifiables.

Ce qui s'est passé

Le planificateur Kubernetes est chargé d'assigner les nouveaux Pods aux nœuds au sein d'un cluster. Il traite ces Pods séquentiellement, ce qui signifie que plus les clusters deviennent grands, plus le débit du planificateur devient un goulot d'étranglement critique pour les performances. Au fil des années, le groupe SIG Scheduling de Kubernetes a implémenté diverses améliorations pour augmenter ce débit. La dernière amélioration majeure, incluse dans Kubernetes v1.32, introduit un élément de contexte de planification appelé QueueingHint.

Avant cette version, le planificateur gérait les Pods non planifiés à l'aide de trois structures de données internes : ActiveQ pour les nouveaux Pods ou ceux prêts à être réessayés, BackoffQ pour les Pods attendant la fin d'une période de backoff après des tentatives échouées, et le Pool de Pods Non Planifiables (Unschedulable Pod Pool) pour les Pods qui ne peuvent actuellement pas être planifiés. Lorsqu'un Pod échoue lors d'un cycle de planification, il est généralement déplacé vers le Pool de Pods Non Planifiables. Le planificateur ne déplace ces Pods vers ActiveQ ou BackoffQ que si des changements spécifiques du cluster surviennent et pourraient résoudre l'échec de planification.

Auparavant, la logique déterminant quels événements du cluster pouvaient résoudre un échec était large et souvent inefficace. Les plugins enregistraient des événements généraux du cluster, tels que la création ou la suppression d'objets, via EnqueueExtensions. Si un événement enregistré se produisait, le planificateur réessayait le Pod, même si l'événement était sans rapport avec la raison spécifique de l'échec précédent. De plus, une fonctionnalité interne appelée preCheck tentait de filtrer les événements en fonction des contraintes principales, mais elle n'était pas extensible aux plugins personnalisés et manquait de précision.

Comment cela fonctionne

QueueingHint affine ce mécanisme de réessai en permettant à chaque plugin de s'abonner à des événements spécifiques du cluster et de prendre une décision granulaire quant à savoir si un événement entrant pourrait réellement rendre un Pod spécifique planifiable. Au lieu de réessayer largement un Pod chaque fois qu'un événement enregistré se produit, le planificateur demande désormais au plugin concerné si le changement spécifique est pertinent.

Par exemple, considérons un Pod nommé pod-a qui nécessite une affinité de Pod spécifique. Si le plugin InterPodAffinity rejette pod-a parce qu'aucun nœud existant n'a de Pod correspondant, pod-a entre dans le Pool de Pods Non Planifiables. Le planificateur enregistre que InterPodAffinity a causé le rejet. Avec QueueingHint, le plugin InterPodAffinity s'abonne aux mises à jour des étiquettes de Pod. Si un Pod en cours d'exécution reçoit une mise à jour d'étiquette qui correspond désormais à l'exigence d'affinité de pod-a, le rappel QueueingHint du plugin détecte cette correspondance et invite le planificateur à déplacer pod-a de nouveau dans ActiveQ ou BackoffQ. Si la mise à jour d'étiquette ne correspond pas, le Pod reste dans le pool, économisant ainsi un cycle de planification.

Cette fonctionnalité est en développement depuis Kubernetes v1.28. Elle a été initialement activée par défaut, mais désactivée dans une version de correctif en raison d'une fuite de mémoire signalée. Entre v1.28 et v1.31, les contributeurs ont corrigé la fuite de mémoire et implémenté QueueingHints dans tous les plugins intégrés (in-tree). Dans v1.32, la fonctionnalité est de nouveau activée par défaut, l'implémentation étant terminée et les problèmes de stabilité résolus.

Détails clés

• Version : La fonctionnalité QueueingHint est activée par défaut dans Kubernetes v1.32.
• Mécanisme : QueueingHint permet aux plugins d'évaluer des événements spécifiques du cluster pour décider si un Pod non planifiable doit être réessayé.
• Problème précédent : Les méthodes antérieures utilisaient un enregistrement d'événements large, entraînant des réessais de planification inutiles pour les Pods qui restaient non planifiables.
• Extensibilité : Contrairement à l'ancienne fonctionnalité preCheck, QueueingHint est extensible et fonctionne avec des plugins personnalisés, répondant au problème #110175.
• Historique : La fonctionnalité a été introduite expérimentalement dans v1.28, désactivée en raison d'une fuite de mémoire, puis stabilisée au fil des versions suivantes.
• Composant : L'optimisation cible la file d'attente de planification, spécifiquement le déplacement des Pods entre le Pool de Pods Non Planifiables et ActiveQ/BackoffQ.

Pourquoi c'est important

Pour les ingénieurs gérant des clusters Kubernetes à grande échelle, le débit du planificateur impacte directement la vitesse de déploiement des applications et l'utilisation des ressources. Chaque fois que le planificateur tente de placer un Pod qui n'a aucune chance d'être planifié, il consomme des cycles CPU et ajoute de la latence au traitement des autres Pods en attente. En éliminant ces réessais futiles, QueueingHint réduit la surcharge computationnelle sur le plan de contrôle.

Cette optimisation est particulièrement précieuse pour les clusters ayant des exigences de planification complexes, tels que ceux utilisant des règles d'affinité ou d'anti-affinité de Pod étendues. Dans de tels environnements, les Pods entrent fréquemment dans le Pool de Pods Non Planifiables. Sans logique de réessai précise, le planificateur pourrait réveiller ces Pods à plusieurs reprises pour des changements de cluster sans rapport, créant du bruit et retardant la planification des Pods viables. QueueingHint garantit que seuls les changements significatifs déclenchent un réessai, maintenant ainsi l'efficacité du pipeline de planification.

De plus, l'extensibilité de QueueingHint profite aux développeurs qui écrivent des plugins de planification personnalisés. Auparavant, les plugins personnalisés ne pouvaient pas tirer parti du filtrage efficace fourni par preCheck, les obligeant à compter sur des déclencheurs d'événements plus larges et moins efficaces. Désormais, les plugins personnalisés peuvent implémenter leur propre logique QueueingHint, assurant une intégration transparente avec le mécanisme de réessai optimisé du planificateur. Cela conduit à des performances plus cohérentes tant pour les flux de travail de planification standard que personnalisés.

Ce que vous pouvez faire

• Mettez à niveau vos clusters de test vers Kubernetes v1.32 pour observer le comportement stabilisé de QueueingHint.
• Examinez vos plugins de planification personnalisés pour vous assurer qu'ils implémentent les rappels QueueingHint pour une gestion précise des événements.
• Surveillez les métriques du planificateur pour constater une réduction des taux de réessai et une amélioration du débit dans les scénarios de forte charge.
• Vérifiez les schémas d'utilisation résiduelle de la mémoire si vous avez précédemment rencontré des problèmes avec l'implémentation expérimentale de v1.28.
• Consultez la documentation du SIG Scheduling de Kubernetes pour obtenir des directives détaillées sur l'implémentation de QueueingHint dans les plugins personnalisés.
• Évaluez les performances du cluster avant et après la mise à niveau pour quantifier la réduction des cycles de planification inutiles.