Pod-Bursting in GKE konfigurieren

Autopilot Standard

Auf dieser Seite erfahren Sie, wie Sie Pods so konfigurieren, dass sie die verfügbare, ungenutzte Kapazität auf GKE-Knoten (Google Kubernetes Engine) nutzen.

Was ist Bursting?

Bursting beschreibt die Aktion von Pods, die vorübergehend mehr Rechenkapazität auf dem Knoten verwenden, als ursprünglich angefordert wurde.

Mit Kubernetes können Sie bestimmte Kapazitäten von Ressourcen wie CPU oder Arbeitsspeicher für Ihre Pods anfordern. Sie legen diese Anfragen in Ihrem Pod-Manifest fest. Der Kubernetes-Planer platziert Ihre Pods auf Knoten, die genügend Kapazität haben, um diese Ressourcenanfragen zu erfüllen.

Einige Arbeitslasten nutzen nicht während der gesamten Laufzeit 100 % der angeforderten Ressourcen. Eine Arbeitslast, die während des Startvorgangs zusätzliche CPU-Ressourcen verbraucht, benötigt für den normalen Betrieb möglicherweise nicht die gleiche Menge an Ressourcen. In diesen Fällen können Sie die Limits für Ihre Arbeitslast auf einen höheren Wert als die Ressourcenanfragen festlegen oder die Limits nicht festlegen. In GKE kann die Arbeitslast vorübergehend mehr Ressourcen nutzen, als Sie in den Anfragen angegeben haben, sofern diese Kapazität verfügbar ist.

Weitere Informationen zur Funktionsweise dieses Prozesses in GKE finden Sie auf dieser Seite unter Bursting-Kapazität in GKE.

Vorteile von Pod-Bursting

Bursting ist nützlich, wenn Ihre Pods nur für kurze Zeit zusätzliche Ressourcen benötigen, um Spitzen bei der Ressourcennutzung zu bewältigen. Beispiele für solche Szenarien:

Sie haben Gruppen von Arbeitslasten, die häufig inaktiv sind und eine kleine Anzahl von Anfragen pro Sekunde senden, aber gelegentlich Trafficspitzen feststellen und von zusätzlichen Ressourcen profitieren würden, um diese Anfragen zu verarbeiten.
Ihre Arbeitslasten benötigen während des Starts mehr Ressourcen als während des normalen Betriebs.
Sie möchten die Nutzung der bereitgestellten Rechenkapazität maximieren.

Bursting ermöglicht es Ihnen, nur die Ressourcen anzufordern, die der Pod für den Großteil der Laufzeit benötigt, und sorgen gleichzeitig dafür, dass der Pod bei Bedarf mehr Ressourcen verbrauchen kann. Das Bursting bietet unter anderem folgende Vorteile:

Niedrigere laufenden Kosten: Sie müssen den erwarteten maximalen Ressourcenverbrauch der Arbeitslast nicht anfordern. Ihre Anfragen können sich auf die niedrigeren stabilen Werte beziehen. In Autopilot zahlen Sie die Summe Ihrer Pod-Ressourcenanfragen, sodass Ihre laufenden Kosten niedriger sind.
Effizientere Ressourcennutzung: Sie vermeiden inaktive Rechenkapazität, da Ihre Pods auf nicht verwendete Kapazitäten zugreifen. Ihre Arbeitslasten verwenden mit höherer Wahrscheinlichkeit alle kostenpflichtigen Ressourcen.
Verbesserte Leistung: Pods können bei Bedarf zusätzliche Ressourcen verwenden, um die Zeit für die Verarbeitung eingehender Anfragen zu reduzieren oder um während einer vertikalen Skalierung schneller zu starten.

Wann sollte Bursting nicht verwendet werden?

Kubernetes weist Pods, die höhere Ressourcenlimits als ihre Anfragen angeben, die Klasse "Dienstqualität" zu.Burstable Burstable QoS-Pods werden mit höherer Wahrscheinlichkeit entfernt, wenn Kubernetes Ressourcen auf dem Knoten zurückfordern muss. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Burstable-Dienstqualitätklasse.

