[Live-Übertragungsvorschau] Werden große Models Programmierer ersetzen? "

QoS-Verwaltungsfunktionen können Online- und Offline-Anwendungen einheitlich planen und so die Ressourcennutzung erheblich verbessern.

Quelle |. ByteDance-Infrastrukturteam

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

In diesem Artikel wird das Papier „ Gödel: Unified Large-Scale Resource Management and Scheduling at Bytedance “ interpretiert , das vom Bytedance Infrastructure Orchestration and Scheduling-Team auf der SoCC 2023, der wichtigsten internationalen Cloud-Computing-Konferenz, veröffentlicht wurde .

Link zum Papier: dl.acm.org/doi/proceedings/10.1145/3620678

Das Papier stellt ein von ByteDance vorgeschlagenes Hochdurchsatz-Aufgabenplanungssystem auf Basis von Kubernetes vor, das die Mischung von Online-Aufgaben und Offline-Aufgaben unterstützt. Ziel ist es, das Ressourcenzuteilungsproblem verschiedener Arten von Aufgaben in großen Rechenzentren effektiv zu lösen und zu verbessern Ressourcen des Rechenzentrums.

Derzeit unterstützt das Planungssystem die Verwaltung extrem großer Cluster mit Zehntausenden von Knoten und bietet Ressourcen-Pooling-Funktionen für mehrere Arten von Aufgaben, darunter Microservices, Batch-, Streaming-Aufgaben und KI. Seit 2022 wird es stapelweise in den internen Rechenzentren von ByteDance eingesetzt. Es wurde nachgewiesen, dass der Gödel-Scheduler in Spitzenzeiten eine CPU-Auslastung von >60 % und eine GPU-Auslastung von >95 % bietet , mit einem Spitzenplanungsdurchsatz von fast 5.000 Pods/Sek .

Einführung

In den letzten Jahren sind mit der rasanten Entwicklung der Geschäftsbereiche von ByteDance die internen Geschäftstypen des Unternehmens immer vielfältiger geworden, darunter Microservices, geförderte Suche (Empfehlung/Werbung/Suche), Big Data, maschinelles Lernen und der Umfang der Speicherung und andere Unternehmen expandieren rasant, und auch die Menge der dafür benötigten Rechenressourcen nimmt rapide zu. In der Anfangszeit verfügten das Online- und Offline-Geschäft von Bytedance über unabhängige Ressourcenpools, und zwischen den Unternehmen wurde eine separate Poolverwaltung eingeführt. Um das explosionsartige Wachstum der Online-Geschäftsanfragen während wichtiger Festivals und Großveranstaltungen bewältigen zu können, müssen Infrastrukturteams oft im Voraus planen und dem Online-Geschäftsressourcenpool einige Offline-Geschäftsressourcen zur Verfügung stellen. Obwohl diese Methode vorübergehenden Bedarf decken kann, ist der Ressourcenleihprozess zwischen verschiedenen Ressourcenpools langwierig, komplex und ineffizient. Gleichzeitig führen unabhängige Ressourcenpools zu hohen Kosten für die gemeinsame Ansiedlung von Offline-Unternehmen, und die Obergrenze für eine Verbesserung der Ressourcennutzung ist ebenfalls sehr begrenzt. Um dieses Problem zu lösen, schlägt das Papier den einheitlichen Offline-Scheduler Gödel vor, der darauf abzielt, mit denselben Planern Offline-Dienste einheitlich zu planen und zu verwalten und ein Ressourcen-Pooling zu realisieren, wodurch die Ressourcennutzung und die Ressourcenelastizität optimiert werden Erfahrung und reduzieren den Betriebs- und Wartungsdruck. Der Gödel-Scheduler basiert auf der Kubernetes-Plattform und kann den nativen Kubernetes-Scheduler nahtlos ersetzen. Er ist dem nativen Kubernetes-Scheduler und anderen Schedulern in der Community in Bezug auf Leistung und Funktionalität überlegen.

Den Motor starten

