Benutzerdefinierte Compute-Klassen

Autopilot Standard

Sie können eigene ComputeClasses 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 zur automatischen Skalierung von Knoten verwendet, um die Anforderungen bestimmter Arbeitslasten bestmöglich zu erfüllen.

ComputeClasses 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. ComputeClasses können standardmäßig in allen unterstützten GKE-Clustern konfiguriert und verwendet werden.

Vorteile benutzerdefinierter ComputeClasses

Benutzerdefinierte ComputeClasses bieten folgende Vorteile:

• Fallback-Computing-Prioritä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-ComputeClasses: 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.
• Deklarative Mindestkapazität: Sie können proaktiv eine Mindestanzahl von Knoten dieser ComputeClass in Ihrem Cluster verwalten, um sicherzustellen, dass Kapazität für kritische Arbeitslasten verfügbar ist.

Anwendungsfälle für benutzerdefinierte ComputeClasses

Ziehen Sie die Verwendung benutzerdefinierter ComputeClasses 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 verwenden soll, um neue Knoten für bestimmte Arbeitslasten bereitzustellen.
• 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 ComputeClasses

Benutzerdefinierte ComputeClasses 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 eine übereinstimmende Arbeitslast neue Infrastruktur erfordert, stellt GKE neue Knoten gemäß den Prioritäten bereit, die Sie in Ihrer ComputeClass-Definition festgelegt haben.

Die Attribute, die Sie in Ihren ComputeClasses festlegen, definieren, wie GKE neue Knoten für die Ausführung 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. Die Konfiguration vorhandener Knoten wird von GKE nicht rückwirkend geändert, um sie an Ihre Änderungen anzupassen.

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

Beachten Sie die folgenden Richtlinien, damit Ihre benutzerdefinierten ComputeClasses 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 sich die CRD in Ihrem Cluster auch mit dem folgenden Befehl ansehen:

kubectl describe crd computeclasses.cloud.google.com

Benutzerdefinierte ComputeClass 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-Standardknotenpools 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, beim Erstellen neuer Knoten vorhandene zonale Compute Engine-Reservierungen zu nutzen.
7. Mindestanzahl von Knoten bereitstellen: Optional können Sie GKE anweisen, eine Mindestanzahl von Knoten in Ihrem Cluster beizubehalten.

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 zonaler Ressourcenerschöpfung (z. B. ZONE_RESOURCE_POOL_EXHAUSTED- oder GCE out of resources-Meldungen während FailedScaleUp-Ereignissen) und Kontingenteinschränkungen nicht verfügbar sind. Wenn Sie eine priorisierte Liste alternativer Maschinenserien oder Bereitstellungsmodelle definieren, kann Ihr Cluster automatisch verfügbare Kapazität bereitstellen, anstatt Pods im Status Pending zu belassen. Weitere Informationen zur Fehlerbehebung bei unzureichender Rechenkapazität finden Sie unter Knotenpool kann aufgrund unzureichender Ressourcen nicht erstellt werden und Knotenskalierung fehlgeschlagen: Compute Engine hat keine Ressourcen mehr.

Sie erstellen eine Fallback-Strategie, indem Sie im Feld priorities in der ComputeClass-Spezifikation eine Liste von Prioritätsregeln definieren. Jede Prioritätsregel kann Knoten auf eine der folgenden Arten anfordern:

• Knotenattribute: Definieren Sie die Attribute der Knoten, auf denen Pods ausgeführt werden sollen, z. B. die zu verwendenden Maschinenfamilien. Wenn ein Pod einen Hochskalierungsvorgang auslöst, versucht GKE, einen Knoten mit diesen Attributen zu erstellen. In jeder Prioritätsregel muss ein Hardwaretyp angegeben werden, der bereitgestellt werden soll, wie im Abschnitt Knoteneigenschaften auf oberster Ebene für Prioritätsregeln beschrieben.

• Knotenpoolauswahl: Geben Sie in GKE-Standardclustern die Namen vorhandener Knotenpools an, die mit der ComputeClass verknüpft werden sollen. Wenn ein Pod einen Hochskalierungsvorgang auslöst, versucht GKE, den Pod in diesen Knotenpools zu platzieren. Prioritätsregeln, die Knotenpools auswählen, unterstützen keine anderen Felder. Weitere Informationen finden Sie im Abschnitt GKE Standard-Knotenpools und ComputeClasses.

Wenn ein neuer Knoten für einen eingehenden Pod benötigt wird, der eine ComputeClass auswählt, versucht GKE standardmäßig, Knoten in der Reihenfolge zu erstellen, in der die Prioritätsregeln im ComputeClass-Manifest angezeigt werden. In GKE-Version 1.35.2-gke.1842000 und höher können Sie mit dem Feld priorityScore auch explizit eine Punktzahl für jede Prioritätsregel in einer ComputeClass festlegen. In diesem Fall verarbeitet GKE die Regeln in der Reihenfolge von der höchsten zur niedrigsten Punktzahl. Wenn alle Prioritätsregeln in einer ComputeClass ausgeschöpft sind, erstellt GKE Knoten basierend auf dem Verhalten, das unter Skalierungsverhalten definieren, wenn keine Prioritätsregeln gelten beschrieben ist.

Prioritätsregel-Scores

Erfordert GKE-Version 1.35.2-gke.1842000 oder höher.

Wenn Sie die Reihenfolge, in der GKE Prioritätsregeln für eine ComputeClass verarbeitet, genau steuern möchten, verwenden Sie das Feld priorityScore in Ihren Regeln. Während der Skalierung verarbeitet GKE Ihre Prioritätsregeln anhand der Punktzahl. Größere Punktzahlen haben dabei eine höhere Priorität als kleinere Werte.

Das Feld priorityScore hat die folgenden Eigenschaften:

• Das Feld akzeptiert einen ganzzahligen Wert mit einem Mindestwert von 1 und einem Höchstwert von 1000.
• Sie müssen das Feld priorityScore in allen oder in keiner Ihrer Prioritätsregeln verwenden.

• Sie können für bis zu drei separate Regeln denselben Prioritätswert festlegen. Während der Skalierung verarbeitet GKE Regeln mit derselben Punktzahl zusammen. Die GKE wählt eine bestimmte Regel basierend auf den Betriebskriterien des Cluster-Autoscalers aus.

  Gruppierte Regeln können die Latenz des Autoscalings erhöhen, da GKE mehr Simulationen ausführen muss, um die optimale Knotenkonfiguration zu ermitteln. Die Wahrscheinlichkeit, dass Sie eine Latenzerhöhung bemerken, hängt davon ab, wie breit die Hardwareauswahl in der Regel ist:

  • Regeln mit einem breiten Umfang, z. B. das Attribut machineFamily, tragen eher zu einer leichten Erhöhung der Autoscaling-Latenz bei. Es ist jedoch wahrscheinlicher, dass die GKE verfügbare Hardware findet, die die Anforderungen dieser Regeln erfüllt.
  • Regeln mit einem engen Bereich, z. B. die Property machineType, tragen weniger wahrscheinlich zu einer Erhöhung der Latenz bei. Es ist jedoch wahrscheinlicher, dass GKE keine verfügbare Hardware findet, die den Anforderungen dieser Regeln entspricht.

Das folgende Beispiel zeigt eine ComputeClass, die Prioritätsregelwerte festlegt:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: priority-rule-score-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  # Highest priority score in the ComputeClass
  - machineFamily: e2
    spot: true
    priorityScore: 30
  # Grouped priority rules that have the same score.
  - machineFamily: n2
    spot: true
    priorityScore: 20
  - machineFamily: t2d
    spot: true
    priorityScore: 20
  # Lowest priority score in the ComputeClass.
  - machineFamily: n1
    spot: true
    priorityScore: 10
  whenUnsatisfiable: ScaleUpAnyway

Während eines Hochskalierungsereignisses für diese Beispiel-ComputeClass führt GKE Folgendes aus:

1. Die GKE versucht, E2-Instanzen zu erstellen.
2. Wenn keine E2-Instanzen verfügbar sind, erstellt die GKE entweder N2- oder T2D-Instanzen, je nach Ergebnis des Cluster-Autoscalings.
3. Wenn keine N2- und T2D-Instanzen verfügbar sind, versucht GKE, N1-Instanzen zu erstellen.
4. Wenn N1-Instanzen nicht verfügbar sind, greift GKE auf die Standard-Maschinenserie für den Cluster zurück.

Knotenattribute der obersten Ebene für Prioritätsregeln

Wenn Sie Prioritätsregeln angeben, die Knoteneigenschaften definieren, müssen Sie einen Hardwaretyp auf oberster Ebene für die Knoten auswählen. Die anderen Attribute, die Sie für eine Regel angeben können, hängen vom Attribut der obersten Ebene dieser Regel ab.

Sie können für eine Regel eine der folgenden Top-Level-Properties verwenden:

• machineFamily: Eine Compute Engine-Maschinenreihe, z. B. n4.
• machineType: ein bestimmter Compute Engine-Maschinentyp, z. B. n4-standard-32.
• gpu: Eine GPU-Konfiguration, die einen GPU-Typ, eine bestimmte Anzahl von GPUs und eine Treiberkonfiguration enthalten kann.
• tpu: Eine Cloud TPU-Konfiguration, die eine TPU-Version, eine Topologie und eine Anzahl von Chips enthalten kann.

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

Jede Generation von Compute Engine-Maschinenserien unterstützt bestimmte Laufwerkstypen. Die N4-Maschinenserie unterstützt beispielsweise Hyperdisk ML-Laufwerkstypen, die N2-Maschinenserie jedoch nicht. In ComputeClasses, die sich über mehrere Generationen erstrecken, können zustandsorientierte Arbeitslasten, die einen bestimmten Laufwerkstyp anfordern, möglicherweise nicht auf nichtflüchtige Daten zugreifen, wenn der Maschinentyp diesen Laufwerkstyp nicht unterstützt. Je nachdem, wie Sie Laufwerke in Ihren Arbeitslasten erstellen und verwenden, können Sie eine der folgenden Methoden verwenden, um das Risiko unzugänglicher persistenter Daten zu verringern:

• Dynamische Volume-Bereitstellung: Verwenden Sie in GKE-Version 1.35.3-gke.1290000 und höher eine StorageClass, die die automatische Auswahl des Laufwerkstyps konfiguriert. Die GKE erstellt einen Laufwerkstyp, der mit dem Maschinentyp des Knotens kompatibel ist, auf dem Ihre Arbeitslast ausgeführt wird. Prüfen Sie in früheren GKE-Versionen, ob alle Maschinenserien in Ihrer ComputeClass den Laufwerkstyp unterstützen, den Ihre StorageClasses bereitstellen.

• Bereits vorhandene nichtflüchtige Speicher: Prüfen Sie, ob alle Maschinenserien in Ihrer ComputeClass die Laufwerkstypen Ihrer bereits vorhandenen nichtflüchtigen Speicher unterstützen.

Weitere Informationen zu den unterstützten Laufwerkstypen für die einzelnen Maschinenserien finden Sie in der Vergleichstabelle für Maschinenserien.

machineFamily-Konfigurationen

Das Feld machineFamily akzeptiert jede Compute Engine-Maschinenserie, die von GKE unterstützt wird, z. B. n2 oder c3. Wenn nicht angegeben, ist der Standardwert e2. Wenn Sie das Feld machineFamily verwenden, stellt GKE Knoten aus dieser Serie mit einem Maschinentyp bereit, der groß genug ist, um Ihre Pods auszuführen. Der Autoscaling-Algorithmus bestimmt die am besten geeignete Größe anhand der aggregierten Ressourcenanfragen aller ausstehenden Pods. Wenn Sie die genaue Maschinengröße genauer steuern möchten, verwenden Sie stattdessen das Feld machineType.

Wenn Sie eine breitere Maschinenfamilie anfordern, werden keine Bare-Metal-Maschinentypen bereitgestellt. Wenn Sie beispielsweise c3 oder c4a anfordern, werden keine Maschinentypen wie c3-standard-192-metal oder c4a-standard-72-metal bereitgestellt. Da für Bare-Metal-Knotentypen ein genauer Maschinentyp angefordert werden muss, können Sie auch die vordefinierte Autopilot-ComputeClass Performance nicht verwenden. Stattdessen müssen Sie eine benutzerdefinierte ComputeClass erstellen und den genauen Maschinentyp im Feld machineType angeben. Für die Verwendung von Bare-Metal-Maschinentypen vom Typ c3 oder c4a mit ComputeClasses, der automatischen Erstellung von Knotenpools oder dem Autopilot-Modus ist die GKE-Version 1.35.3-gke.1389000 oder höher erforderlich.

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

• spot: Spot-VMs Der Standardwert ist false.
• minCores: Mindestanzahl der vCPUs pro Knoten. Der Standardwert ist 0. Dieses Feld ist nützlich, um zu verhindern, dass Knoten erstellt werden, die für Ihre Anforderungen zu klein sind.
• minMemoryGb: Mindestspeicherplatz pro Knoten. Der Standardwert ist 0.
• storage.bootDiskType: Bootlaufwerktyp In Autopilot-Clustern wird nur der bootDiskType-Typ pd-balanced unterstützt. Erfordert GKE-Version 1.34.1-gke.1431000 oder höher.
• storage.bootDiskSize: Größe in GB für das Bootlaufwerk des Knotens. Erfordert GKE-Version 1.34.1-gke.1431000 oder höher.
• 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 wie einem Machine Learning-Modell oder einem Container-Image verwendet werden. 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 Speicherabbilds.
  • storage.secondaryBootDisks.project: der Name des Projekts, zu dem das Speicherabbild 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 gesetzt 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 Maschinenplatzierung:
  • policyName: der Name einer Richtlinie für kompakte Platzierung oder einer Arbeitslastrichtlinie von GKE Autopilot.
• enableNestedVirtualization: Gibt an, ob die verschachtelte Virtualisierung auf den Knoten aktiviert werden soll. Der Standardwert ist false.

Das folgende Beispiel zeigt eine Prioritätsregel, die machineFamily verwendet:

priorities:
- machineFamily: n4
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskType: hyperdisk-balanced
    bootDiskSize: 100
    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 benutzerdefinierten Maschinentyp-String 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 Maschinentypen aus jeder von GKE unterstützten Maschinenserie angeben.

Sie können neben dem Feld machineType weitere 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 bootDiskType-Typ pd-balanced 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.
• enableNestedVirtualization: Gibt an, ob die verschachtelte Virtualisierung auf den Knoten aktiviert werden soll. Der Standardwert ist false.

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

priorities:
- machineType: n4-standard-32
  spot: true
  storage:
    bootDiskType: hyperdisk-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.
• acceleratorNetworkProfile: Das Netzwerkprofil für Beschleuniger für die GPU, z. B. auto. Erfordert GKE-Version 1.35.2-gke.1842000 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:

• tpu.type: der TPU-Typ, z. B. tpu-v5p-slice. Weitere Informationen finden Sie unter TPU-Verfügbarkeit in GKE Autopilot.
• tpu.count: die Anzahl der anzuhängenden TPUs.
• tpu.topology: die zu verwendende TPU-Topologie, z. B. "2x2x1". Weitere Informationen finden Sie unter Topologie für Autopilot auswählen.

