[Aperçu de diffusion en direct] Les grands modèles remplaceront-ils les programmeurs ? "

Les capacités de gestion de la qualité de service peuvent planifier uniformément les applications en ligne et hors ligne, améliorant ainsi considérablement l'utilisation des ressources.

Source | Équipe d'infrastructure ByteDance

Open Source | github.com/kubewharf/godel-scheduler

Cet article interprète l'article « Gödel : Unified Large-Scale Resource Management and Scheduling at Bytedance » publié par l'équipe d'orchestration et de planification de l'infrastructure de Bytedance lors de SoCC 2023, la plus grande conférence internationale sur le cloud computing .

Lien papier : dl.acm.org/doi/proceedings/10.1145/3620678

Le document présente un système de planification de tâches à haut débit basé sur Kubernetes proposé par ByteDance qui prend en charge le mélange de tâches en ligne et de tâches hors ligne. Il vise à résoudre efficacement le problème d'allocation des ressources de différents types de tâches dans les centres de données à grande échelle et à améliorer leur fonctionnement. ressources du centre de données. Utilisation, résilience et débit de planification.

Actuellement, le système de planification prend en charge la gestion de clusters à très grande échelle comportant des dizaines de milliers de nœuds et offre des capacités de mutualisation de ressources pour plusieurs types de tâches, notamment les microservices, les tâches par lots, les tâches de streaming et l'IA. Depuis 2022, il a été déployé par lots dans les centres de données internes de ByteDance. Il a été vérifié que le planificateur Gödel fournit une utilisation du processeur > 60 % et une utilisation du GPU > 95 % pendant les périodes de pointe , avec un débit de planification maximal de près de 5 000 pods/s .

introduction

Au cours des dernières années, avec le développement rapide des secteurs d'activité de ByteDance, les types d'activités internes de l'entreprise sont devenus de plus en plus diversifiés, notamment les microservices, la recherche promue (recommandation/publicité/recherche), le big data, l'apprentissage automatique, l'échelle de stockage. et d'autres entreprises se développent rapidement, et la quantité de ressources informatiques requises pour elles augmente également rapidement. Au début, les activités en ligne et hors ligne de Bytedance disposaient de pools de ressources indépendants, et une gestion distincte des pools a été adoptée entre les entreprises. Afin de faire face à la croissance explosive des demandes commerciales en ligne lors de festivals et d'événements importants, les équipes d'infrastructure doivent souvent planifier à l'avance et prêter certaines ressources commerciales hors ligne au pool de ressources commerciales en ligne. Bien que cette méthode puisse répondre à des besoins temporaires, le processus de prêt de ressources entre différents pools de ressources est long, complexe et inefficace. Dans le même temps, les pools de ressources indépendants entraînent des coûts élevés de colocalisation entre les entreprises hors ligne, et le plafond permettant d'améliorer l'utilisation des ressources est également très limité. Afin de résoudre ce problème, le document propose le planificateur hors ligne unifié Gödel, qui vise à utiliser le même ensemble de planificateurs pour planifier et gérer uniformément les services hors ligne et réaliser une mise en commun des ressources, améliorant ainsi l'utilisation et l'élasticité des ressources. expérience et réduire la pression d’exploitation et de maintenance. Le planificateur Gödel est basé sur la plate-forme Kubernetes et peut remplacer de manière transparente le planificateur natif Kubernetes. Il est supérieur au planificateur natif Kubernetes et aux autres planificateurs de la communauté en termes de performances et de fonctionnalités.

Demarre le moteur

ByteDance exploite des dizaines de centres de données multiclusters à très grande échelle. Des dizaines de millions de tâches conteneurisées sont créées et supprimées chaque jour. Le débit moyen des tâches d'un seul cluster pendant la pointe du soir est supérieur à 1 000 pods/s. Les priorités commerciales, les modes de fonctionnement et les besoins en ressources de ces tâches sont différents. Comment planifier ces tâches de manière efficace et raisonnable pour maintenir une utilisation et une élasticité élevées des ressources tout en garantissant un SLA de tâche de haute qualité et des exigences en ressources différentes est un défi très difficile.

