Benutzerdefinierte Compute-Klassen

Sie können eigene Compute-Klassen erstellen, um die Attribute der Knoten zu steuern, die Google Kubernetes Engine (GKE) beim Autoscaling Ihres Clusters bereitstellt. Dieses Dokument richtet sich an Plattformadministratoren, die Autoscaling-Profile für Knoten deklarativ definieren möchten, damit bestimmte Arbeitslasten auf Hardware ausgeführt werden, die ihren Anforderungen entspricht. Weitere Informationen zu ComputeClasses finden Sie unter GKE ComputeClasses.

ComputeClasses – Übersicht

In GKE ist eine ComputeClass ein Profil, das aus einer Reihe von Knotenattributen besteht, mit denen GKE die Knoten bereitstellt, auf denen Ihre Arbeitslasten während Autoscaling-Ereignissen ausgeführt werden. ComputeClasses können auf bestimmte Optimierungen ausgerichtet werden, z. B. auf die Bereitstellung von Hochleistungsknoten oder die Priorisierung kostenoptimierter Konfigurationen für niedrigere Betriebskosten. Mit benutzerdefinierten ComputeClasses können Sie Profile definieren, die GKE dann zum automatischen Skalieren von Knoten verwendet, die die Anforderungen bestimmter Arbeitslasten bestmöglich erfüllen.

Benutzerdefinierte Compute-Klassen stehen für den GKE-Autopilot-Modus und den GKE-Standardmodus in Version 1.30.3-gke.1451000 und höher zur Verfügung und bieten einen deklarativen Ansatz zum Definieren von Knotenattributen und Autoscaling-Prioritäten. Benutzerdefinierte Compute-Klassen können standardmäßig in allen unterstützten GKE-Clustern konfiguriert und verwendet werden.

Vorteile benutzerdefinierter Compute-Klassen

Benutzerdefinierte Compute-Klassen bieten folgende Vorteile:

  • Fallback-Rechenprioritäten: Hiermit können Sie in jeder ComputeClass eine Hierarchie von Knotenkonfigurationen definieren, die von GKE priorisiert werden sollen. Wenn die bevorzugte Konfiguration nicht verfügbar ist, wählt GKE automatisch die nächste Konfiguration in der Hierarchie aus. Dieses Fallback-Modell sorgt dafür, dass Ihre Arbeitslasten auch dann auf optimierter Hardware mit minimalen Planungsverzögerungen ausgeführt werden, selbst wenn keine Rechenressourcen verfügbar sind.
  • Detaillierte Autoscaling-Steuerung: Sie können Knotenkonfigurationen definieren, die für bestimmte Arbeitslasten am besten geeignet sind. GKE priorisiert diese Konfigurationen beim Erstellen von Knoten während der Skalierung.
  • Deklarative Infrastrukturkonfiguration: Nutzen Sie einen deklarativen Ansatz für die Infrastrukturverwaltung, damit GKE automatisch Knoten für Sie erstellt, die Ihren spezifischen Arbeitslastanforderungen entsprechen.
  • Aktive Migration: Wenn an Ihrem Standort Rechenressourcen für eine bevorzugte Maschinenkonfiguration verfügbar werden, migriert GKE Ihre Arbeitslasten automatisch auf neue Knoten, die die bevorzugte Konfiguration verwenden.
  • Kostenoptimierung: Priorisieren Sie kosteneffiziente Knotentypen wie Spot-VMs, um Ihre Clusterkosten zu reduzieren.
  • Benutzerdefinierte Standard-Compute-Klassen: Legen Sie eine benutzerdefinierte ComputeClass als Standard für einen gesamten Cluster oder für bestimmte Kubernetes-Namespaces fest, damit Arbeitslasten auf optimierter Hardware ausgeführt werden, auch wenn keine bestimmte ComputeClass angefordert wird.
  • Benutzerdefinierte Grenzwerte für die Knotenkonsolidierung: Hier können Sie benutzerdefinierte Grenzwerte für die Ressourcennutzung für Knoten festlegen. Wenn die Ressourcennutzung eines bestimmten Knotens unter Ihren Schwellenwert fällt, versucht GKE, die Arbeitslasten zu einem ähnlichen, verfügbaren Knoten zu konsolidieren und den nicht ausgelasteten Knoten herunterzuskalieren.

Anwendungsfälle für benutzerdefinierte Compute-Klassen

Ziehen Sie die Verwendung benutzerdefinierter Compute-Klassen in Szenarien wie den folgenden in Betracht:

  • Sie möchten Ihre KI-/ML-Arbeitslasten auf bestimmten GPU- oder TPU-Konfigurationen ausführen.
  • Sie möchten Standardhardwarekonfigurationen für die Arbeitslasten festlegen, die von bestimmten Teams ausgeführt werden, um den Overhead für die Anwendungsoperatoren zu reduzieren.
  • Sie führen Arbeitslasten aus, die für bestimmte Compute Engine-Maschinenserien oder Hardwarekonfigurationen eine optimale Leistung erzielen.
  • Sie möchten Hardwarekonfigurationen angeben, die bestimmten Geschäftsanforderungen entsprechen, z. B. hohe Leistung, kostenoptimiert oder Hochverfügbarkeit.
  • Sie möchten, dass GKE bei nicht verfügbaren Rechenressourcen hierarchisch auf bestimmte Hardwarekonfigurationen zurückgreift, damit Ihre Arbeitslasten immer auf Maschinen ausgeführt werden, die ihren Anforderungen entsprechen.
  • Sie möchten die optimalen Konfigurationen für die gesamte Flotte Ihres Unternehmens zentral festlegen, damit Ihre Kosten vorhersehbarer sind und Ihre Arbeitslasten zuverlässiger ausgeführt werden.
  • Sie möchten zentral festlegen, welche Ihrer Compute Engine-Kapazitätsreservierungen GKE zum Bereitstellen neuer Knoten für bestimmte Arbeitslasten verwenden soll.
  • Sie möchten eine Richtlinie für kompakte Platzierung für die Verwendung mit GKE Autopilot angeben. Weitere Informationen finden Sie unter Kompakte Platzierung.

Funktionsweise benutzerdefinierter Compute-Klassen

Benutzerdefinierte Compute-Klassen sind benutzerdefinierte Kubernetes-Ressourcen, die dieGoogle Cloud -Infrastruktur bereitstellen. Sie definieren ein ComputeClass-Objekt im Cluster und fordern dann diese ComputeClass in Arbeitslasten an oder legen diese ComputeClass als Standard für einen Kubernetes-Namespace fest. Wenn für eine passende Arbeitslast neue Infrastruktur erforderlich ist, stellt GKE neue Knoten entsprechend den Prioritäten bereit, die Sie in Ihrer ComputeClass-Definition festgelegt haben.

Die Attribute, die Sie in Ihren Compute-Klassen festlegen, definieren, wie GKE neue Knoten zum Ausführen von Arbeitslasten konfiguriert. Wenn Sie eine vorhandene ComputeClass ändern, verwenden alle zukünftigen Knoten, die GKE für diese ComputeClass erstellt, die geänderte Konfiguration. GKE ändert die Konfiguration vorhandener Knoten nicht rückwirkend, um sie an Ihre Änderungen anzupassen.

Benutzerdefinierte ComputeClasses beeinflussen Autoscaling-Entscheidungen, werden aber nicht vom kube-scheduler berücksichtigt. Bei der Pod-Planung priorisiert der Scheduler möglicherweise keine Knoten mit höheren benutzerdefinierten ComputeClass-Prioritäten, auch wenn vorhandene Knoten mit verschiedenen Prioritäten verfügbar sind.

