Ressourcenanforderungen in Autopilot


Auf dieser Seite werden die maximalen, minimalen und standardmäßigen Ressourcenanfragen beschrieben, die Sie für GKE-Autopilot-Arbeitslasten (Google Kubernetes Engine) angeben können, und wie diese Anfragen automatisch geändert werden, um die Stabilität der Arbeitslasten zu gewährleisten.

Übersicht über Ressourcenanfragen in Autopilot

Autopilot verwendet die in Ihrer Arbeitslastkonfiguration angegebenen Ressourcenanfragen, um die Knoten zu konfigurieren, die Ihre Arbeitslasten ausführen. Autopilot erzwingt Mindest- und maximale Ressourcenanforderungen basierend auf der Compute-Klasse oder der Hardwarekonfiguration, die Ihre Arbeitslasten verwenden. Wenn Sie für einige Container keine Anfragen angeben, weist Autopilot Standardwerte zu, damit diese Container ordnungsgemäß ausgeführt werden.

Wenn Sie eine Arbeitslast in einem Autopilot-Cluster bereitstellen, prüft GKE die Arbeitslastkonfiguration anhand der zulässigen Mindest- und Höchstwerte für die ausgewählte Compute-Klasse oder Hardwarekonfiguration (wie z. B. GPUs). Wenn Ihre Anfragen unter dem Mindestwert liegen, ändert Autopilot Ihre Arbeitslastkonfiguration automatisch, um Ihre Anfragen innerhalb des zulässigen Bereichs zu bringen. Wenn Ihre Anfragen das Maximum überschreiten, lehnt Autopilot Ihre Arbeitslast ab und zeigt eine Fehlermeldung an.

In der folgenden Liste sind die Kategorien der Ressourcenanfragen zusammengefasst:

  • Standardressourcenanfragen: Autopilot fügt diese hinzu, wenn Sie keine eigenen Anfragen für Arbeitslasten angeben.
  • Minimale und maximale Ressourcenanfragen: Autopilot überprüft Ihre angegebenen Anfragen, um sicherzustellen, dass sie innerhalb dieser Limits liegen. Wenn Ihre Anfragen außerhalb der Limits liegen, ändert Autopilot Ihre Arbeitslastanfragen.
  • Arbeitslasttrennung und erweiterte Daueranfragen: Autopilot hat unterschiedliche Standardwerte und unterschiedliche Mindestwerte für Arbeitslasten, die Sie voneinander trennen, oder für Pods, die einen erweiterten Schutz vor einer von GKE initiierten Bereinigung erhalten.
  • Ressourcenanfragen für DaemonSets: Autopilot hat unterschiedliche Standard-, Mindest- und Höchstwerte für Container in DaemonSets.

Ressourcen anfordern

In Autopilot fordern Sie Ressourcen in Ihrer Pod-Spezifikation an. Die unterstützten Mindest- und Höchstwerte, die Sie basierend auf der Hardwarekonfiguration des Knotens anfordern können, auf dem die Pods ausgeführt werden. Informationen zum Anfordern bestimmter Hardwarekonfigurationen finden Sie auf den folgenden Seiten:

Standardanforderungen für Ressourcen

Wenn Sie für einige Container in einem Pod keine Ressourcenanforderungen angeben, wendet Autopilot Standardwerte an. Diese Standardeinstellungen eignen sich für viele kleinere Arbeitslasten.

Außerdem wendet Autopilot unabhängig von der ausgewählten Compute-Klasse oder Hardwarekonfiguration die folgenden Standardressourcenanforderungen an:

  • Container in DaemonSets

    • CPU: 50 mCPU
    • Arbeitsspeicher: 100 (MiB)
    • Sitzungsspezifischer Speicher: 100 MiB
  • Alle anderen Container

    • Sitzungsspezifischer Speicher: 1 GiB

Weitere Informationen zu den Limits für Autopilot-Cluster finden Sie unter Kontingente und Limits.

Standardanfragen für Compute-Klassen

Autopilot wendet die folgenden Standardwerte auf Ressourcen an, die nicht in der Pod-Spezifikation für Pods definiert sind, die auf Computing-Klassen ausgeführt werden: Wenn Sie nur eine der Anfragen festlegen und die andere leer lassen, verwendet GKE das im Abschnitt Mindest- und maximale Anfragen definierte CPU-:Arbeits-Speicherverhältnis, um die fehlende Anfrage festzulegen auf einen Wert, der dem Verhältnis entspricht.

Compute-Klasse Ressource Standardanfrage
Allgemeiner Zweck (Standard) CPU 0,5 vCPU
Arbeitsspeicher 2 GiB
Accelerator Weitere Informationen finden Sie im Abschnitt Standardressourcen für Beschleuniger.
Ausgeglichen CPU 0,5 vCPU
Arbeitsspeicher 2 GiB
Leistung CPU
  • C3-Maschinenserie: 2 vCPUs
  • C3-Maschinenserie mit lokaler SSD: 2 vCPU
  • C3D-Maschinenserie: 2 vCPUs
  • C3D-Maschinenserie mit lokaler SSD: 4 vCPU
  • H3-Maschinenserie: 80 vCPU
  • C2-Maschinenserie: 2 vCPUs
  • C2D-Maschinenserie: 2 vCPU
  • T2A-Maschinenserie: 2 vCPUs
  • T2D-Maschinenserie: 2 vCPUs
