Pod-Bursting in GKE konfigurieren

Autopilot Standard

Auf dieser Seite wird beschrieben, wie Sie Pods für Burst-Kapazität in verfügbaren nicht verwendeten Kapazitäten auf GKE-Knoten (Google Kubernetes Engine) konfigurieren.

Was ist Bursting?

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

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

Einige Arbeitslasten verwenden nicht 100% der angeforderten Ressourcen für ihre gesamte Laufzeit. Beispielsweise benötigt eine Arbeitslast, die während der Startphase zusätzliche CPU verbraucht, nicht dieselben Ressourcen für den normalen Betrieb. In diesen Situationen können Sie die Ressourcenlimits für Ihre Arbeitslast auf einen höheren Wert als die Ressourcenanfragen festlegen oder die Limits nicht festlegen. Mit GKE kann die Arbeitslast vorübergehend mehr Ressourcen nutzen, als in den Anfragen angegeben sind, sofern diese Kapazität verfügbar ist.

Weitere Informationen zur Funktionsweise dieses Prozesses in GKE finden Sie in diesem Dokument unter Funktionsweise von Bursting.

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. Beispielszenarien:

Sie haben Gruppen von Arbeitslasten, die häufig inaktiv sind und eine kleine Anzahl von Anfragen pro Sekunde senden. Gelegentlich kommt es jedoch zu Trafficspitzen und Sie würden von zusätzlichen Ressourcen profitieren, um diese Anfragen zu verarbeiten.
Ihre Arbeitslasten benötigen beim Start 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 Ihr Pod für den Großteil seiner Laufzeit benötigt, und sorgen gleichzeitig dafür, dass Ihr Pod bei Bedarf mehr Ressourcen verbrauchen kann. Das Bursting bietet unter anderem folgende Vorteile:

Niedrigere laufende Kosten: Sie müssen nicht den erwarteten maximalen Ressourcenverbrauch der Arbeitslast anfordern. Ihre Anfragen können sich auf die niedrigeren stabilen Status beziehen. In Autopilot zahlen Sie für die Summe Ihrer Pod-Ressourcenanfragen, sodass die laufenden Kosten niedriger sind.
Effizientere Ressourcennutzung: Sie vermeiden inaktive Rechenkapazität, da Ihre Pods nicht 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 verkürzen oder während einer vertikalen Skalierung schneller zu starten.

Wann kein Bursting verwendet werden sollte

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

Hinweise

Führen Sie die folgenden Aufgaben aus, 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.

Achten Sie darauf, dass Sie einen GKE Autopilot-Cluster mit Version 1.29.2-gke.1060000 oder höher oder eine beliebige Version eines GKE Standard-Clusters haben. Informationen zum Erstellen eines neuen Clusters finden Sie unter Autopilot-Cluster erstellen.

Bursting-Verfügbarkeit in GKE

Arbeitslasten können in den folgenden Situationen Bursts verursachen:

Bursting-Verfügbarkeit
GKE-Autopilot-Modus	Pods, die die Computing-Klasse "Performance" oder die Accelerator-Computing-Klasse verwenden, können in jeder GKE-Version Bursts ausführen, die diese Computing-Klasse unterstützen. In allen anderen Compute-Klassen und für Pods, die keine Compute-Klasse angeben, ist Bursting nur verfügbar, wenn der Cluster die beiden folgenden Bedingungen erfüllt: Sie haben den Cluster ursprünglich mit der GKE-Version 1.26 oder höher erstellt. Auf dem Cluster wird die GKE-Version 1.29.2-gke.1060000 oder höher ausgeführt. Diese Einschränkung besteht, da in Autopilot-Clustern für das Bursting cgroup v2 erforderlich ist. cgroup v2 ist nur in Clustern verfügbar, die ursprünglich mit Version 1.26 und höher erstellt wurden.
GKE-Standardmodus	Pods können in jeder GKE-Version Bursts ausführen.

Bursting-Verfügbarkeit

GKE-Autopilot-Modus

