In diesem Dokument wird beschrieben, wie Sie resiliente Google Kubernetes Engine-Cluster (GKE) und Strategien für die Arbeitslastplanung entwerfen, mit denen Sie Ressourcen wie GPUs, TPUs und leistungsstarke CPUs erhalten. Durch die Nutzung von Gemini inGoogle Cloud und Compute Advisor (Vorschau) können Sie ausstehende Pods verhindern und die zuverlässige Planung für KI-Arbeitslasten verbessern.
Dieses Dokument richtet sich an Cloud-Architekten sowie Plattformadministratoren und ‑operatoren, die GKE-Infrastruktur verwalten und die Kapazitätsplanung und ‑terminierung optimieren möchten.
Übersicht über Flexibilität, Effizienz und Verfügbarkeit von Rechenkapazität in GKE
Die Kubernetes-Planung basiert auf deklarierten Ressourcenanfragen. Wenn Sie große Beschleuniger wie GPUs oder TPUs planen, können strenge Ressourcenanfragen dazu führen, dass Cluster nicht hochskaliert werden, wenn bestimmte Hardware nicht verfügbar ist. Sie können die Kapazitätsverfügbarkeit in GKE mit den folgenden Funktionen optimieren:
- Automatisches Erstellen von Knotenpools:Dynamisches Erstellen von Knotenpools mit mehreren Familien.
- Fallbacks auf Arbeitslastebene:Toleranzen und Knotenauswahlen, die für die Akzeptanz alternativer Hardware konfiguriert sind.
- Geografische und regionale Planung:GKE-Funktionen für mehrere Zonen und Regionen.
- Reservierungsverwaltung:Vorab gekaufte Kapazität wird genutzt, bevor On-Demand-Ressourcen angefordert werden.
Best Practices für Flexibilität, Effizienz und Verfügbarkeit von Rechenkapazität in GKE
In diesem Abschnitt finden Sie Empfehlungen zur Erhöhung der Kapazitätsverfügbarkeit beim Planen von Arbeitslasten in GKE. Diese Best Practices umfassen Strategien wie das Entwerfen flexibler Hardwareanforderungen, das Konfigurieren der automatischen Erstellung von Knotenpools und das Nutzen der geografischen Verteilung, um sich an Ressourcenbeschränkungen anzupassen. Mit der automatischen Erstellung von Knotenpools werden Knotenpools automatisch basierend auf Pod-Spezifikationen verwaltet. Anstatt Knotenpools vorab zu definieren, geben Sie Ressourcenanforderungen in Ihren Pod-Manifesten an und lassen Sie GKE Knoten dynamisch erstellen.
Sie können die folgenden Best Practices auch mit Compute Advisor ermitteln und implementieren. Weitere Informationen finden Sie unter Compute Advisor verwenden.
Optionen zur Erhöhung der Verfügbarkeit von Rechenkapazität
Um die Kapazitätsverfügbarkeit zu optimieren, können Sie GKE anweisen, Arbeitslasten nicht an eine einzelne statische Maschinenfamilie oder einen einzelnen statischen Beschleunigertyp zu binden. Im Folgenden finden Sie Beispiele dafür, wie Sie flexible Knotenpools und Pod-Affinitätsregeln für verschiedene Arbeitslastklassen konfigurieren können. Welche Alternativen Sie auswählen, hängt von den Ressourcenanforderungen Ihrer Anwendung ab:
CPU-Knotenpools für allgemeine Zwecke:
- Hauptbeispiel: N2 (Intel-basiert, für allgemeine Zwecke).
- Beispielalternativen:N2D (AMD EPYC), C2 oder C2D (computing-optimiert) oder E2 (kostenoptimiert).
- Implementierungsmuster:Konfigurieren Sie Pod-Spezifikationen mit Knotenaffinität oder Toleranzen, die die Planung für mehrere Maschinenfamilienlabels zulassen, z. B.
cloud.google.com/machine-familyin["n2", "n2d", "c2d"]. Mit dieser Konfiguration kann GKE den Pool bereitstellen, der über verfügbare Kapazität verfügt.
GPU-Knotenpools:
- Hauptbeispiel: A2-Serie (NVIDIA A100-GPUs).
- Beispiel für Alternativen:L4 (Universal AI/ML) oder T4 (Inference).
- Implementierungsmuster:Konfigurieren Sie separate Knotenpools oder Compute-Klassen für verschiedene GPU-Stufen. Bei Arbeitslasten, die ohne A100-spezifische Funktionen ausgeführt werden können, sollten Sie zulassen, dass Pods auf L4- oder T4-Pools zurückgreifen, wenn die A2-Bereitstellung eingeschränkt ist.
TPU-Knotenpools:
- Hauptbeispiel: TPU Ironwood (TPU7x).
- Beispielhafte Alternativen:TPU v6 (Trillium) oder TPU v5 (v5e oder v5p).
- Implementierungsmuster:Die Bereitstellung von TPU-Slices kann stark eingeschränkt sein. Entwerfen Sie Trainingsarbeitslasten mit Flexibilität auf Framework-Ebene (z. B. JAX- oder PyTorch-Konfigurationen, die variable Slice-Topologien unterstützen), um sie auf v6- oder v5-Slices bereitzustellen, wenn die TPU Ironwood-Kapazität (TPU7x) nicht verfügbar ist.
In der folgenden Tabelle sind die primären Optionen und Hardwarealternativen für verschiedene Arten von Arbeitslasten zusammengefasst:
| Arbeitslasttyp | Beispiel für die primäre Auswahl | Beispielalternativen | Hinweise zur Architektur |
|---|---|---|---|
| System- oder Kernarbeitslasten | N2 | N2D, C2D, E2 | Umfasst Intel- und AMD-Hardwarepools für die automatische Erstellung von Knotenpools. |
| GPU-Inferenz und -Verarbeitung | A2 (A100) | L4, T4 | Flexibles Ausrichten auf kostengünstigere oder hochverfügbare GPU-Knotenpools. |
| TPU-Modelltraining | TPU Ironwood (TPU7x) | TPU v6, TPU v5 (v5e oder v5p) | Verwendet flexible Topologien für die Slice-basierte Planung. |
Automatische Erstellung von Knotenpools und ComputeClasses implementieren
Um die Kapazitätsverfügbarkeit zu optimieren, kombinieren Sie die automatische Erstellung von Knotenpools mit ComputeClasses. Die folgende Liste enthält Best Practices:
ComputeClasses definieren:Erstellen Sie ComputeClass-Ressourcen, in denen eine priorisierte Liste von Maschinenfamilien, GPU-Typen oder Bereitstellungsmodellen angegeben wird. Die GKE versucht, Knoten mit der Konfiguration mit der höchsten Priorität bereitzustellen, die in der Klasse verfügbar ist. Eine priorisierte Fallback-Liste hilft Ihnen erheblich dabei, die Ressourcen zu erhalten, die für Ihre Arbeitslasten erforderlich sind. Wenn Sie beispielsweise verhindern möchten, dass GKE auf Maschinen für allgemeine Zwecke zurückgreift, wenn ein bevorzugter spezialisierter Beschleuniger nicht verfügbar ist, fügen Sie Ihrer ComputeClass-Konfiguration die Einstellung
whenUnsatisfiable: DoNotScaleUphinzu. Weitere Informationen finden Sie unter Automatisch skalierte Knotenattribute mit benutzerdefinierten ComputeClasses steuern.ComputeClasses in Pod-Spezifikationen referenzieren: Verwenden Sie in den Pod-Spezifikationen Ihrer Arbeitslast das Label
cloud.google.com/compute-class, um Ihre benutzerdefinierte ComputeClass anstelle einer bestimmten Maschinenfamilie oder eines bestimmten GPU-Typs anzugeben. Weitere Informationen finden Sie unter Compute-Klasse in einer Arbeitslast anfordern.Mehrere Toleranzen definieren:Wenn Sie keine Compute-Klassen verwenden, verwenden Sie in Ihren Pod-Spezifikationen Regeln zur Knotenaffinität, die eine Reihe von Maschinentypen zulassen (z. B.
cloud.google.com/machine-familyin["n2", "n2d"]). Weitere Informationen finden Sie unter Automatische Knotenpoolerstellung konfigurieren.
Geografische und multiregionale Flexibilität in GKE
Um die Verfügbarkeit von Kapazitäten zu erhöhen, stellen Sie GKE-Cluster bereit, die sich über mehrere Zonen erstrecken, oder führen Sie Multi-Cluster-Architekturen aus:
Cluster mit mehreren Zonen:Hier werden Knotenpools so konfiguriert, dass sie in allen verfügbaren Zonen einer Region automatisch skaliert werden.
Multiregionale Clusterföderation: Stellen Sie für große asynchrone Jobs (z. B. Offline-Batch-Inferenz oder verteiltes Training) einen Multi-Cluster-Orchestrator (wie Kueue oder Cluster Director) bereit, um Arbeitslasten global in die Warteschlange zu stellen und sie an eine Region mit verfügbarer Kapazität zu senden.
Pods, die auf Spot-VMs ausgeführt werden:Führen Sie unterbrechbare Arbeitslasten auf Spot-VMs aus, indem Sie Toleranzen hinzufügen und GKE anweisen, überschüssige Kapazität in verschiedenen Zonen zu verteilen.
Zusätzliche Best Practices für Flexibilität, Effizienz und Verfügbarkeit von Rechenkapazität in GKE
Neben der Diversifizierung der Hardware sollten Sie die folgenden GKE-Best Practices anwenden, um die Cluster-Skalierung zu optimieren:
- Pod-Überdimensionierung (Kapazitätspuffer) implementieren: Stellen Sie „Pausen-Pods“ mit niedriger Priorität bereit, die im Voraus Knotenkapazität reservieren. Wenn KI-Arbeitslasten mit hoher Priorität gesendet werden und die regionale Kapazität eingeschränkt ist, werden die Pausen-Pods von Kubernetes sofort vorzeitig beendet. So können Container gestartet werden, ohne dass auf die Bereitstellung neuer Knoten gewartet werden muss. Weitere Informationen finden Sie unter Kapazitätspuffer.
- Flex-Start mit Bereitstellung per Warteschlange verwenden:Für große Batch- und KI-Modell-Trainingsjobs sollten Sie Flex-Start mit Bereitstellung per Warteschlange verwenden. Diese Funktion ist in Kueue und Dynamic Workload Scheduler integriert. Flex-Start mit Bereitstellung per Warteschlange (FSQ) bietet eine atomare Alles-oder-Nichts-Knotenzuweisung, die verhindert, dass die Hochskalierung des Clusters teilweise fehlschlägt. Weitere Informationen finden Sie unter Große Arbeitslast mit Flex-Start mit Bereitstellung per Warteschlange ausführen.
- Image-Streaming und Vorabladen von Container-Images aktivieren:Aktivieren Sie für große KI-Container-Images (z. B. PyTorch- oder TensorFlow-Images mit mehr als 10 GB) das GKE-Image-Streaming oder verwenden Sie sekundäre Bootlaufwerke für das Vorabladen von Images. Diese Konfiguration verkürzt die Aufwärmzeit der Knoten, sodass neu bereitgestellte Knoten innerhalb von Sekunden mit der Ausführung von Arbeitslasten beginnen können. Weitere Informationen finden Sie unter Container-Images mithilfe von Image-Streaming abrufen und Sekundäre Bootlaufwerke zum Vorabladen von Daten oder Container-Images verwenden.
- Standortrichtlinie für Cluster Autoscaler auf
ANYfestlegen: Konfigurieren Sie Knotenpools (insbesondere für Spot-VMs oder Flex-Start) mit der StandortrichtlinieANY. Mit dieser Einstellung wird Cluster Autoscaler angewiesen, in allen angegebenen Zonen nach der angeforderten Kapazität zu suchen. Cluster Autoscaler findet Kapazität, indem er die Knotenanzahl ausgleicht. Weitere Informationen finden Sie unter Cluster Autoscaler – Übersicht. - Beschleuniger-Auslastung mit GPU-Freigabe optimieren:Für Arbeitslasten, die keine dedizierte GPU erfordern, können Sie GPU-Timesharing, MIGs (Multi-Instance GPUs) oder NVIDIA MPS verwenden, damit mehrere Container einen einzelnen Beschleuniger gemeinsam nutzen können. Mit diesem Ansatz wird die effektive Kapazität über Knotenpools hinweg optimiert. Weitere Informationen finden Sie unter GPU-Freigabestrategien in GKE.
Compute Advisor verwenden
Compute Advisor ist eine KI-basierte Oberfläche in derGoogle Cloud Console, die von Gemini unterstützt wird und Ihnen hilft, robuste und kostengünstige Architekturen für GKE zu entwerfen.
Compute Advisor bietet nahezu in Echtzeit Verfügbarkeitsinformationen für Flex-Start-VMs und Spot-VMs und prüft vor der Bereitstellung die Richtlinien und Ressourcenkontingente Ihrer Organisation. Compute Advisor bietet keine Verfügbarkeitsinformationen für Arbeitslasten, die On-Demand-Ressourcen erfordern.
So greifen Sie in der Google Cloud Console auf Gemini zu:
-
Rufen Sie in der Google Cloud Console die Seite Übersicht auf.
-
Senden Sie im Bereich Infrastruktur mit Compute Advisor gestalten einen Prompt. Gemini beginnt mit der Generierung einer Antwort.
-
Führen Sie einen der folgenden Beispiel-Prompts in Compute Advisor aus, um Architekturempfehlungen zu generieren. Wenn Sie auf die Schaltflächen Prompt in Compute Advisor ausführen klicken, kann es länger als 15 Sekunden dauern, bis die Google Cloud -Konsole geladen wird:
Allgemeine Beschleunigerstrategie:
Anwendungsfall:Mit diesem Prompt können Sie regionale Kapazitätssignale analysieren und Empfehlungen zu Maschinentypen, Zonen und Fallback-Planungsstrategien erhalten, wenn Sie Clusterkonfigurationen entwerfen.
Configure a GKE cluster to improve chances of obtaining scarce GPU or TPU capacity.Geografische Flexibilität und Fallbacks:
Anwendungsfall: Verwenden Sie diesen Prompt, wenn Sie Multi-Cluster-Architekturen oder globale Jobwarteschlangensysteme (z. B. mit Kueue) entwerfen, um die Ausführung von Arbeitslasten je nach Ressourcenverfügbarkeit zwischen Regionen zu verschieben.
Configure multi-region fallbacks and geographic scheduling on GKE to increase GPU availability.Priorität bei der Nutzung von Reservierungen:
Anwendungsfall:Verwenden Sie diesen Prompt, um YAML-Konfigurationsmuster für Pod-Affinitäts- und Autoscaling-Regeln zu generieren, bei denen die Reservierungskapazität priorisiert wird.
Configure GKE autoscaling rules and Pod specs to prioritize consuming active reservations before scaling into on-demand pools.ComputeClasses für die Fallback-Priorisierung:
Anwendungsfall:Verwenden Sie diesen Prompt, um das YAML-Manifest für eine ComputeClass-CustomResourceDefinition zu generieren, die leistungsstarke GPUs priorisiert, aber Fallbacks für niedrigere Stufen enthält, um die Planung von Arbeitslasten zu gewährleisten.
Define a ComputeClass manifest for GKE to prioritize A2 GPU nodes with automatic fallbacks to L4 or T4 GPUs.Automatisches Erstellen von Knotenpools zur Diversifizierung:
Anwendungsfall: Verwenden Sie diesen Prompt, um das YAML-Manifest für die Ressourcenlimits des GKE-Cluster-Autoscalers und die Pod-Affinitätsregeln zu schreiben, mit denen die automatische Knotenbereitstellung alternative GPU- oder CPU-Knoten automatisch bereitstellen kann.
Configure GKE node pool auto-creation to diversify machine families and prevent pending pods when regional accelerator capacity is constrained.
Nächste Schritte
- GKE-Cluster mit Compute Advisor entwerfen und optimieren
- Automatisches Erstellen von Knotenpools konfigurieren
- Fehlerbehebung beim horizontalen Pod-Autoscaling