Beachten Sie die folgenden Richtlinien, damit Ihre benutzerdefinierten Compute-Klassen für Ihre Flotte optimiert sind:

  • Informieren Sie sich über die Rechenanforderungen Ihrer Flotte, einschließlich anwendungsspezifischer Hardwareanforderungen.
  • Entscheiden Sie sich für ein Thema, das das Design jeder ComputeClass bestimmt. Eine leistungsoptimierte ComputeClass kann beispielsweise eine Fallback-Strategie haben, die nur Maschinentypen mit hoher CPU-Leistung verwendet.
  • Entscheiden Sie sich für die Compute Engine-Maschinenfamilie und -Maschinenreihe, die Ihren Arbeitslasten am besten entspricht. Weitere Informationen finden Sie im Leitfaden zu Ressourcen und Vergleichen für Maschinenfamilien.
  • Planen Sie für jede ComputeClass eine Fallback-Strategie, damit Arbeitslasten immer auf Knoten ausgeführt werden, die ähnliche Maschinenkonfigurationen verwenden. Wenn die N4-Maschinenserie beispielsweise nicht verfügbar ist, können Sie auf C3-Maschinen zurückgreifen.

Vollständige benutzerdefinierte Ressourcendefinition ansehen

Die aktuelle benutzerdefinierte Ressourcendefinition (Custom Resource Definition, CRD) für die benutzerdefinierte Ressource ComputeClass, einschließlich aller Felder und ihrer Beziehungen, finden Sie in der Referenzdokumentation zu ComputeClass.

Sie können die CRD auch in Ihrem Cluster aufrufen, indem Sie den folgenden Befehl ausführen:

kubectl describe crd computeclasses.cloud.google.com

Benutzerdefinierte Compute-Klasse planen

Führen Sie die folgenden Schritte aus, um eine benutzerdefinierte ComputeClass in Ihrem Cluster effektiv zu planen, bereitzustellen und zu verwenden:

  1. Fallback-Rechenprioritäten auswählen: Hiermit legen Sie eine Reihe von Regeln fest, die die Eigenschaften der Knoten steuern, die GKE für die ComputeClass erstellt.
  2. GKE Standard-Knotenpools und ComputeClasses konfigurieren: Führen Sie für Cluster im Standardmodus die erforderlichen Konfigurationsschritte aus, um die ComputeClass mit Ihren Knotenpools zu verwenden.
  3. Skalierungsverhalten definieren, wenn keine Prioritätsregeln gelten: Teilen Sie GKE optional mit, was zu tun ist, wenn Knoten, die Ihren Prioritätsregeln entsprechen, nicht bereitgestellt werden können.
  4. Autoscaling-Parameter für die Knotenkonsolidierung festlegen: Teilen Sie GKE mit, wann Arbeitslasten konsolidiert und nicht ausgelastete Knoten entfernt werden sollen.
  5. Aktive Migration zu Knoten mit höherer Priorität konfigurieren: Sie können GKE optional anweisen, Arbeitslasten zu bevorzugten Knoten zu verschieben, sobald Hardware verfügbar ist.
  6. Compute Engine-Reservierungen nutzen: Optional können Sie GKE anweisen, vorhandene zonale Compute Engine-Reservierungen beim Erstellen neuer Knoten zu nutzen.

Fallback-Computing-Prioritäten auswählen

Der Hauptvorteil einer benutzerdefinierten ComputeClass besteht darin, dass Sie die Fallback-Strategie steuern können, wenn Ihre bevorzugten Knoten aufgrund von Faktoren wie Ressourcenerschöpfung und Kontingenteinschränkungen nicht verfügbar sind.

Sie erstellen eine Fallback-Strategie, indem Sie in Ihrer benutzerdefinierten ComputeClass eine Liste von Prioritätsregeln definieren. Wenn ein Cluster vertikal skaliert werden muss, priorisiert GKE das Erstellen von Knoten, die der ersten Prioritätsregel entsprechen. Wenn GKE diese Knoten nicht erstellen kann, wird auf die nächste Regel mit höherer Priorität zurückgegriffen. Dieser Vorgang wird wiederholt, bis GKE den Cluster erfolgreich skaliert oder alle Regeln ausgeschöpft hat. Wenn alle Regeln ausgeschöpft sind, erstellt GKE Knoten basierend auf dem Standard- oder angegebenen Verhalten, das unter Skalierungsverhalten definieren, wenn keine Prioritätsregeln gelten beschrieben ist.

Verschiedene Compute Engine-Maschinenreihen unterstützen unterschiedliche Technologien und Funktionen. Ältere Generationen einer Maschinenserie unterstützen möglicherweise nicht dieselben Speichertypen wie neuere Generationen. Wenn Sie zustandsorientierte Arbeitslasten ausführen, die auf nichtflüchtige Daten angewiesen sind, sollten Sie keine ComputeClass verwenden, die mehrere Generationen einer Maschinenserie umfasst. Die Arbeitslasten können möglicherweise nicht auf die persistenten Daten zugreifen, wenn sie von GKE auf einem Maschinentyp platziert werden, der diesen Speichertyp nicht unterstützt. Weitere Informationen finden Sie in der Vergleichstabelle für Maschinenserien. Filtern Sie dort nach bestimmten Speichertypen.

Prioritätsregeln

Prioritätsregeln werden im Feld spec.priorities der benutzerdefinierten ComputeClass-Ressource definiert. Jede Regel im Feld priorities beschreibt die Eigenschaften der zu bereitzustellenden Knoten. GKE verarbeitet das Feld priorities in der Reihenfolge. Das bedeutet, dass der erste Eintrag im Feld die höchste Priorität für die Bereitstellung von Knoten hat.

Es gibt zwei Arten von Prioritätsregeln:

  • Deklarative Regeltypen: Verwenden Sie Knoteneigenschaften, um die bereitzustellenden Knoten zu beschreiben.

  • Regeltyp für Knotenpool: In GKE-Standardclustern enthält diese Option eine Liste der manuell erstellten Knotenpools, die mit der ComputeClass verknüpft sind, in der GKE Knoten bereitstellen soll.

Deklarative Prioritätsregeln

Mit deklarativen Prioritätsregeln können Sie Maschineneigenschaften wie Maschinenfamilie oder -typ, Spot-VMs, Beschleunigeroptionen, Speicheroptionen, Reservierungen und Mindestanforderungen an Ressourcen angeben, die GKE bei der Bereitstellung von Knoten verwenden soll. Eine vollständige Liste der unterstützten Felder finden Sie in der CRD-Referenz für ComputeClass.

Konfigurationen für Maschinenfamilien

Das Feld machineFamily akzeptiert eine Compute Engine-Maschinenserie wie n4 oder c4. Wenn nicht angegeben, ist der Standardwert e2.