Arbeitsspeicher
  • C3-Maschinenserie: 8 GiB
  • C3-Maschinenserie mit lokaler SSD: 8 GiB
  • C3D-Maschinenserie: 8 GiB
  • C3D-Maschinenserie mit lokaler SSD: 16 GiB
  • H3-Maschinenserie: 320 GiB
  • C2-Maschinenserie: 8 GiB
  • C2D-Maschinenserie: 8 GiB
  • T2A-Maschinenserie: 8 GiB
  • T2D-Maschinenserie: 8 GiB
Sitzungsspezifischer Speicher
  • C3-Maschinenserie: 1 GiB
  • C3-Maschinenserie mit lokaler SSD: 1 GiB
  • C3D-Maschinenserie: 1 GiB
  • C3D-Maschinenserie mit lokaler SSD: 1 GiB
  • H3-Maschinenserie: 1 GiB
  • C2-Maschinenserie: 1 GiB
  • C2D-Maschinenserie: 1 GiB
  • T2A-Maschinenserie: 1 GiB
  • T2D-Maschinenserie: 1 GiB
Horizontal skalieren CPU 0,5 vCPU
Arbeitsspeicher 2 GiB

Standardanfragen für Beschleuniger

In der folgenden Tabelle werden die Standardwerte beschrieben, die GKE Pods zuweist, für die keine Werte im Feld requests der Pod-Spezifikation angegeben sind. Diese Tabelle gilt für Pods, die die Compute-Klasse Accelerator verwenden. Dies ist die empfohlene Methode zum Ausführen von Beschleunigern in Autopilot-Clustern.

Accelerator Ressource Standardanfrage insgesamt
NVIDIA H100 Mega (80 GB)-GPUs
nvidia-h100-mega-80gb
CPU
  • 8 GPUs: 200 vCPU
Arbeitsspeicher
  • 8 GPUs: 1400 GiB
Sitzungsspezifischer Speicher
  • 8 GPUs: 1 GiB
NVIDIA H100 (80 GB)-GPUs
nvidia-h100-80gb
CPU
  • 8 GPUs: 200 vCPU
Arbeitsspeicher
  • 8 GPUs: 1400 GiB
Sitzungsspezifischer Speicher
  • 8 GPUs: 1 GiB
NVIDIA A100 (40 GB) GPUs
nvidia-tesla-a100
CPU
  • 1 GPU: 9 vCPU
  • 2 GPUs: 20 vCPU
  • 4 GPUs: 44 vCPU
  • 8 GPUs: 92 vCPU
  • 16 GPUs: 92 vCPU
Arbeitsspeicher
  • 1 GPU: 60 GiB
  • 2 GPUs: 134 GiB
  • 4 GPUs: 296 GiB
  • 8 GPUs: 618 GiB
  • 16 GPUs: 1.250 GiB
NVIDIA A100 (80 GB) GPUs
nvidia-a100-80gb
CPU
  • 1 GPU: 9 vCPU
  • 2 GPUs: 20 vCPU
  • 4 GPUs: 44 vCPU
  • 8 GPUs: 92 vCPU
Arbeitsspeicher
  • 1 GPU: 134 GiB
  • 2 GPUs: 296 GiB
  • 4 GPUs: 618 GiB
  • 8 GPUs: 1.250 GiB
Sitzungsspezifischer Speicher
  • 1 GPU: 1 GiB
  • 2 GPUs: 1 GiB
  • 4 GPUs: 1 GiB
  • 8 GPUs: 1 GiB
NVIDIA L4-GPUs
nvidia-l4
CPU
  • 1 GPU: 2 vCPU
  • 2 GPUs: 21 vCPU
  • 4 GPUs: 45 vCPU
  • 8 GPUs: 93 vCPU
Arbeitsspeicher
  • 1 GPU: 7 GiB
  • 2 GPUs: 78 GiB
  • 4 GPUs: 170 GiB
  • 8 GPUs: 355 GiB
NVIDIA T4-GPUs
nvidia-tesla-t4
CPU
  • 1 GPU: 0,5 vCPU
  • 4 GPUs: 0,5 vCPU
Arbeitsspeicher
  • 1 GPU: 2 GiB
  • 4 GPUs: 2 GiB
TPU Trillium (v6e) (Vorabversion)
tpu-v6e-slice (einzelner Host)
CPU Alle Topologien: 1 mCPU
Arbeitsspeicher Alle Topologien: 1 MiB
TPU Trillium (v6e) (Vorabversion)
tpu-v6e-slice (mit mehreren Hosts)
CPU Alle Topologien: 1 mCPU
Arbeitsspeicher Alle Topologien: 1 MiB
TPU v5e
tpu-v5-lite-device (einzelner Host)
CPU Alle Topologien: 1 mCPU
Arbeitsspeicher Alle Topologien: 1 MiB
TPU v5e
tpu-v5-lite-podslice (Multi-Host)
CPU Alle Topologien: 1 mCPU
Arbeitsspeicher Alle Topologien: 1 MiB
TPU v5p
tpu-v5p-slice
CPU Alle Topologien: 1 mCPU
Arbeitsspeicher Alle Topologien: 1 MiB
TPU v4
tpu-v4-podslice
CPU Alle Topologien: 1 mCPU
Arbeitsspeicher Alle Topologien: 1 MiB

Unterstützte GPUs ohne Accelerator-Compute-Klasse