Sie können neben dem Feld tpu auch andere spec.priorities-Felder in Ihrer Prioritätsregel 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.
• location:
  • zones: Eine Liste von Google Cloud Zonen, in denen GKE Knoten bereitstellen kann. Wenn keine Angabe erfolgt, stellt GKE Knoten in den Zonen bereit, die in den Einstellungen für die automatische Knotenbereitstellung des Clusters konfiguriert sind. Wenn keine Zonen für die automatische Knotenbereitstellung konfiguriert sind, stellt GKE Knoten in einer der Standardzonen bereit, die von der Steuerungsebene verwendet werden.

    Optional: Verwenden Sie eine KI-Zone wie us-central1-ai1a. KI-Zonen sind spezielle Standorte, die für KI-/ML-Arbeitslasten in Google Cloud -Regionen optimiert sind.

  • zoneTypes: Eine Liste von Zonentyps, die eine Reihe von Google Cloud-Zonen angibt, in denen GKE Knoten bereitstellen kann. Die unterstützten Werte sind CLUSTER_DEFAULT (Standard), STANDARD und AI. Weitere Informationen finden Sie unter Priorität für „location zoneTypes“ verwenden.

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 in der 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:

• Autopilot-Arbeitslasten: Weitere Informationen finden Sie im Abschnitt „TPUs mit benutzerdefinierten ComputeClasses bereitstellen“ unter TPU-Arbeitslasten in GKE Autopilot bereitstellen.
• Standardarbeitslasten: Weitere Informationen finden Sie im Abschnitt „TPUs mit benutzerdefinierten ComputeClasses bereitstellen“ unter TPU-Arbeitslasten in GKE Standard bereitstellen.

Außerdem können Sie für TPU-Arbeitslasten Folgendes tun:

• Arbeitslasttyp definieren
• SLO definieren
• In Sammlungen in TPU Trillium (v6e) gruppieren
• KI-Zonen als Ziel

KI-Zonen für die Zielauswahl

Sie können auch eine Compute-Klasse verwenden, um KI-Zonen für Ihre Pods anzugeben. KI-Zonen sind spezialisierte Standorte innerhalb von Google Cloud -Regionen, die für KI-/ML-Arbeitslasten optimiert sind. Die folgende Compute-Klasse legt eine priorisierte Liste von Zonen fest, die KI-Zonen enthält:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: accelerator-ai-preferred
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
    # --- Priority 1: TPU in a specific AI zone (On-Demand) ---
    - tpu:
        type: tpu-v5p-slice
        count: 4
        topology: 4x4x4
      location:
        zones:
          - "us-central1-ai1a" # Specify your target AI zone
      # machineFamily: a3 # Optional

    # --- Priority 2: TPU in any AI zone (On-Demand)  ---
    - tpu:
        type: tpu-v5p-slice
        count: 4
        topology: 4x4x4
      location:
        zoneTypes:
          - "AI" # All AI zones in the cluster's region

    # --- Priority 3: GPU in a specific Standard zone (On-Demand) ---
    - gpu:
        type: nvidia-tesla-a100
        count: 1
      location:
        zones:
          - "us-central1-a" # Fallback to a standard zone
          - "us-central1-b"
  whenUnsatisfiable: DoNotScaleUp

Diese ComputeClass konfiguriert GKE so, dass Knoten mit v5p-TPUs oder A100-GPUs für die Arbeitslast bereitgestellt werden. Die Knoten haben die folgenden Einstellungen:

• Priorität 1: Versuchen Sie, die TPU in der KI-Zone us-central1-ai1a bereitzustellen.
• Priorität 2: Wenn die TPU in der spezifischen KI-Zone nicht verfügbar ist, versuchen Sie, sie in einer beliebigen KI-Zone der Region des Clusters bereitzustellen.
• Priorität 3: Wenn die TPU in KI-Zonen nicht verfügbar ist, versuchen Sie, die GPU in den Standardzonen us-central1-a oder us-central1-b bereitzustellen.
• Wenn in keiner der angegebenen Zonen A100-GPUs verfügbar sind, skaliert GKE den Knotenpool nicht hoch.

DRANET-Netzwerkkonfiguration

Erfordert GKE-Version 1.35.2-gke.1842000 oder höher

Wenn Sie von GKE verwaltetes DRANET verwenden möchten, um Netzwerkschnittstellen für Pods anzufordern und zuzuweisen, müssen Sie das Feature in Ihrer ComputeClass aktivieren. Sie müssen:

• Aktivieren Sie den DRANET-Netzwerktreiber, indem Sie nodePoolConfig.dra.networking.enabled auf true setzen.
• Legen Sie in der Liste priorities für acceleratorNetworkProfile den Wert auto fest.

Weitere Informationen zur Verwendung von DRANET finden Sie unter Netzwerkressourcen mit von GKE verwaltetem DRANET zuweisen.

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 in der Reihenfolge ihres Auftretens oder, wenn das Feld priorityScore festgelegt ist, von der höchsten zur niedrigsten Punktzahl.

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 vCPUs 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 für einige Felder in den Prioritätsregeln Ihrer ComputeClass-Spezifikation Standardwerte festlegen. Diese Standardwerte gelten, wenn die entsprechenden Felder in einer bestimmten Regel weggelassen werden. 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 die GKE-Version 1.32.1-gke.1729000 oder höher.
• Ist nicht mit der Prioritätsregel nodepools kompatibel, die keine Felder enthält.

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

GKE Standard-Knotenpools und ComputeClasses

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.

• Automatisch erstellte Knotenpools: Keine manuelle Konfiguration erforderlich. Die GKE führt die Konfigurationsschritte für die ComputeClass automatisch für Sie aus. Weitere Informationen finden Sie unter Automatische Erstellung von Knotenpools und ComputeClasses.
• Manuell erstellte Knotenpools: Eine manuelle Konfiguration ist erforderlich. Sie müssen Ihren manuell erstellten Knotenpools Knotenlabels und Knotenmarkierungen hinzufügen, um die Knoten einer bestimmten ComputeClass zuzuordnen. Weitere Informationen finden Sie unter Manuell erstellte Knotenpools für die Verwendung von ComputeClass konfigurieren.

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.

Der 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 ComputeClass 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 ComputeClass zuweisen. Pods, die GKE auf diesen manuell erstellten Knotenpools plant, lösen nur während Autoscaling-Ereignissen die Knotenerstellung in diesen Knotenpools aus.

Automatische Erstellung von Knotenpools und ComputeClasses

Sie können die automatische Erstellung von Knotenpools mit einer benutzerdefinierten ComputeClass verwenden, damit GKE Knotenpools automatisch basierend auf Ihren Prioritätsregeln erstellen und löschen kann.

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

1. Fügen Sie der Spezifikation ComputeClass das Feld nodePoolAutoCreation mit dem Wert enabled: true hinzu.
2. Wenn auf Ihrem Cluster eine Version vor GKE-Version 1.33.3-gke.1136000 ausgeführt wird, müssen Sie auch die automatische Knotenbereitstellung auf Clusterebene aktivieren.

Die 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 ComputeClasses, für die die automatische Erstellung von Knotenpools nicht konfiguriert ist, werden weiterhin nur vorhandene Knotenpools skaliert.

Sie können ComputeClasses, die die automatische Erstellung von Knotenpools ermöglichen, zusammen mit ComputeClasses 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 ComputeClass in Konflikt stehen. GKE lehnt alle Pods ab, die eine ComputeClass und auch Spot-VMs oder bestimmte Maschinenreihen anfordern.

• Wenn Sie eine Standard-ComputeClass für Ihren Cluster festlegen, lösen Pods, die einen Knotenselektor für Maschinenfamilien verwenden, nur in einer der folgenden Situationen die Knotenerstellung für diese Standardklasse aus:

  • Die Pods wählen eine Maschinenfamilie aus, die einer der Prioritätsregeln in der Standardklasse auf Clusterebene entspricht. Beispiel: Ein Pod, der N4-Instanzen auswählt, löst die Knotenerstellung aus, 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 die GKE neue Knoten mit dieser Maschinenfamilie.

  Pods, die eine Maschinenfamilie auswählen, 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 ComputeClasses konfigurieren, die das Feld nodepools verwenden, um auf vorhandene Knotenpools zu verweisen. Die 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 hochzuskalieren 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 priorities.nodepools-Feld angegeben haben, müssen dieser ComputeClass mithilfe von Knotenlabels und Knotenmarkierungen zugeordnet werden, wie im Abschnitt Manuell erstellte Knotenpools für ComputeClasses konfigurieren angegeben.

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:

Best Practice: Wenn Sie dieses Feld weglassen, hängt das Standardverhalten von der GKE-Version Ihres Clusters ab. Um unerwartetes Skalierungsverhalten nach einem Versionsupgrade zu vermeiden, geben Sie dieses Feld explizit in Ihrem ComputeClass-Manifest an.

• 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.

  Die 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-Maschinenserie platziert wird.

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

Platzierungsrichtlinie anfordern

Ab 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 der Richtlinie für kompakte Platzierung und der Arbeitslastrichtlinie.

Sowohl die Platzierungsrichtlinie als auch die Arbeitslastrichtlinie platzieren Knoten physisch nahe beieinander, um die Netzwerklatenz zu reduzieren. Wenn Sie eine bestimmte Richtlinie verwenden möchten, geben Sie ihren Namen in einem policyName-Feld 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 kompakte Platzierung auf alle Arbeitslasten an, die diese ComputeClass verwenden, und stellt ihre 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 ComputeClasses das Standardverhalten, da alle Cluster, die ComputeClasses 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 ComputeClasses, die vorhandene Knoten automatisch durch neue Knoten ersetzt. Die folgenden Arten der aktiven Migration werden unterstützt:

• optimizeRulePriority: GKE ersetzt Knoten, die eine Konfiguration mit niedrigerer Priorität verwenden, durch Knoten, die eine Konfiguration mit höherer Priorität verwenden. Diese Option ermöglicht eine automatische Wiederherstellung nach einem vorübergehenden zonalen Kapazitätsmangel (ZONE_RESOURCE_POOL_EXHAUSTED). Sie sorgt dafür, dass Ihre zustandslosen oder störungstoleranten Pods schließlich zu Ihrer bevorzugten Knotenkonfiguration zurückkehren, auch wenn GKE ursprünglich Fallback-Hardware aus einer Regel mit niedrigerer Priorität bereitstellen musste.
• ensureAllDaemonSetPodsRunning: GKE ersetzt Knoten mit nicht planbaren DaemonSet-Pods durch größere Knoten, auf denen alle erforderlichen DaemonSet-Pods ausgeführt werden können. Mit dieser Option können Sie dafür sorgen, dass alle DaemonSets letztendlich auf Ihren Knoten ausgeführt werden.

Während einer aktiven Migration führt GKE Folgendes aus:

1. GKE erstellt einen neuen Knoten mit einer Konfiguration, die die Anforderungen des aktiven Migrationstyps erfüllt.
2. GKE sperrt den vorhandenen Knoten, sodass keine neuen Pods auf diesem Knoten ausgeführt werden.

3. GKE leert den vorhandenen Knoten, wodurch Pods aus dem Knoten entfernt werden. Die folgenden Faktoren beeinflussen, wie schnell der Knoten geleert wird:

   • PodDisruptionBudgets
   • terminationGracePeriodSeconds

   Kubernetes-Controller wie Deployments oder Jobs erstellen Pods, um entfernte Pods zu ersetzen. GKE plant diese neuen Pods auf dem neuen Knoten.

4. Nachdem der vorhandene Knoten per Drain beendet wurde, löscht GKE den Knoten.

Die aktive Migration wirkt sich in den folgenden Szenarien nicht auf Pods und Knoten aus:

• Bei der aktiven Migration werden Pods mit der Annotation cluster-autoscaler.kubernetes.io/safe-to-evict: "false" nicht entfernt.
• Bei der aktiven Migration werden Pods nicht entfernt, wenn die Entfernung gegen ein PodDisruptionBudget verstoßen würde.
• Bei der aktiven Migration werden keine Knoten ersetzt, die nicht entfernt werden können. Beispielsweise wird bei der aktiven Migration ein Knoten nicht ersetzt, wenn dies gegen die Knotenpool-Einstellung --min-nodes verstößt.

Bevor Sie die aktive Migration für eine ComputeClass aktivieren, sollten Sie die folgenden potenziellen Auswirkungen berücksichtigen:

• Bei der aktiven Migration werden keine Daten migriert, die in nichtflüchtigem Speicher wie Compute Engine Persistent Disks gespeichert sind. Um das Risiko von Datenverlusten zu minimieren, sollten Sie die aktive Migration nicht in ComputeClasses aktivieren, die von zustandsorientierten Arbeitslasten verwendet werden.
• Wenn Sie in Standardclustern die automatische Erstellung von Knotenpools verwenden, kann eine aktive Migration das Erstellen neuer Knotenpools auslösen, wenn vorhandene Knotenpools die in Ihrer ComputeClass definierten Kriterien nicht erfüllen.
• Arbeitslasten, die nichtflüchtige Volumes mit zonalen Ressourcen wie Hyperdisk verwenden, funktionieren möglicherweise nicht gut mit der aktiven Migration. Zonale Einschränkungen und die Einschränkungen des Maschinentyps 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 auf neue Knoten, wenn Rechenressourcen verfügbar werden.

Aktive Migration zu Knoten mit höherer Priorität

Mit dem aktiven Migrationstyp optimizeRulePriority kann GKE vorhandene Knoten, die eine Konfiguration mit niedrigerer Priorität verwenden, durch Knoten ersetzen, die eine Konfiguration mit höherer Priorität verwenden.

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, z. B. aufgrund eines vorübergehenden Mangels an zonalen Ressourcen (ZONE_RESOURCE_POOL_EXHAUSTED), hätte GKE C4-Knoten als Fallback-Option verwendet. Wenn die N4-Kapazität an Ihrem Standort wiederhergestellt wird oder Ihr Kontingent erhöht wird, migriert GKE Ihre Arbeitslasten automatisch zurück auf N4-Knoten:

1. GKE erstellt einen neuen N4-Knoten.
2. GKE sperrt den vorhandenen C4-Knoten und leert ihn. Ihre Pods werden unter Berücksichtigung aller PodDisruptionBudgets und Konfigurationen für die ordnungsgemäße Beendigung entfernt.
3. Kubernetes-Controller erstellen Pods, um die entfernten Pods zu ersetzen. Diese neuen Pods werden auf dem N4-Knoten ausgeführt.
4. Nachdem der C4-Knoten geleert wurde, löscht GKE den Knoten.

Wenn Sie das Feld priorityScore verwenden, um explizite Punktzahlen für Ihre Prioritätsregeln festzulegen, ersetzt GKE Knoten mit einer niedrigeren Punktzahl durch Knoten mit einer höheren Punktzahl.

Aktive Migration zum Ausführen nicht planbarer DaemonSet-Pods

Mit dem aktiven Migrationstyp ensureAllDaemonSetPodsRunning kann GKE vorhandene Knoten mit nicht planbaren DaemonSet-Pods automatisch durch größere Knoten ersetzen, auf denen diese DaemonSet-Pods ausgeführt werden können.

In der folgenden ComputeClass-Spezifikation wird beispielsweise die N4-Maschinenfamilie konfiguriert:

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

Stellen Sie sich ein Szenario vor, in dem Sie ein Deployment mit einem einzelnen Pod erstellt haben, das diese ComputeClass verwendet und zwei vCPUs angefordert hat. Zum Ausführen dieses Pods hat GKE einen n4-standard-2-Knoten erstellt. Später erstellen Sie ein DaemonSet, das ebenfalls zwei vCPUs anfordert. Der DaemonSet-Pod kann nicht auf dem Knoten n4-standard-2 ausgeführt werden. In diesem Szenario führt GKE Folgendes aus:

1. GKE erstellt einen Knoten, der einen größeren N4-Maschinentyp wie n4-standard-4 verwendet, auf dem Ihr Pod und der DaemonSet-Pod ausgeführt werden können. Der ausstehende DaemonSet-Pod wird auf diesem neuen Knoten geplant.
2. GKE sperrt den Knoten n4-standard-2 und beendet ihn per Drain.
3. Wenn Ihr Pod entfernt wird, erstellt das Deployment einen Ersatz-Pod. Die GKE plant diesen Pod auf dem n4-standard-4-Knoten zusammen mit dem DaemonSet-Pod.
4. Nachdem der Knoten n4-standard-2 geleert wurde, löscht GKE den Knoten.

Compute Engine-Reservierungen nutzen

Verfügbar ab GKE-Version 1.31.1-gke.2105000

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

Wenn Sie Compute Engine-Reservierungen mit einer benutzerdefinierten ComputeClass nutzen möchten, können Sie die folgenden Methoden verwenden:

• Automatisches Erstellen von Knotenpools: GKE erstellt automatisch neue Knotenpools, um die von Ihnen angegebenen Reservierungen zu nutzen. Weitere Informationen finden Sie unter Automatische Erstellung von Knotenpools und ComputeClasses.
• Manuell erstellte Knotenpools: In Clustern im Standardmodus können Sie Arbeitslasten an manuell erstellte Knotenpools weiterleiten, indem Sie das Feld spec.priorities.nodepools in Ihrer ComputeClass angeben.

Ab GKE-Version 1.36.0-gke.3204000 können Sie Ihre Arbeitslasten so konfigurieren, dass sie jede übereinstimmende Reservierung nutzen, ohne auf On-Demand-Kapazität zurückzugreifen. Verwenden Sie dazu die Affinitätseinstellung AnyThenFail.

Reservierungen in manuell erstellten Knotenpools nutzen

So verwenden Sie Reservierungen in manuell erstellten Knotenpools in Standard-Clustern mithilfe von ComputeClasses:

1. Binden Sie die Reservierungen an die Knotenpools. Folgen Sie dazu der Anleitung unter Reservierte Instanzen in GKE Standard nutzen.

2. Erstellen Sie eine ComputeClass, die die Prioritätsregel nodepools verwendet, um Ihre manuell erstellten Knotenpools auszuwählen.

Stellen Sie sich beispielsweise ein Szenario vor, in dem Sie zwei Knotenpools haben, die Sie jeweils mit einer separaten Kapazitätsreservierung verknüpft haben. Sie möchten, dass Pods die reservierte Kapazität im Knotenpool reservation-pool-1 anstelle des Knotenpools reservation-pool-2 verwenden. Die ComputeClass, die diese Einstellungen implementiert, sieht in etwa so aus:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: manual-pool-reservations
spec:
  priorities:
  - nodepools: ['reservation-pool-1']
  - nodepools: ['reservation-pool-2']

In diesem Beispiel versucht GKE zuerst, Pods in reservation-pool-1 zu platzieren, da diese Prioritätsregel zuerst im Feld priorities angezeigt wird.

Knotenpools automatisch erstellen, um Reservierungen zu nutzen

Wenn Sie die automatische Erstellung von Knotenpools verwenden, können Sie anfordern, dass GKE Kapazitätsreservierungen verwendet, um Knotenpools für bestimmte Prioritätsregeln zu erstellen. Wenn Sie Reservierungen in automatisch erstellten Knotenpools nutzen möchten, müssen die folgenden Anforderungen erfüllt sein:

• Die ComputeClass muss die automatische Erstellung von Knotenpools aktivieren.
• Nicht-TPU-Reservierungen können nur verwendet werden, wenn entweder machineType oder machineFamily definiert ist.
• ComputeClasses, 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 ComputeClass 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 ComputeClass 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 diese spezifische Reservierung keine verfügbare Kapazität hat, versucht GKE, a3-highgpu-1g-Instanzen mithilfe einer beliebigen ü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 erfordern beide Prioritätsregeln mit Reservierungsverweisen explizit das Feld localSSDCount:, da die Maschinenform a3-highgpu-1g lokale SSDs enthält.

Im folgenden Beispiel wird eine freigegebene spezifische Reservierung gezeigt, die auf Spot-VMs und schließlich 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:

  • Geben Sie den Namen der Reservierung im Feld reservations.specific.name an.
  • Der Wert des Felds reservations.affinity muss Specific sein.

• Spezifische freigegebene Reservierungen: Konfigurieren Sie die folgenden Felder:

  • Geben Sie den Namen der Reservierung im Feld reservations.specific.name an.
  • Geben Sie im Feld reservations.specific.project die Projekt-ID des Projekts an, zu dem die Reservierung gehört.
  • Der Wert des Felds reservations.affinity muss Specific sein.

• Alle übereinstimmenden Reservierungen mit Fallback: Konfigurieren Sie die folgenden Felder:

  • Der Wert des Felds reservations.affinity muss AnyBestEffort sein.
  • Legen Sie keinen Reservierungsnamen oder kein Projekt fest.

• Alle übereinstimmenden Reservierungen ohne Fallback: Konfigurieren Sie die folgenden Felder:

  • Der Wert des Felds reservations.affinity muss AnyThenFail sein.
  • Legen Sie keinen Reservierungsnamen oder kein Projekt fest.
  • Optional. Wenn Sie den Fehler strikt erzwingen möchten, falls alle übereinstimmenden Reservierungen aufgebraucht sind, konfigurieren Sie die Einstellung whenUnsatisfiable: DoNotScaleUp auf der Ebene spec der ComputeClass.

Für TPU-Reservierungen ist eine spezifische Affinität erforderlich. Die Einstellungen reservations.affinity: AnyBestEffort und reservations.affinity: AnyThenFail werden nicht unterstützt.

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

• Spezifische Reservierungen: GKE versucht die nächste Prioritätsregel in der ComputeClass.
• Alle übereinstimmenden Reservierungen mit Fallback (AnyBestEffort): GKE versucht, einen On-Demand-Knoten bereitzustellen, der die Anforderungen dieser Prioritätsregel erfüllt. Wenn GKE keinen On-Demand-Knoten bereitstellen kann, versucht GKE die nächste Prioritätsregel in der ComputeClass.
• Alle übereinstimmenden Reservierungen ohne Fallback (AnyThenFail): GKE überspringt die Bereitstellung eines On-Demand-Knotens und versucht die nächste Prioritätsregel in der ComputeClass. Wenn keine anderen Regeln gelten, schlägt der Skalierungsvorgang je nach Wert der Einstellung whenUnsatisfiable fehl.

Wenn GKE die Anforderungen einer der Prioritätsregeln für die ComputeClass nicht erfüllen kann, tritt das Verhalten auf, wenn keine Regeln gelten.

Bestimmte Reservierungsblöcke nutzen

Ab GKE-Version 1.31.4-gke.1072000 können Sie einen bestimmten Reservierungsblock innerhalb einer hardwaregestützten Reservierung als Ziel festlegen. Dieses Feature 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 gezeigt:

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 GKE-Version 1.33.1-gke.1788000 können Sie einen bestimmten Reservierungsunterblock innerhalb eines Reservierungsblocks als Ziel festlegen. Dieses Feature 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 Folgendes:

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

Minimale Knotenanzahl

Verfügbar in GKE-Version 1.36.3-gke.1253000 und höher.

Sie können mit dem Feld minimumCapacity.targetNodeCount eine Mindestanzahl von Knoten angeben, die GKE entweder für eine gesamte ComputeClass oder für bestimmte Prioritätsregeln beibehalten soll. Die GKE behält mindestens die angegebene Anzahl von Knoten bei, auch wenn diese Kapazität inaktiv ist. Die Angabe einer Mindestkapazität eignet sich gut für Arbeitslasten, die eine grundlegende Rechenkapazität erfordern, z. B. große KI/ML-Trainings- oder Bereitstellungsarbeitslasten mit niedriger Latenz. GKE skaliert Knoten weiterhin automatisch über den Mindestwert hinaus, wenn Ihre Arbeitslasten mehr Kapazität benötigen.