Sie können neben dem Feld machineFamily auch andere spec.priorities-Felder verwenden, um Ihre Rechenanforderungen deklarativ zu definieren, z. B.:

  • spot: Spot-VMs Der Standardwert ist false.
  • minCores: Mindestanzahl der vCPUs pro Knoten. Der Standardwert ist 0.
  • minMemoryGb: Mindestspeicherplatz pro Knoten. Der Standardwert ist 0.
  • storage.bootDiskKMSKey: Pfad zum Cloud Key Management Service-Schlüssel, der für die Verschlüsselung des Bootlaufwerks verwendet werden soll.
  • storage.secondaryBootDisks: Nichtflüchtige Speicher, die zum Vorabladen von GKE-Knoten mit Daten verwendet werden, z. B. ein Machine-Learning-Modell oder ein Container-Image. Erfordert GKE-Version 1.31.2-gke.1105000 oder höher. Informationen zum Einrichten eines sekundären Bootlaufwerks für Ihren Cluster finden Sie unter Sekundäre Bootlaufwerke konfigurieren.
    • storage.secondaryBootDisks.diskImageName: Der Name des vorab zu ladenden Laufwerk-Images.
    • storage.secondaryBootDisks.project: Der Name des Projekts, zu dem das Laufwerk-Image gehört. Wenn dieser Wert nicht angegeben ist, wird standardmäßig Ihr Clusterprojekt verwendet.
    • storage.secondaryBootDisks.mode: der Modus, in dem das sekundäre Bootlaufwerk verwendet werden soll. Wenn dieser Wert auf CONTAINER_IMAGE_CACHE festgelegt ist, wird das sekundäre Bootlaufwerk als Container-Image-Cache verwendet. Der Wert muss entweder CONTAINER_IMAGE_CACHE oder MODE_UNSPECIFIED sein. Wenn dieser Wert nicht angegeben ist, lautet der Standardwert MODE_UNSPECIFIED.
  • placement: Die Besonderheiten der Maschinenaufstellung:

Das folgende Beispiel zeigt eine Prioritätsregel, in der machineFamily verwendet wird:

priorities:
- machineFamily: n4
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1
    secondaryBootDisks:
    - diskImageName: pytorch-mnist
      project: k8s-staging-jobset
machineType-Konfigurationen

Das Feld machineType akzeptiert einen vordefinierten Compute Engine-Maschinentyp wie n4-standard-32 oder einen String für einen benutzerdefinierten Maschinentyp wie n4-custom-8-20480. Für die Verwendung benutzerdefinierter Maschinentypen ist die GKE-Version 1.33.2-gke.1111000 oder höher erforderlich.

Sie können neben dem Feld machineType auch andere spec.priorities-Felder angeben, um Ihre Rechenanforderungen deklarativ zu definieren, z. B.:

  • spot: Spot-VMs verwenden Der Standardwert ist false.
  • storage: Knotenspeicher konfigurieren.
    • storage.bootDiskType: Bootlaufwerktyp In Autopilot wird nur der Typ pd-balanced von bootDiskType unterstützt.
    • storage.bootDiskKMSKey: Pfad zum Cloud KMS-Schlüssel, der für die Verschlüsselung des Bootlaufwerks verwendet werden soll.
    • storage.bootDiskSize: Größe in GB für das Bootlaufwerk des Knotens.
    • storage.localSSDCount: Anzahl der lokalen SSDs, die dem Knoten hinzugefügt werden sollen. Wenn angegeben, muss dieser mindestens 1 sein.

Das folgende Beispiel zeigt eine Prioritätsregel, mit der machineType verwendet wird, um n4-standard-32-Maschinentypen bereitzustellen:

priorities:
- machineType: n4-standard-32
  spot: true
  storage:
    bootDiskType: pd-balanced
    bootDiskSize: 250
    localSSDCount: 2
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1
GPU-Konfiguration

Wenn Sie GPUs in Ihren Prioritätsregeln auswählen möchten, geben Sie den Typ, die Anzahl und die driverVersion (optional) der GPU im Feld gpu einer Prioritätsregel an. Die folgenden Felder werden unterstützt:

  • gpu.type: Ein GPU-Typ, z. B. nvidia-l4. Weitere Informationen finden Sie unter GPU-Unterstützung mit Autopilot oder Standard auswählen.
  • gpu.count: Die Anzahl der anzuhängenden GPUs. Unterstützte Mengen nach GPU-Typ finden Sie unter Unterstützte GPU-Mengen.
  • gpu.driverVersion: Die zu installierende NVIDIA-Treiberversion. Muss default oder latest sein. Erfordert GKE-Version 1.31.1-gke.1858000 oder höher.

Sie können auch andere spec.priorities-Felder wie Spot-VMs, Speicheroptionen und Reservierungen in Kombination mit den gpu-Feldern angeben.

Das folgende Beispiel zeigt eine Regel für GPUs:

priorities:
- gpu:
    type: nvidia-l4
    count: 1
  storage:
    secondaryBootDisks:
    - diskImageName: big-llm
      project: k8s-llm
  spot: true
TPU-Konfiguration

Erfordert GKE-Version 1.31.2-gke.1518000 oder höher

Wenn Sie TPUs in Ihren Prioritätsregeln auswählen möchten, geben Sie den Typ, die Anzahl und die Topologie der TPU im Feld tpu einer Prioritätsregel an. Die folgenden Felder sind Pflichtfelder:

Sie können in Ihrer Prioritätsregel neben dem Feld tpu auch andere spec.priorities-Felder angeben, z. B.:

  • spot: Spot-VMs verwenden Der Standardwert ist false.
  • storage: Knotenspeicher konfigurieren.
    • storage.bootDiskType: Bootlaufwerktyp
    • storage.bootDiskKMSKey: Pfad zum Cloud KMS-Schlüssel, der für die Verschlüsselung des Bootlaufwerks verwendet werden soll.
    • storage.bootDiskSize: Größe in GB für das Bootlaufwerk des Knotens.
  • reservations: Compute Engine-Reservierung verwenden. Weitere Informationen finden Sie im Abschnitt Compute Engine-Reservierungen nutzen.

Das folgende Beispiel zeigt eine Regel für TPUs:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
    reservations:
      specific:
      - name: tpu-reservation
        project: reservation-project
      affinity: Specific
  - spot: true
    tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
  nodePoolAutoCreation:
    enabled: true

In diesem Beispiel wird das folgende Fallback-Verhalten definiert:

  1. GKE versucht, ein TPU v5p-Slice mit 16 Knoten und mehreren Hosts bereitzustellen, indem eine freigegebene Compute Engine-Reservierung mit dem Namen tpu-reservation aus dem Projekt reservation-project verwendet wird.
  2. Wenn für die Reservierung keine TPUs verfügbar sind, versucht GKE, ein TPU v5p-Slice mit 16 Knoten und mehreren Hosts bereitzustellen, das auf Spot-VMs ausgeführt wird.
  3. Wenn keine der oben genannten Regeln erfüllt werden kann, folgt GKE der Logik im Abschnitt Skalierungsverhalten definieren, wenn keine Prioritätsregeln gelten.

Nachdem Sie eine benutzerdefinierte TPU-ComputeClass in Ihrem Cluster bereitgestellt haben, wählen Sie diese benutzerdefinierte ComputeClass in Ihrer Arbeitslast aus:

Außerdem haben Sie bei TPU-Arbeitslasten folgende Möglichkeiten:

Spezifikationen für Beschleuniger und Maschinengröße

Bei deklarativen Beschleunigerkonfigurationen müssen die Felder machineType oder machineFamily nicht explizit angegeben werden, es sei denn, Sie verwenden sie in Kombination mit Reservierungen.

Prioritätsregeln für Knotenpools