Wenn Sie die Accelerator-Compute-Klasse nicht verwenden, werden nur die folgenden GPUs unterstützt. Die Standardressourcenanfragen für diese GPUs sind mit denen der Compute-Klasse „Accelerator“ identisch:

  • NVIDIA A100 (40 GB)
  • NVIDIA A100 (80 GB)
  • NVIDIA L4
  • NVIDIA Tesla T4

Minimale und maximale Ressourcenanforderungen

Die insgesamt durch Ihre Bereitstellungskonfiguration angeforderten Ressourcen sollten innerhalb der unterstützten Mindest- und Höchstwerte liegen, die Autopilot zulässt. Dabei gelten folgende Bedingungen:

  • Anfragen für flüchtigen Speicher:

    • Für den sitzungsspezifischen Speicher wird das Bootlaufwerk der VM verwendet, es sei denn, an Ihre Knoten sind lokale SSDs angeschlossen.

      Compute-Hardware mit lokalen SSDs wie A100-GPUs (80 GB), H100-GPUs (80 GB) oder die Z3-Maschinenserie unterstützen eine maximale Anfrage, die der Größe der lokalen SSD abzüglich des Systemoverheads entspricht. Informationen zu diesem Systemoverhead finden Sie unter Von lokalen SSDs unterstützter sitzungsspezifischer Speicher.

    • Ab GKE-Version 1.29.3-gke.1038000 unterstützen Pods der Leistungsklasse und Pods mit Hardware-Beschleunigern einen maximalen sitzungsspezifischen Speicheranfrage von 56 TiB, sofern die Hardware keine lokalen SSDs enthält.

      In allen anderen Autopilot-Pods muss die Gesamtanfrage für sitzungsspezifischen Speicher für alle Container im Pod zwischen 10 MiB und 10 GiB liegen, sofern nicht anders angegeben, unabhängig von der GKE-Version.

    • Für größere Volumes sollten Sie allgemeine sitzungsspezifische Volumes verwenden. Diese bieten die gleichen Funktionen und Leistung wie sitzungsspezifischer Speicher, sind aber deutlich flexibler, da sie mit jeder GKE-Speicheroption verwendet werden können. Die maximale Größe für ein generisches sitzungsspezifisches Volume, das pd-balanced verwendet, beträgt beispielsweise 64 TiB.

  • Für DaemonSet-Pods betragen die Mindestressourcenanfragen Folgendes:

    • Cluster, die Bursting unterstützen: 1 mCPU pro Pod, 2 MiB Arbeitsspeicher pro Pod und 10 MiB sitzungsspezifischer Speicher pro Container im Pod.
    • Cluster, die Bursting nicht unterstützen: 10 mCPU pro Pod, 10 MiB Arbeitsspeicher pro Pod und 10 MiB sitzungsspezifischer Speicher pro Container im Pod.

    Informationen dazu, ob Ihr Cluster Bursting unterstützt, finden Sie unter Verfügbarkeit von Bursting in GKE.

  • Wenn Ihr Cluster Bursting unterstützt, erzwingt Autopilot keine 0,25 vCPU-Schritte für Ihre Pod-CPU-Anfragen. Wenn Ihr Cluster Bursting nicht unterstützt, rundet Autopilot Ihre CPU-Anfragen auf die nächste 0,25 vCPU auf. Informationen dazu, ob Ihr Cluster Bursting unterstützt, finden Sie unter Verfügbarkeit von Bursting in GKE.

  • Das CPU-:Speicherverhältnis muss innerhalb des zulässigen Bereichs für die ausgewählte Compute-Klasse oder Hardwarekonfiguration liegen. Wenn das CPU-:Speicherverhältnis außerhalb des zulässigen Bereichs liegt, erhöht Autopilot automatisch die kleinere Ressource. Wenn Sie beispielsweise 1 vCPU und 16 GiB Arbeitsspeicher (Verhältnis 1:16) für Pods anfordern, die in der Klasse Scale-Out ausgeführt werden, erhöht Autopilot die CPU-Anfrage auf 4 vCPUs, was das Verhältnis zu 1:4 ändert.

Mindest- und Höchstwerte für Compute-Klassen

In der folgenden Tabelle werden die minimalen, maximalen und zulässigen Verhältnissen von CPU zu Arbeitsspeicher für jede von Autopilot unterstützte Compute-Klasse beschrieben:

Compute-Klasse CPU:Speicherverhältnis (vCPU:GiB) Ressource Minimum Maximum
Allgemeiner Zweck (Standard) Zwischen 1:1 und 1:6,5 CPU

Der Wert hängt davon ab, ob Ihr Cluster Bursting unterstützt:

  • Cluster, die Bursting unterstützen: 50 m CPU
  • Cluster, die kein Bursting unterstützen: 250m CPU

Informationen dazu, ob Ihr Cluster Bursting unterstützt, finden Sie unter Verfügbarkeit von Bursting in GKE.

30 vCPU
Arbeitsspeicher

Der Wert hängt davon ab, ob Ihr Cluster Bursting unterstützt:

  • Cluster, die Bursting unterstützen: 52 MiB
  • Cluster, die kein Bursting unterstützen: 512 MiB

Informationen dazu, ob Ihr Cluster Bursting unterstützt, finden Sie unter Verfügbarkeit von Bursting in GKE.

110 GiB
Accelerator Mindest- und Höchstwerte für Beschleuniger
Ausgeglichen Zwischen 1:1 und 1:8 CPU 0,25 vCPU

222 vCPU