Hinweise

Führen Sie die folgenden Schritte durch, bevor Sie beginnen:

Aktivieren Sie die Google Kubernetes Engine API.

Google Kubernetes Engine API aktivieren

Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

Sie benötigen einen GKE Autopilot-Cluster mit Version 1.30.2-gke.1394000 oder höher oder eine beliebige Version eines GKE-Standardclusters. Informationen zum Erstellen eines neuen Clusters finden Sie unter Autopilot-Cluster erstellen.

Bursting-Verfügbarkeit in GKE

In den folgenden Fällen kann es zu einem Ausstoß von Arbeitslasten kommen:

Bursting-Verfügbarkeit
GKE-Autopilot-Modus	Pods, die die Computing-Klasse "Leistung" oder die Compute-Klasse "Accelerator" verwenden, können in jeder GKE-Version, die diese Computing-Klasse unterstützt, Bursts erzeugen. In allen anderen Compute-Klassen und für Pods, für die keine Compute-Klasse angegeben ist, ist Bursting nur verfügbar, wenn der Cluster beide der folgenden Bedingungen erfüllt: Sie haben den Cluster ursprünglich mit GKE-Version 1.26 oder höher erstellt. Auf dem Cluster wird die GKE-Version 1.30.2-gke.1394000 oder höher ausgeführt. Diese Einschränkung ist darauf zurückzuführen, dass in Autopilot-Clustern Bursting cgroup v2 erfordert. cgroup v2 ist nur in Clustern verfügbar, die ursprünglich mit Version 1.26 oder höher erstellt wurden.
GKE-Standardmodus	Pods können in jeder GKE-Version Bursts verwenden.

Bursting-Verfügbarkeit

GKE-Autopilot-Modus

Pods, die die Computing-Klasse "Leistung" oder die Compute-Klasse "Accelerator" verwenden, können in jeder GKE-Version, die diese Computing-Klasse unterstützt, Bursts erzeugen.

In allen anderen Compute-Klassen und für Pods, für die keine Compute-Klasse angegeben ist, ist Bursting nur verfügbar, wenn der Cluster beide der folgenden Bedingungen erfüllt:

Sie haben den Cluster ursprünglich mit GKE-Version 1.26 oder höher erstellt.
Auf dem Cluster wird die GKE-Version 1.30.2-gke.1394000 oder höher ausgeführt.

Diese Einschränkung ist darauf zurückzuführen, dass in Autopilot-Clustern Bursting cgroup v2 erfordert. cgroup v2 ist nur in Clustern verfügbar, die ursprünglich mit Version 1.26 oder höher erstellt wurden.

GKE-Standardmodus

Pods können in jeder GKE-Version Bursts verwenden.

Autopilot-Cluster, die ursprünglich mit einer Version vor 1.26 erstellt wurden und später auf 1.29.2-gke.1060000 oder höher aktualisiert wurden, unterstützen kein Bursting. Führen Sie den folgenden Befehl aus, um die ursprüngliche Clusterversion zu prüfen:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(initialClusterVersion)"

Die Ausgabe muss die GKE-Version 1.26 oder höher sein.

Beschränkungen

Bei Autopilot-Arbeitslasten kann Bursting nur für CPU- und Arbeitsspeicheranfragen verwendet werden.
Wenn Sie einen Autopilot-Cluster auf eine unterstützte Version aktualisieren, aktualisiert GKE die Worker-Knoten so, dass sie im Laufe der Zeit mit der Version der Steuerungsebene übereinstimmen. Um Bursting zu aktivieren, ist ein Neustart der Steuerebene erforderlich. Dieser muss erfolgen, nachdem alle Knoten eine unterstützte Version ausführen. Die Steuerungsebene wird etwa einmal pro Woche automatisch neu gestartet, wenn Vorgänge wie Skalierung, Upgrades oder Wartung ausgeführt werden.