Das Feld nodepools verwendet eine Liste der vorhandenen Knotenpools, in denen GKE versucht, ausstehende Pods zu erstellen. In GKE werden die Werte in diesem Feld nicht der Reihe nach verarbeitet. Sie können neben dem Feld nodepools keine anderen spec.priorities-Felder im selben Prioritätsregelelement verwenden, da Regeln mit dem Feld nodepools nicht deklarativ sind. Dieses Feld wird nur im GKE Standard-Modus unterstützt. Weitere Informationen zur Verwendung finden Sie unter In einer ComputeClass-Definition bestimmte Knotenpools als Ziel festlegen.

So erstellt GKE Knoten mithilfe von Prioritätsregeln

Wenn Sie eine Arbeitslast bereitstellen, für die eine ComputeClass angefordert wird und ein neuer Knoten erforderlich ist, verarbeitet GKE die Liste der Regeln im Feld priorities der ComputeClass-Spezifikation der Reihe nach.

Betrachten Sie beispielsweise die folgende Spezifikation:

spec:
  ...
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false

Wenn Sie eine Arbeitslast bereitstellen, die eine ComputeClass mit diesen Prioritätsregeln anfordert, ordnet GKE die Knoten so zu:

  1. GKE platziert Pods auf allen vorhandenen Knoten, die mit dieser ComputeClass verknüpft sind.
  2. Wenn die vorhandenen Knoten die Pods nicht aufnehmen können, stellt GKE neue Knoten bereit, die die N4-Maschinenreihe verwenden, Spot-VMs sind und mindestens 64 vCPU haben.
  3. Wenn N4-Spot-VMs mit mindestens 64 vCPUs in der Region nicht verfügbar sind, stellt GKE neue Knoten bereit, die N4-Spot-VMs verwenden, die in die Pods passen, unabhängig von der Anzahl der Kerne.
  4. Wenn in der Region keine N4-Spot-VMs verfügbar sind, stellt GKE neue On-Demand-N4-VMs bereit.
  5. Wenn keine der oben genannten Regeln erfüllt werden kann, folgt GKE der Logik im Abschnitt Skalierungsverhalten definieren, wenn keine Prioritätsregeln gelten.

Standardwerte für Prioritätsregeln

Sie können Standardwerte für einige der Felder in den Prioritätsregeln Ihrer ComputeClass-Spezifikation festlegen. Diese Standardwerte werden angewendet, wenn die entsprechenden Felder in einer bestimmten Regel nicht angegeben sind. Sie können diese Standardwerte mit dem Feld priorityDefaults in Ihrer ComputeClass-Spezifikation festlegen.

Für das Feld priorityDefaults gelten die folgenden Einschränkungen:

  • Erfordert GKE-Version 1.32.1-gke.1729000 oder höher.
  • Nicht kompatibel mit der Prioritätsregel nodepools, die keine Felder enthält.

Weitere Informationen zu den Arten von Standardwerten, die Sie festlegen können, finden Sie im Abschnitt priorityDefaults in der CustomResourceDefinition für ComputeClass.

GKE Standard-Knotenpools und Compute-Klassen

Wenn Sie den GKE-Standardmodus verwenden, müssen Sie möglicherweise eine manuelle Konfiguration ausführen, damit die Pods Ihrer ComputeClass wie erwartet geplant werden.

Manuell erstellte Knotenpools für die Verwendung mit einer ComputeClass konfigurieren

Wenn Ihre GKE-Standardcluster Knotenpools enthalten, die Sie manuell erstellt haben, müssen Sie diese Knotenpools konfigurieren, um sie bestimmten ComputeClasses zuzuordnen. GKE plant Pods, die eine bestimmte ComputeClass anfordern, nur auf Knoten in Knotenpools, die Sie dieser ComputeClass zuordnen. Diese Anforderung gilt nicht für eine ComputeClass, die Sie als Standard auf Clusterebene konfigurieren.

Knotenpools im GKE Autopilot-Modus und automatisch erstellte Knotenpools im GKE Standard-Modus führen diese Konfiguration für Sie aus.

Wenn Sie einen manuell erstellten Knotenpool mit einer ComputeClass verknüpfen möchten, fügen Sie dem Knotenpool beim Erstellen oder Aktualisieren Knotenlabels und Knotenmarkierungen hinzu. Geben Sie dazu das Flag --node-labels und das Flag --node-taints an:

  • Knotenlabel: cloud.google.com/compute-class=COMPUTE_CLASS
  • Markierung: cloud.google.com/compute-class=COMPUTE_CLASS:NoSchedule

In diesen Attributen ist COMPUTE_CLASS der Name Ihrer benutzerdefinierten ComputeClass.

Mit den folgenden Befehlen wird beispielsweise ein vorhandener Knotenpool aktualisiert und der Compute-Klasse dev-class zugeordnet:

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-labels="cloud.google.com/compute-class=dev-class"

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-taints="cloud.google.com/compute-class=dev-class:NoSchedule"

Sie können jedem Knotenpool in Ihrem Cluster eine benutzerdefinierte Compute-Klasse zuweisen. Pods, die GKE auf diesen manuell erstellten Knotenpools plant, lösen nur während Autoscaling-Ereignissen die Knotenerstellung in diesen Knotenpools aus.

Automatisches Erstellen von Knotenpools und Compute-Klassen

Sie können die automatische Knotenpoolerstellung mit einer benutzerdefinierten Compute-Klasse verwenden, damit GKE Knotenpools automatisch basierend auf Ihren Prioritätsregeln erstellen und löschen kann.

Damit GKE automatisch Knotenpools für eine Compute-Klasse erstellen kann, müssen Sie Folgendes tun:

  1. Fügen Sie der Spezifikation ComputeClass das Feld nodePoolAutoCreation mit dem Wert enabled: true hinzu.
  2. Sofern Ihr Cluster nicht für den Rapid Channel registriert ist und die GKE-Version 1.33.3-gke.1136000 oder höher ausgeführt wird, müssen Sie auch die automatische Knotenbereitstellung auf Clusterebene aktivieren.

GKE kann dann neue Knotenpools für Pods erstellen, die Ihre ComputeClass verwenden. GKE entscheidet basierend auf Faktoren wie der Größe der Cluster und den Pod-Anforderungen, ob ein vorhandener Knotenpool hochskaliert oder ein neuer Knotenpool erstellt wird. Bei Pods mit Compute-Klassen, für die die automatische Erstellung von Knotenpools nicht konfiguriert ist, werden weiterhin nur vorhandene Knotenpools skaliert.

Sie können Compute-Klassen, die die automatische Erstellung von Knotenpools ermöglichen, zusammen mit Compute-Klassen verwenden, die mit manuell erstellten Knotenpools im selben Cluster interagieren.

