Mit Gemini die Verfügbarkeit von Ressourcen in GKE planen

In diesem Dokument wird beschrieben, wie Sie robuste 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 in Google Cloud und Compute Advisor (Vorschau) können Sie ausstehende Pods vermeiden und die zuverlässige Planung für KI-Arbeitslasten verbessern.

Dieses Dokument richtet sich an Cloud-Architekten und Plattformadministratoren und ‑operatoren, die die GKE-Infrastruktur verwalten und die Kapazitätsplanung und ‑planung optimieren möchten.

Verfügbarkeit von Ressourcen in GKE

Die Kubernetes-Planung basiert auf deklarierten Ressourcenanfragen. Bei der Planung von Beschleunigern im großen Maßstab wie GPUs oder TPUs können strenge Ressourcenanfragen dazu führen, dass Cluster nicht skaliert werden können, wenn bestimmte Hardware nicht verfügbar ist. Sie können die Kapazitätsverfügbarkeit in GKE mit den folgenden Funktionen optimieren:

  • Automatische Knotenpoolerstellung:dynamische Knotenpoolerstellung für mehrere Familien.
  • Fallbacks auf Arbeitslastebene:Toleranzen und Knotenauswahlen, die alternative Hardware akzeptieren.
  • Geografische und regionale Planung:multizonale und multiregionale Funktionen von GKE.
  • Reservierungsverwaltung:Nutzung der vorab gekauften Kapazität vor dem Anfordern von On-Demand-Ressourcen.

Best Practices für die Verfügbarkeit von Ressourcen in GKE

In diesem Abschnitt finden Sie Empfehlungen zur Erhöhung der Kapazitätsverfügbarkeit bei der Planung von Arbeitslasten in GKE. Diese Best Practices umfassen Strategien wie das Entwerfen flexibler Hardwareanforderungen, das Konfigurieren der automatischen Knotenpoolerstellung und die Nutzung der geografischen Verteilung, um sich an Ressourcenbeschränkungen anzupassen. Die automatische Knotenpoolerstellung verwaltet Knotenpools automatisch basierend auf Pod-Spezifikationen. Anstatt Knotenpools vorab zu definieren, geben Sie die 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 für Hardwareflexibilität