Wenn Mindest-CPU-Plattform ausgewählt ist:

  • Intel-Plattformen: 126 vCPU
  • AMD-Plattformen: 222 vCPU
Arbeitsspeicher 0,5 GiB

851 GiB

Wenn Mindest-CPU-Plattform ausgewählt ist:

  • Intel-Plattformen: 823 GiB
  • AMD-Plattformen: 851 GiB
Leistung CPU 0,001 vCPU
  • C3-Maschinenserie: 174 vCPU
  • C3-Maschinenserie mit lokaler SSD: 174 vCPU
  • C3D-Maschinenserie: 358 vCPU
  • C3D-Maschinenserie mit lokaler SSD: 358 vCPU
  • H3-Maschinenserie: 86 vCPU
  • C2-Maschinenserie: 58 vCPU
  • C2D-Maschinenserie: 110 vCPU
  • T2A-Maschinenserie: 46 vCPU
  • T2D-Maschinenserie: 58 vCPU
Arbeitsspeicher 1 MiB
  • C3-Maschinenserie: 1,345 GiB
  • C3-Maschinenserie mit lokaler SSD: 670 GiB
  • C3D-Maschinenserie: 2750 GiB
  • C3D-Maschinenserie mit lokaler SSD: 1,375 GiB
  • H3-Maschinenserie: 330 GiB
  • C2-Maschinenserie: 218 GiB
  • C2D-Maschinenserie: 835 GiB
  • T2A-Maschinenserie: 172 GiB
  • T2D-Maschinenserie: 218 GiB
Sitzungsspezifischer Speicher 10 MiB
  • C3-Maschinenserie: 250 GiB
  • C3-Maschinenserie mit lokaler SSD: 10.000 GiB
  • C3D-Maschinenserie: 250 GiB
  • C3D-Maschinenserie mit lokaler SSD: 10.000 GiB
  • H3-Maschinenserie: 250 GiB
  • C2-Maschinenserie: 250 GiB
  • C2D-Maschinenserie: 250 GiB
  • T2A-Maschinenserie: 250 GiB
  • T2D-Maschinenserie: 250 GiB

In Version 1.29.3-gke.1038000 und höher können Sie eine maximale Anfrage für sitzungsspezifischen Speicher von 56 TiB angeben, sofern die Hardware keine lokalen SSDs enthält.

Horizontal skalieren 1:4 CPU 0,25 vCPU
  • arm64: 43 vCPU
  • amd64: 54 vCPU
Arbeitsspeicher 1 GiB
  • arm64: 172 GiB
  • amd64: 216 GiB

Informationen zum Anfordern von Compute-Klassen in Ihren Autopilot-Pods finden Sie unter Compute-Klassen für Autopilot-Pods auswählen.

Mindest- und Höchstwerte für Beschleuniger

In den folgenden Abschnitten werden die minimalen, maximalen und zulässigen Verhältnisse von CPU zu Arbeitsspeicher für Pods beschrieben, die Hardwarebeschleuniger wie GPUs und TPUs verwenden.

Sofern nicht anders angegeben, beträgt der maximale unterstützte Sitzungsspezifische Speicher 122 GiB in Versionen 1.28.6-gke.1369000 oder höher und 1.29.1-gke.1575000 oder höher. Bei früheren Versionen beträgt der maximal unterstützte Sitzungsspezifische Speicher 10 GiB.

Mindest- und Höchstwerte für die Accelerator-Computing-Klasse

Die folgende Tabelle enthält die minimalen und maximalen Ressourcenanforderungen für Pods, die die Compute-Klasse „Accelerator“ verwenden. Dies ist die empfohlene Methode zum Ausführen von Accelerators mit GKE Autopilot-Clustern. In der Compute-Klasse „Accelerator“ erzwingt GKE keine CPU-zu-Speicher-Anfragequotienten.

Beschleunigertyp Ressource Minimum Maximum
NVIDIA H100 Mega (80 GB)
nvidia-h100-mega-80gb
CPU
  • 8 GPUs: 0,001 vCPU
  • 8 GPUs: 206 vCPU
Arbeitsspeicher
  • 8 GPUs: 1 MiB
  • 8 GPUs: 1.795 GiB
Sitzungsspezifischer Speicher
  • 8 GPU: 10 MiB
  • 8 GPUs: 5.250 GiB
NVIDIA H100 (80 GB)
nvidia-h100-80gb
CPU
  • 8 GPUs: 0,001 vCPU
  • 8 GPUs: 206 vCPU
Arbeitsspeicher
  • 8 GPUs: 1 MiB
  • 8 GPUs: 1.795 GiB
Sitzungsspezifischer Speicher
  • 8 GPU: 10 MiB
  • 8 GPUs: 5.250 GiB
NVIDIA A100 (40 GB)
nvidia-tesla-a100
CPU 0,001 vCPU
  • 1 GPU: 11 vCPU
  • 2 GPUs: 22 vCPU
  • 4 GPUs: 46 vCPU
  • 8 GPUs: 94 vCPU
  • 16 GPUs: 94 vCPU

Die Summe der CPU-Anfragen aller DaemonSets, die auf einem A100-GPU-Knoten ausgeführt werden, darf 2 vCPUs nicht überschreiten.

Arbeitsspeicher 1 MiB
  • 1 GPU: 74 GiB
  • 2 GPUs: 148 GiB
  • 4 GPUs: 310 GiB
  • 8 GPUs: 632 GiB
  • 16 GPUs: 1.264 GiB

