Vereinfachte Konzepte für die automatische Skalierung von KI-/ML-Arbeitslasten in GKE

Dieses Dokument bietet einen Überblick über die Konzepte für das Autoscaling von KI-/ML-Arbeitslasten in Google Kubernetes Engine (GKE).

Dieses Dokument richtet sich an Entwickler von maschinellem Lernen (ML), die noch keine Erfahrung mit GKE haben. Wir empfehlen Ihnen, die folgenden Dokumente der Reihe zu lesen, um den Einstieg in die Verwendung von GKE für KI/ML-Arbeitslasten zu erleichtern:

  1. Vorteile von GKE für die KI‑/ML-Inferenz
  2. KI‑/ML-Modellinferenz in GKE
  3. Vereinfachte Konzepte für die automatische Skalierung von KI-/ML-Arbeitslasten in GKE (dieses Dokument)

Hinweise

Sie sollten mit den folgenden Konzepten vertraut sein:

Die Herausforderung: Spitzenbedarf decken

Cymbal Shops, ein fiktiver Onlinehändler, bereitet sich auf sein jährliches Verkaufsereignis vor. Das KI-basierte Empfehlungssystem des Geschäfts muss personalisierte Vorschläge in Echtzeit für eine große Anzahl von Onlinekäufern liefern.

Wenn die Empfehlungs-Engine langsamer wird, leidet die Nutzerfreundlichkeit und es gehen Umsätze verloren. Es ist jedoch nicht kosteneffizient, während des normalen Traffics übermäßige Serverkapazität bereitzustellen. Ziel ist es, dass Ressourcen automatisch an die Nachfrage angepasst werden, um eine gute Nutzererfahrung zu gewährleisten und gleichzeitig die Kosten im Blick zu behalten.

Die Lösung: On-Demand-Autoscaling

GKE-Autoscaling funktioniert wie ein Filialleiter, der sich auf einen Verkaufsanstieg vorbereitet. Anstatt ein riesiges Gebäude ständig mit Personal zu besetzen und mit Strom zu versorgen, passt der Manager die gesamte Kapazität des Geschäfts – Personal, Verkaufsfläche und Ausstattung – dynamisch an die Bedürfnisse der Käufer zu einem bestimmten Zeitpunkt an.

GKE wendet dasselbe Prinzip an: Die Ressourcen, die Ihrer Anwendung zugewiesen sind (sowohl Arbeitslast als auch Infrastruktur), werden automatisch an die Echtzeitnachfrage angepasst.

Geschäftliche Vorteile von GKE-Autoscaling

Durch die Kombination von horizontalen und vertikalen Skalierungsstrategien bietet GKE einen robusten Ansatz mit drei Hauptvorteilen:

  • Kostenoptimierung: Sie zahlen nur für die von Ihnen verwendeten Rechenressourcen und vermeiden die Kosten für eine Überdimensionierung. GKE-Autoscaling verhindert Verschwendung, indem Ihre Anwendungen automatisch an ihre tatsächlichen CPU- und Arbeitsspeicheranforderungen angepasst werden. Außerdem kann teure, spezielle Hardware (z. B. GPUs) nur für die Momente bereitgestellt werden, in denen sie benötigt wird, und sie wird entfernt, wenn der Job abgeschlossen ist.
  • Höhere Zuverlässigkeit und Leistung: Ihre Anwendung kann automatisch skaliert werden (weitere Kopien hinzufügen), um plötzliche Trafficspitzen zu bewältigen und die Stabilität für Ihre Nutzer zu gewährleisten. Gleichzeitig trägt das Autoscaling von GKE dazu bei, häufige OOM-Fehler („Out Of Memory“) zu vermeiden, die zum Absturz von Anwendungen führen können. Bei anspruchsvollen KI-/ML-Jobs trägt sie dazu bei, dass die erforderliche leistungsstarke Hardware verfügbar ist, damit die Jobs effizient ausgeführt und rechtzeitig abgeschlossen werden können.
  • Geringerer operativer Aufwand: Die multidimensionale Autoscaling-Strategie von GKE vereinfacht die Ressourcenverwaltung erheblich. GKE automatisiert die komplexen Aufgaben der Anpassung von Ressourcenanfragen und der Verwaltung spezieller Knotenpools für verschiedene Hardware. Durch diese Automatisierung können sich Ihre Entwicklungsteams auf die Anwendungsentwicklung konzentrieren, anstatt die Infrastruktur zu optimieren.