So starten Sie die Steuerungsebene manuell neu:
1. Prüfen Sie, ob auf allen Knoten die Version 1.30.2-gke.1394000 oder höher ausgeführt wird:
```
kubectl get nodes
```
  Die Ausgabe sieht in etwa so aus:
```
NAME                                          STATUS   ROLES    AGE     VERSION
gk3-ap-cluster-1-default-pool-18092e49-mllk   Ready    <none>   4m26s   v1.30.2-gke.1349000
```
  Alle Knoten in der Ausgabe müssen die erforderliche Version oder höher haben.
2. Starten Sie manuell ein Upgrade der Steuerungsebene auf dieselbe Version, die der Cluster bereits verwendet. Eine Anleitung finden Sie unter Manuelles Upgrade der Steuerungsebene.

Mit dem Cluster verbinden

Führen Sie dazu diesen Befehl aus:

gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION

Ersetzen Sie dabei Folgendes:

CLUSTER_NAME ist der Name Ihres vorhandenen Clusters.
LOCATION: Der Standort Ihres Clusters.

Bursting-fähige Arbeitslast bereitstellen

Speichern Sie das folgende Manifest als burstable-deployment.yaml:
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
      tier: web
  template:
    metadata:
      labels:
        app: hello
        tier: web
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 250m
          limits:
            cpu: 350m