Die Summe der Speicheranfragen aller DaemonSets, die auf einem A100-GPU-Knoten ausgeführt werden, darf 14 GiB nicht überschreiten.

NVIDIA A100 (80 GB)
nvidia-a100-80gb
CPU 0,001 vCPU
  • 1 GPU: 11 vCPU
  • 2 GPUs: 22 vCPU
  • 4 GPUs: 46 vCPU
  • 8 GPUs: 94 vCPU

Die Summe der CPU-Anfragen aller DaemonSets, die auf einem A100-GPU-Knoten (80 GB) ausgeführt werden, darf 2 vCPUs nicht überschreiten.

Arbeitsspeicher 1 MiB
  • 1 GPU: 148 GiB
  • 2 GPUs: 310 GiB
  • 4 GPUs: 632 GiB
  • 8 GPUs: 1264 GiB

Die Summe der Speicheranfragen aller DaemonSets, die auf einem A100-GPU-Knoten (80 GB) ausgeführt werden, darf 14 GiB nicht überschreiten.

Sitzungsspezifischer Speicher 512 MiB
  • 1 GPU: 280 GiB
  • 2 GPUs: 585 GiB
  • 4 GPUs: 1220 GiB
  • 8 GPUs: 2540 GiB
NVIDIA L4
nvidia-l4
CPU 0,001 vCPU
  • 1 GPU: 31 vCPU
  • 2 GPUs: 23 vCPU
  • 4 GPUs: 47 vCPU
  • 8 GPUs: 95 vCPU

Die Summe der CPU-Anfragen aller DaemonSets, die auf einem L4-GPU-Knoten ausgeführt werden, darf 2 vCPUs nicht überschreiten.

Arbeitsspeicher 1 MiB
  • 1 GPU: 115 GiB
  • 2 GPUs: 83 GiB
  • 4 GPUs: 177 GiB
  • 8 GPUs: 363 GiB

Die Summe der Speicheranfragen aller DaemonSets, die auf einem L4-GPU-Knoten ausgeführt werden, darf 14 GiB nicht überschreiten.

NVIDIA Tesla T4
nvidia-tesla-t4
CPU 0,001 vCPU
  • 1 GPU: 46 vCPU
  • 2 GPUs: 46 vCPU
  • 4 GPUs: 94 vCPU
Arbeitsspeicher 1 MiB
  • 1 GPU: 287,5 GiB
  • 2 GPUs: 287,5 GiB
  • 4 GPUs: 587,5 GiB
TPU v5e
tpu-v5-lite-device
CPU 0,001 vCPU
  • 1x1-Topologie: 24 vCPUs
  • 2x2-Topologie: 112 vCPU
  • 2x4-Topologie: 224 vCPU
Arbeitsspeicher 1 MiB
  • 1x1-Topologie: 48 GiB
  • 2x2-Topologie: 192 GiB
  • 2x4-Topologie: 384 GiB
Sitzungsspezifischer Speicher 10 MiB 56 TiB
TPU v5e
tpu-v5-lite-podslice
CPU 0,001 vCPU
  • 1x1-Topologie: 24 vCPUs
  • 2x2-Topologie: 112 vCPU
  • 2x4-Topologie (Anfrage mit 4 Chips): 112 vCPU
  • 2 × 4-Topologie (Anfrage mit 8 Chips): 224 vCPU
  • 4x4-Topologie: 112 vCPU
  • 4x8-Topologie: 112 vCPU
  • 8x8-Topologie: 112 vCPU
  • 8x16-Topologie: 112 vCPU
  • 16x16-Topologie: 112 vCPU
Arbeitsspeicher 1 MiB
  • 1x1-Topologie: 48 GiB
  • 2x2-Topologie: 192 GiB
  • 2x4-Topologie (4-Chip-Anfrage): 192 GiB
  • 2x4-Topologie (8-Chip-Anfrage): 384 GiB
  • 4x4-Topologie: 192 GiB
  • 4x8-Topologie: 192 GiB
  • 8x8-Topologie: 192 GiB
  • 8x16-Topologie: 192 GiB
  • 16 × 16 Topologie: 192 GiB
Sitzungsspezifischer Speicher 10 MiB 56 TiB
TPU v5p
tpu-v5p-slice
CPU 0,001 vCPU 280 vCPU
Arbeitsspeicher 1 MiB 448 GiB
Sitzungsspezifischer Speicher 10 MiB 56 TiB
TPU v4
tpu-v4-podslice
CPU 0,001 vCPU 240 vCPU
Arbeitsspeicher 1 MiB 407 GiB
Sitzungsspezifischer Speicher 10 MiB 56 TiB

Informationen zum Anfordern von GPUs in Ihren Autopilot-Pods finden Sie unter GPU-Arbeitslasten in Autopilot bereitstellen.

Mindest- und Höchstwerte für GPUs ohne Compute-Klasse

In der folgenden Tabelle sind die Mindest- und Höchstwerte für die Ressourcenanfragen für Pods aufgeführt, die die Accelerator-Compute-Klasse nicht verwenden:

GPU-Typ CPU:Speicherverhältnis (vCPU:GiB) Ressource Minimum Maximum
NVIDIA A100 (40 GB)
nvidia-tesla-a100
Nicht erzwungen CPU
  • 1 GPU: 9 vCPU
  • 2 GPUs: 20 vCPU
  • 4 GPUs: 44 vCPU
  • 8 GPUs: 92 vCPU
  • 16 GPUs: 92 vCPU
  • 1 GPU: 11 vCPU
  • 2 GPUs: 22 vCPU
  • 4 GPUs: 46 vCPU
  • 8 GPUs: 94 vCPU
  • 16 GPUs: 94 vCPU