Grâce à des recherches, nous avons constaté qu'aucun des planificateurs de cluster couramment utilisés dans la communauté ne peut bien répondre aux exigences de ByteDance :

Bien que le planificateur natif de Kubernetes soit très adapté à la planification de microservices et fournisse une variété de sémantiques de planification flexibles, sa prise en charge des services hors ligne n'est pas satisfaisante, car le planificateur natif de Kubernetes a un faible débit de planification (< 200 pods/s). ), La taille du cluster pris en charge est également limitée (généralement <= 5 000 nœuds) et ne peut pas répondre aux énormes besoins de planification commerciale en ligne au sein de ByteDance.
Volcano de la communauté CNCF est un planificateur principalement destiné aux services hors ligne, qui peut répondre aux besoins de planification des services hors ligne (par exemple, batch, formation hors ligne, etc.) (par exemple, planification de gangs). Cependant, son débit de planification est également relativement faible et il ne peut pas prendre en charge les services en ligne en même temps.
YARN est un autre outil de gestion des ressources de cluster populaire et constitue depuis longtemps le premier choix pour la planification d'activités hors ligne. Il prend non seulement en charge la sémantique de planification requise pour les services hors ligne tels que la formation par lots et hors ligne, mais dispose également d'un débit de planification élevé et peut prendre en charge des clusters à grande échelle. Cependant, son principal inconvénient est qu'il ne prend pas bien en charge les activités en ligne telles que les microservices et qu'il ne peut pas répondre simultanément aux besoins de planification des entreprises en ligne et hors ligne.

Par conséquent, ByteDance espère développer un planificateur combinant les avantages de Kubernetes et de YARN pour ouvrir des pools de ressources et gérer uniformément tous les types d'entreprises. Sur la base de la discussion ci-dessus, le planificateur devrait avoir les caractéristiques suivantes :

Pool de ressources unifié

Toutes les ressources informatiques du cluster sont visibles et attribuables à diverses tâches en ligne et hors ligne. Réduisez le taux de fragmentation des ressources ainsi que les coûts d’exploitation et de maintenance des clusters.

Utilisation améliorée des ressources

Mélangez des tâches de différents types et priorités dans les dimensions du cluster et des nœuds pour améliorer l'utilisation des ressources du cluster.

Haute élasticité des ressources

Dans les dimensions cluster et nœud, les ressources informatiques peuvent être transférées de manière flexible et rapide entre des services de priorités différentes. Tout en améliorant l'utilisation des ressources, les droits d'allocation prioritaire des ressources et le SLA des services de haute qualité sont garantis à tout moment.

Débit de planification élevé

Par rapport au planificateur natif de Kubernetes et au planificateur Volcano de la communauté, les services en ligne et hors ligne doivent considérablement améliorer le débit de planification. Répondez aux exigences de l’entreprise > 1 000 pods/s.

Planification basée sur la topologie

La microtopologie des ressources des nœuds candidats est identifiée lors de la prise de décisions de planification plutôt que lorsque kubelet l'admet, et les nœuds appropriés sont sélectionnés pour la planification en fonction des besoins de l'entreprise.

Présentation de Gödel

Gödel Scheduler est un planificateur distribué utilisé dans les environnements de cluster Kubernetes qui peut planifier uniformément des services en ligne et hors ligne. Il peut fournir une bonne évolutivité et une bonne qualité de planification tout en répondant aux exigences de fonctions commerciales et de performances hors ligne. Comme le montre la figure ci-dessous, Gödel Scheduler a une structure similaire au planificateur natif de Kubernetes et se compose de trois composants : Dispatcher, Scheduler et Binder. La différence est que pour prendre en charge des clusters plus grands et fournir un débit de planification plus élevé, son composant Scheduler peut être multi-instance et adopter une planification simultanée optimiste, tandis que Dispatcher et Binder s'exécutent dans une seule instance.

composants principaux