Berücksichtigen Sie die folgenden Interaktionen mit der automatischen Erstellung von Knotenpools:

  • Sie können die Knotenauswahlen Machinenfamilie und Spot-VMs nicht verwenden, da diese Auswahlen mit dem Verhalten der Compute-Klasse in Konflikt stehen. GKE lehnt alle Pods ab, die eine ComputeClass und auch Spot-VMs oder bestimmte Maschinenreihen anfordern.

  • Wenn Sie eine Standard-Compute-Klasse für Ihren Cluster festlegen, wird die Knotenerstellung für diese Standardklasse nur in den folgenden Situationen ausgelöst:

    • Die Pods wählen eine Maschinenfamilie aus, die einer der Prioritätsregeln in der Standardklasse auf Clusterebene entspricht. Wenn beispielsweise ein Pod N4-Instanzen auswählt, wird die Knotenerstellung ausgelöst, wenn die Standardklasse auf Clusterebene eine Prioritätsregel für N4-Instanzen hat.
    • Die Standard-ComputeClass auf Clusterebene hat im Feld spec.whenUnsatisfiable den Wert ScaleUpAnyway. Auch wenn die Pods eine Maschinenfamilie auswählen, die nicht in den ComputeClass-Prioritäten enthalten ist, erstellt GKE neue Knoten mit dieser Maschinenfamilie.

    Pods, für die eine Maschinenfamilie ausgewählt wird, die nicht in den Standardklassenprioritäten auf Clusterebene enthalten ist, lösen keine Knotenerstellung aus, wenn die ComputeClass im Feld whenUnsatisfiable den Wert DoNotScaleUp hat.

  • Sie können die automatische Erstellung von Knotenpools für Compute-Klassen konfigurieren, die das Feld nodepools verwenden, um auf vorhandene Knotenpools zu verweisen. GKE verarbeitet die Prioritäten der Reihe nach und versucht, die vorhandenen Knotenpools zu skalieren, um Ihre Pods zu platzieren.

Betrachten Sie das folgende Beispiel für einen Cluster, der sowohl manuell erstellte Knotenpools als auch die automatische Erstellung von Knotenpools enthält:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - nodepools: [manually-created-pool]
  - machineFamily: n4
  - machineFamily: c4
  nodePoolAutoCreation:
    enabled: true

In diesem Beispiel versucht GKE Folgendes:

  1. Erstellen Sie neue Knoten im Knotenpool manually-created-pool.
  2. N4-Knoten entweder in vorhandenen N4-Knotenpools bereitstellen oder einen neuen Knotenpool erstellen
  3. Wenn GKE keine N4-Knoten erstellen kann, wird versucht, vorhandene C4-Knotenpools vertikal zu skalieren oder neue C4-Knotenpools zu erstellen.

In einer ComputeClass-Definition bestimmte Knotenpools als Ziel festlegen

Im Feld priorities.nodepools können Sie eine Liste von manuell erstellten Knotenpools angeben, in denen GKE in GKE-Standardclustern, die Cluster-Autoscaling verwenden, versucht, Pods in keiner bestimmten Reihenfolge zu planen. Dieses Feld unterstützt nur eine Liste von Knotenpools. Sie können in derselben Prioritätsregel keine zusätzlichen Maschineneigenschaften wie die Maschinenreihe angeben. Wenn Sie eine Arbeitslast bereitstellen, die eine ComputeClass mit benannten Knotenpools anfordert, versucht GKE, die ausstehenden Pods in diesen Knotenpools zu planen. GKE kann in diesen Knotenpools neue Knoten erstellen, um die Pods zu platzieren.

Die Knotenpools, die Sie im Feld priorities.nodepools angegeben haben, müssen dieser ComputeClass mithilfe von Knotenlabels und Knotenmarkierungen zugeordnet werden, wie im Abschnitt Manuell erstellte Knotenpools für ComputeClasses konfigurieren beschrieben.

Die Liste der Knotenpools, die Sie im Feld nodepools angeben, hat keine Priorität. Zum Konfigurieren einer Fallback-Reihenfolge für benannte Knotenpools müssen Sie mehrere separate priorities.nodepools-Elemente angeben. Betrachten Sie beispielsweise die folgende Spezifikation:

spec:
  ...
  priorities:
  - nodepools: [pool1, pool2]
  - nodepools: [pool3]

In diesem Beispiel versucht GKE zuerst, ausstehende Pods, die diese ComputeClass anfordern, auf vorhandenen Knoten in Knotenpools zu platzieren, die mit der ComputeClass gekennzeichnet sind. Wenn vorhandene Knoten nicht verfügbar sind, versucht GKE, neue Knoten in pool1 oder pool2 bereitzustellen. Wenn GKE keine neuen Knoten in diesen Knotenpools bereitstellen kann, versucht GKE, neue Pods in pool3 bereitzustellen.

Skalierungsverhalten definieren, wenn keine Prioritätsregeln gelten

Mit der benutzerdefinierten Ressource ComputeClass können Sie angeben, was GKE tun soll, wenn keine Knoten vorhanden sind, die eine der Prioritätsregeln erfüllen können. Das Feld whenUnsatisfiable in der Spezifikation unterstützt die folgenden Werte.

  • ScaleUpAnyway: Einen neuen Knoten erstellen, der die Standardmaschinenkonfiguration des Clusters verwendet In GKE-Versionen vor 1.33 ist dies das Standardverhalten, wenn Sie dieses Feld weglassen.

    GKE führt eine der folgenden Aktionen aus:

    • In Autopilot-Clustern platziert GKE den Pod unabhängig von der Konfiguration der Knotenmaschine auf einem neuen oder vorhandenen Knoten.
    • In Standardclustern, die keine automatische Knotenpoolerstellung verwenden, versucht GKE, jeden manuell erstellten Knotenpool hochzuskalieren, der ein Label und eine Markierung definiert, die einer bestimmten ComputeClass entsprechen.
    • In Standardclustern, in denen die automatische Knotenpoolerstellung verwendet wird, erstellt GKE möglicherweise einen neuen Knotenpool, in dem der Pod mit der Standard-E2-Maschinenreihe platziert wird.

  • DoNotScaleUp: Belassen Sie den Pod im Status Pending, bis ein Knoten verfügbar ist, der die Anforderungen der Compute-Klasse erfüllt. In GKE-Version 1.33 und höher ist dies das Standardverhalten, wenn Sie dieses Feld weglassen.

Platzierungsrichtlinie anfordern

Ab der GKE-Version 1.33.2-gke.1335000 können Sie in GKE Autopilot-Clustern die kompakte Platzierung mit einer benutzerdefinierten Platzierungsrichtlinie oder Arbeitslastrichtlinie verwenden. Weitere Informationen finden Sie unter Vergleich von Richtlinien für kompakte Platzierung und Arbeitslastrichtlinien.

Sowohl mit der Platzierungsrichtlinie als auch mit der Arbeitslastrichtlinie werden Knoten physisch nahe beieinander platziert, um die Netzwerklatenz zu reduzieren. Wenn Sie eine bestimmte Richtlinie verwenden möchten, geben Sie ihren Namen im Feld policyName an. Die Richtlinie muss eine Compute Engine-Ressourcenrichtlinie sein, die bereits im GKE-Projekt vorhanden ist.

Dazu ein Beispiel:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
    placement:
      policyName: my-placement-policy
  nodePoolAutoCreation:
    enabled: true

In dieser Konfiguration wendet GKE die Richtlinie für die kompakte Platzierung für alle Arbeitslasten an, die diese ComputeClass verwenden, und stellt die zugehörigen Knoten gemäß der vorhandenen Ressourcenrichtlinie mit dem Namen my-placement-policy bereit.

Autoscaling-Parameter für die Knotenkonsolidierung festlegen

Standardmäßig entfernt GKE nicht ausgelastete Knoten durch das Ausführen von Arbeitslasten. Dadurch werden diese Arbeitslasten auf anderen Knoten mit Kapazität konsolidiert. Dies ist für alle Compute-Klassen das Standardverhalten, da alle Cluster, die Compute-Klassen verwenden, den Cluster Autoscaler verwenden oder Autopilot-Cluster sind. Bei einer Knotenkonsolidierung entlastet GKE einen nicht optimal genutzten Knoten, erstellt die Arbeitslasten auf einem anderen Knoten neu und löscht den entlasteten Knoten.