Die Summe der CPU-Anfragen aller DaemonSets, die auf einem A100-GPU-Knoten ausgeführt werden, darf 2 vCPUs nicht überschreiten.

Arbeitsspeicher
  • 1 GPU: 60 GiB
  • 2 GPUs: 134 GiB
  • 4 GPUs: 296 GiB
  • 8 GPUs: 618 GiB
  • 16 GPUs: 1.250 GiB
  • 1 GPU: 74 GiB
  • 2 GPUs: 148 GiB
  • 4 GPUs: 310 GiB
  • 8 GPUs: 632 GiB
  • 16 GPUs: 1.264 GiB

Die Summe der Speicheranfragen aller DaemonSets, die auf einem A100-GPU-Knoten ausgeführt werden, darf 14 GiB nicht überschreiten.

NVIDIA A100 (80 GB)
nvidia-a100-80gb
Nicht erzwungen CPU
  • 1 GPU: 9 vCPU
  • 2 GPUs: 20 vCPU
  • 4 GPUs: 44 vCPU
  • 8 GPUs: 92 vCPU
  • 1 GPU: 11 vCPU
  • 2 GPUs: 22 vCPU
  • 4 GPUs: 46 vCPU
  • 8 GPUs: 94 vCPU

Die Summe der CPU-Anfragen aller DaemonSets, die auf einem A100-GPU-Knoten (80 GB) ausgeführt werden, darf 2 vCPUs nicht überschreiten.

Arbeitsspeicher
  • 1 GPU: 134 GiB
  • 2 GPUs: 296 GiB
  • 4 GPUs: 618 GiB
  • 8 GPUs: 1.250 GiB
  • 1 GPU: 148 GiB
  • 2 GPUs: 310 GiB
  • 4 GPUs: 632 GiB
  • 8 GPUs: 1264 GiB

Die Summe der Speicheranfragen aller DaemonSets, die auf einem A100-GPU-Knoten (80 GB) ausgeführt werden, darf 14 GiB nicht überschreiten.

Sitzungsspezifischer Speicher
  • 1 GPU: 512 MiB
  • 2 GPUs: 512 MiB
  • 4 GPUs: 512 MiB
  • 8 GPUs: 512 MiB
  • 1 GPU: 280 GiB
  • 2 GPUs: 585 GiB
  • 4 GPUs: 1220 GiB
  • 8 GPUs: 2540 GiB
NVIDIA L4
nvidia-l4
  • 1 GPU: Zwischen 1:3,5 und 1:4
  • 2, 4 und 8 GPUs: Nicht erzwungen
CPU
  • 1 GPU: 2 vCPU
  • 2 GPUs: 21 vCPU
  • 4 GPUs: 45 vCPU
  • 8 GPUs: 93 vCPU
  • 1 GPU: 31 vCPU
  • 2 GPUs: 23 vCPU
  • 4 GPUs: 47 vCPU
  • 8 GPUs: 95 vCPU

Die Summe der CPU-Anfragen aller DaemonSets, die auf einem L4-GPU-Knoten ausgeführt werden, darf 2 vCPUs nicht überschreiten.

Arbeitsspeicher
  • 1 GPU: 7 GiB
  • 2 GPUs: 78 GiB
  • 4 GPUs: 170 GiB
  • 8 GPUs: 355 GiB
  • 1 GPU: 115 GiB
  • 2 GPUs: 83 GiB
  • 4 GPUs: 177 GiB
  • 8 GPUs: 363 GiB

Die Summe der Speicheranfragen aller DaemonSets, die auf einem L4-GPU-Knoten ausgeführt werden, darf 14 GiB nicht überschreiten.

NVIDIA Tesla T4
nvidia-tesla-t4
Zwischen 1:1 und 1:6,25 CPU 0,5 vCPU
  • 1 GPU: 46 vCPU
  • 2 GPUs: 46 vCPU
  • 4 GPUs: 94 vCPU
Arbeitsspeicher 0,5 GiB
  • 1 GPU: 287,5 GiB
  • 2 GPUs: 287,5 GiB
  • 4 GPUs: 587,5 GiB

Informationen zum Anfordern von GPUs in Ihren Autopilot-Pods finden Sie unter GPU-Arbeitslasten in Autopilot bereitstellen.

Ressourcenanfragen für die Arbeitslasttrennung und erweiterte Dauer

Mit Autopilot können Sie das Planungs- und Bereinigungsverhalten von Kubernetes mit Methoden wie den folgenden bearbeiten:

  • Verwenden Sie Markierungen und Toleranzen und Knotenselektoren, damit bestimmte Pods nur auf bestimmten Knoten platziert werden. Weitere Informationen finden Sie unter Arbeitslasttrennung in GKE konfigurieren.
  • Verwenden Sie Pod-Anti-Affinität, um zu verhindern, dass sich Pods auf demselben Knoten befinden. Die standardmäßigen und minimalen Ressourcenanfragen für Arbeitslasten, die diese Methoden zur Steuerung des Planungsverhaltens verwenden, sind höher als für Arbeitslasten, die dies nicht tun.
  • Verwenden Sie eine Annotation, um Pods vor der Bereinigung durch automatische Knotenupgrades und Herunterskalierungsereignisse bis zu sieben Tage zu schützen. Weitere Informationen finden Sie unter Laufzeit von Autopilot-Pods verlängern.