Dispatcher est l'entrée de l'ensemble du processus de planification et est principalement responsable de la mise en file d'attente des tâches, de la distribution des tâches, du partitionnement des nœuds, etc. Il se compose principalement de plusieurs parties : Sorting Policy Manager, Dispatching Policy Manager, Node Shuffler et SchedulerMaintener.

Sort Policy Manager : principalement responsable des tâches de mise en file d'attente. Il implémente actuellement des stratégies de file d'attente telles que FIFO, DRF et FairShare. D'autres stratégies de mise en file d'attente seront ajoutées à l'avenir, telles que celles basées sur la valeur de priorité, etc.
Dispatching Policy Manager : principalement responsable de la distribution des tâches à différentes instances du planificateur et de la prise en charge de différentes stratégies de distribution via la configuration du plug-in. La stratégie par défaut actuelle est basée sur LoadBalance.
Node Shuffler : principalement responsable du partitionnement des nœuds du cluster en fonction du nombre d'instances du planificateur. Chaque nœud ne peut être que dans une seule partition. Chaque instance de Scheduler correspond à une partition. Lorsqu'une instance de Scheduler fonctionne, elle donnera la priorité aux nœuds de sa propre partition. Si aucun nœud répondant aux exigences n'est trouvé, elle recherchera des nœuds dans d'autres partitions. Si l'état du cluster change, comme l'ajout ou la suppression de nœuds, ou si le nombre de planificateurs change, la redistribution des nœuds redivisera les nœuds en fonction de la situation réelle.
Responsable du planificateur : principalement responsable de la maintenance de l'état de chaque instance du planificateur, y compris l'état de santé de l'instance du planificateur, l'état de charge, le nombre de nœuds de partition, etc.

Scheduler reçoit les demandes de tâches de Dispatcher et est chargé de prendre des décisions spécifiques de planification et de préemption pour les tâches, mais ne les exécute pas réellement. Comme le planificateur natif de Kubernetes, le planificateur de Gödel détermine également une décision de planification via une série de plugins sur différents liens. Par exemple, les deux plugins suivants sont utilisés pour trouver les nœuds qui répondent aux exigences.

Plugins de filtrage : demandes de ressources basées sur des tâches, filtrage des nœuds qui ne répondent pas aux exigences ;
Plugins de notation : notez les nœuds filtrés ci-dessus et sélectionnez le nœud le plus approprié.

Contrairement au planificateur natif de Kubernetes, le planificateur de Gödel permet à plusieurs instances de s'exécuter de manière distribuée . Pour les clusters à très grande échelle et les scénarios nécessitant un débit élevé, nous pouvons configurer plusieurs instances de planificateur pour répondre aux besoins. À l'heure actuelle, chaque instance du planificateur est planifiée indépendamment et en parallèle. Lors de la sélection d'un nœud, il est d'abord sélectionné dans la partition à laquelle l'instance appartient. Cela offre de meilleures performances, mais cela ne peut garantir l'optimalité locale qu'en l'absence d'instance appropriée. nœud dans la partition locale, il sera sélectionné dans la partition à laquelle appartient l'instance. Les nœuds sont sélectionnés dans les partitions d'autres instances, mais cela peut provoquer un conflit, c'est-à-dire que plusieurs instances du planificateur sélectionnent le même nœud en même temps. . Plus il y a d'instances de planificateur, plus le risque de conflit est grand. Par conséquent, le nombre d’instances doit être défini de manière appropriée. Plus n’est pas toujours mieux.

De plus, afin de prendre en charge les tâches en ligne et hors ligne, Gödel Scheduler adopte une sémantique de planification à deux niveaux , c'est-à-dire qu'il prend en charge la planification à deux niveaux de l'unité de planification et de l'unité d'exécution du pod représentant des déploiements commerciaux tels que Pod Group ou ReplicaSet. L'utilisation spécifique sera présentée plus tard.