Der Zeitpunkt und die Kriterien für das Entfernen des Knotens hängen vom Autoscaling-Profil ab. Sie können die Grenzwerte für die Unterauslastung von Ressourcen, die das Entfernen von Knoten und die Konsolidierung von Arbeitslasten auslösen, im Abschnitt autoscalingPolicy in der Definition Ihrer benutzerdefinierten ComputeClass optimieren. Sie können die folgenden Parameter optimieren:

  • consolidationDelayMinutes: Die Anzahl der Minuten, nach denen GKE nicht ausreichend genutzte Knoten entfernt
  • consolidationThreshold: Der Auslastungsgrenzwert für CPU und Arbeitsspeicher als Prozentsatz der verfügbaren Ressourcen des Knotens. GKE berücksichtigt nur dann Knoten zum Entfernen, wenn die Ressourcennutzung unter diesem Schwellenwert liegt.
  • gpuConsolidationThreshold: Der Auslastungsgrenzwert für die GPU als Prozentsatz der verfügbaren Ressourcen des Knotens. GKE berücksichtigt nur dann Knoten zum Entfernen, wenn die Ressourcennutzung unter diesem Schwellenwert liegt. Legen Sie diesen Wert auf 100 oder 0 fest, damit GKE alle Knoten konsolidiert, bei denen die angeschlossenen GPUs nicht zu 100 % ausgelastet sind.

Dazu ein Beispiel:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
  - machineFamily: c4
  autoscalingPolicy:
    consolidationDelayMinutes: 5
    consolidationThreshold: 70

In dieser Konfiguration entfernt GKE nicht verwendete Knoten nach fünf Minuten. Knoten werden nur dann für die Konsolidierung ausgewählt, wenn sowohl ihre CPU- als auch ihre Arbeitsspeicherauslastung unter 70 % liegt.

Aktive Migration

Die aktive Migration ist eine optionale Autoscaling-Funktion in benutzerdefinierten Compute-Klassen, die vorhandene Knoten automatisch durch neue Knoten ersetzt. Knoten werden je nach Art der Migration anhand bestimmter Kriterien ersetzt.

Bei einer aktiven Migration erstellt GKE neue Knoten und drosselt und löscht dann die veralteten Knoten. Die Migration erfolgt schrittweise, um die Unterbrechung der Arbeitslast zu minimieren. Bei aktiven Migrationen ist Folgendes zu beachten:

  • Bei der aktiven Migration werden keine Daten migriert, die in nichtflüchtigem Speicher wie Compute Engine-Laufwerken gespeichert sind. Um das Risiko von Datenverlust zu minimieren, sollten Sie die aktive Migration nicht in Compute-Klassen aktivieren, die von zustandsbehafteten Arbeitslasten verwendet werden.
  • Wenn Sie die automatische Knotenbereitstellung in Ihren Standardclustern aktiviert haben, kann eine aktive Migration das Erstellen neuer Knotenpools auslösen, wenn vorhandene Knotenpools die Kriterien nicht erfüllen, die in Ihrer benutzerdefinierten Compute-Klasse definiert sind.
  • Bei der aktiven Migration werden keine Knoten ersetzt, die nicht entfernt werden können. Bei der aktiven Migration wird ein Knoten beispielsweise nicht ersetzt, wenn dadurch die Knotenpooleinstellung --min-nodes verletzt wird.
  • Um Unterbrechungen kritischer Arbeitslasten zu vermeiden, werden bei der aktiven Migration die folgenden Pods nicht verschoben:
    • Pods, für die ein PodDisruptionBudget festgelegt ist, wenn die Migration das PodDisruptionBudget überschreiten würde.
    • Pods mit der Anmerkung cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
  • Arbeitslasten, die nichtflüchtige Speicher mit zonalen Ressourcen wie Hyperdisk verwenden, funktionieren möglicherweise nicht gut mit der aktiven Migration. Zonale Einschränkungen und die Einschränkungen für Maschinentypen einiger Hyperdisk-Produkte können die Effektivität der aktiven Migration verringern. Außerdem können einige zustandsorientierte Arbeitslasten die durch die aktive Migration verursachte Unterbrechung möglicherweise nicht tolerieren.
  • Wenn Sie eine vorhandene ComputeClass aktualisieren, um die aktive Migration zu aktivieren, migriert GKE vorhandene Pods im Laufe der Zeit auf neue Knoten.

Die folgenden Arten der aktiven Migration werden unterstützt:

Aktive Migration zu Knoten mit höherer Priorität konfigurieren

Sie können die aktive Migration so konfigurieren, dass vorhandene Knoten, die in einer Fallback-Prioritätsliste für Compute-Klassen niedriger sind, durch neue Knoten ersetzt werden, die in dieser Prioritätsliste weiter oben sind. Diese Konfiguration sorgt dafür, dass alle laufenden Pods schließlich auf den für diese ComputeClass am besten geeigneten Knoten ausgeführt werden, auch wenn GKE diese Pods ursprünglich auf weniger geeigneten Knoten ausführen musste.

In der folgenden Beispielspezifikation für die Compute-Klasse werden N4-Knoten C4-Knoten vorgezogen:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
  - machineFamily: c4
  activeMigration:
    optimizeRulePriority: true

Wenn bei der Bereitstellung eines Pods mit dieser ComputeClass keine N4-Knoten verfügbar wären, hätte GKE C4-Knoten als Fallback-Option verwendet. Wenn N4-Knoten für die spätere Bereitstellung verfügbar sind, z. B. wenn Ihr Kontingent erhöht wird oder wenn N4-VMs an Ihrem Standort verfügbar sind, erstellt GKE einen neuen N4-Knoten und migriert den Pod schrittweise vom vorhandenen C4-Knoten zum neuen N4-Knoten. GKE löscht dann den veralteten C4-Knoten.

Aktive Migration zum Ausführen von nicht planbaren DaemonSet-Pods konfigurieren

Sie können die aktive Migration so konfigurieren, dass vorhandene Knoten mit nicht planbaren DaemonSet-Pods automatisch durch größere Knoten ersetzt werden, auf denen alle erforderlichen DaemonSet-Pods ausgeführt werden können.

Hier ein Beispiel für eine ComputeClass-Spezifikation:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n1
  activeMigration:
    ensureAllDaemonSetPodsRunning: true

Wenn beispielsweise durch die Bereitstellung eines Pods mit dieser ComputeClass eine n1-standard-2-Maschine skaliert wurde und Sie später ein DaemonSet bereitgestellt haben, das zwei CPUs anfordert, würde durch die aktive Migration der n1-standard-2-Knoten durch einen größeren Knoten aus derselben n1-Maschinenfamilie, z. B. einen n1-standard-4-Knoten, ersetzt, um genügend Platz für alle Pods zu schaffen.

Compute Engine-Reservierungen nutzen

Verfügbar in GKE-Version 1.31.1-gke.2105000 und höher

Wenn Sie Compute Engine-Kapazitätsreservierungen verwenden, um eine höhere Gewissheit der Hardwareverfügbarkeit in bestimmtenGoogle Cloud -Zonen zu erhalten, können Sie jede Fallback-Priorität in Ihrer benutzerdefinierten ComputeClass so konfigurieren, dass GKE Reservierungen beim Erstellen neuer Knoten nutzt.