Um die Kapazitätsverfügbarkeit zu optimieren, können Sie GKE anweisen, Arbeitslasten nicht an eine einzelne statische Maschinenfamilie oder einen einzelnen Beschleunigertyp zu binden. Im Folgenden finden Sie Beispiele dafür, wie Sie flexible Knotenpools und Regeln für die Pod-Affinität für verschiedene Arbeitslastklassen konfigurieren können. Die spezifischen Alternativen, die Sie auswählen, hängen von den Ressourcenanforderungen Ihrer Anwendung ab:

  • CPU-Knotenpools für allgemeine Zwecke:

    • Primäres Beispiel:N2 (für allgemeine Zwecke, Intel-basiert).
    • 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 Maschinenfamilien Labels zulassen, z. B. cloud.google.com/machine-family in ["n2", "n2d", "c2d"]. Mit dieser Konfiguration kann GKE den Pool bereitstellen, der über verfügbare Kapazität verfügt.

  • GPU-Knotenpools:

    • Primäres Beispiel:A2-Serie (NVIDIA A100-GPUs).
    • Beispielalternativen:L4 (universell für KI/ML) oder T4 (Inferenz).
    • Implementierungsmuster:Konfigurieren Sie separate Knotenpools oder ComputeClasses für verschiedene GPU-Stufen. Für Arbeitslasten, die ohne A100-spezifische Funktionen ausgeführt werden können, können Sie Pods auf L4- oder T4-Pools zurückgreifen, wenn die A2-Bereitstellung eingeschränkt ist.

  • TPU-Knotenpools:

    • Primäres Beispiel:TPU Ironwood (TPU7x).
    • Beispielalternativen: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 Frameworkebene (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 Auswahlen und Hardwarealternativen für verschiedene Arbeitslasttypen zusammengefasst:

Arbeitslasttyp Beispiel für primäre Auswahl Beispielalternativen Hinweise zur Architektur
System- oder Kernarbeitslasten N2 N2D, C2D, E2 Umfasst Intel- und AMD-Hardwarepools für die automatische Knotenpoolerstellung.
GPU-Inferenz und ‑Verarbeitung A2 (A100) L4, T4 Zielt flexibel auf kostengünstigere oder besser verfügbare GPU-Knotenpools ab.
TPU-Modelltraining TPU Ironwood (TPU7x) TPU v6, TPU v5 (v5e oder v5p) Nutzt flexible Topologien für die slicebasierte Planung.

Automatische Knotenpoolerstellung und ComputeClasses implementieren

Um die Kapazitätsverfügbarkeit zu optimieren, kombinieren Sie die automatische Knotenpoolerstellung mit ComputeClasses. Die folgende Liste enthält Best Practices:

  • ComputeClasses definieren:Erstellen Sie ComputeClass-Ressourcen, die eine priorisierte Liste von Maschinenfamilien, GPU-Typen oder Bereitstellungsmodellen angeben. GKE versucht, Knoten mit der Konfiguration mit der höchsten Priorität bereitzustellen, die in der Klasse verfügbar ist. Eine priorisierte Fallbackliste hilft Ihnen erheblich dabei, die Ressourcen zu erhalten, die Ihre Arbeitslasten benötigen. 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 der ComputeClass-Konfiguration die Einstellung whenUnsatisfiable: DoNotScaleUp hinzu. Weitere Informationen finden Sie unter Automatisch skalierte Knotenattribute mit benutzerdefinierten ComputeClasses steuern.

  • Auf ComputeClasses in Pod-Spezifikationen verweisen:Verwenden Sie in den Pod-Spezifikationen Ihrer Arbeitslast das Label cloud.google.com/compute-class, um auf Ihre benutzerdefinierte ComputeClass anstelle einer bestimmten Maschinenfamilie oder eines bestimmten GPU-Typs zu verweisen. Weitere Informationen finden Sie unter ComputeClass in einer Arbeitslast anfordern.

  • Mehrere Toleranzen definieren: Wenn Sie keine ComputeClasses verwenden, verwenden Sie in den Pod-Spezifikationen Regeln für die Knotenaffinität, die eine Reihe von Maschinenfamilien zulassen (z. B. cloud.google.com/machine-family in ["n2", "n2d"]). Weitere Informationen finden Sie unter Automatische Knotenpoolerstellung konfigurieren.

Geografische und multiregionale Flexibilität in GKE

Um die Kapazitätsverfügbarkeit zu erhöhen, stellen Sie GKE-Cluster bereit, die sich über mehrere Zonen erstrecken, oder führen Sie multiregionale Architekturen aus:

  • Multizonale Cluster:Stellen Sie sicher, dass Knotenpools so konfiguriert sind, dass sie in allen verfügbaren Zonen einer Region automatisch skaliert werden.

  • Multiregionale Clusterföderation:Für große asynchrone Jobs (z. B. Offline-Batch-Inferenz oder verteiltes Training) stellen Sie einen Multi-Cluster-Orchestrator (z. B. 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.

Weitere Best Practices für die Verfügbarkeit von GKE

Neben der Diversifizierung der Hardware sollten Sie diese Best Practices für GKE anwenden, um den Erfolg der Clusterskalierung zu optimieren:

  • Pod-Überbereitstellung (Kapazitätspuffer) implementieren : Stellen Sie „Pausen“-Pods mit niedriger Priorität bereit, die Knotenkapazität im Voraus reservieren. Wenn KI-Arbeitslasten mit hoher Priorität gesendet werden und die regionale Kapazität begrenzt ist, werden die Pausen-Pods sofort von Kubernetes vorzeitig beendet, sodass Container gestartet werden können, ohne auf die Bereitstellung neuer Knoten warten zu müssen. Weitere Informationen finden Sie unter Kapazitätspuffer.
  • Flex-Start mit Bereitstellung per Warteschlange verwenden:Verwenden Sie für große Batch- und KI-Modelltrainingsjobs Flex-Start mit Bereitstellung per Warteschlange, das in Kueue und Dynamic Workload Scheduler integriert ist. Flex-Start mit Bereitstellung per Warteschlange bietet eine atomare Knotenbereitstellung, bei der entweder alle Knoten bereitgestellt werden oder keine. So werden Fehler bei der teilweisen Clusterskalierung vermieden. 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 Warm-up-Zeit des Knotens, sodass neu bereitgestellte Knoten innerhalb von Sekunden Arbeitslasten ausführen können. Weitere Informationen finden Sie unter Image-Streaming verwenden, um Container-Images abzurufen und Sekundäre Bootlaufwerke zum Vorabladen von Daten oder Container-Images verwenden.
  • Standortrichtlinie für Cluster Autoscaler auf ANY festlegen:Konfigurieren Sie Knotenpools (insbesondere für Spot-VMs oder Flex-Start) mit der ANY Standortrichtlinie. Mit dieser Einstellung wird der Cluster Autoscaler angewiesen, in allen angegebenen Zonen nach der angeforderten Kapazität zu suchen. Der Cluster Autoscaler findet Kapazität, indem er die Anzahl der Knoten ausgleicht. Weitere Informationen finden Sie unter Cluster Autoscaler – Übersicht.
  • Beschleunigerauslastung mit GPU-Freigabe optimieren:Verwenden Sie für Arbeitslasten, die keine dedizierte GPU erfordern, GPU-Timesharing, Multi-Instanz-GPUs (MIG) oder NVIDIA MPS, damit mehrere Container einen einzelnen Beschleuniger gemeinsam nutzen können. Dieser Ansatz optimiert die effektive Kapazität in allen Knotenpools. Weitere Informationen finden Sie unter GPU-Freigabestrategien in GKE.

Compute Advisor verwenden

Compute Advisor ist eine KI-gestützte Schnittstelle in der Google Cloud Console, die von Gemini unterstützt wird und Ihnen hilft, robuste 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 Ihre Organisationsrichtlinien und Ressourcenkontingente. 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:

  1. Rufen Sie in der Google Cloud Console die Seite Übersicht auf.

    Zur Übersicht

  2. Senden Sie im Abschnitt Infrastruktur mit Compute Advisor entwerfen einen Prompt. Gemini beginnt mit der Generierung einer Antwort.

  3. Führen Sie einen der folgenden Beispielprompts in Compute Advisor aus, um Architekturempfehlungen zu generieren. Wenn Sie auf die Schaltfläche Prompt in Compute Advisor klicken, kann es länger als 15 Sekunden dauern, bis die Google Cloud Console geladen wird:

    • Allgemeine Beschleunigerstrategie:

      Anwendungsfall:Verwenden Sie diesen Prompt, um regionale Kapazitätssignale zu analysieren und Empfehlungen zu Maschinentypen, Zonen und Fallback-Planungsstrategien zu erhalten, wenn Sie Clusterkonfigurationen entwerfen.

      Configure a GKE cluster to improve chances of obtaining scarce GPU or TPU capacity.

      Prompt in Compute Advisor ausführen

    • Geografische Flexibilität und Fallbacks:

      Anwendungsfall:Verwenden Sie diesen Prompt, wenn Sie Multicluster-Architekturen oder globale Job-Warteschlangensysteme (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.

      Prompt in Compute Advisor ausführen

    • Verbrauch von Prioritätsreservierungen:

      Anwendungsfall:Verwenden Sie diesen Prompt, um YAML-Konfigurationsmuster für Regeln für die Pod-Affinität und das Autoscaling zu generieren, die die Reservierungskapazität priorisieren.

      Configure GKE autoscaling rules and Pod specs to prioritize consuming active reservations before scaling into on-demand pools.

      Prompt in Compute Advisor ausführen

    • 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 der niedrigeren Stufe enthält, um die Arbeitslastplanung zu gewährleisten.

      Define a ComputeClass manifest for GKE to prioritize A2 GPU nodes with automatic fallbacks to L4 or T4 GPUs.

      Prompt in Compute Advisor ausführen

    • Automatische Knotenpoolerstellung für die Diversifizierung:

      Anwendungsfall:Verwenden Sie diesen Prompt, um das YAML-Manifest für Ressourcenlimits für den GKE-Cluster Autoscaler und Regeln für die Pod-Affinität 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.

      Prompt in Compute Advisor ausführen

Nächste Schritte