ByteDance betreibt Dutzende extrem großer Multi-Cluster-Rechenzentren. Täglich werden Dutzende Millionen Container-Aufgaben erstellt und gelöscht. Der durchschnittliche Aufgabendurchsatz eines einzelnen Clusters beträgt während der Abendspitze >1000 Pods/Sekunde. Die Geschäftsprioritäten, Betriebsmodi und Ressourcenanforderungen dieser Aufgaben sind unterschiedlich. Es ist eine sehr herausfordernde Aufgabe, diese Aufgaben effizient und sinnvoll zu planen, um eine hohe Ressourcenauslastung und -elastizität aufrechtzuerhalten und gleichzeitig ein qualitativ hochwertiges Aufgaben-SLA sicherzustellen.

Durch Recherche haben wir herausgefunden, dass keiner der in der Community häufig verwendeten Cluster-Scheduler die Anforderungen von ByteDance gut erfüllen kann:

Obwohl der native Kubernetes-Scheduler sehr gut für die Planung von Mikrodiensten geeignet ist und eine Vielzahl flexibler Planungssemantiken bietet, ist seine Unterstützung für Offline-Dienste nicht zufriedenstellend. Gleichzeitig hat der native Kubernetes-Scheduler einen geringen Planungsdurchsatz (< 200 Pods/Sek.). ), Die unterstützte Clustergröße ist ebenfalls begrenzt (normalerweise <= 5000 Knoten) und kann die enormen Online-Geschäftsplanungsanforderungen innerhalb von ByteDance nicht erfüllen.
Volcano aus der CNCF-Community ist ein Planer, der hauptsächlich auf Offline-Dienste ausgerichtet ist und die Planungsanforderungen von Offline-Diensten (z. B. Batch, Offline-Schulung usw.) erfüllen kann (z. B. Gang-Scheduling). Allerdings ist auch die Durchsatzrate bei der Planung relativ gering und es können nicht gleichzeitig Online-Dienste unterstützt werden.
YARN ist ein weiteres beliebtes Cluster-Ressourcen-Management-Tool und war lange Zeit die erste Wahl für die Offline-Geschäftsplanung. Es bietet nicht nur eine gute Unterstützung für die Planungssemantik, die für Offline-Dienste wie Batch- und Offline-Training erforderlich ist, sondern verfügt auch über eine hohe Planungsdurchsatzrate und kann große Cluster unterstützen. Der größte Nachteil besteht jedoch darin, dass es Online-Unternehmen wie Microservices nicht gut unterstützt und die Planungsanforderungen von Online- und Offline-Unternehmen nicht gleichzeitig erfüllen kann.

Daher hofft ByteDance, einen Scheduler zu entwickeln , der die Vorteile von Kubernetes und YARN kombiniert, um Ressourcenpools zu öffnen und alle Arten von Unternehmen einheitlich zu verwalten. Basierend auf der obigen Diskussion wird erwartet, dass der Scheduler die folgenden Eigenschaften aufweist:

Einheitlicher Ressourcenpool

Alle Rechenressourcen im Cluster sind sowohl online als auch offline sichtbar und verschiedenen Aufgaben zuordenbar. Reduzieren Sie die Ressourcenfragmentierungsrate sowie die Betriebs- und Wartungskosten des Clusters.

Verbesserte Ressourcennutzung

Mischen Sie Aufgaben unterschiedlicher Art und Priorität in den Cluster- und Knotendimensionen, um die Nutzung der Clusterressourcen zu verbessern.

Hohe Ressourcenelastizität

In den Dimensionen Cluster und Knoten können Rechenressourcen flexibel und schnell zwischen Diensten unterschiedlicher Priorität übertragen werden. Bei gleichzeitiger Verbesserung der Ressourcennutzung sind die Ressourcenprioritätszuteilungsrechte und das SLA für hochwertige Dienste jederzeit gewährleistet.

Hoher Planungsdurchsatz

Im Vergleich zum nativen Kubernetes-Scheduler und dem Volcano-Scheduler der Community müssen sowohl Online- als auch Offline-Dienste den Planungsdurchsatz erheblich verbessern. Erfüllen Sie Geschäftsanforderungen > 1000 Pods/Sek.

Topologiebewusste Planung