Für die Nutzung von Reservierungen in benutzerdefinierten Compute-Klassen gelten die folgenden Anforderungen:

  • Sie müssen die automatische Erstellung von Knotenpools verwenden, damit GKE Reservierungen zum Erstellen neuer Knoten nutzen kann. Weitere Informationen finden Sie im Abschnitt Automatische Erstellung von Knotenpools und Compute-Klassen. Sie können Reservierungen auch weiterhin nutzen, wenn Sie Knotenpools in Ihrem Cluster manuell erstellen.
  • Reservierungen, die keine TPUs betreffen, können nur verwendet werden, wenn entweder machineType oder machineFamily definiert ist.
  • Compute-Klassen, die lokale SSDs konfigurieren, müssen die Prioritätsregel machineType und nicht machineFamily verwenden. Weitere Informationen finden Sie im Abschnitt Regeltyp „machineType“.
  • ComputeClasses, die Reservierungen für eine machineType mit angehängten lokalen SSDs angeben, müssen explizit ein localSSDCount:-Feld enthalten.

In der folgenden Beispielspezifikation für die Compute-Klasse wird eine bestimmte freigegebene Reservierung für die Bereitstellung von a3-highgpu-1g-Instanzen priorisiert. Wenn die priorisierten Instanztypen nicht verfügbar sind, greift GKE auf alle übereinstimmenden Reservierungen in der Spezifikation zurück:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: accelerator-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      specific:
      - name: a3-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      affinity: AnyBestEffort
  whenUnsatisfiable: DoNotScaleUp

Wenn Sie einen Pod bereitstellen, der die Compute-Klasse accelerator-reservations verwendet, versucht GKE zuerst, die Reservierung a3-shared-reservation zu verwenden, wenn neue a3-highgpu-1g-Instanzen zum Ausführen des Pods erstellt werden. Wenn für diese spezielle Reservierung keine Kapazität verfügbar ist, versucht GKE, a3-highgpu-1g-Instanzen mit einer übereinstimmenden Reservierung hochzuskalieren. Wenn keine Reservierungen verfügbar sind, greift GKE auf a3-highgpu-1g-Spot-VMs zurück. Wenn keine Spot-VMs verfügbar sind, schlägt der Skalierungsvorgang fehl.

In diesem Beispiel ist das Feld localSSDCount: für beide Prioritätsregeln mit Reservierungsreferenzen explizit erforderlich, da die Maschinenform a3-highgpu-1g lokale SSDs enthält.

Im folgenden Beispiel wird eine freigegebene spezifische Reservierung gezeigt, die auf Spot-VMs und dann auf On-Demand-VMs zurückgreift:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: shared-specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: n4
    reservations:
      specific:
      - name: n4-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineFamily: n4
    spot: true
  - machineFamily: n4
  whenUnsatisfiable: DoNotScaleUp

Sie können die folgenden Arten von Reservierungen nutzen:

  • Spezifische Reservierungen für ein einzelnes Projekt: Konfigurieren Sie die folgenden Felder:

    • reservations.specific.name: Der Name der Reservierung.
    • reservations.affinity: muss Specific sein.

  • Bestimmte freigegebene Reservierungen: Konfigurieren Sie die folgenden Felder:

    • reservations.specific.name: Der Name der Reservierung.
    • reservations.specific.project: die Projekt-ID des Projekts, zu dem die Reservierung gehört.
    • reservations.affinity: muss Specific sein.

  • Jede übereinstimmende Reservierung: Konfigurieren Sie die folgenden Felder:

    • reservations.affinity: muss AnyBestEffort sein.
    • Legen Sie keinen Reservierungsnamen oder kein Projekt fest.

Für TPU-Reservierungen ist eine spezifische Affinität erforderlich. reservations.affinity: AnyBestEffort wird nicht unterstützt.

Wenn GKE in einer Reservierung keine verfügbare Kapazität findet, hängt das resultierende Verhalten vom Typ der Reservierung ab, die in der ComputeClass-Prioritätsregel ausgewählt ist:

  • Spezifische Reservierungen: GKE versucht die nächste Prioritätsregel in der ComputeClass.
  • Alle übereinstimmenden Reservierungen: GKE versucht, einen On-Demand-Knoten bereitzustellen, der die Anforderungen dieser Prioritätsregel erfüllt. Wenn GKE keinen On-Demand-Knoten bereitstellen kann, wird die nächste Prioritätsregel in der Compute-Klasse ausprobiert.

Wenn GKE die Anforderungen keiner der Prioritätsregeln für die Compute-Klasse erfüllen kann, tritt das Verhalten ein, wenn keine Regeln gelten.

Bestimmte Reservierungsblöcke nutzen

Ab der GKE-Version 1.31.4-gke.1072000 können Sie einen bestimmten Reservierungsblock in einer hardwaregestützten Reservierung auswählen. Diese Funktion ist für die Maschinentypen A3 Ultra und A4 verfügbar.

Wenn Sie einen bestimmten Reservierungsblock nutzen möchten, konfigurieren Sie Ihre ComputeClass-Ressource wie in diesem Beispiel:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: a3
    gpu:
      type: nvidia-h200-141gb
      count: 8
    reservations:
      specific:
      - name: a3ultra-specific-reservation
        reservationBlock:
          name: RESERVATION_BLOCK_NAME
      affinity: Specific

Ersetzen Sie RESERVATION_BLOCK_NAME durch den Namen des Zielreservierungsblocks.

Ab der GKE-Version 1.33.1-gke.1788000 können Sie einen bestimmten Reservierungsunterblock innerhalb eines Reservierungsblocks als Ziel festlegen. Diese Funktion ist für den Maschinentyp A4X verfügbar.

Wenn Sie einen bestimmten Reservierungsunterblock nutzen möchten, konfigurieren Sie Ihre ComputeClass-Ressource wie im Beispiel unter Bestimmte Reservierungsunterblöcke nutzen gezeigt.

Beachten Sie bei der Verwendung dieser Funktion die folgenden Aspekte:

  • Diese Funktionen gelten nur für bestimmte Reservierungen in einem einzelnen oder einem freigegebenen Projekt.

Knotensystemkonfiguration anpassen

Sie können bestimmte Parameter im Kubelet und im Linux-Kernel anpassen, indem Sie das Feld nodeSystemConfig in Ihrer ComputeClass-Spezifikation verwenden. Sie können dieses Feld in jeder Prioritätsregel angeben, in der eine Compute Engine-Maschinenserie oder ein Compute Engine-Maschinentyp definiert wird. Sie können auch globale Standardwerte für alle Felder der Knotenkonfiguration festlegen, die in Prioritätsregeln ausgelassen werden. Fügen Sie dazu das Feld nodeSystemConfig dem Feld priorityDefaults in Ihrer ComputeClass hinzu.

Dieses Feature ist in GKE ab Version 1.32.1-gke.1729000 verfügbar.

Weitere Informationen finden Sie auf den folgenden Seiten:

Standard-ComputeClasses für Cluster und Namespaces

Sie können GKE so konfigurieren, dass standardmäßig eine ComputeClass auf Pods angewendet wird, für die keine bestimmte ComputeClass ausgewählt ist. Sie können eine Standard-ComputeClass für bestimmte Namespaces oder für einen gesamten Cluster definieren. Weitere Informationen zum Konfigurieren Ihrer Cluster oder Namespaces mit einer Standardklasse finden Sie unter ComputeClasses standardmäßig auf Pods anwenden.

Knotenpools gruppieren