Pods, die die Computing-Klasse "Performance" oder die Accelerator-Computing-Klasse verwenden, können in jeder GKE-Version Bursts ausführen, die diese Computing-Klasse unterstützen.

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

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

Diese Einschränkung besteht, da in Autopilot-Clustern für das Bursting cgroup v2 erforderlich ist. cgroup v2 ist nur in Clustern verfügbar, die ursprünglich mit Version 1.26 und höher erstellt wurden.

GKE-Standardmodus

Pods können in jeder GKE-Version Bursts ausführen.

Autopilot-Cluster, die ursprünglich mit einer Version vor 1.26 erstellt und später auf 1.29.2-gke.1060000 und höher aktualisiert wurden, unterstützen kein Bursting. Führen Sie 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

Autopilot-Arbeitslasten können Bursting nur für CPU- und Arbeitsspeicheranfragen verwenden.
Autopilot-Steuerungsebenen und -Knoten müssen eine unterstützte GKE-Version verwenden. Wenn Sie Ihre Cluster vor Kurzem auf eine unterstützte Version aktualisiert haben, achten Sie darauf, dass auf Ihren Knoten diese Version ausgeführt wird, bevor Sie das Bursting verwenden.

Mit dem Cluster verbinden

Führen Sie dazu diesen Befehl aus:

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

Dabei gilt:

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:
      nodeSelector:
        pod-type: "non-critical"
      tolerations:
      - key: pod-type
        operator: Equal
        value: "non-critical"
        effect: NoSchedule
      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 Bursting zu ermöglichen:
- resources.requests: Die Ressourcen, die der Container benötigt. Setzen Sie diesen Wert auf die Kapazität, die der Container im stabilen Zustand benötigt.
- resources.limits: Die maximale Ressourcenkapazität, die der Container verwenden kann. Wenn Sie Limits festlegen, die höher als die Anfragen sind, können Pods das angegebene Limit erreichen, wenn diese Kapazität auf dem Knoten verfügbar ist. Wenn Sie dieses Feld weglassen, können die Pods Bursts bis zur verfügbaren Burst-Kapazität auf dem Knoten ausführen. 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. Weist GKE an, neue Knoten zu erstellen, um die Burst-fähigen 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. Weitere Informationen finden Sie unter Arbeitslasttrennung in GKE konfigurieren.
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
```

Bursting-Kapazität in GKE

Zur Vereinfachung des Pod-Bursting berechnet GKE die Bursting-Kapazität für jeden Knoten in einem Cluster. Diese Berechnung für einen bestimmten Knoten sieht so aus:

Autopilot-Cluster: 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 Burst-Kapazität um 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 ein Bursting durchführen muss.

Autopilot fügt der Burst-Kapazität auch einen vordefinierten Zwischenspeicher hinzu, damit alle System-Pods auf dem Knoten, die über ihre Anfragen hinausgehen, keine Auswirkungen auf Ihre eigenen Burst-fähigen Pods haben.
Standardcluster: Die gesamte Ressourcenkapazität, die auf der Knoten-VM verfügbar ist.

Best Practices für Bursting

Beachten Sie die folgenden Vorgehensweisen für Pod-Bursting:

Legen Sie Ihre Ressourcenanfragen auf die Limits für alle Pods fest, die wichtige Funktionen in Ihrer Umgebung bieten. Dadurch wird sichergestellt, dass diese Pods die Kubernetes-Dienstqualitätsklasse Guaranteed erhalten.
Achten Sie darauf, dass Sie das Arbeitsspeicher-Bursting nur auf Pods konfigurieren, die entfernt werden können, wenn Kubernetes Arbeitsspeicher auf dem Knoten zurückgewinnen muss.
Fordern Sie immer genügend Arbeitsspeicher an, damit der Pod starten kann. Verlassen Sie sich bei der Erfüllung Ihrer Bootanforderungen nicht auf das Arbeitsspeicher-Bursting.
Durch die Trennung von Arbeitslasten können Sie verhindern, dass Pods, die mehrere Bursts ihrer CPU-Anfragen überschreiten, kritische Arbeitslasten beeinträchtigen. So verhindern Sie, dass diese Pods neben Ihren kritischen Pods platziert werden.

Bursting-Kapazität in Autopilot-Knoten optimieren

Autopilot berechnet die Burst-Kapazität als Summe der Ressourcenanfragen aller Pods auf einem bestimmten Knoten, einschließlich System-Pods und DaemonSets. Sie können die Burst-Kapazität auf einem Knoten auf folgende Weise optimieren. Bursting ist jedoch opportunistisch und nicht garantiert.

Verwenden Sie die Pod-Affinität, um bestimmte Pods auf demselben Knoten zu platzieren, um die Burst-Kapazität auf Knoten für bestimmte Arbeitslasten zu erhöhen.
Damit auf jedem Knoten immer eine bestimmte Burst-Kapazität 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 Burst-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 Bursting-Gesamtkapazität auf dem Knoten beträgt 450 m CPU (die Summe der Ressourcenanfragen). Jeder Pod benötigt nur 100 m CPU zum Ausführen. Das bedeutet, dass der Knoten eine verbleibende verfügbare Burst-Kapazität von 250 m hat.

Betrachten Sie die folgenden Szenarien, in denen eine Trafficspitze auftritt:

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

Wie GKE Pods verarbeitet, die die Burst-Kapazität überschreiten

Wenn Ihre Burst-fähigen Pods versuchen, mehr Ressourcen als die Burst-Kapazität auf dem Knoten zu verwenden, führt GKE die folgenden Aktionen aus:

CPU: Wenn die CPU-Nutzung die Burst-fähige Kapazität überschreitet, drosselt GKE die CPU-Nutzung einiger Container, sodass alle Container auf dem Knoten die von ihnen angeforderte CPU erhalten.
Arbeitsspeicher: Wenn die Speichernutzung die Burst-Kapazität überschreitet, beendet GKE Container, um Arbeitsspeicher auf dem Knoten freizugeben. GKE beginnt mit der Beendigung ressourcenintensiver Container in Pods mit einer niedrigeren Dienstqualität.

Wir empfehlen, immer genügend Arbeitsspeicher für den normalen Pod-Betrieb anzufordern. Wenn ein Container die Abhängigkeit von Arbeitsspeicher-Bursting hat, um normal zu funktionieren, kann er wiederholt abstürzen, wenn dieser Speicher nicht verfügbar ist.

Pod-Bursting mit freier Kapazitätsbereitstellung 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 wie Onlinespeicher-Flash-Verkäufen zu reservieren. Andere Pods auf demselben Knoten können Bursts in diese nicht verwendete reservierte Kapazität ausführen, sodass die Kapazität in der Zeit bis zum Ereignis mit hohem Traffic nicht inaktiv ist. Sie können diese Kapazität mit verschiedenen 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-Standardclustern

GKE-Standardcluster unterstützen auch Pod-Bursting durch Festlegen von höheren Limits als die Anfragen oder durch Weglassen von Limits. In Standardclustern müssen Sie jedoch Knotenpools mit der entsprechenden Ressourcenkapazität erstellen und konfigurieren, um das Bursting zu unterstützen. Das Erzielen der potenziellen Kostensenkung von Bursting-Pods in Standardclustern erfordert eine sorgfältigere Knotenplanung und Pod-bin-packing, da Sie für die zugrunde liegenden Compute Engine-VMs bezahlen.

Berücksichtigen Sie in Standardclustern Folgendes:

Das maximale Ressourcenverbrauchslimit, das die Kubernetes-Bereinigung oder die CPU-Drosselung auslöst, ist die zuweisbare Ressourcenkapazität auf dem Knoten. Informationen zum Ermitteln dieses Werts finden Sie unter Größen von GKE-Standardknoten 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 Arbeitsspeicher übertragen werden, werden daher eher von der Knotendruckbereinigung von Kubernetes beendet.