Autoscaling von Arbeitslasten

Mit dem Autoscaling von Arbeitslasten wird die Leistung Ihrer Anwendung automatisch an die Nachfrage angepasst. GKE verwendet ein zweistufiges Autoscaling-System, um die Ressourcen Ihrer Anwendung effizient zu verwalten.

Horizontales Pod-Autoscaling (HPA): Hinzufügen weiterer Ressourcen

Das horizontale Pod-Autoscaling (HPA) überwacht die Ressourcennutzung der Pods Ihrer Anwendung. In unserem Vergleich sind die Pods die „Verkäufer“ und der HPA der „Teamleiter“, der beobachtet, wie beschäftigt die Verkäufer sind.

Wenn die Nachfrage nach den Pods steigt, stellt HPA automatisch weitere Pods bereit, um die Last zu verteilen. Wenn die Nachfrage sinkt, beendet das HPA inaktive Pods, um Ressourcen zu sparen.

Weitere Informationen finden Sie unter Horizontales Pod-Autoscaling.

Vertikales Pod-Autoscaling (VPA): Ressourcen leistungsfähiger machen

Während sich die horizontale Skalierung auf die Erhöhung der Anzahl der Ressourcen konzentriert, ist die vertikale Skalierung eine ergänzende Strategie, die sich auf die Erhöhung der Leistung vorhandener Ressourcen konzentriert. Im Kontext unseres Beispiels mit dem Ladengeschäft geht es nicht darum, mehr Personal einzustellen, sondern die Fähigkeiten des aktuellen Teams zu verbessern, um die individuelle Effizienz zu steigern.

Dieser Ansatz der vertikalen Skalierung auf Pod-Ebene wird vom vertikalen Pod-Autoscaler (VPA) verwaltet. Der VPA analysiert den Ressourcenverbrauch Ihrer Anwendung und passt die CPU- und Arbeitsspeicheranforderungen des Pods nach oben oder unten an die tatsächliche Nutzung an.

Der VPA kann die Ressourcenanforderungen und ‑limits eines Pods anpassen, indem er den Pod beispielsweise neu bereitstellt, um von 1 CPU und 16 GB auf 4 CPUs und 64 GB zu skalieren. Dabei wird der Pod mit seiner neuen, leistungsfähigeren Konfiguration neu gestartet, um seine Arbeitslast besser zu bewältigen.

Weitere Informationen finden Sie in den folgenden Ressourcen:

HPA und VPA ergänzen sich. HPA passt die Anzahl der Pods als Reaktion auf Änderungen des Traffics an und VPA sorgt dafür, dass jeder dieser Pods die richtige Größe für seine Aufgabe hat. Diese Skalierungsstrategien verhindern die Verschwendung von Ressourcen und unnötige Kosten und sorgen dafür, dass Ihre App bei Traffic-Schwankungen reaktionsfähig und verfügbar bleibt. Wir empfehlen jedoch nicht, HPA und VPA für dieselben Messwerte (CPU und Arbeitsspeicher) zu verwenden, da es zu Konflikten kommen kann. Weitere Informationen finden Sie unter Einschränkungen für horizontales Pod-Autoscaling.

Autoscaling der Infrastruktur

Beim Infrastruktur-Autoscaling wird Hardware automatisch hinzugefügt oder entfernt, um den Anforderungen Ihrer Arbeitslasten gerecht zu werden.

Cluster Autoscaler: Der Gebäudemanager

Das Cluster-Autoscaling sorgt dafür, dass genügend zugrunde liegende Infrastruktur (VMs oder Knoten im Kontext von GKE) vorhanden ist, um die Pods aufzunehmen. Die Knoten können mit den „Etagen“ eines Geschäfts verglichen werden, wobei der Cluster Autoscaler der „Gebäudemanager“ ist.

Wenn die HPA weitere Pods hinzufügen muss, die vorhandenen Knoten jedoch nicht genügend verfügbare Kapazität haben, stellt der Cluster-Autoscaler einen neuen Knoten bereit. Wenn ein Knoten nicht ausgelastet ist, verschiebt Cluster Autoscaler die Pods dieses Knotens auf andere Knoten und beendet den nun leeren Knoten.

Weitere Informationen finden Sie unter Cluster Autoscaler.

Automatisches Erstellen von Knotenpools: der Automatisierungsspezialist