Die Ressourcenmikrotopologie der Kandidatenknoten wird bei Planungsentscheidungen und nicht erst bei der Zulassung durch Kubelet identifiziert, und geeignete Knoten werden für die Planung basierend auf den Geschäftsanforderungen ausgewählt.

Einführung in Gödel

Gödel Scheduler ist ein verteilter Scheduler, der in Kubernetes-Clusterumgebungen verwendet wird und Online- und Offline-Dienste einheitlich planen kann. Er kann eine gute Skalierbarkeit und Planungsqualität bieten und gleichzeitig Offline-Geschäftsfunktions- und Leistungsanforderungen erfüllen. Wie in der folgenden Abbildung dargestellt, hat Gödel Scheduler eine ähnliche Struktur wie der native Kubernetes-Scheduler und besteht aus drei Komponenten: Dispatcher, Scheduler und Binder. Der Unterschied besteht darin, dass zur Unterstützung größerer Cluster und zur Bereitstellung eines höheren Planungsdurchsatzes die Scheduler-Komponente mehrere Instanzen haben und eine optimistische gleichzeitige Planung übernehmen kann, während Dispatcher und Binder in einer einzigen Instanz ausgeführt werden.

Kernkomponenten

Der Dispatcher ist der Eingang zum gesamten Planungsprozess und hauptsächlich für die Aufgabenwarteschlange, Aufgabenverteilung, Knotenpartitionierung usw. verantwortlich. Es besteht hauptsächlich aus mehreren Teilen: Sorting Policy Manager, Dispatching Policy Manager, Node Shuffler und Scheduler Maintainer.

Sortierrichtlinien-Manager : Hauptsächlich für Warteschlangenaufgaben verantwortlich. Derzeit werden Warteschlangenstrategien wie FIFO, DRF und FairShare implementiert. In Zukunft werden weitere Warteschlangenstrategien hinzugefügt, z. B. prioritätswertbasiert usw.
Dispatching Policy Manager : Hauptsächlich verantwortlich für die Verteilung von Aufgaben an verschiedene Scheduler-Instanzen und die Unterstützung verschiedener Verteilungsstrategien durch Plug-in-Konfiguration. Die aktuelle Standardstrategie basiert auf LoadBalance.
Node Shuffler : Hauptverantwortlich für die Partitionierung von Clusterknoten basierend auf der Anzahl der Scheduler-Instanzen. Jeder Knoten kann sich nur in einer Partition befinden. Jede Scheduler-Instanz entspricht einer Partition. Wenn eine Scheduler-Instanz funktioniert, gibt sie den Knoten in ihrer eigenen Partition Priorität. Wenn kein Knoten gefunden wird, der die Anforderungen erfüllt, sucht sie nach Knoten in anderen Partitionen. Wenn sich der Clusterstatus ändert, beispielsweise durch das Hinzufügen oder Löschen von Knoten, oder wenn sich die Anzahl der Scheduler ändert, werden die Knoten durch Node Shuffle entsprechend der tatsächlichen Situation neu aufgeteilt.
Scheduler-Betreuer : Hauptverantwortlich für die Aufrechterhaltung des Status jeder Scheduler-Instanz, einschließlich des Integritätsstatus der Scheduler-Instanz, des Ladestatus, der Anzahl der Partitionsknoten usw.

Der Scheduler empfängt Aufgabenanforderungen vom Dispatcher und ist dafür verantwortlich, spezifische Planungs- und Vorabentscheidungsentscheidungen für Aufgaben zu treffen, führt diese jedoch nicht tatsächlich aus. Wie der native Scheduler von Kubernetes ermittelt auch der Scheduler von Gödel eine Planungsentscheidung über eine Reihe von Plugins an verschiedenen Links. Beispielsweise werden die folgenden beiden Plugins verwendet, um Knoten zu finden, die die Anforderungen erfüllen.

Filter-Plugins: aufgabenbasierte Ressourcenanforderungen, Herausfiltern von Knoten, die die Anforderungen nicht erfüllen;
Scoring-Plugins: Bewerten Sie die oben gefilterten Knoten und wählen Sie den am besten geeigneten Knoten aus.

