Compute-Klassen „Balanced“ und „Scale-Out“ in Autopilot-Clustern

Sie können die ComputeClasses Balanced und Scale-Out in Google Kubernetes Engine (GKE) Autopilot-Clustern verwenden, um Arbeitslasten auszuführen, die zusätzliche Rechenkapazität oder spezielle CPU-Konfigurationen erfordern. Diese Seite richtet sich an Clusteradministratoren, die flexiblere Compute-Optionen als die Standardkonfiguration von Autopilot-Clustern benötigen.

Übersicht über die Compute-Klassen „Balanced“ und „Scale-Out“

Standardmäßig werden Pods in GKE Autopilot-Clustern auf einer containeroptimierten Computing-Plattform ausgeführt. Diese Plattform ist ideal für Arbeitslasten für allgemeine Zwecke wie Webserver und Batchjobs mit mittlerer Intensität. Die containeroptimierte Computing-Plattform bietet eine zuverlässige, skalierbare und kostenoptimierte Hardwarekonfiguration, die die Anforderungen der meisten Arbeitslasten bewältigen kann.

Wenn Sie Arbeitslasten mit besonderen Hardwareanforderungen haben, z. B. maschinelles Lernen oder KI-Aufgaben ausführen, Datenbanken mit hohem Traffic in Echtzeit ausführen oder bestimmte CPU-Plattformen und -Architekturen benötigen, können Sie ComputeClasses verwenden, um diese Hardware bereitzustellen.

Nur in Autopilot-Clustern bietet GKE die folgenden kuratierten Compute-Klassen, mit denen Sie Pods ausführen können, die mehr Flexibilität als die standardmäßige containeroptimierte Compute-Plattform benötigen:

  • Balanced: bietet eine höhere maximale CPU- und Arbeitsspeicherkapazität als die containeroptimierte Computing-Plattform.
  • Scale-Out: Deaktiviert das gleichzeitige Multi-Threading (SMT) und ist für die horizontale Skalierung optimiert.

Diese Compute-Klassen sind nur in Autopilot-Clustern verfügbar. Ähnlich wie bei der standardmäßigen containeroptimierten Compute-Plattform verwaltet Autopilot die Knotengröße und Ressourcenzuweisung basierend auf den ausgeführten Pods.

Benutzerdefinierte Compute-Klassen für zusätzliche Flexibilität

Wenn die Compute-Klassen „Balanced“ oder „Scale-Out“ in Autopilot-Clustern nicht den Anforderungen Ihrer Arbeitslast entsprechen, können Sie eigene Compute-Klassen konfigurieren. Sie stellen benutzerdefinierte ComputeClass-Kubernetes-Ressourcen in Ihren Clustern mit Gruppen von Knotenattributen bereit, die GKE zum Konfigurieren neuer Knoten im Cluster verwendet. Mit diesen benutzerdefinierten Compute-Klassen können Sie beispielsweise Arbeitslasten auf derselben Hardware wie die Compute-Klassen Balanced oder Scale-Out in einem beliebigen GKE-Autopilot- oder Standardcluster bereitstellen. Weitere Informationen finden Sie unter Arbeitslasten im Autopilot-Modus in GKE Standard.

Preise

Pods, die die ComputeClasses Balanced oder Scale-Out verwenden, werden anhand der folgenden SKUs abgerechnet:

Weitere Informationen finden Sie unter GKE-Preise.

Technische Details zu Balanced und Scale-Out

In diesem Abschnitt werden die Maschinentypen und Anwendungsfälle für die Klassen Balanced und Scale-Out beschrieben. Wenn Sie in Ihren Pods keine ComputeClass anfordern, platziert Autopilot die Pods standardmäßig auf der containeroptimierten Compute-Plattform. Die containeroptimierte Compute-Plattform verwendet eine beliebige Maschinenserie aus der Compute Engine-Maschinenfamilie für allgemeine Zwecke, vorzugsweise Maschinentypen, deren Größe geändert werden kann. Da die zugrunde liegende Maschinenserie nicht festgelegt ist, variiert die Leistung pro CPU je nachdem, auf welcher Maschinenserie GKE Ihren Pod plant.