Ab GKE-Version 1.32.2-gke.1359000 können Sie mehrere Knotenpools in einer einzelnen logischen Einheit namens Sammlung gruppieren, indem Sie das Feld nodePoolGroup in Ihrer ComputeClass-Spezifikation verwenden. Durch diese Gruppierung können Sie gemeinsame Konfigurationen auf viele Knotenpools anwenden.

TPU-Sammlung mit mehreren Hosts

Sie können Ihr TPU-Deployment mit mehreren Hosts gruppieren, um ein Service Level Objective (SLO) für alle Knotenpools in der Sammlung festzulegen. Wenn Sie Knotenpools gruppieren möchten, geben Sie den Namen der Gruppe im Feld nodePoolGroup an. Alle Knotenpools, die mit dieser ComputeClass bereitgestellt werden, gehören derselben Gruppe an.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-multi-host-collection
spec:
  nodePoolGroup:
    name: my-tpu-collection
  ...

Hier finden Sie weitere Informationen:

Knotenpoolkonfiguration

Mit dem Feld nodePoolConfig in Ihrer ComputeClass-Spezifikation können Sie eine Konfiguration anwenden, die sich auf alle Knoten in den Knotenpools auswirkt, die mit dieser Klasse erstellt wurden.

Bildtyp angeben

Sie können das Basisbetriebssystem für die Knoten im Knotenpool mit dem Feld imageType angeben. In diesem Feld können Sie einen Image-Typ für die Knotenpools auswählen, die auf den Knoten ausgeführt werden. Wenn Sie dieses Feld weglassen, ist der Standardwert cos_containerd. Das folgende Beispiel zeigt, wie Sie imageType in Ihrer ComputeClass angeben:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-node-pool-config
spec:
  nodePoolConfig:
    imageType: cos_containerd

Weitere Informationen finden Sie unter Knoten-Images.

Dienstkonto

Im Feld serviceAccount wird das Google Cloud Dienstkonto angegeben, das von den Knoten in Knotenpools verwendet wird, die von der ComputeClass verwaltet werden. Im folgenden Beispiel wird gezeigt, wie Sie die serviceAccount in Ihrer ComputeClass angeben:

spec:
  nodePoolConfig:
    serviceAccount: my-service-account@my-project.iam.gserviceaccount.com

Weitere Informationen finden Sie unter Dienstkonten in GKE.

Arbeitslasttyp für TPU-SLO definieren

Ab GKE-Version 1.32.2-gke.1359000 können Sie das Service Level Objective (SLO) für Ihre TPU-Arbeitslasten mit dem Feld workloadType in nodePoolConfig definieren. Der Wert in diesem Feld gibt GKE den beabsichtigten Verwendungszweck der TPU-Ressourcen an. Das Feld workloadType unterstützt die folgenden Werte:

  • HIGH_AVAILABILITY: Verwenden Sie diesen Wert für Verfügbarkeits-orientierte Arbeitslasten wie Inferenzbereitstellung, um Unterbrechungen zu begrenzen und zu optimieren.
  • HIGH_THROUGHPUT: Verwenden Sie diesen Wert für Batch- oder Trainingsjobs, bei denen die gesamte zugrunde liegende Infrastruktur die meiste Zeit ausgeführt werden muss, um Fortschritte zu erzielen. Dieser Wert kann nur verwendet werden, wenn auch nodePoolGroup angegeben ist.

Im folgenden Beispiel wird eine ComputeClass für eine TPU-Sammlung mit mehreren Hosts definiert, die für Inferenzarbeitslasten mit hoher Verfügbarkeit optimiert ist.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: multi-host-inference
spec:
  nodePoolGroup:
    name: my-inference-collection
  nodePoolConfig:
    workloadType: HIGH_AVAILABILITY
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - tpu:
      type: tpu-v6e-slice
      topology: 2x4

Weitere Informationen finden Sie auf den folgenden Seiten:

Compute-Klassen in Arbeitslasten anfordern

Wenn Sie eine benutzerdefinierte ComputeClass verwenden möchten, muss Ihr Pod diese ComputeClass explizit anfordern, indem er ein nodeSelector in der Pod-Spezifikation verwendet. Optional können Sie eine ComputeClass als Standard für einen bestimmten Kubernetes-Namespace festlegen. Pods in diesem Namespace verwenden diese ComputeClass, sofern sie keine andere ComputeClass anfordern.

Im folgenden Manifest wird beispielsweise die Compute-Klasse cost-optimized angefordert:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: custom-workload
spec:
  replicas: 2
  selector:
    matchLabels:
      app: custom-workload
  template:
    metadata:
      labels:
        app: custom-workload
    spec:
      nodeSelector:
        cloud.google.com/compute-class: cost-optimized
      containers:
      - name: test
        image: gcr.io/google_containers/pause
        resources:
          requests:
            cpu: 1.5
            memory: "4Gi"

Knotenselektoren für Systemknotenlabels

GKE fügt Knoten Systemlabels hinzu, um Knoten anhand von Kriterien wie dem Maschinentyp, angehängten Hardwarebeschleunigern oder dem Typ des Bootlaufwerks zu identifizieren. Diese Systemlabels haben eines der folgenden Präfixe im Labelschlüssel:

  • k8s.io
  • cloud.google.com
  • gke.io

In GKE-Version 1.32.3-gke.1499000 und höher können Sie Arbeitslasten bereitstellen, die gleichzeitig einen Knotenselektor zum Auswählen von Systemlabels und eine ComputeClass verwenden. Wenn Sie Systemlabels in Pods auswählen, die Compute-Klassen auswählen, prüfen Sie, ob diese Pods wie erwartet geplant werden. Ein Konflikt zwischen der Konfiguration einer ComputeClass und den Knotenselektoren in einem Pod kann zu Problemen wie den folgenden führen:

  • GKE kann keine Knoten erstellen, die die Konfiguration mit der höchsten Priorität für die ComputeClass verwenden.
  • Der Pod bleibt im Status Pending.

GKE lehnt auch alle Pods ab, die Systemlabels auswählen, für die es ein entsprechendes Feld in der ComputeClass-Spezifikation gibt. Wenn Sie ComputeClasses verwenden, aktualisieren Sie Ihre Arbeitslasten, um die folgenden Labels aus Knotenselektoren zu entfernen, und konfigurieren Sie das entsprechende Feld in den ComputeClasses, die Sie erstellen:

Knotenlabel Feld ComputeClass
cloud.google.com/machine-family priorities.machineFamily
cloud.google.com/machine-type priorities.machineType
cloud.google.com/gke-spot priorities.spot
cloud.google.com/gke-accelerator priorities.gpu.type
cloud.google.com/gke-gpu-driver-version priorities.gpu.driverVersion
cloud.google.com/reservation-name priorities.reservations.specific.name
cloud.google.com/reservation-project priorities.reservations.specific.project
cloud.google.com/reservation-affinity priorities.reservations.affinity
cloud.google.com/gke-ephemeral-storage-local-ssd priorities.storage.localSSDCount
cloud.google.com/gke-boot-disk priorities.storage.bootDiskType
cloud.google.com/gke-boot-disk-size priorities.storage.bootDiskSize
cloud.google.com/gke-node-pool-group-name nodePoolGroup.name
cloud.google.com/gke-workload-type nodePoolConfig.workloadType

Beschränkungen

Der Name Ihrer ComputeClass darf nicht mit gke oder autopilot beginnen.

Nächste Schritte