Wenn Sie eine Mindestkapazität für eine ComputeClass oder Prioritätsregel angeben, beachten Sie Folgendes:

• Wenn die Kapazität für die gesamte ComputeClass gilt, behält GKE mindestens diese Anzahl von Knoten für alle Prioritätsregeln in der ComputeClass bei. Wenn die Kapazität für eine bestimmte Prioritätsregel gilt, behält GKE mindestens diese Anzahl von Knoten für diese Prioritätsregel bei.
• Wenn die Anzahl der Knoten kleiner als die angegebene Mindestanzahl ist, erstellt GKE automatisch neue Knoten, um die Mindestkapazität aufrechtzuerhalten, auch wenn auf diesen zusätzlichen Knoten keine Pods ausgeführt werden.
• GKE skaliert die Knoten, die die Mindestkapazität ausmachen, nicht herunter, auch wenn diese Knoten leer sind.
• Die angegebene Kapazität ist ein Mindestwert. Bei Ereignissen mit Hochskalieren kann GKE die Mindestanzahl von Knoten überschreiten, um ausstehende Pods auszuführen.
• Wenn Sie die aktive Migration zu Knoten mit höherer Priorität aktivieren, kann GKE die Knoten für die Mindestkapazität durch Knoten aus einer Regel mit höherer Priorität ersetzen. GKE ersetzt jedoch keinen Knoten, wenn durch den Ersatz eine Prioritätsregel unter ihre Mindestkapazität fällt.
• Ressourcenverfügbarkeit oder Kontingente können GKE daran hindern, Knoten für die Mindestkapazitätsanforderung zu erstellen.
• Wenn die GKE nicht genügend Knoten für die Mindestkapazität einer Prioritätsregel erstellen kann, greift sie nicht auf andere Prioritätsregeln zurück. Stattdessen erstellt GKE die fehlenden Knoten für diese Prioritätsregel, sobald Kapazität verfügbar ist.
• Knoten können weiterhin gelöscht und ersetzt werden, um den Zustand des Clusters aufrechtzuerhalten (z. B. um einen fehlerhaften Knoten zu reparieren oder eine Spot-VM vorzeitig zu beenden). Die GKE erstellt automatisch neue Knoten, um die Mindestkapazität aufrechtzuerhalten.

Je nachdem, ob Sie eine Mindestkapazität für eine gesamte ComputeClass oder für bestimmte Prioritätsregeln konfigurieren, gelten die folgenden Anforderungen:

• Mindestkapazität für die ComputeClass: Wenn Sie das Feld minimumCapacity.targetNodeCount für die gesamte ComputeClass angeben, müssen alle Prioritätsregeln direkt oder indirekt einen bestimmten Maschinentyp anfordern. Für jede Prioritätsregel muss mindestens eine der folgenden Konfigurationen verwendet werden:

  • machineType
  • gpu
  • tpu
  • Eine bestimmte Kapazitätsreservierung

  GKE lehnt ComputeClasses ab, die flexible Konfigurationen in einer Prioritätsregel verwenden, z. B. das Feld machineFamily, und die auch eine Mindestkapazität für die gesamte ComputeClass angeben.

• Mindestkapazität für eine Prioritätsregel: Wenn Sie das Feld minimumCapacity.targetNodeCount für eine bestimmte Prioritätsregel angeben, muss diese Prioritätsregel direkt oder indirekt einen bestimmten Maschinentyp anfordern. Verwenden Sie dazu mindestens eine der folgenden Konfigurationen:

  • machineType
  • gpu
  • tpu
  • Eine bestimmte Kapazitätsreservierung

Die folgenden Beispiele zeigen die Konfiguration der Mindestkapazität für eine ComputeClass und für eine Prioritätsregel:

• ComputeClass:

  apiVersion: cloud.google.com/v1
  kind: ComputeClass
  metadata:
    name: gpu-class-min-nodes
  spec:
    nodePoolAutoCreation:
      enabled: true
    # Define a global minimum capacity of 5 nodes for this ComputeClass
    minimumCapacity:
      targetNodeCount: 5
    priorities:
    - gpu:
        type: "nvidia-tesla-a100"
        count: 1
      machineType: "a2-highgpu-1g"
    - gpu:
        type: "nvidia-l4"
        count: 1
      machineType: "g2-standard-8"
  

• Prioritätsregel:

  apiVersion: cloud.google.com/v1
  kind: ComputeClass
  metadata:
    name: tiered-compute-class
  spec:
    nodePoolAutoCreation:
      enabled: true
    priorities:
    - machineType: "n2-standard-16"
      # Maintain at least three nodes of this specific configuration
      minimumCapacity:
        targetNodeCount: 3
    - machineType: "e2-standard-4"
  

Mindestkapazität für eine ComputeClass und ihre Prioritätsregeln

Wenn Sie eine Mindestkapazität für eine ComputeClass und für einige ihrer Prioritätsregeln angeben, werden die Mindestwerte der Prioritätsregeln auf den Mindestwert der ComputeClass angerechnet. Das folgende Verhalten gilt:

• Wenn die Mindestwerte der Prioritätsregeln mindestens dem Mindestwert der ComputeClass entsprechen, erfüllen die Knoten für die Prioritätsregeln auch den Mindestwert der ComputeClass. Die GKE erstellt keine zusätzlichen Knoten für das ComputeClass-Minimum, auch nicht in Regeln mit höherer Priorität, die keine Mindestkapazität angeben.
• Der Mindestwert für die ComputeClass schränkt die Mindestwerte für die Prioritätsregeln nicht ein. GKE erstellt alle Knoten für jeden Mindestwert der Prioritätsregel, auch wenn die Gesamtzahl den Mindestwert der ComputeClass überschreitet.
• Wenn die Mindestwerte der Prioritätsregeln zusammen weniger als der Mindestwert der ComputeClass ergeben, erstellt GKE die verbleibenden Knoten anhand der Prioritätsregeln in der entsprechenden Reihenfolge. Bei Bedarf greift die GKE für diese verbleibenden Knoten auf Regeln mit niedrigerer Priorität zurück.

Betrachten Sie beispielsweise die folgende ComputeClass, die eine Mindestkapazität für die ComputeClass und für die zweite Prioritätsregel angibt:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: combined-min-nodes
spec:
  nodePoolAutoCreation:
    enabled: true
  minimumCapacity:
    targetNodeCount: 5
  priorities:
  - machineType: "n2-standard-16"
  - machineType: "e2-standard-16"
    minimumCapacity:
      targetNodeCount: 3

Für diese ComputeClass erstellt GKE drei e2-standard-16-Knoten für die zweite Prioritätsregel. Diese Knoten werden auf die Mindestanzahl von fünf Knoten für die ComputeClass angerechnet. Für die beiden verbleibenden Knoten versucht GKE zuerst, n2-standard-16-Knoten zu erstellen. Wenn keine n2-standard-16-Knoten verfügbar sind, greift GKE auf e2-standard-16-Knoten zurück.

Wenn Sie die aktive Migration zu Knoten mit höherer Priorität aktivieren, kann GKE später bis zu zwei e2-standard-16-Knoten durch n2-standard-16-Knoten ersetzen. GKE behält jedoch mindestens drei e2-standard-16-Knoten für die Mindestkapazität der Regel mit der zweiten Priorität bei.

Wenn Sie das Feld targetNodeCount in der zweiten Prioritätsregel stattdessen auf 6 setzen, erstellt GKE sechs e2-standard-16-Knoten. Diese sechs Knoten erfüllen die Mindestanforderung der ComputeClass von fünf Knoten. Daher erstellt die GKE keine n2-standard-16-Knoten für die Mindestkapazität.

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, die eine Compute Engine-Maschinenreihe oder einen Compute Engine-Maschinentyp definiert. Sie können auch globale Standardwerte für alle Konfigurationsfelder des Knotensystems festlegen, die in Prioritätsregeln weggelassen werden. Fügen Sie dazu das Feld nodeSystemConfig zum Feld priorityDefaults in Ihrer ComputeClass hinzu.