Während der Cluster Autoscaler Knoten zu vorhandenen Knotenpools hinzufügt, wird die Funktion des Cluster Autoscalers durch die automatische Erstellung von Knotenpools erweitert. So können automatisch neue Knotenpools erstellt werden, die den spezifischen Anforderungen Ihrer Pods entsprechen.

Für bestimmte KI-/ML-Arbeitslasten ist spezielle Hochleistungshardware wie GPUs oder TPUs erforderlich, die in Knotenpools für allgemeine Zwecke nicht verfügbar sind. Durch die automatische Erstellung von Knotenpools wird die Bereitstellung dieser speziellen Hardware vollständig automatisiert, wenn Ihre Arbeitslasten sie benötigen. So wird sichergestellt, dass auch die rechenintensivsten Aufgaben die benötigte Hardware erhalten, wenn sie sie benötigen.

Weitere Informationen finden Sie unter Automatische Erstellung von Knotenpools.

Informationen zu den verfügbaren Beschleunigern in GKE finden Sie unter:

ComputeClasses: Der Trigger für das automatische Erstellen von Knotenpools

Die automatische Erstellung von Knotenpools kann zwar durch die Anfrage eines Pods nach einem bestimmten Hardwaretyp (z. B. nvidia-l4-vws) ausgelöst werden, die Verwendung einer Compute-Klasse ist jedoch die robustere und modernere Methode. Eine ComputeClass ist eine von Ihnen definierte GKE-Ressource, die auf einer Reihe von Regeln basiert, um das automatische Skalieren Ihrer Hardware zu steuern und anzupassen. Es ist zwar kein Autoscaler, funktioniert aber mit dem Cluster Autoscaler.

Um die Analogie zu erweitern, können Sie sich ComputeClasses als „intelligentes Anforderungsformular“ für die Ausrüstung Ihres Geschäfts vorstellen.

Anstatt dass ein Verkäufer (Ihr Pod) eine bestimmte, starre Hardware anfordert (z. B. „Ich brauche die Kasse Modell 500 von Marke X“), wird über das Anforderungsformular eine Funktion angefordert (z. B. „Ich brauche eine Hochgeschwindigkeitskasse“). Das Formular – die ComputeClass – enthält eine Reihe von Regeln für das Einkaufsteam (GKE), wie diese Bestellung ausgeführt werden soll.

Compute-Klassen trennen die Hardwareanforderung Ihres Pods von der Bereitstellung durch GKE. Anstatt dass Ihr Pod eine bestimmte Maschine (z. B. a3-highgpu-8g) anfordert, kann er eine ComputeClass anfordern. Die Compute-Klasse selbst definiert die „smarte“ Logik, eine priorisierte Liste von Regeln, die GKE mitteilt, wie die Anfrage erfüllt werden soll.

Weitere Informationen finden Sie unter GKE ComputeClasses.

Einen detaillierten Überblick über ComputeClasses mit Praxisbeispielen und YAML-Konfigurationen finden Sie im technischen Leitfaden GKE-Arbeitslasten mit benutzerdefinierten ComputeClasses optimieren.

Wichtige Messwerte und Trigger für das Autoscaling

Die Autoscaling-Komponenten überwachen verschiedene Signale, um fundierte Skalierungsentscheidungen zu treffen. In der folgenden Tabelle sehen Sie einen Vergleich der auf Messwerten basierenden Autoscaling-Auslöser.

Komponente Reagiert auf Signalquelle Denkprozess GKE-Aktion
HPA Aktuelle Last Echtzeitverbrauch, z. B. die CPU-Auslastung liegt gerade bei 90 %. „Die aktuellen Pods sind überlastet. Wir müssen diesen Traffic sofort verteilen.“ Skaliert horizontal: Ändert die Anzahl der Pod-Replikate, um die Nachfrage zu decken.
VPA Effizienz der Größenanpassung Bisheriger Verbrauch, z. B. durchschnittliche RAM-Nutzung in den letzten 24 Stunden. „Der Ressourcenbedarf dieses Pods hat sich geändert oder unsere ursprünglichen Schätzungen waren falsch. Wir müssen die Ressourcenzuweisung an die tatsächliche Nutzung anpassen.“ Hoch- oder Herunterskalieren: Die Größe (CPU- oder RAM-Limits) des Pods wird angepasst.
Automatische Erstellung von Knotenpools Hardwareverfügbarkeit Nicht erfüllte Anfragen, z. B. wenn sich der Pod im Status „Pending“ (Ausstehend) befindet, weil keine GPU-Knoten vorhanden sind. „Dieser Pod kann nicht gestartet werden, da die angeforderte physische Hardware fehlt.“ Infrastruktur bereitstellen: Erstellt neue Knotenpools mit der angegebenen Hardware.