Im Gegensatz zum nativen Kubernetes-Scheduler ermöglicht Gödels Scheduler die verteilte Ausführung mehrerer Instanzen . Für sehr große Cluster und Szenarien, die einen hohen Durchsatz erfordern, können wir mehrere Scheduler-Instanzen entsprechend den Anforderungen konfigurieren. Zu diesem Zeitpunkt wird jede Scheduler-Instanz unabhängig und parallel geplant. Bei der Auswahl eines Knotens wird zunächst die Partition ausgewählt, zu der die Instanz gehört. Dies kann jedoch nur dann eine lokale Optimalität gewährleisten Knoten in der lokalen Partition werden aus der Partition ausgewählt, zu der die Instanz gehört. Knoten werden in den Partitionen anderer Instanzen ausgewählt. Dies kann jedoch zu einem Konflikt führen, d. h., mehrere Scheduler-Instanzen wählen gleichzeitig denselben Knoten aus . Je mehr Scheduler-Instanzen vorhanden sind, desto größer ist die Wahrscheinlichkeit eines Konflikts. Daher sollte die Anzahl der Instanzen angemessen eingestellt werden. Mehr ist nicht immer besser.

Um sowohl Online- als auch Offline-Aufgaben zu unterstützen, verwendet Gödel Scheduler außerdem eine zweistufige Planungssemantik , das heißt, es unterstützt die zweistufige Planung von Scheduling Unit und Pod's Running Unit, die Geschäftsbereitstellungen wie Pod Group oder ReplicaSet darstellen. Die spezifische Verwendung wird später vorgestellt.

Binder ist hauptsächlich für die Prüfung optimistischer Konflikte, die Durchführung spezifischer Vorkaufsvorgänge, die Vorbereitung von Aufgaben vor der Bindung, z. B. das dynamische Erstellen von Speichervolumes, und schließlich die Durchführung von Bindungsvorgängen verantwortlich. Im Allgemeinen ähnelt es dem Kubernetes-Binder-Workflow, aber in Gödel muss sich Binder mit mehr Konflikten befassen, die durch mehrere Scheduler-Instanzen verursacht werden. Sobald ein Konflikt entdeckt wird, rufen Sie sofort zurück und vereinbaren Sie einen neuen Termin. Bei Vorbelegungsvorgängen prüft Binder, ob mehrere Schduler-Instanzen versuchen, dieselbe Instanz (z. B. Victim Pod) vorzubehalten. Wenn ein solches Problem besteht, verarbeitet Binder nur die erste Vorbelegung und lehnt Vorbehaltsanfragen der verbleibenden Schduler-Instanzen ab. Für die Gruppen-/Co-Scheduling muss der Binder Konflikte (falls vorhanden) für alle Pods in der Pod-Gruppe behandeln. Entweder werden alle Pod-Konflikte gelöst und jeder Pod separat gebunden, oder die Planung der gesamten Pod-Gruppe wird abgelehnt.

CNR steht für Custom Node Resource, eine CRD, die von ByteDance erstellt wurde, um Knoten-Echtzeitinformationen zu ergänzen. Obwohl es nicht Teil von Gödel Scheduler selbst ist, kann es Gödels Planungssemantik verbessern. Dieses CRD definiert nicht nur die Ressourcenmenge und den Status eines Knotens, sondern auch die Mikrotopologie der Ressourcen, wie z. B. den CPU-/Speicherverbrauch und die verbleibende Ressourcenmenge auf jedem Socket des Dual-Socket-Knotens. Dadurch kann der Planer beim Planen von Aufgaben mit Mikrotopologie-Affinitätsanforderungen geeignete Knoten basierend auf dem von CNR beschriebenen Knotenstatus auswählen.

Im Vergleich zu nativem Kubernetes, das nur den Topologie-Manager verwendet, kann die Verwendung von CNR den Planungsfehler vermeiden, der bei Kubelet auftritt, wenn Pods für Knoten geplant werden, die die Topologieeinschränkungen nicht erfüllen. Wenn ein Pod erfolgreich auf dem Knoten erstellt wurde, wird der CNR durch den zu Katalyst gehörenden Knotenagenten aktualisiert .

Verwandte Lektüre: „ Katalyst: Bytedance Cloud Native Cost Optimization Practice “

zweistufige Planung