Dieses Feature ist in der GKE-Version 1.32.1-gke.1729000 und höher verfügbar.

Hier finden Sie weitere Informationen:

• ComputeClass CustomResourceDefinition
• Knotensystemkonfiguration anpassen

Knotenlabels und ‑markierungen angeben

In Ihrer ComputeClass-Spezifikation können Sie mit den Feldern nodeLabels und taints Konfigurationen definieren, die sowohl mit vorhandenen Knotenpools übereinstimmen als auch die Erstellung neuer Knotenpools steuern. Diese Konfigurationen können global im Feld nodePoolConfig für die gesamte ComputeClass angewendet oder mit dem Feld priority auf eine bestimmte Priorität beschränkt werden. Sie müssen jedoch darauf achten, dass sich die auf Prioritätsebene definierten Labels und Markierungen nicht mit den global festgelegten überschneiden.

Diese Funktionen sind in den folgenden Ländern verfügbar:

• Prioritätsknotenlabels in GKE-Version 1.33.2-gke.1111000 und höher.
• Prioritätsmarkierungen in GKE-Version 1.33.4-gke.1350000 und höher.
• Globale Knotenlabels und Markierungen in GKE-Version 1.34.1-gke.3084002 und höher.

Zusätzlich zu benutzerdefinierten Labels weist GKE allen Knoten, die für eine ComputeClass bereitgestellt oder mit ihr verknüpft sind, automatisch das Systemlabel cloud.google.com/compute-class zu. Sie können Knoten nach ComputeClass filtern und auflisten:

kubectl get nodes -l cloud.google.com/compute-class=COMPUTECLASS_NAME

Weitere Informationen finden Sie unter ComputeClass CustomResourceDefinition.

Standard-Arm-Architektur-Taint konfigurieren

Standardmäßig fügt GKE allen Arm-Knoten die Markierung kubernetes.io/arch=arm64:NoSchedule hinzu, einschließlich Knoten, die für benutzerdefinierte ComputeClasses erstellt wurden. GKE plant nur Arbeitslasten, die eine Toleranz für diese Markierung auf den Arm-Knoten haben. Dadurch wird verhindert, dass x86-Arbeitslasten auf inkompatibler Architektur ausgeführt werden. Wenn Ihre Arbeitslasten sowohl mit x86 als auch mit Arm kompatibel sind, können Sie diese Standardmarkierung deaktivieren. Jede Arbeitslast, die die ComputeClass auswählt, kann auf den Arm-Knoten ausgeführt werden, auch wenn diese Arbeitslasten keine Toleranz für die Arm-Architektur haben.

Sie können das Standardverhalten für Markierungen in Standardknotenpools und mit Knoten, die für benutzerdefinierte ComputeClasses erstellt wurden, aktualisieren. Weitere Informationen zum Konfigurieren des Verhaltens für Standardknotenpools finden Sie unter Standard-Arm-Architektur-Taint konfigurieren.

Wenn Sie das Standardverhalten ändern und GKE Arbeitslasten ohne entsprechende Toleranz auf Arm-Knoten planen lassen möchten, die für eine benutzerdefinierte ComputeClass erstellt wurden, konfigurieren Sie Ihre ComputeClass wie in diesem Beispiel gezeigt:

taintConfig:
  architectureTaintBehavior: NONE

Für dieses Feld ist ein Cluster mit der GKE-Version 1.36.2-gke.1498000 oder höher erforderlich.

Standard-ComputeClasses für Cluster und Namespaces

Sie können GKE so konfigurieren, dass standardmäßig eine ComputeClass auf Pods angewendet wird, die keine bestimmte ComputeClass auswählen. 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 einzigen logischen Einheit, einer sogenannten Sammlung, gruppieren. Verwenden Sie dazu das Feld nodePoolGroup in Ihrer ComputeClass-Spezifikation. Mit dieser Gruppierung können Sie freigegebene Konfigurationen auf viele Knotenpools anwenden.

TPU-Sammlung mit mehreren Hosts

Erfordert GKE-Version 1.31.2-gke.1518000 oder höher. Nur in TPU Trillium (v6e) verfügbar

Sie können Ihre TPU-Bereitstellung 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 zur selben Gruppe.

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

Hier finden Sie weitere Informationen:

• TPUs in GKE planen
• TPU-Slice-Knotenpools mit mehreren Hosts
• TPU-Sammlungen für Inferenz-Arbeitslasten planen

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. Im folgenden Beispiel wird gezeigt, wie Sie die 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

Das Feld serviceAccount gibt das Dienstkonto von Google Cloud an, das von den Knoten in Knotenpools verwendet wird, die von der ComputeClass verwaltet werden. Das folgende Beispiel zeigt, wie Sie die serviceAccount in Ihrer ComputeClass angeben:

spec:
  nodePoolConfig:
    serviceAccount: [e-mail]

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 die beabsichtigte Verwendung für die TPU-Ressourcen an. Das Feld workloadType unterstützt die folgenden Werte:

• HIGH_AVAILABILITY: Verwenden Sie diesen Wert für Arbeitslasten, bei denen die Verfügbarkeit im Vordergrund steht, z. B. für die Bereitstellung von Inferenzen, 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 Hochverfügbarkeits-Inferenzarbeitslasten 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

Hier finden Sie weitere Informationen:

• TPUs in GKE
• TPUs in GKE planen

Sandbox-Konfiguration

Erfordert GKE-Version 1.36.2-gke.1368000 oder höher

Sie können Arbeitslasten vom Host-Kernel von Knoten isolieren, indem Sie die Pods in Sandboxes mit GKE Sandbox ausführen. In ComputeClasses können Sie GKE Sandbox aktivieren und mit dem Feld nodePoolConfig.sandbox einen Sandbox-Typ für die Knoten auswählen. Die folgenden Sandbox-Typen werden unterstützt:

• gvisor: Erfordert GKE-Version 1.36.2-gke.1368000 oder höher.
• microvm: Erfordert GKE-Version 1.37.0-gke.4713000 oder höher und Knoten, die verschachtelte Virtualisierung verwenden.

Weitere Informationen zu den Funktionen, Einschränkungen und Anforderungen dieser Sandbox-Typen finden Sie unter Informationen zu GKE Sandbox.

Informationen zum Aktivieren und Anfordern von Sandboxes mit einer ComputeClass finden Sie unter Arbeitslasten mit GKE Sandbox isolieren.

Konfiguration von Instanzmetadaten

Erfordert GKE-Version 1.36.2-gke.1498000 oder höher.

Mit dem Feld instanceMetadata in einer ComputeClass-Spezifikation können Sie benutzerdefinierte Metadaten-Schlüssel/Wert-Paare direkt in die Compute Engine-VM-Instanzen einfügen, die von Cluster Autoscaler oder Node Auto-Provisioning für Ihre Knotenpools bereitgestellt werden. Dies entspricht der Angabe des Flags --metadata beim manuellen Erstellen von Knotenpools mit der Google Cloud CLI.

Die Konfiguration benutzerdefinierter Instanzmetadaten mit ComputeClasses wird nur in GKE Standard-Clustern im Standardmodus (spec.autopilot.enabled: false) unterstützt.

Sie können instanceMetadata an zwei Stellen in einer ComputeClass angeben:

• Globale Konfiguration (spec.nodePoolConfig.instanceMetadata): Wendet benutzerdefinierte Metadaten-Schlüssel/Wert-Paare global auf alle neuen Knotenpools und VMs an, die von der ComputeClass erstellt werden.
• Prioritätsspezifische Überschreibungen (spec.priorities[].instanceMetadata): Wendet benutzerdefinierte Metadaten-Schlüssel/Wert-Paare nur an, wenn GKE Knoten mit dieser spezifischen Priorität in der Hierarchie bereitstellt.

Wenn derselbe Metadatenschlüssel sowohl in nodePoolConfig.instanceMetadata als auch in priorities[].instanceMetadata definiert ist, überschreibt der in priorities[].instanceMetadata angegebene Wert den globalen Wert.