Außerdem hängt die Planung von Pods mit angehängtem nichtflüchtigen Speicher von der Kompatibilität des Speichertyps ab:

  • Legacy Persistent Disks: Pods mit angehängten Legacy Persistent Disks (z. B. pd-standard) werden nur auf Maschinenserien ausgeführt, die sie unterstützen, z. B. E2.
  • Hyperdisk: Pods mit angehängtem Speicher der nächsten Generation (z. B. hyperdisk-balanced) werden auf neueren Maschinenserien wie C3 ausgeführt.
  • Status „Ausstehend“: Wenn Sie einen Pod explizit für die Ausführung auf einer neueren Maschinenserie konfigurieren (z. B. durch Verwendung von Knotenauswahlen zum Anfordern von C3-Knoten oder durch Konfiguration einer benutzerdefinierten ComputeClass), aber eine alte Persistent Disk anhängen, bleibt der Pod auf unbestimmte Zeit im Status Pending. Das liegt daran, dass GKE keinen Knoten finden kann, der sowohl die Einschränkungen für den Maschinentyp als auch für die Festplattenkompatibilität erfüllt. Wenn Sie explizit eine Maschinenreihe auswählen, sind Sie dafür verantwortlich, dass PersistentVolume und Festplatte kompatibel sind.

Die folgende Tabelle bietet einen technischen Überblick über die ComputeClasses Balanced und Scale-Out.

Ausgewogene und Scale-Out-Compute-Klassen
Balanced

Bietet mehr CPU- und Arbeitsspeicherkapazität als die maximalen Werte der containeroptimierten Computing-Plattform. Bietet zusätzliche CPU-Plattformen und die Möglichkeit, Mindest-CPU-Plattformen für Pods festzulegen, z. B. Intel Ice Lake oder höher.

  • Verfügbare CPUs: AMD EPYC Milan, Intel Ice Lake, Intel Cascade Lake
  • Verfügbare Architektur: amd64
  • Maschinenserie: N2 (Intel-CPUs) oder N2D-Maschinenserie (AMD-CPUs).

Verwenden Sie die Klasse Balanced für Anwendungen wie die folgenden:

  • Webserver
  • Mittlere bis große Datenbanken
  • Caching
  • Streaming und Medienbereitstellung
  • Hyperdisk Throughput und Extrem-Speicher
Scale-Out

Bietet Single-Thread-pro-Core-Computing und horizontale Skalierung.

  • Verfügbare CPUs: Ampere Altra Arm oder AMD EPYC Milan
  • Verfügbare Architektur: arm64 oder amd64
  • Maschinenserie: T2A (Arm) oder T2D (x86).
  • Zusätzliche Funktionen:
    • SMT ist deaktiviert. Eine vCPU entspricht einem physischen Kern.
    • Maximale Taktgeschwindigkeit von 3,5 GHz.

Verwenden Sie die Klasse Scale-Out für Anwendungen wie die folgenden:

  • Webserver
  • Containerisierte Mikrodienste
  • Datenlogverarbeitung
  • Umfangreiche Java-Anwendungen
  • Hyperdisk Throughput-Speicher

ComputeClass-Auswahl in Arbeitslasten

Wenn Sie eine ComputeClass für eine GKE-Arbeitslast verwenden möchten, wählen Sie die ComputeClass im Arbeitslastmanifest mit einer Knotenauswahl für das Label cloud.google.com/compute-class aus.

Im folgenden Beispiel-Deployment-Manifest wird eine ComputeClass ausgewählt:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      nodeSelector:
        # Replace with the name of a compute class
        cloud.google.com/compute-class: COMPUTE_CLASS 
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "250m"
            memory: "1Gi"

Ersetzen Sie COMPUTE_CLASS durch den Namen einer Compute-Klasse, z. B. Balanced oder Scale-Out. Sie können in einer Arbeitslast maximal eine ComputeClass auswählen.

Wenn Sie die Arbeitslast bereitstellen, führt GKE Folgendes aus:

  • Stellt automatisch Knoten bereit, die von der angegebenen Konfiguration unterstützt werden, um Ihre Pods auszuführen.
  • Den neuen Knoten werden automatisch Knotenlabels und Markierungen hinzugefügt, um zu verhindern, dass andere Pods auf diesen Knoten geplant werden. Die Markierungen sind für jede ComputeClass eindeutig. Wenn Sie auch eine CPU-Architektur auswählen, fügt GKE eine separate Markierung hinzu, die für diese Architektur eindeutig ist.
  • Fügt den bereitgestellten Pods automatisch Toleranzen hinzu, die den angewendeten Markierungen entsprechen, sodass GKE diese Pods auf den neuen Knoten platzieren kann.

