Um die Stabilität von Arbeitslasten zu verbessern, werden im Autopilot-Modus von Google Kubernetes Engine (GKE) die Werte von Pod-Ressourcenanfragen wie CPU, Arbeitsspeicher oder sitzungsspezifischer Speicher verwaltet. Diese Seite enthält die folgenden Informationen, mit denen Sie effiziente, stabile und kostengünstige Arbeitslasten planen können:
- Standardwerte, die Autopilot auf Pods anwendet, für die keine Werte angegeben sind.
- Mindest- und Höchstwerte, die von Autopilot für Ressourcenanforderungen erzwungen werden.
- Wie die Standard-, Mindest- und Höchstwerte je nach der Hardware variieren, die von Ihren Pods angefordert wird.
Diese Seite richtet sich an Betreiber und Entwickler, die Cloud-Ressourcen bereitstellen und konfigurieren und Arbeitslasten bereitstellen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und ‑Aufgaben.
Sie sollten mit der Kubernetes-Ressourcenverwaltung vertraut sein.
Ü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 | |
| Beschleuniger | Es werden keine Standardanfragen erzwungen. | |
| Ausgeglichen | CPU | 0,5 vCPU |
| Arbeitsspeicher | 2 GiB | |
| Leistung | Es werden keine Standardanfragen erzwungen. | |
| Horizontal skalieren | CPU | 0,5 vCPU |
| Arbeitsspeicher | 2 GiB | |
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 zu flüchtigem Speicher:
Für den sitzungsspezifischen Speicher wird das VM-Bootlaufwerk verwendet, sofern an Ihre Knoten keine lokalen SSDs angehängt sind.
Die Rechenhardware, die lokale SSDs wie A100-GPUs (80 GB), H100-GPUs (80 GB) oder die Z3-Maschinenserie umfasst, unterstützt eine maximale Anfrage, die der Größe der lokalen SSD abzüglich des System-Overheads entspricht. Weitere Informationen zu diesem System-Overhead finden Sie unter Von lokalen SSDs unterstützter sitzungsspezifischer Speicher.
In GKE-Version 1.29.3-gke.1038000 und höher unterstützen Pods der Leistungsklasse und Hardwarebeschleuniger-Pods eine maximale Anfrage für sitzungsspezifischen Speicher von 56 TiB, sofern die Hardware keine lokalen SSDs enthält.
In allen anderen Autopilot-Pods, unabhängig von der GKE-Version, muss die gesamte Anfrage zu sitzungsspezifischem Speicher für alle Container im Pod zwischen 10 MiB und 10 GiB liegen, sofern nicht anders angegeben.
Für größere Volumes verwenden Sie allgemeine sitzungsspezifische Volumes, die gleichwertige Funktionen und Leistung für sitzungsspezifischen Speicher bieten, jedoch deutlich flexibler sind, da sie mit einer beliebigen GKE-Speicheroption verwendet werden können. Die maximale Größe für ein generisches sitzungsspezifisches Volume, das
pd-balancedverwendet, beträgt beispielsweise 64 TiB.
Für DaemonSet-Pods gelten die folgenden Mindestressourcenanfragen:
- 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 kein Bursting 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 Bursting-Verfügbarkeit in GKE.
Wenn Ihr Cluster Bursting unterstützt, erzwingt Autopilot keine Inkremente von 0,25 vCPU für Ihre Pod-CPU-Anforderungen. Wenn Ihr Cluster kein Bursting 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-Outausgefü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:
Informationen dazu, ob Ihr Cluster Bursting unterstützt, finden Sie unter Bursting-Verfügbarkeit in GKE. |
30 vCPU |
| Arbeitsspeicher | Der Wert hängt davon ab, ob Ihr Cluster Bursting unterstützt:
Informationen dazu, ob Ihr Cluster Bursting unterstützt, finden Sie unter Bursting-Verfügbarkeit in GKE. |
110 GiB | ||
| Beschleuniger | 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:
|
| Arbeitsspeicher | 0,5 GiB | 851 GiB Wenn Mindest-CPU-Plattform ausgewählt ist:
|
||
| Leistung | – | CPU | Keine Mindestanzahl an Anfragen erforderlich |
|
| Arbeitsspeicher | Keine Mindestanzahl an Anfragen erforderlich |
|
||
| Sitzungsspezifischer Speicher | Keine Mindestanzahl an Anfragen erforderlich |
|
||
| Horizontal skalieren | Genau 1:4 | CPU | 0,25 vCPU |
|
| Arbeitsspeicher | 1 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 GKE werden keine Mindestanforderungen für CPU, Arbeitsspeicher oder flüchtigen Speicher für Pods erzwungen, die Beschleuniger verwenden. In der folgenden Tabelle sind die maximalen Anfragen für jede dieser Ressourcen aufgeführt, basierend auf der Anzahl und dem Typ des verwendeten Beschleunigers.
Sofern nicht anders angegeben, beträgt der maximale unterstützte sitzungsspezifische Speicher 56 TiB.
| Beschleunigertyp | Ressource | Maximum |
|---|---|---|
NVIDIA B200nvidia-B200 |
CPU |
|
| Arbeitsspeicher |
|
|
| Sitzungsspezifischer Speicher |
|
|
NVIDIA H200 (141 GB)nvidia-h200-141gb |
CPU |
|
| Arbeitsspeicher |
|
|
| Sitzungsspezifischer Speicher |
|
|
NVIDIA H100 Mega (80 GB)nvidia-h100-mega-80gb |
CPU |
|
| Arbeitsspeicher |
|
|
| Sitzungsspezifischer Speicher |
|
|
NVIDIA H100 (80 GB)nvidia-h100-80gb |
CPU |
|
| Arbeitsspeicher |
|
|
| Sitzungsspezifischer Speicher |
|
|
NVIDIA A100 (40 GB)nvidia-tesla-a100 |
CPU |
Die Summe der CPU-Anfragen aller DaemonSets, die auf einem A100-GPU-Knoten ausgeführt werden, darf 2 vCPUs nicht überschreiten. |
| Arbeitsspeicher |
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 |
Die Summe der CPU-Anfragen aller DaemonSets, die auf einem A100-GPU-Knoten (80 GB) ausgeführt werden, darf 2 vCPUs nicht überschreiten. |
| Arbeitsspeicher |
Die Summe der Speicheranfragen aller DaemonSets, die auf einem A100-GPU-Knoten (80 GB) ausgeführt werden, darf 14 GiB nicht überschreiten. |
|
| Sitzungsspezifischer Speicher |
|
|
NVIDIA L4nvidia-l4 |
CPU |
Die Summe der CPU-Anfragen aller DaemonSets, die auf einem L4-GPU-Knoten ausgeführt werden, darf 2 vCPUs nicht überschreiten. |
| Arbeitsspeicher |
Die Summe der Speicheranfragen aller DaemonSets, die auf einem L4-GPU-Knoten ausgeführt werden, darf 14 GiB nicht überschreiten. |
|
NVIDIA Tesla T4nvidia-tesla-t4 |
CPU |
|
| Arbeitsspeicher |
|
|
TPU v5etpu-v5-lite-podslice |
CPU |
|
| Arbeitsspeicher |
|
|
| Sitzungsspezifischer Speicher | 56 TiB | |
TPU v5ptpu-v5p-slice |
CPU | 280 vCPU |
| Arbeitsspeicher | 448 GiB | |
| Sitzungsspezifischer Speicher | 56 TiB | |
TPU v4tpu-v4-podslice |
CPU | 240 vCPU |
| Arbeitsspeicher | 407 GiB | |
| Sitzungsspezifischer Speicher | 56 TiB |
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 sequenziell ausgeführt und müssen alle abgeschlossen sein, bevor Anwendungscontainer gestartet werden können. Wenn Sie in Autopilot-Clustern keine CPU- oder Arbeitsspeicheranforderungen für Init-Container angeben oder Anforderungen explizit auf 0 festlegen, ändert Autopilot Ihre Pods während der Erstellung, um jedem Init-Container Ressourcenanforderungen hinzuzufügen. Die jedem Init-Container zugewiesenen Anforderungen entsprechen der Summe der Anforderungen für alle Anwendungscontainer im Pod. Das ist das Standardverhalten.
Dieses Verhalten unterscheidet sich von Standardclustern, in denen Init-Container alle nicht zugewiesenen Ressourcen verwenden, die auf dem Knoten verfügbar sind, auf dem der Pod geplant ist.
Automatische Ressourcenzuweisung für Init-Container
Die automatische Ressourcenzuweisung für Init-Container erfolgt bei der Pod-Erstellung. Wir empfehlen, Ressourcenanfragen für die Init-Container in Autopilot-Clustern nicht manuell anzugeben, damit jeder Container standardmäßig die vollständigen Ressourcen erhält, die für den Pod verfügbar sind.
Wenn Sie die Ressourcenanfragen von Containern, die keine Init-Container sind, im Pod nach der Erstellung ändern, werden die Ressourcenanfragen der Init-Container von Autopilot nicht automatisch angepasst. Daher werden möglicherweise Gebühren berechnet, die nicht mit der tatsächlichen Ressourcennutzung des Pods übereinstimmen. Die Abrechnung erfolgt auf Grundlage der effektiven Ressourcenanfrage des Pods, die dem größeren der folgenden Werte entspricht:
- Die größte Ressourcenanfrage eines einzelnen Init-Containers im Pod.
- Die Summe der Anfragen für alle Anwendungscontainer im Pod.
Weitere Informationen finden Sie unter Automatische Ressourcenverwaltung in Autopilot.
Manuelle Ressourcenzuweisung für Init-Container
Wenn Sie die vorhandenen Ressourcenanforderungen für Ihre Anwendungscontainer ändern müssen, um Kosten und Ressourcen zu verwalten, empfehlen wir, eine der folgenden Aktionen auszuführen, um die Anforderungen für den Init-Container anzupassen:
- Ressourcenanforderungen für den Init-Container manuell aktualisieren, damit sie den neuen Gesamtanforderungen für den Pod entsprechen. Beachten Sie beim manuellen Festlegen der Ressourcenanforderungen Folgendes:
- Anforderungen, die niedriger als die Gesamtresourcen des Pods sind, können den Init-Container einschränken.
- Anforderungen, die höher sind als die gesamten Ressourcen des Pods, können die Kosten erhöhen.
- Entfernen Sie die Ressourcenanfragen, damit Autopilot sie neu berechnen kann. Im Autopilot-Modus werden die Ressourcen standardmäßig jedem Init-Container basierend auf den aktuellen Gesamtresourcen neu zugewiesen, die von allen Anwendungscontainern im Pod angefordert werden.
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:
Informationen dazu, ob Ihr Cluster Bursting unterstützt, finden Sie unter Bursting-Verfügbarkeit in GKE. |
requests nicht festgelegt, limits festgelegt |
Autopilot setzt requests auf den Wert von limits, was dem Kubernetes-Standardverhalten 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:
Informationen dazu, ob Ihr Cluster Bursting unterstützt, finden Sie unter Bursting-Verfügbarkeit in GKE. |
requests ist größer als limits |
Autopilot legt requests auf den Wert von limits fest.
Vorher: resources:
requests:
cpu: "450m"
limits:
cpu: "400m"Nachher: resources:
requests:
cpu: "400m"
limits:
cpu: "400m" |
requests nicht festgelegt, limits nicht festgelegt |
Autopilot legt Das Verhalten für
Informationen dazu, ob Ihr Cluster Bursting unterstützt, finden Sie unter Bursting-Verfügbarkeit 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 Arbeitsspeicher: 0,5 GiB Sitzungsspezifischer Speicher: 10 MiB |
CPU: 50 mCPU Arbeitsspeicher: 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 Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB |
CPU: 30 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB |
| 2 | CPU: 10 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB |
CPU: 10 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB |
| 3 | CPU: 10 mvCPU Arbeitsspeicher: 0,5 GiB Sitzungsspezifischer Speicher: 10 MiB |
CPU: 10 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB |
| Pod-Ressourcen insgesamt | CPU: 50 mCPU Speicher: 1,5 GiB Sitzungsspezifischer Speicher: 30 MiB |
Einzelner Container mit zu wenig Arbeitsspeicher für die angeforderte CPU
In diesem Beispiel ist der Arbeitsspeicher 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 Flüchtiger Speicher: 10 MiB |
CPU: 4 vCPU Speicher: 4 GiB Flüchtiger Speicher: 10 MiB |
| Pod-Ressourcen insgesamt | CPU: 4 vCPU Speicher: 4 GiB Flüchtiger Speicher: 10 MiB |
Nächste Schritte
- Compute-Klassen in den Autopilot-Arbeitslasten auswählen
- Weitere Informationen zu den unterstützten Autopilot-Compute-Klassen
- GPUs in Autopilot-Pods auswählen