Schema- und Validierungsregeln

Beachten Sie beim Definieren von instanceMetadata die folgenden Validierungseinschränkungen:

• Typ: Schlüssel/Wert-Paare, die als map (map[string]string) strukturiert sind.
• Größenbeschränkungen:
  • Die maximale Größe eines einzelnen Metadatenwerts beträgt 32 KB (32.768 Byte).
  • Die maximale Gesamtgröße aller Metadaten-Schlüssel/Wert-Paare in der gesamten ComputeClass-Ressource darf 512 KB (524.288 Byte) nicht überschreiten.
• Wichtige Einschränkungen und Formatierung:
  • Sie können maximal 32 benutzerdefinierte Metadaten-Schlüssel/Wert-Paare pro ComputeClass definieren.
  • Schlüssel müssen weniger als 128 Zeichen lang sein und dürfen nur alphanumerische Zeichen, Bindestriche (-) und Unterstriche (_) enthalten.
• Reservierte Schlüssel: GKE und Compute Engine reservieren bestimmte Systemmetadatenschlüssel, die für die Verwaltung von Clustervorgängen erforderlich sind (z. B. kube-env, user-data, startup-script und cluster-name). Sie können reservierte Systemmetadatenschlüssel nicht überschreiben oder angeben.
• Unveränderlichkeit bei vorhandenen Knotenpools: Wenn Sie instanceMetadata für eine vorhandene ComputeClass ändern, gilt dies nur, wenn GKE neue Knotenpools bereitstellt (wenn nodePoolAutoCreation aktiviert ist). Vorhandene Knotenpools und VMs werden nicht rückwirkend geändert.

Im folgenden Beispiel wird gezeigt, wie Sie sowohl globale Instanzmetadaten für alle Knotenpools als auch eine prioritätsspezifische Metadatenüberschreibung konfigurieren:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: metadata-example-class
spec:
  nodePoolAutoCreation:
    enabled: true
  nodePoolConfig:
    instanceMetadata:
      environment: "production"
      team: "backend-platform"
  priorities:
  - machineFamily: n4
    instanceMetadata:
      workload-tier: "high-performance"
  - machineFamily: e2
    instanceMetadata:
      workload-tier: "fallback-general"
      team: "shared-infra"

Autoscaling-Limits konfigurieren

Verfügbar in GKE-Version 1.36.2-gke.2064000 und höher.

Standardmäßig stellt GKE neue Knoten für eine ComputeClass bis zu den Autoscaling-Limits des gesamten Clusters bereit. Wenn Sie strengere Ressourcengrenzen für eine bestimmte ComputeClass erzwingen möchten, z. B. die maximale Anzahl von GPUs, CPUs oder Gesamtknoten, die für die ComputeClass bereitgestellt werden können, können Sie eine benutzerdefinierte CapacityQuota-Ressource anwenden.

Weitere Informationen finden Sie unter Granulare Ressourcenlimits konfigurieren.

Konfiguration von Shielded GKE-Knoten

Erfordert GKE-Version 1.36.3-gke.1244000 oder höher

Wenn Sie Shielded GKE Nodes-Features wie Secure Boot und Integritätsmonitoring für automatisch erstellte Knotenpools konfigurieren möchten, die von einer ComputeClass verwaltet werden, geben Sie das Feld shieldedInstanceConfig im Block nodePoolAutoCreation (spec.nodePoolAutoCreation.shieldedInstanceConfig) an.

Die Standardwerte für shieldedInstanceConfig hängen von Ihrem Clustermodus und Ihrer ComputeClass-Konfiguration ab:

• In Clustern im Standardmodus: Wenn shieldedInstanceConfig während des Abgleichs von nodePoolAutoCreation initialisiert wird, wird das Feld enableIntegrityMonitoring standardmäßig auf true und das Feld enableSecureBoot standardmäßig auf false gesetzt, sofern Sie sie nicht explizit konfigurieren.
• In Autopilot-Clustern (oder wenn spec.autopilot.enabled in einer ComputeClass true ist): Die Felder enableSecureBoot und enableIntegrityMonitoring sind standardmäßig auf true gesetzt und können nicht deaktiviert werden.

Im folgenden Beispiel wird gezeigt, wie Sie das Feld shieldedInstanceConfig im Block nodePoolAutoCreation konfigurieren, um Shielded GKE-Knoten-Features für automatisch erstellte Knotenpools zu aktivieren:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: shielded-ccc
spec:
  nodePoolAutoCreation:
    enabled: true
    shieldedInstanceConfig:
      enableSecureBoot: true
      enableIntegrityMonitoring: true

ComputeClasses in Arbeitslasten anfordern

Wenn Sie eine benutzerdefinierte ComputeClass verwenden möchten, muss Ihr Pod diese ComputeClass explizit mit einem nodeSelector in der Pod-Spezifikation anfordern. Sie können optional eine ComputeClass als Standard für einen bestimmten Kubernetes-Namespace festlegen. Pods in diesem Namespace verwenden diese ComputeClass, sofern die Pods keine andere ComputeClass anfordern.

Im folgenden Manifest wird beispielsweise die ComputeClass 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: registry.k8s.io/pause
        resources:
          requests:
            cpu: 1.5
            memory: "4Gi"

Knotenauswahl für Systemknotenlabels

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

• k8s.io
• cloud.google.com
• gke.io
• node.kubernetes.io/instance-type

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

• Die 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, die ein entsprechendes Feld in der ComputeClass-Spezifikation haben. Wenn Sie ComputeClasses verwenden, aktualisieren Sie Ihre Arbeitslasten, um die folgenden Labels aus Knotenselektoren zu entfernen, und konfigurieren Sie das entsprechende Feld in den von Ihnen erstellten ComputeClasses:

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
node.kubernetes.io/instance-type	priorities.machineType

ComputeClass-Nutzung überwachen

Sie können mithilfe von Cloud Monitoring-Messwerten überwachen, wie der Cluster Autoscaler mit ComputeClasses interagiert. Messwerte wie kubernetes.io/autoscaler/cluster_pending_pods_per_ccc, kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_ccc und kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc erfassen ausstehende Pods, Versuche zur Knotenbereitstellung und Bereitstellungsfehler. Diese Messwerte sind in GKE-Version 1.37 und höher verfügbar.

Ausführliche Informationen zum Abfragen dieser Messwerte und zum Interpretieren von Labels finden Sie unter Cluster-Autoscaling-Ereignisse und -Messwerte ansehen.

Beschränkungen

• Der Name der ComputeClass darf nicht mit gke oder autopilot beginnen (reserviert für System-ComputeClasses).
• Bestimmte Cluster weisen hohe Raten für die Erstellung und Löschung von Pods auf, was die Auswertungszeit für Cluster Autoscaler erhöht. Während eines Skalierungsvorgangs hat Cluster Autoscaler möglicherweise nicht genügend Zeit, um nachfolgende Prioritätsregeln in einer ComputeClass zu bewerten, bevor der Backoff-Zeitraum für vorherige Prioritätsregeln abläuft. Dies kann dazu führen, dass Pods im Status „Ausstehend“ verbleiben. Um dieses Problem zu beheben, reduzieren Sie die Rate, mit der Pods erstellt und gelöscht werden, z. B. indem Sie die aktive Migration für die ComputeClass deaktivieren.

Nächste Schritte

• Best Practices für ComputeClasses
• Automatisch skalierte Knotenattribute mit benutzerdefinierten ComputeClasses steuern
• Weitere Informationen zu ComputeClasses vom Typ „Balanced“ und „horizontal skalierbar“ in Autopilot-Clustern
• Automatische Erstellung von Knotenpools konfigurieren
• Weitere Informationen zum GKE-Cluster-Autoscaling
• Compute-Klassen für Autopilot-Pods auswählen
• Probleme mit benutzerdefinierten ComputeClasses beheben