Wenn die von Ihnen angegebenen Anfragen unter den Mindestwerten liegen, ändert sich das Verhalten von Autopilot basierend auf der verwendeten Methode so:

  • Markierungen, Toleranzen, Selektoren und Pods mit erweiterter Dauer: Autopilot ändert Ihre Pods, um die Anfragen beim Planen der Pods zu erhöhen.
  • Pod-Anti-Affinität: Autopilot lehnt den Pod ab und zeigt eine Fehlermeldung an.

In der folgenden Tabelle werden die Standardanfragen und die minimalen Ressourcenanfragen beschrieben, die Sie angeben können. Wenn eine Konfiguration oder Compute-Klasse in dieser Tabelle nicht vorhanden ist, erzwingt Autopilot keine Mindest- oder Standardwerte.

Compute-Klasse Ressource Standard Minimum
Allgemeiner Zweck CPU 0,5 vCPU 0,5 vCPU
Arbeitsspeicher 2 GiB 0,5 GiB
Ausgeglichen CPU 2 vCPU 1 vCPU
Arbeitsspeicher 8 GiB 4 GiB
Horizontal skalieren CPU 0,5 vCPU 0,5 vCPU
Arbeitsspeicher 2 GiB 2 GiB

Init-Container

Init-Container werden nacheinander ausgeführt und müssen abgeschlossen sein, bevor die Anwendungscontainer gestartet werden. Wenn Sie keine Ressourcenanfragen für Ihre Autopilot-init-Container angeben, weist GKE jedem Init-Container die für den Pod verfügbaren Standardressourcen zu. Dieses Verhalten unterscheidet sich vom GKE-Standard, bei dem jeder Init-Container alle nicht zugewiesenen Ressourcen verwenden kann, die auf dem Knoten verfügbar sind, auf dem der Pod geplant ist.

Im Gegensatz zu Anwendungscontainern empfiehlt GKE, dass Sie keine Ressourcenanfragen für Autopilot-init-Container angeben, damit jeder Container die vollständigen Ressourcen erhält, die für den Pod verfügbar sind. Wenn Sie weniger Ressourcen als die Standardwerte anfordern, schränken Sie den init-Container ein. Wenn Sie mehr Ressourcen anfordern als die Autopilot-Standardeinstellungen, können Sie die Abrechnung für die Lebensdauer des Pods erhöhen.

Ressourcenlimits in Autopilot festlegen

Mit Kubernetes können Sie sowohl requests als auch limits für Ressourcen in Ihrer Pod-Spezifikation festlegen. Das Verhalten Ihrer Pods ändert sich je nachdem, ob Ihre limits sich von Ihren requests unterscheiden, wie in der folgenden Tabelle beschrieben:

Festgelegte Werte Autopilot-Verhalten
requests ist gleich limits Pods verwenden die QoS-Klasse Guaranteed.
requests festgelegt, limits nicht festgelegt

Das Verhalten hängt davon ab, ob Ihr Cluster Bursting unterstützt:

  • Cluster, die Bursting unterstützen: Pods können die verfügbare Skalierungskapazität nutzen.
  • Cluster, die kein Bursting unterstützen: GKE legt den limits gleich dem requests fest.

Informationen dazu, ob Ihr Cluster Bursting unterstützt, finden Sie unter Verfügbarkeit von Bursting in GKE.

requests nicht festgelegt, limits festgelegt Autopilot setzt requests auf den Wert limits, was dem Standardverhalten von Kubernetes entspricht.

Vorher:

resources:
  limits:
    cpu: "400m"

Nachher:

resources:
  requests:
    cpu: "400m"
  limits:
    cpu: "400m"
requests weniger als limits

Das Verhalten hängt davon ab, ob Ihr Cluster Bursting unterstützt:

  • Cluster, die Bursting unterstützen: Pods können bis zum in limits angegebenen Wert hochskalieren.
  • Cluster, die kein Bursting unterstützen: GKE legt den limits gleich dem requests fest.

Informationen dazu, ob Ihr Cluster Bursting unterstützt, finden Sie unter Verfügbarkeit von Bursting in GKE.

requests ist größer als limits Autopilot setzt requests auf den Wert limits.

Vorher:

resources:
  requests:
    cpu: "450m"
  limits:
    cpu: "400m"

Nachher:

resources:
  requests:
    cpu: "400m"
  limits:
    cpu: "400m"
requests nicht festgelegt, limits nicht festgelegt

Autopilot setzt requests auf die Standardwerte für die Compute-Klasse oder Hardwarekonfiguration.

Das Verhalten von limits hängt davon ab, ob Ihr Cluster Bursting unterstützt:

  • Cluster, die Bursting unterstützen: Autopilot legt limits nicht fest.
  • Cluster, die kein Bursting unterstützen: GKE legt den limits gleich dem requests fest.

Informationen dazu, ob Ihr Cluster Bursting unterstützt, finden Sie unter Verfügbarkeit von Bursting in GKE.

In den meisten Fällen sollten Sie angemessene Ressourcenanfragen und gleiche Limits für Ihre Arbeitslasten festlegen.