Binder est principalement responsable de la vérification optimiste des conflits, de l'exécution d'opérations de préemption spécifiques, de la préparation des tâches avant la liaison, telles que la création dynamique de volumes de stockage et enfin de l'exécution des opérations de liaison. En général, il est similaire au workflow Kubernetes Binder, mais à Gödel, Binder doit gérer davantage de conflits causés par plusieurs instances de Scheduler. Une fois qu'un conflit est découvert, rappelez-le immédiatement et reprogrammez-le. Pour les opérations de préemption, Binder vérifie s'il existe plusieurs instances de Schduler essayant de préempter la même instance (c'est-à-dire Victim Pod). Si un tel problème existe, Binder ne gère que la première préemption et rejette les demandes de préemption émises par les instances Schduler restantes. Pour la planification groupée/co-planifiée, le classeur doit gérer les conflits (le cas échéant) pour tous les pods du groupe de pods. Soit tous les conflits de pods sont résolus et chaque pod est lié séparément, soit la planification de l'ensemble du groupe de pods est rejetée ;

CNR signifie Custom Node Resource, qui est un CRD créé par ByteDance pour compléter les informations en temps réel sur les nœuds. Bien qu'il ne fasse pas partie de Gödel Scheduler lui-même, il peut améliorer la sémantique de planification de Gödel. Ce CRD définit non seulement la quantité de ressources et l'état d'un nœud, mais définit également la micro-topologie des ressources, telle que la consommation CPU/mémoire et la quantité de ressources restante sur chaque socket du nœud à double socket. Cela permet au planificateur de sélectionner les nœuds appropriés en fonction de l'état des nœuds décrit par CNR lors de la planification de tâches avec des exigences d'affinité microtopologique.

Par rapport à Kubernetes natif qui utilise uniquement un gestionnaire de topologie, l'utilisation de CNR peut éviter l'échec de planification que rencontre kubelet lorsque les pods sont planifiés sur des nœuds qui ne répondent pas aux restrictions de topologie. Si un Pod est créé avec succès sur le nœud, le CNR sera mis à jour par l'agent de nœud appartenant à Katalyst .

Lecture connexe : « Katalyst : Bytedance Cloud Native Cost Optimization Practice »

planification à deux niveaux

Lorsque Bytedance a conçu Gödel, l'un de ses principaux objectifs était de répondre aux besoins de planification des services en ligne et hors ligne. Pour atteindre cet objectif, Gödel introduit deux niveaux de sémantique de planification, à savoir Scheduling Unit et Running Unit.