Wenn Sie beispielsweise die ComputeClass Scale-Out für einen Pod anfordern:

  1. Autopilot fügt für diese Knoten eine Markierung hinzu, die für Scale-Out spezifisch ist.
  2. Autopilot fügt den Scale-Out-Pods eine Toleranz für diese Markierung hinzu.

Pods, die nicht Scale-Out anfordern, erhalten keine Toleranz. Daher plant GKE diese Pods nicht auf den Scale-Out-Knoten.

Wenn Sie in der Arbeitslastspezifikation nicht explizit eine ComputeClass anfordern, plant Autopilot Pods auf Knoten, die die standardmäßige containeroptimierte Compute-Plattform verwenden. Die meisten Arbeitslasten für allgemeine Zwecke können ohne Probleme auf dieser Plattform ausgeführt werden.

Wenn Sie Compute-Klassen verwenden oder bestimmte Maschinenreihen anfordern, achten Sie darauf, dass Ihre Arbeitslasten keinen inkompatiblen Speicher verwenden. Verwenden Sie beispielsweise keine älteren Persistent Disk-Volumetypen wie nichtflüchtiger Standardspeicher (pd-standard) oder nichtflüchtiger SSD-Speicher (pd-ssd) auf Maschinenreihen, die sie nicht unterstützen. Wenn Sie inkompatiblen Speicher verwenden, können Pods im Status Pending verbleiben, wenn GKE keinen Knoten finden oder bereitstellen kann, der alle Einschränkungen erfüllt. Wenn ein Pod geplant ist, der Speicher aber nicht angehängt oder bereitgestellt werden kann, verbleibt der Pod im Status ContainerCreating. Weitere Informationen zur Fehlerbehebung bei der Speicherkompatibilität finden Sie unter Arbeitslast, die auf älteren Maschinenserien geplant ist oder aufgrund von Speicherinkompatibilität im Status Pending hängen bleibt.

CPU-Architektur anfordern

In einigen Fällen können Ihre Arbeitslasten für eine bestimmte Architektur wie Arm erstellt werden. Die Compute-Klasse „horizontal skalieren“ unterstützt mehrere CPU-Architekturen. Sie können neben Ihrer ComputeClass-Anfrage eine bestimmte Architektur anfordern. Geben Sie dazu ein Label in Ihrer Knotenauswahl oder Knotenaffinitätsregel an, wie im folgenden Beispiel gezeigt:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-arm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-arm
  template:
    metadata:
      labels:
        app: nginx-arm
    spec:
      nodeSelector:
        cloud.google.com/compute-class: COMPUTE_CLASS
        kubernetes.io/arch: ARCHITECTURE
      containers:
      - name: nginx-arm
        image: nginx
        resources:
          requests:
            cpu: 2000m
            memory: 2Gi

Ersetzen Sie ARCHITECTURE durch die gewünschte CPU-Architektur, z. B. arm64 oder amd64. Sie können maximal eine Architektur für Ihre Arbeitslast auswählen. Die von Ihnen ausgewählte ComputeClass muss die von Ihnen angegebene Architektur unterstützen.

Wenn Sie nicht explizit eine Architektur anfordern, verwendet Autopilot die Standardarchitektur der ComputeClass.

Arm-Architektur auf Autopilot

Autopilot unterstützt Anfragen für Knoten, die die ARM-CPU-Architektur verwenden. ARM-Knoten sind kostengünstiger als ähnliche x86-Knoten und bieten gleichzeitig Leistungsverbesserungen. Eine Anleitung zum Anfordern von ARM-Knoten finden Sie unter Autopilot-Arbeitslasten in der ARM-Architektur bereitstellen.

Prüfen Sie, ob Sie in Ihren Bereitstellungen die richtigen Images verwenden. Wenn Ihre Pods ARM-Images verwenden und Sie keine ARM-Knoten anfordern, plant Autopilot die Pods auf x86-Knoten und die Pods abstürzen. Ähnlich verhält es sich, wenn Sie versehentlich x86-Images verwenden, aber ARM-Knoten für die Pods anfordern, die dann zum Absturz der Pods führen.

Standard-, Mindest- und Höchstwerte für Ressourcenanfragen

Wenn Sie eine ComputeClass für Ihre Autopilot-Arbeitslasten auswählen, müssen Sie Ressourcenanfragen angeben, die die Mindest- und Höchstwerte für diese ComputeClass erfüllen. Informationen zu den Standardanfragen sowie zu den Mindest- und Höchstwerten für jede ComputeClass finden Sie unter Ressourcenanfragen und -limits in GKE Autopilot.

Nächste Schritte