Als Bytedance Gödel entwarf, bestand eines seiner Hauptziele darin, die Planungsanforderungen von Online- und Offline-Diensten zu erfüllen. Um dieses Ziel zu erreichen, führt Gödel zwei Ebenen der Planungssemantik ein, nämlich Scheduling Unit und Running Unit.

Ersteres entspricht einem bereitgestellten Job und besteht aus einer oder mehreren laufenden Einheiten. Wenn ein Benutzer beispielsweise einen Job über die Kubernetes-Bereitstellung bereitstellt, wird der Job einer Planungseinheit zugeordnet und jeder Pod, der die Aufgabe ausführt, entspricht einer laufenden Einheit. Im Gegensatz zur direkten Pod-orientierten Planung von nativem Kubernetes verwendet Gödels zweistufiges Planungsframework immer den Gesamtstatus der Planungseinheit als Zulassungsprinzip. Wenn eine Planungseinheit als planbar gilt, werden die darin enthaltenen laufenden Einheiten (d. h. Pods) der Reihe nach geplant.

Die Regel zur Beurteilung, ob eine Planungseinheit planbar ist, lautet, dass es >= Min_Member-Laufeinheiten gibt, die die Planungsbedingungen erfüllen, d. h. wenn der Planer Knoten finden kann, die die Ressourcenanforderungen für genügend Pods in einem Job erfüllen, wird der Job berücksichtigt planbar sein. Zu diesem Zeitpunkt wird jeder Pod vom Planer der Reihe nach für den angegebenen Knoten geplant. Andernfalls werden nicht alle Pods geplant und die gesamte Jobbereitstellung wird abgelehnt.

Es ist ersichtlich, dass Min_Member der Planungseinheit ein sehr wichtiger Parameter ist. Durch das Festlegen unterschiedlicher Min_Member können die Anforderungen verschiedener Szenarien erfüllt werden. Der Wertebereich von Min_Member ist [1, Anzahl der laufenden Einheiten].

Wenn es beispielsweise auf das Microservice-Geschäft ausgerichtet ist, wird Min_Member auf 1 gesetzt. Solange die Ressourcenanforderung einer laufenden Einheit/eines Pods in jeder Planungseinheit erfüllt werden kann, kann die Planung durchgeführt werden. Zu diesem Zeitpunkt läuft der Gödel-Scheduler im Wesentlichen genauso wie der native Kubernetes-Scheduler.

Bei Offline-Diensten wie Batch- und Offline-Training, die eine Gang-Semantik erfordern, entspricht der Wert von Min_Member der Anzahl der laufenden Einheiten/Pods (einige Dienste können je nach tatsächlichem Bedarf auch auf einen Wert zwischen 1 und der Anzahl der laufenden Einheiten angepasst werden). ), d. h. die Planung beginnt erst, wenn alle Pods Ressourcenanforderungen erfüllen können. Der Wert von Min_Member wird automatisch basierend auf dem Geschäftstyp und den Parametern in der Geschäftsbereitstellungsvorlage festgelegt.

Leistungsoptimierung

Aufgrund der eigenen Geschäftsanforderungen von ByteDance gelten hohe Anforderungen an die Durchsatzplanung. Eines der Designziele von Gödel ist die Bereitstellung eines hohen Durchsatzes. Zu diesem Zweck platziert der Gödel-Scheduler den zeitaufwändigsten Teil des Filterknotens in einem Multi-Instanz-Scheduler, der gleichzeitig ausgeführt werden kann. Einerseits ist die Anzahl der Schduler-Instanzen nicht immer besser, da mehrere Instanzen auf Konflikte stoßen. Andererseits reicht die Leistungsverbesserung durch mehrere Instanzen allein nicht aus, um den abendlichen Spitzenwert von 1000–2000 Pods/zu bewältigen. s in einem einzelnen Cluster. Um die Planungseffizienz weiter zu verbessern, hat Gödel weitere Optimierungen in den folgenden Aspekten vorgenommen.

Kandidatenknoten zwischenspeichern