Le premier correspond à un job déployé et se compose d’une ou plusieurs Running Units. Par exemple, lorsqu'un utilisateur déploie une tâche via Kubernetes Deployment, la tâche est mappée à une unité de planification et chaque pod exécutant la tâche correspond à une unité d'exécution. Contrairement à la planification directe orientée pod de Kubernetes natif, le cadre de planification à deux niveaux de Gödel utilisera toujours le statut global de l'unité de planification comme principe d'admission. Lorsqu'une unité de planification est considérée comme planifiable, les unités en cours d'exécution (c'est-à-dire les pods) qu'elle contient seront planifiées dans l'ordre.

La règle pour déterminer si une unité de planification est planifiable est qu'il y a >= Min_Member Running Units qui remplissent les conditions de planification, c'est-à-dire que lorsque le planificateur peut trouver des nœuds qui répondent aux besoins en ressources pour suffisamment de pods dans une tâche, la tâche est considérée comme être programmable. À ce moment-là, chaque pod sera programmé tour à tour sur le nœud désigné par le planificateur. Sinon, tous les pods ne seront pas planifiés et l'intégralité du déploiement de la tâche sera rejetée.

On voit que Min_Member of Scheduling Unit est un paramètre très important. La définition de différents Min_Member peut répondre aux besoins de différents scénarios. La plage de valeurs de Min_Member est [1, nombre d'unités courantes].

Par exemple, lorsqu'il est orienté vers une activité de microservices, Min_Member est défini sur 1. Tant que la demande de ressources d'une unité d'exécution/pod dans chaque unité de planification peut être satisfaite, la planification peut être effectuée. À ce stade, le planificateur Gödel fonctionne essentiellement de la même manière que le planificateur natif de Kubernetes.

Face à des services hors ligne tels que Batch et formation hors ligne qui nécessitent une sémantique de gang, la valeur de Min_Member est égale au nombre d'unités d'exécution/pods (certains services peuvent également être ajustés à une valeur comprise entre 1 et nombre d'unités d'exécution en fonction des besoins réels. ) , c'est-à-dire que la planification ne démarre que lorsque tous les pods peuvent répondre aux demandes de ressources. La valeur de Min_Member est automatiquement définie en fonction du type d'entreprise et des paramètres du modèle de déploiement d'entreprise.

Optimisation des performances

En raison des besoins commerciaux propres de ByteDance, celui-ci a des exigences élevées en matière de planification du débit. L'un des objectifs de conception de Gödel est de fournir un débit élevé. À cette fin, le planificateur Gödel place la partie la plus chronophage du nœud de filtrage dans un planificateur multi-instance pouvant s'exécuter simultanément. D'une part, comme plusieurs instances rencontreront des conflits, le nombre d'instances Schduler n'est pas toujours meilleur ; d'autre part, l'amélioration des performances apportée par plusieurs instances à elle seule n'est pas suffisante pour faire face au pic du soir de 1 000 à 2 000 pods/. s dans un seul cluster. Afin d'améliorer encore l'efficacité de la planification, Gödel a procédé à d'autres optimisations dans les aspects suivants.

Mettre en cache les nœuds candidats

Dans le processus de filtrage des nœuds, Filtrer et Prioriser sont les deux parties les plus chronophages. Le premier filtre les nœuds disponibles en fonction des demandes de ressources, et le second note les nœuds candidats pour trouver le nœud le plus approprié. Si la vitesse d'exécution de ces deux parties peut être augmentée, l'ensemble du cycle de planification sera considérablement compressé.

L'équipe de développement de ByteDance a observé que même si les ressources informatiques sont utilisées par différentes applications provenant de différentes unités commerciales, tous ou la plupart des pods d'une application d'un certain utilisateur professionnel ont généralement les mêmes besoins en ressources.

Exemple : une application sociale s'applique à la création de 20 000 serveurs HTTP. Chaque serveur nécessite 4 cœurs de processeur et 8 Go de mémoire. Une équipe Big Data doit exécuter un programme d'analyse de données avec 10 000 sous-tâches, chacune nécessitant 1 cœur de processeur et 4 Go de mémoire.

La plupart des pods dans ces tâches créées en masse ont la même application de ressources, le même segment de réseau, la même affinité de périphérique et d'autres exigences. Ensuite, les nœuds candidats sélectionnés par le Filter Plugin répondent aux besoins du premier Pod et sont susceptibles de répondre aux besoins des autres Pods pour cette tâche.

Par conséquent, le planificateur Gödel met en cache les nœuds candidats après avoir planifié le premier pod et recherche préférentiellement les nœuds disponibles dans le cache lors du prochain cycle de planification. À moins que l'état du cluster ne change (des nœuds sont ajoutés ou supprimés) ou que des pods avec des besoins en ressources différents soient rencontrés, il n'est pas nécessaire de réanalyser les nœuds du cluster à chaque tour. Les nœuds qui n'ont aucune ressource à allouer pendant le processus de planification seront supprimés du cache et le tri sera ajusté en fonction de l'état du cluster. Cette optimisation peut considérablement optimiser le processus de sélection des nœuds lors de la planification d'un groupe de pods pour le même utilisateur professionnel, idéalement, elle peut réduire la complexité temporelle de O(n) à O(1) .

Réduire la proportion de nœuds analysés

Bien que l'optimisation ci-dessus puisse réduire le processus de construction des nœuds candidats, si l'état du cluster ou l'application des ressources change, tous les nœuds du cluster doivent toujours être réanalysés.

Afin de réduire davantage le temps perdu, Gödel a ajusté le taux d'analyse de la liste de candidats et a utilisé la solution optimale locale comme remplacement approximatif de la solution optimale globale. Puisqu'il est nécessaire de trouver suffisamment de nœuds candidats pour toutes les unités d'exécution/pods pendant le processus de planification, Gödel analysera au moins le nombre de nœuds d'unités d'exécution. Sur la base de l'analyse des données historiques, Gödel analyse le nombre d'unités d'exécution + 50 nœuds par défaut. pour trouver des candidats. Si aucun numéro approprié n’est trouvé, le même numéro sera à nouveau scanné. Cette méthode, combinée à la mise en cache des nœuds candidats, réduira considérablement le temps nécessaire au planificateur pour trouver les nœuds appropriés pour les pods.

Optimiser les structures de données et les algorithmes

En plus des deux optimisations ci-dessus, le planificateur Gödel optimise également en permanence les structures de données et les algorithmes :

Afin de maintenir la liste de nœuds candidats à faible coût et d'éviter les frais généraux causés par une reconstruction fréquente de la liste de nœuds. Gödel a reconstruit le mécanisme de maintenance NodeList du planificateur natif Kubernetes , a résolu les problèmes de performances des clusters de production à très grande échelle en discrétisant la liste de nœuds et a obtenu de meilleurs effets de discrétisation des nœuds avec une surcharge inférieure ;

Afin d'améliorer l'utilisation globale des ressources, ByteDance mélange et déploie des tâches en ligne de haute qualité et des tâches hors ligne de mauvaise qualité. En raison des caractéristiques de marée des entreprises, un grand nombre d'entreprises en ligne reviennent pendant la pointe du soir, ce qui nécessite souvent une préemption à haute fréquence des entreprises hors ligne de mauvaise qualité. Le processus de préemption implique une grande quantité de calculs de recherche, et une préemption fréquente affecte sérieusement l'efficacité globale du travail du planificateur. Afin de résoudre ce problème, le planificateur Gödel introduit une stratégie d'élagage multidimensionnel basée sur les pods et les nœuds , qui permet au débit de préemption de récupérer rapidement et au délai de préemption d'être considérablement réduit.

Résultats expérimentaux

L'article évalue les performances de l'ordonnanceur Gödel en termes de débit de planification, de taille de cluster, etc.

Premièrement, pour le secteur des microservices, ByteDance a comparé Gödel (instance unique) au planificateur natif de Kubernetes. En termes d'échelle de cluster, Kubernetes natif ne peut prendre en charge qu'un cluster maximum de 5 000 nœuds par défaut, et le débit de planification maximum est inférieur à 200 pods/s. Après avoir utilisé KubeBrain , un magasin open source de valeurs-clés hautes performances de Byte , Kubernetes natif peut prendre en charge des clusters plus grands et le débit de planification est également considérablement amélioré. Mais les performances de la combinaison Kubernetes + KubeBrain sont encore bien inférieures à celles de Gödel. Gödel peut atteindre une performance de 2 600 pods/s sur un cluster de 5 000 nœuds. Même à 20 000 nœuds, il y a encore environ 2 000 pods/s, soit plus de 10 fois les performances du planificateur natif de Kubernetes .

Afin d'obtenir un débit de planification plus élevé, Gödel peut activer plusieurs instances. La figure de droite ci-dessous représente 1 à 6 instances de planificateur ouvertes en séquence dans un cluster de 10 000 nœuds. Le débit augmente progressivement au cours de la phase initiale et la valeur maximale peut atteindre environ 4 600 pods/s. Mais lorsque le nombre d'instances dépasse 5, les performances diminuent. La raison en est que plus il y a d'instances, plus il y a de conflits entre instances, ce qui affecte l'efficacité de la planification. Par conséquent, ce n’est pas que plus il y a d’instances de planification, mieux c’est.

Pour les tâches hors ligne avec des exigences sémantiques de Gang, l'article compare Gödel avec YARN et le volcan K8s couramment utilisés dans la communauté open source. On voit clairement que les performances de Gödel sont non seulement bien supérieures à celles du volcan K8s, mais aussi près du double de celles de YARN. Gödel prend en charge la planification simultanée de tâches en ligne et hors ligne. Le document simule le scénario dans lequel différentes entreprises sont mélangées en modifiant la proportion de tâches hors ligne soumises dans le système. On constate que quelle que soit la proportion de services hors ligne, les performances de Gödel sont relativement stables, avec un débit maintenu autour de 2 000 Pods/s .

Afin de démontrer pourquoi Gödel présente une si grande amélioration des performances, l'article se concentre sur l'analyse des contributions de deux optimisations majeures : « la mise en cache des nœuds candidats » et la « réduction du taux d'analyse ». Comme le montre la figure ci-dessous, l'expérience précédente a été répétée en utilisant la version complète de Gödel, Gödel avec uniquement l'optimisation du cache de nœuds activée et Gödel avec uniquement un taux d'analyse réduit activé. Les résultats expérimentaux ont prouvé que ces deux principaux éléments d'optimisation ont contribué environ. 60 % et 60 % respectivement. Amélioration des performances de 30 % .

En plus d'utiliser des références pour évaluer les performances extrêmes de Gödel, le document montre également l'expérience réelle de ByteDance en utilisant le planificateur de Gödel dans un environnement de production, montrant que Gödel possède de bonnes capacités en matière de mise en commun des ressources, d'élasticité et de circulation.

La figure de gauche ci-dessous décrit l'allocation des ressources des tâches en ligne et des tâches hors ligne dans un certain cluster sur une certaine période de temps. Au début, les tâches en ligne consomment peu de ressources et une grande quantité de ressources informatiques est allouée aux tâches hors ligne de moindre priorité. Lorsque les tâches en ligne connaissent une augmentation de la demande de ressources en raison d'un événement spécial (urgence, recherche rapide, etc.), Gödel alloue immédiatement des ressources aux tâches en ligne et la quantité de ressources allouée aux tâches hors ligne diminue rapidement. Lorsque le pic passe, les tâches en ligne commencent à réduire les demandes de ressources et le planificateur transfère à nouveau les ressources vers les tâches hors ligne. Grâce à la mise en commun hors ligne et au transfert dynamique de ressources, ByteDance peut toujours maintenir une utilisation élevée des ressources. Aux heures de pointe du soir, le taux de ressources moyen du cluster atteint plus de 60 % et il peut également être maintenu à environ 40 % pendant la phase creuse de la journée.

Résumé et perspectives d'avenir

L'article présente Gödel, un système de planification conçu et développé par l'équipe d'orchestration et de planification de ByteDance pour unifier les pools de ressources hors ligne. Le système de planification prend en charge la planification simultanée de tâches en ligne et hors ligne dans des clusters à très grande échelle, prend en charge la mise en commun, l'élasticité et la circulation des ressources, et offre un débit de planification élevé. Depuis que Gödel a été lancé par lots dans le propre centre de données de ByteDance en 2022, il a répondu aux besoins de colocalisation de la plupart des entreprises sur le terrain, atteignant une utilisation moyenne des ressources de plus de 60 % pendant la pointe du soir et un débit de planification d'environ 5 000 pods/ s .

À l'avenir, l'équipe d'orchestration et de planification continuera à promouvoir l'expansion et l'optimisation du planificateur Gödel, à enrichir davantage la sémantique de planification, à améliorer la réactivité du système et à réduire la probabilité de conflits dans les situations multi-instances. Tout en optimisant la planification initiale, ils continueront à promouvoir l'expansion et l'optimisation du planificateur Gödel. construira et renforcera également les capacités de réacheminement du système, la conception et le développement de Gödel Rescheduler. Grâce au travail collaboratif de Gödel Scheduler et Rescheduler, une allocation raisonnable des ressources du cluster tout au long du cycle est obtenue.

Le planificateur Gödel est actuellement open source . Nous invitons sincèrement les développeurs et les entreprises communautaires à rejoindre la communauté et à participer à la co-construction du projet avec nous. L'adresse du projet est : github.com/kubewharf/godel-scheduler !

Scannez le code QR pour rejoindre la communauté open source ByteDance

Interprétation du document SoCC : Comment ByteDance implémente la planification unifiée des ressources dans des clusters à grande échelle