HPA-Trigger (Horizontal Pod Autoscaler): Reaktion auf die Last

Die HPA skaliert die Anzahl der Pods (nach oben oder unten), indem sie Echtzeit-Leistungsmesswerte beobachtet. Beispielsweise sind CPU- und Arbeitsspeicherauslastung, die grundlegenden Messwerte, die die Verarbeitungslast für Ihre Pods angeben, sofort für HPA verfügbar.

Für einige Messwerte sind jedoch explizite Konfigurationen erforderlich, z. B.:

  • Load-Balancer-Messwerte (Anfragen pro Sekunde, RPS): ein direkter Messwert für den Anwendungs-Traffic, der schnellere Skalierungsreaktionen ermöglicht. Informationen zur Verwendung dieses Messwerts finden Sie unter Auslastungsbasiertes Load-Balancing und Performance-HPA-Profil aktivieren.
  • Benutzerdefinierte Messwerte: Konfigurieren Sie das Autoscaling anhand von benutzerdefinierten Unternehmensmesswerten wie „Anzahl der aktiven Nutzer“, um Ressourcen proaktiv auf Grundlage der erwarteten Nachfrage zu verwalten. Wenn Sie benutzerdefinierte Messwerte verwenden möchten, müssen Sie eine Messwertpipeline einrichten, um sie für die HPA verfügbar zu machen. Weitere Informationen finden Sie unter Google Cloud Managed Service for Prometheus.

VPA-Trigger (Vertical Pod Autoscaler): Reaktion auf Ressourcenanforderungen

Der VPA skaliert die Größe Ihres Pods (erhöht oder verringert sie), indem er den bisherigen Ressourcenverbrauch beobachtet:

  • CPU- und Arbeitsspeichernutzung: Der VPA analysiert die bisherige Nutzung eines Pods, um festzustellen, ob die Ressourcenanfrage korrekt ist. Das Hauptziel von VPA besteht darin, Ressourcenkonflikte zu verhindern, indem die Speicher- und CPU-Anforderungen eines Pods an seinen tatsächlichen Bedarf angepasst werden.

Trigger für die automatische Erstellung von Knotenpools: Reaktion auf Hardwareanforderungen

Bei der automatischen Erstellung von Knotenpools werden neue Knotenpools mit spezieller Hardware bereitgestellt. Sie wird nicht durch Leistungsmesswerte wie die CPU-Auslastung ausgelöst. Stattdessen wird sie durch die Ressourcenanforderung eines Pods ausgelöst:

  • Nicht planbare Ressourcenanfrage: ein wichtiger Trigger. Wenn ein Pod erstellt wird, wird bestimmte Hardware angefordert. Wenn der Cluster diese Anfrage nicht erfüllen kann, weil kein vorhandener Knoten diese Hardware hat, wird die automatische Erstellung von Knotenpools ausgelöst.
  • ComputeClass-Anfrage: Ein Pod fordert eine ComputeClass an, z. B. cloud.google.com/compute-class: premium-gpu. Wenn kein Knoten im Cluster die Funktionen von „premium-gpu“ bereitstellen kann, wird durch die automatische Erstellung von Knotenpools automatisch ein neuer Knotenpool erstellt, der diese Funktionen bereitstellen kann.

Informationen zum Verwenden benutzerdefinierter, Prometheus- und externer Messwerte für das Autoscaling finden Sie unter Arbeitslasten anhand von Messwerten automatisch skalieren.

Fazit

Durch die Anwendung dieser Autoscaling-Strategien können Sie schwankende KI/ML-Arbeitslasten effektiv verwalten. So wie der Filialleiter von Cymbal Shops sein umsatzstärkstes Ereignis durch flexibles Verwalten seiner Ressourcen bewältigt hat, können Sie mit GKE-Autoscaling Ihre Infrastruktur- und Arbeitslastressourcen automatisch erweitern und reduzieren. So bleiben Ihre Modelle bei Traffic-Spitzen leistungsstark und in ruhigen Phasen kosteneffizient. Ihre Umgebung ist also immer optimal dimensioniert.

Nächste Schritte