Beim Filtern von Knoten sind Filter und Priorisieren die beiden zeitaufwändigsten Teile. Ersteres filtert verfügbare Knoten basierend auf Ressourcenanforderungen, und letzteres bewertet Kandidatenknoten, um den am besten geeigneten Knoten zu finden. Wenn die Laufgeschwindigkeit dieser beiden Teile erhöht werden kann, wird der gesamte Planungszyklus stark komprimiert.

Das Entwicklungsteam von ByteDance stellte fest, dass zwar Rechenressourcen von verschiedenen Anwendungen aus unterschiedlichen Geschäftseinheiten genutzt werden, alle oder die meisten Pods einer Anwendung eines bestimmten Geschäftsbenutzers jedoch in der Regel die gleichen Ressourcenanforderungen haben.

Beispiel: Eine soziale APP benötigt 20.000 HTTP-Server. Jeder Server benötigt 4 CPU-Kerne und 8 GB Speicher. Ein Big-Data-Team muss ein Datenanalyseprogramm mit 10.000 Unteraufgaben ausführen, die jeweils 1 CPU-Kern und 4 GB Arbeitsspeicher erfordern.

Die meisten Pods in diesen massenhaft erstellten Aufgaben haben dieselbe Ressourcenanwendung, dasselbe Netzwerksegment, dieselbe Geräteaffinität und andere Anforderungen. Dann erfüllen die vom Filter-Plugin ausgewählten Kandidatenknoten die Anforderungen des ersten Pods und erfüllen wahrscheinlich auch die Anforderungen anderer Pods für diese Aufgabe.

Daher speichert der Gödel-Scheduler Kandidatenknoten nach der Planung des ersten Pods zwischen und sucht in der nächsten Planungsrunde vorzugsweise nach verfügbaren Knoten aus dem Cache. Sofern sich der Clusterstatus nicht ändert (Knoten werden hinzugefügt oder gelöscht) oder Pods mit unterschiedlichen Ressourcenanforderungen gefunden werden, besteht keine Notwendigkeit, die Knoten im Cluster jede Runde erneut zu scannen. Knoten, die während des Planungsprozesses keine Ressourcen zuzuweisen haben, werden aus dem Cache entfernt und die Sortierung wird basierend auf dem Clusterstatus angepasst. Diese Optimierung kann den Knotenüberprüfungsprozess erheblich optimieren, wenn eine Gruppe von Pods für denselben Geschäftsbenutzer geplant wird, und im Idealfall die Zeitkomplexität von O(n) auf O(1) reduziert werden .

Reduzieren Sie den Anteil der gescannten Knoten

Obwohl die obige Optimierung den Konstruktionsprozess von Kandidatenknoten verkürzen kann, müssen alle Knoten im Cluster erneut gescannt werden, wenn sich der Clusterstatus oder die Ressourcenanwendung ändert.

Um den Zeitaufwand weiter zu reduzieren, passte Gödel das Scanverhältnis der Kandidatenliste an und verwendete die lokale optimale Lösung als ungefähren Ersatz für die globale optimale Lösung. Da während des Planungsprozesses genügend Kandidatenknoten für alle Running Units/Pods gefunden werden müssen, scannt Gödel standardmäßig mindestens die Anzahl der Running Units-Knoten. Basierend auf der Analyse historischer Daten scannt Gödel standardmäßig die Anzahl der Running Units + 50 Knoten Kandidaten zu finden. Wird keine passende Nummer gefunden, wird die gleiche Nummer erneut gescannt. In Kombination mit der Zwischenspeicherung von Kandidatenknoten verringert diese Methode den Zeitaufwand des Planers bei der Suche nach geeigneten Knoten für Pods erheblich.

Optimieren Sie Datenstrukturen und Algorithmen

Zusätzlich zu den beiden oben genannten Optimierungen optimiert der Gödel-Scheduler auch kontinuierlich Datenstrukturen und Algorithmen:

Um die Kandidatenknotenliste kostengünstig zu verwalten und den durch häufige Rekonstruktion der Knotenliste verursachten Mehraufwand zu vermeiden. Gödel rekonstruierte den NodeList-Wartungsmechanismus des nativen Kubernetes-Schedulers , löste die Leistungsprobleme extrem großer Produktionscluster durch Diskretisierung der Knotenliste und erzielte bessere Knotendiskretisierungseffekte bei geringerem Overhead.