Legen Sie für Arbeitslasten, die vorübergehend mehr Ressourcen benötigen als ihr stabiler Status, z. B. während des Bootvorgangs oder in höheren Trafficzeiträumen, die Limits höher als Ihre Anfragen fest, damit die Pods Bursts verursachen können. Weitere Informationen finden Sie unter Pod-Bursting in GKE konfigurieren.

Automatische Ressourcenverwaltung in Autopilot

Wenn sich die von Ihnen angegebenen Ressourcenanforderungen für Ihre Arbeitslasten außerhalb der zulässigen Bereiche befinden oder Sie für einige Container keine Ressourcen anfordern, ändert Autopilot Ihre Arbeitslastkonfiguration so, dass sie die zulässigen Limits erfüllt. Autopilot berechnet Ressourcenverhältnisse und Ressourcenanforderungen für Hochskalieren, nachdem die Standardwerte auf Container ohne Anfrage angewendet wurden.

  • Fehlende Anfragen: Wenn Sie in einigen Containern keine Ressourcen anfordern, wendet Autopilot die Standardanfragen für die Compute-Klasse oder Hardwarekonfiguration an.
  • CPU:Arbeitsspeicherverhältnis: Autopilot skaliert die kleinere Ressource, um das Verhältnis innerhalb des zulässigen Bereichs zu bringen.
  • Sitzungsspezifischer Speicher: Autopilot ändert Ihre sitzungsspezifischen Speicheranfragen so, dass die von jedem Container benötigte Mindestmenge erfüllt wird. Der kumulative Wert für Speicheranfragen in allen Containern darf nicht größer als der maximal zulässige Wert sein. Vor Version 1.28.6-gke.1317000 skaliert Autopilot den angeforderten flüchtigen Speicher herunter, wenn der Wert das Maximum überschreitet. In Version 1.28.6-gke.1317000 und höher lehnt Autopilot Ihre Arbeitslast ab.
  • Anfragen unterhalb der Mindestwerte: Wenn Sie weniger Ressourcen als das zulässige Minimum für die ausgewählte Hardwarekonfiguration anfordern, ändert Autopilot den Pod automatisch so, dass er mindestens den Ressourcenwert anfordert.

Wenn Autopilot eine Ressource automatisch so skaliert, dass ein Mindest- oder Standardressourcenwert erreicht wird, weist GKE standardmäßig die zusätzliche Kapazität dem ersten Container im Pod-Manifest zu. In GKE-Version 1.27.2-gke.2200 und höher können Sie GKE anweisen, die zusätzlichen Ressourcen einem bestimmten Container zuzuweisen. Fügen Sie dazu dem Feld annotations in Ihrem Pod-Manifest Folgendes hinzu:

autopilot.gke.io/primary-container: "CONTAINER_NAME"

Ersetzen Sie CONTAINER_NAME durch den Namen des Containers.

Beispiele für Ressourcenänderungen

Das folgende Beispielszenario zeigt, wie Autopilot Ihre Arbeitslastkonfiguration ändert, um die Anforderungen Ihrer ausgeführten Pods und Container zu erfüllen.

Einzelner Container mit < 0,05 vCPU

Containernummer Ursprüngliche Anfrage Geänderte Anfrage
1
CPU: 30 mCPU Arbeits-Speicher: 0,5 GiB
Sitzungsspezifischer Speicher: 10 MiB
CPU: 50 mCPU
Arbeits-Speicher: 0,5 GiB
Sitzungsspezifischer Speicher: 10 MiB

Mehrere Container mit Gesamt-CPU < 0,05 vCPU

Containernummer Ursprüngliche Anfragen Geänderte Anfragen
1
CPU: 10 mCPU Arbeits-Speicher: 0,5 GiB
Sitzungsspezifischer Speicher: 10 MiB
CPU: 30 mCPU
Arbeits-Speicher: 0,5 GiB
Sitzungsspezifischer Speicher: 10 MiB
2
CPU: 10 mCPU Arbeits-Speicher: 0,5 GiB
Sitzungsspezifischer Speicher: 10 MiB

CPU: 10 mCPU Arbeits-Speicher: 0,5 GiB
Sitzungsspezifischer Speicher: 10 MiB
3 CPU: 10 mvCPU
Arbeits-Speicher: 0,5 GiB
Sitzungsspezifischer Speicher: 10 MiB

CPU: 10 mCPU Arbeits-Speicher: 0,5 GiB
Sitzungsspezifischer Speicher: 10 MiB
Pod-Ressourcen insgesamt CPU: 50 mCPU
Arbeits-Speicher: 1,5 GiB
Sitzungsspezifischer Speicher: 30 MiB

Einzelner Container mit zu wenig Arbeitsspeicher für die angeforderte CPU

In diesem Beispiel ist der Speicher für die CPU-Menge zu niedrig (mindestens 1 vCPU:1 GiB). Das minimal zulässige Verhältnis von CPU zu Arbeitsspeicher beträgt 1:1. Wenn das Verhältnis niedriger ist, wird die Speicheranfrage erhöht.

Containernummer Ursprüngliche Anfrage Geänderte Anfrage
1 CPU: 4 vCPU
Speicher: 1 GiB
Sitzungsspezifischer Speicher: 10 MiB
CPU: 4 vCPU
Speicher: 4 GiB
Sitzungsspezifischer Speicher: 10 MiB
Pod-Ressourcen insgesamt CPU: 4 vCPU
Speicher: 4 GiB
Sitzungsspezifischer Speicher: 10 MiB

Nächste Schritte