```
Dieses Manifest enthält die folgenden Felder, um das Bursting zu aktivieren:
- resources.requests: Die Ressourcen, die der Container für seine Funktion benötigt. Legen Sie diesen Wert auf die Kapazität fest, die Ihr Container im Steady State benötigt.
- resources.limits: Die maximale Ressourcenkapazität, die der Container nutzen kann. Wenn Sie die Limits höher als die Anfragen festlegen, können Pods bis zum angegebenen Limit zugreifen, sofern diese Kapazität auf dem Knoten verfügbar ist. Wenn Sie dieses Feld weglassen, können die Pods bis zur verfügbaren Burst-Kapazität auf dem Knoten einen Burst erreichen. Diese Kapazität wird so berechnet:
  - Autopilot-Modus: Nicht verwendete Kapazität in der Summe der Ressourcenanfragen von Pods auf dem Knoten.
  - Standardmodus: Nicht verwendete Kapazität in den Knotenressourcen.
- spec.nodeSelector und spec.tolerations: Optional. Fügen Sie diese Felder mit benutzerdefinierten Labels wie pod-type: "non-critical" hinzu, damit GKE neue Knoten erstellen soll, um die Bursting-Pods auszuführen. GKE wendet Markierungen auf diese neuen Knoten an, um zu verhindern, dass andere Pods wie kritische Arbeitslasten auf denselben Knoten ausgeführt werden. Autopilot erzwingt höhere Mindestressourcenanfragen für Pods, die die Arbeitslasttrennung verwenden. Weitere Informationen finden Sie unter Arbeitslasttrennung in GKE konfigurieren und Ressourcenanfragen in Autopilot.
Arbeitslast bereitstellen:
```
kubectl apply -f burstable-deployment.yaml
```
Der Start der Arbeitslast kann einige Minuten dauern.

Prüfen Sie die Dienstqualitätsklasse eines Pods:

kubectl describe pod helloweb | grep -m 1 "QoS"

Die Ausgabe sieht so aus:

QoS Class: Burstable

Burstfähige Kapazität in GKE

Um das Pod-Bursting zu ermöglichen, berechnet GKE die Skalierungskapazität für jeden Knoten in einem Cluster. Diese Berechnung für einen bestimmten Knoten sieht so aus:

Autopilot-Cluster:
- Pods, die Beschleuniger oder bestimmte Maschinenreihen anfordern: Die zuweisbare Ressourcenkapazität des Knotens, also die Kapazität, die für die Arbeitslastnutzung verfügbar ist. Weitere Informationen finden Sie unter Zuweisbare Ressourcen für Knoten.
- Alle anderen Pods: Die Summe der Ressourcenanfragen aller Pods auf diesem Knoten, unabhängig von der tatsächlichen Ressourcenkapazität des Knotens. Wenn ein Pod beendet wird, reduziert sich die Bursting-Kapazität durch die Anfragen dieses Pods. Der Teil der Bursting-Kapazität, der nicht von ausgeführten Pods verwendet wird, kann zugewiesen werden, wenn einer der Pods Bursts erzeugen muss.
Autopilot fügt der Bursting-Kapazität außerdem einen vordefinierten Puffer hinzu, sodass alle System-Pods auf dem Knoten, die über ihre Anfragen hinausgehen, keine Auswirkungen auf Ihre eigenen Burst-fähigen Pods haben.
Standardcluster: Die zuweisbare Ressourcenkapazität für den Knoten. Dies ist die Kapazität, die für die Arbeitslastnutzung verfügbar ist. Weitere Informationen finden Sie unter Zuweisbare Ressourcen für Knoten.

Best Practices für Bursting

Beachten Sie beim Pod-Bursting die folgenden Vorgehensweisen:

Legen Sie für alle Pods, die wichtige Funktionen in Ihrer Umgebung bereitstellen, Ihre Ressourcenanfragen auf Ihre Limits fest. Dadurch wird sichergestellt, dass diese Pods die Kubernetes-Dienstqualitätsklasse Guaranteed erhalten.
Konfigurieren Sie den Speicherausbruch nur für Pods, die damit umgehen können, dass sie entfernt werden, wenn Kubernetes Speicher auf dem Knoten zurückfordern muss.
Fordern Sie immer genügend Arbeitsspeicher zum Starten des Pods an. Verlass dich nicht auf Arbeitsspeicher-Bursting, um deine Bootanforderungen zu erfüllen.
Verwenden Sie die Arbeitslasttrennung, um zu verhindern, dass Bursting-fähige Pods, die kontinuierlich in mehrere ihrer CPU-Anfragen zugreifen, kritische Arbeitslasten unterbrechen. So können Sie diese Pods nicht neben Ihren kritischen Pods platzieren.

Bursting-fähige Kapazität in Autopilot-Knoten optimieren

Autopilot berechnet die Bursting-Kapazität als Summe der Ressourcenanfragen aller Pods auf einem bestimmten Knoten, einschließlich System-Pods und DaemonSets. Sie haben folgende Möglichkeiten, die Bursting-fähige Kapazität auf einem Knoten zu optimieren: Bursting ist jedoch opportunistisch und wird nicht garantiert.

Verwenden Sie die Pod-Affinität, um bestimmte Pods auf demselben Knoten zu platzieren. Dadurch können Sie die Bursting-fähige Kapazität auf Knoten für bestimmte Arbeitslasten erhöhen.
Damit eine bestimmte Bursting-fähige Kapazität immer auf jedem Knoten verfügbar ist, erstellen Sie DaemonSets, die auf allen Knoten im Cluster ausgeführt werden.

Beispiel für die Funktionsweise von Bursting

In diesem Abschnitt wird ein Beispiel-Deployment mit den folgenden Bursting-fähigen Pods verwendet, um zu zeigen, wie Pod-Bursting in GKE Autopilot-Clustern funktioniert:

Pod 1 fordert 250 m CPU an und hat kein CPU-Limit. Pod 1 benötigt 100 m CPU, um ausgeführt zu werden.
Pod 2 fordert 200 m CPU an und hat ein CPU-Limit von 250 m. Pod 2 benötigt 100 m CPU, um ausgeführt zu werden.

Beide Pods werden auf demselben Knoten ausgeführt. Die Gesamtkapazität für Bursting auf dem Knoten beträgt 450 MiB CPU (Summe der Ressourcenanfragen). Jeder Pod benötigt nur 100 m CPU, um ausgeführt zu werden, d. h., der Knoten hat eine verbleibende verfügbare Bursting-Kapazität von 250 m.

Anhand der folgenden Szenarien können Sie nachvollziehen, wann ein Traffic-Anstieg auftritt:

Pod 1 benötigt zusätzliche 300 m CPU: Er kann Bursts verwenden und 250 m CPU nutzen, was die verfügbare Burst-Kapazität ist. Der Knoten hat keine Bursting-fähige Kapazität mehr.
Pod 2 benötigt zusätzliche 150 mCPU: Er kann Bursts verwenden und zusätzliche 150 mCPU nutzen. Der Knoten hat dann noch 100 MiB an verfügbarer Bursting-fähige Kapazität.
Pod 2 benötigt zusätzliche 200 MB CPU: Er kann bei Bedarf 150 MB CPU nutzen, was eine Gesamtnutzung von 250 MB CPU für Pod 2 ergibt. Pod 2 hat ein CPU-Limit von 250 m und kann dieses Limit nicht überschreiten.

Umgang von GKE mit Pods, die die Bursting-fähige Kapazität überschreiten

Wenn Ihre Pods mit automatischer Auslastung versuchen, mehr Ressourcen zu nutzen als die Bursting-fähige Kapazität des Knotens, ergreift GKE die folgenden Maßnahmen:

CPU: Wenn die CPU-Auslastung die Bursting-fähige Kapazität überschreitet, drosselt GKE die CPU-Auslastung einiger Container, damit alle Container auf dem Knoten die angeforderte CPU erhalten.
Speicher: Wenn die Speichernutzung die Bursting-fähige Kapazität überschreitet, beendet GKE Container, um Speicher auf dem Knoten freizugeben. In GKE werden zuerst ressourcenintensive Container in Pods mit einer niedrigeren QoS beendet.

Wir empfehlen, dass Sie immer genügend Arbeitsspeicher für den normalen Pod-Betrieb anfordern. Wenn ein Container für die normale Funktionsweise auf eine Speicherausweitung angewiesen ist, stürzt er möglicherweise wiederholt ab, wenn dieser Speicher nicht verfügbar ist.

Pod-Bursting mit Bereitstellung freier Kapazität verwenden

Mit GKE können Sie inaktive Pods bereitstellen, um zusätzliche Rechenkapazität für eine schnellere Pod-Skalierung bei zukünftigen Ereignissen mit hohem Traffic, z. B. bei Blitzverkäufen, zu reservieren. Andere Pods auf demselben Knoten können Bursts auf diese nicht verwendete reservierte Kapazität verbrauchen, sodass die Kapazität in der Zeit vor dem Ereignis mit hohem Traffic nicht inaktiv ist. Sie können diese Kapazität mithilfe verschiedener Kubernetes-Mechanismen reservieren. Sie können beispielsweise Pods mit einer niedrigen PriorityClass bereitstellen. Weitere Informationen finden Sie unter Zusätzliche Rechenkapazität für eine schnelle Pod-Skalierung bereitstellen.

Pod-Bursting in GKE Standard-Clustern

GKE-Standardcluster unterstützen auch Pod-Bursting. Dazu werden die Limits höher als die Anfragen festgelegt oder die Limits werden weggelassen. In Standardclustern müssen Sie jedoch Knotenpools mit der entsprechenden Ressourcenkapazität erstellen und konfigurieren, um das Bursting zu unterstützen. Eine potenzielle Kostensenkung von Bursting-fähigen Pods in Standard-Clustern erfordert eine sorgfältigere Knotenplanung und ein Pod-Bin-Packing, da Sie für die zugrunde liegenden Compute Engine-VMs bezahlen.

Beachten Sie bei Standardclustern Folgendes:

Das Limit für den maximalen Ressourcenverbrauch, das das Auslagern von Kubernetes oder die CPU-Drosselung auslöst, ist die zuweisbare Ressourcenkapazität auf dem Knoten. Informationen zum Ermitteln dieses Werts finden Sie unter GKE-Standardknotengrößen planen.
Die Nutzung von Knotenressourcen in Standardclustern erreicht mit größerer Wahrscheinlichkeit einen Kubernetes-Bereinigungsgrenzwert, da GKE den Ressourcenverbrauch nicht automatisch begrenzt, wenn Sie keine Limits angeben. Pods, die in den Speicher gelangen, werden daher wahrscheinlicher durch die Bereinigung des Kubernetes-Knotendrucks beendet.