Um die Gesamtressourcennutzung zu verbessern, mischt und implementiert ByteDance hochwertige Online-Aufgaben und minderwertige Offline-Aufgaben. Aufgrund der Gezeiteneigenschaften des Geschäfts kehren viele Online-Geschäfte während der Abendspitze zurück, was häufig eine hochfrequente Bevorzugung minderwertiger Offline-Geschäfte erfordert. Der Preemption-Prozess erfordert eine große Menge an Suchberechnungen, und häufiges Preemption beeinträchtigt die Gesamtarbeitseffizienz des Schedulers erheblich. Um dieses Problem zu lösen, führt der Gödel-Scheduler eine mehrdimensionale Bereinigungsstrategie basierend auf Pods und Knoten ein , die eine schnelle Wiederherstellung des Vorkaufsdurchsatzes und eine deutliche Reduzierung der Vorkaufsverzögerung ermöglicht.

Experimentelle Ergebnisse

Der Artikel bewertet die Leistung des Gödel-Schedulers im Hinblick auf Planungsdurchsatz, Clustergröße usw.

Zunächst verglich ByteDance für das Microservice-Geschäft Gödel (einzelne Instanz) mit dem nativen Kubernetes-Scheduler. In Bezug auf die Clusterskalierung kann natives Kubernetes standardmäßig nur einen maximalen Cluster von 5.000 Knoten unterstützen, und der maximale Planungsdurchsatz beträgt weniger als 200 Pods/s. Nach der Verwendung von KubeBrain , einem leistungsstarken Open-Source-Schlüsselwertspeicher von Byte , kann natives Kubernetes größere Cluster unterstützen und auch der Planungsdurchsatz wird deutlich verbessert. Aber die Leistung der Kombination aus Kubernetes + KubeBrain ist immer noch viel geringer als bei Gödel. Gödel kann eine Leistung von 2.600 Pods/s auf einem Cluster mit 5.000 Knoten erreichen. Selbst bei 20.000 Knoten sind es immer noch etwa 2.000 Pods/s, was mehr als dem Zehnfachen der Leistung des nativen Kubernetes-Schedulers entspricht .

Um einen höheren Planungsdurchsatz zu erreichen, kann Gödel mehrere Instanzen aktivieren. Die Abbildung rechts unten zeigt 1–6 Scheduler-Instanzen, die nacheinander in einem Cluster von 10.000 Knoten geöffnet werden. Der Durchsatz steigt in der Anfangsphase allmählich an und der Spitzenwert kann etwa 4.600 Pods/s erreichen. Wenn die Anzahl der Instanzen jedoch 5 überschreitet, nimmt die Leistung ab. Der Grund dafür ist, dass es umso mehr Konflikte zwischen den Instanzen gibt, was sich auf die Planungseffizienz auswirkt. Daher gilt nicht, dass je mehr Planungsinstanzen desto besser sind.

Für Offline-Aufgaben mit Gang-semantischen Anforderungen vergleicht das Papier Gödel mit YARN und K8s-Vulkan, die häufig in der Open-Source-Community verwendet werden. Es ist deutlich zu erkennen, dass die Leistung von Gödel nicht nur viel höher ist als die von K8s-Vulkan, sondern auch fast doppelt so hoch wie die von YARN. Gödel unterstützt die gleichzeitige Planung von Online- und Offline-Aufgaben. Das Papier simuliert das Szenario, in dem verschiedene Unternehmen gemischt werden, indem der Anteil der im System übermittelten Offline-Aufgaben geändert wird. Es ist ersichtlich, dass die Leistung von Gödel unabhängig vom Anteil der Offline-Dienste relativ stabil ist und der Durchsatz bei etwa 2.000 Pods/s gehalten wird .

Um zu demonstrieren, warum Gödel eine so große Leistungsverbesserung aufweist, konzentriert sich das Papier auf die Analyse der Beiträge zweier wichtiger Optimierungen: „ Caching-Kandidatenknoten “ und „ Reduzierung des Scan-Verhältnisses “. Wie in der Abbildung unten gezeigt, wurde das vorherige Experiment mit der Vollversion von Gödel wiederholt, wobei Gödel nur die Knoten-Cache-Optimierung aktivierte und Gödel nur das reduzierte Scan-Verhältnis aktivierte. Die experimentellen Ergebnisse bewiesen, dass diese beiden Hauptoptimierungselemente etwa dazu beitrugen 60 % bzw. 30 % Leistungsverbesserung.

Neben der Verwendung von Benchmarks zur Bewertung der extremen Leistung von Gödel zeigt das Papier auch die tatsächlichen Erfahrungen von ByteDance mit dem Gödel-Scheduler in einer Produktionsumgebung und zeigt, dass Gödel über gute Fähigkeiten in Bezug auf Ressourcenpooling, Elastizität und Zirkulation verfügt.

Die linke Abbildung unten beschreibt die Ressourcenzuteilung von Online-Aufgaben und Offline-Aufgaben in einem bestimmten Cluster innerhalb eines bestimmten Zeitraums. Zu Beginn verbrauchen Online-Aufgaben nur wenige Ressourcen und eine große Menge an Rechenressourcen wird Offline-Aufgaben mit niedrigerer Priorität zugewiesen. Wenn bei Online-Aufgaben aufgrund eines besonderen Ereignisses (Notfall, Schnellsuche usw.) ein Anstieg des Ressourcenbedarfs auftritt, weist Gödel den Online-Aufgaben sofort Ressourcen zu, während der Umfang der Ressourcenzuweisung für Offline-Aufgaben schnell abnimmt. Wenn der Spitzenwert erreicht ist, beginnen Online-Aufgaben, die Ressourcenanforderungen zu reduzieren, und der Planer verschiebt Ressourcen erneut auf Offline-Aufgaben. Durch Offline-Pooling und dynamischen Ressourcentransfer kann ByteDance stets eine hohe Ressourcenauslastung aufrechterhalten. Während der abendlichen Spitzenzeiten erreicht die durchschnittliche Ressourcenrate des Clusters mehr als 60 % und kann auch während der Tiefststandsphase am Tag bei etwa 40 % gehalten werden.

Zusammenfassung und Zukunftsaussichten

Das Papier stellt Gödel vor, ein Planungssystem, das vom ByteDance-Orchestrierungs- und Planungsteam entworfen und entwickelt wurde, um Offline-Ressourcenpools zu vereinheitlichen. Das Planungssystem unterstützt die gleichzeitige Planung von Online- und Offline-Aufgaben in sehr großen Clustern, unterstützt die Bündelung, Elastizität und Zirkulation von Ressourcen und verfügt über einen hohen Planungsdurchsatz. Seit Gödel im Jahr 2022 stapelweise im eigenen Rechenzentrum von ByteDance eingeführt wurde, hat es die Co-Location-Anforderungen der meisten Infield-Unternehmen erfüllt und eine durchschnittliche Ressourcenauslastung von mehr als 60 % während der Abendspitze und einen Planungsdurchsatz von etwa 5.000 Pods/ S .

Zukünftig wird das Orchestrierungs- und Planungsteam die Erweiterung und Optimierung des Gödel-Schedulers weiter vorantreiben, die Planungssemantik weiter bereichern, die Reaktionsfähigkeit des Systems verbessern und die Wahrscheinlichkeit von Konflikten in Situationen mit mehreren Instanzen verringern wird auch die Planungskapazitäten, das Design und die Entwicklung von Gödel Rescheduler aufbauen und stärken. Durch die Zusammenarbeit von Gödel Scheduler und Rescheduler wird eine angemessene Zuweisung von Clusterressourcen über den gesamten Zyklus hinweg erreicht.

Gödel Scheduler ist derzeit Open Source . Wir heißen Community-Entwickler und Unternehmen herzlich willkommen, sich der Community anzuschließen und an der gemeinsamen Projektentwicklung teilzunehmen: github.com/kubewharf/godel-scheduler !

Scannen Sie den QR-Code, um der Open-Source-Community von ByteDance beizutreten

Interpretation des SoCC-Papiers: Wie ByteDance eine einheitliche Ressourcenplanung in großen Clustern implementiert