Pod-Bursting in GKE konfigurieren

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 nutzen, als ursprünglich angefordert.

Mit Kubernetes können Sie für Ihre Pods bestimmte Kapazitäten von Ressourcen wie CPU oder Arbeitsspeicher 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 Skalierbare Kapazität in GKE.

Vorteile des 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 Arbeitslastgruppen, die oft inaktiv sind und nur eine geringe Anzahl von Anfragen pro Sekunde senden. Gelegentlich kommt es jedoch zu Verkehrsspitzen und Sie würden von zusätzlichen Ressourcen profitieren, 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 von Ihnen bereitgestellten Rechenkapazität maximieren.

Mit Bursting können Sie nur die Ressourcen anfordern, die Ihr Pod während des Großteils seiner Laufzeit benötigt, und gleichzeitig dafür sorgen, dass Ihr Pod bei Bedarf mehr Ressourcen verbrauchen kann. Zu den Vorteilen von Bursting gehören:

• Niedrigere Betriebskosten: Sie müssen nicht den erwarteten Spitzenverbrauch der Arbeitslast anfordern. Ihre Anfragen können sich auf die niedrigeren Werte für den Steady State 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. Die Wahrscheinlichkeit ist höher, dass Ihre Arbeitslasten alle bezahlten Ressourcen nutzen.
• Verbesserte Leistung: Pods können bei Bedarf zusätzliche Ressourcen nutzen, um die Zeit für die Verarbeitung eingehender Anfragen zu verkürzen oder schneller zu starten, wenn die Kapazität erhöht wird.

Wann Bursting nicht verwendet werden sollte

Kubernetes weist Pods, die höhere Ressourcenlimits als ihre Anfragen angeben, die Burstable-Klasse für die Dienstqualität (Quality of Service, QoS) zu. 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 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.

• 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:

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 im Laufe der Zeit auf die Version der Steuerungsebene. Um Bursting zu aktivieren, ist ein Neustart der Steuerungsebene erforderlich. Dieser muss erfolgen, nachdem alle Knoten eine unterstützte Version und einen unterstützten cgroup-Modus 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 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. Prüfen Sie, ob in Ihrem Cluster cgroupv2 ausgeführt wird. Eine Anleitung finden Sie unter Cgroup-Modus prüfen.

  3. Starten Sie ein manuelles Upgrade der Steuerungsebene auf dieselbe Version, die bereits im Cluster verwendet wird.

     gcloud container clusters upgrade CLUSTER_NAME --master \
         --cluster-version CURRENT_CLUSTER_VERSION
     

     Ersetzen Sie Folgendes:

     • CLUSTER_NAME ist der Name Ihres vorhandenen Clusters.
     • CURRENT_CLUSTER_VERSION: die Version, die auf Ihrem Cluster ausgeführt wird.

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.

Burstfähige Arbeitslast bereitstellen

1. 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 zum Ausführen 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 bursten, 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 des Knotens hochskalieren. 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, um GKE anzuweisen, neue Knoten zum Ausführen der Pods mit automatischer Auslastung zu erstellen. 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 Mindestressourcenanforderungen für Pods mit Arbeitslasttrennung. Weitere Informationen finden Sie unter Arbeitslasttrennung in GKE konfigurieren und Ressourcenanfragen in Autopilot.

2. Arbeitslast bereitstellen:

   kubectl apply -f burstable-deployment.yaml
   

   Es kann einige Minuten dauern, bis die Arbeitslast gestartet wird.

3. So prüfen Sie die QoS-Klasse eines Pods:

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

   Die Ausgabe sieht so aus:

   QoS Class: Burstable
   

Bursting-fä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 eine bestimmte Maschinenreihe 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, wird die Bursting-Kapazität um die Anfragen dieses Pods reduziert. Der Teil der Bursting-Kapazität, der von laufenden Pods nicht verwendet wird, kann zugewiesen werden, wenn einer der Pods einen Burst benötigt.

  Autopilot fügt der Bursting-Kapazität außerdem einen vordefinierten Puffer hinzu, damit System-Pods auf dem Knoten, die über ihre Anfragen hinausgehen, Ihre eigenen Bursting-Pods nicht beeinträchtigen.

• Standardcluster: 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.

Best Practices für Bursting

Beachten Sie beim Bursting von Pods die folgenden Empfehlungen:

• Legen Sie für alle Pods, die wichtige Funktionen in Ihrer Umgebung bereitstellen, Ihre Ressourcenanfragen auf Ihre Limits fest. So erhalten diese Pods die Guaranteed-Klasse für die Kubernetes-Dienstqualität (Quality of Service, QoS).
• 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 an, damit Ihr Pod gestartet werden kann. 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 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 anhand eines Beispiel-Deployments mit den folgenden Pods veranschaulicht, wie das Bursting von Pods 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 MiB CPU, um ausgeführt zu werden. Das bedeutet, dass der Knoten eine verbleibende verfügbare Bursting-fähige Kapazität von 250 MiB hat.

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

• Pod 1 benötigt zusätzliche 300 MiB CPU: Er kann Bursting verwenden und 250 MiB CPU nutzen, was der verfügbaren Bursting-fähigen Kapazität entspricht. Der Knoten hat keine Bursting-fähige Kapazität mehr.
• Pod 2 benötigt zusätzliche 150 m CPU: Er kann bursten und zusätzliche 150 m CPU verwenden. Der Knoten hat dann noch 100 MiB an verfügbarer Bursting-fähige Kapazität.
• Pod 2 benötigt zusätzliche 200 m CPU: Er kann bis zu 150 m CPU belegen, was einer Gesamtauslastung von 250 m CPU für Pod 2 entspricht. 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, immer genügend Arbeitsspeicher für den normalen Pod-Betrieb anzufordern. Wenn ein Container für die normale Funktionsweise auf einen Speicherausbruch 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 wie Blitzverkäufen im Onlineshop zu reservieren. Andere Pods auf demselben Knoten können auf diese nicht verwendete reservierte Kapazität zugreifen, damit die Kapazität in der Zeit vor dem 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 Standard-Clustern

GKE Standard-Cluster unterstützen auch Pod-Bursts, indem die Limits höher als die Anfragen festgelegt oder keine Limits festgelegt werden. In Standardclustern müssen Sie jedoch Knotenpools mit der entsprechenden Ressourcenkapazität erstellen und konfigurieren, um Bursting zu unterstützen. Um die potenziellen Kosteneinsparungen durch Burstable Pods in Standardclustern zu erzielen, ist eine sorgfältigere Knotenplanung und ein besseres Bin-Packing für Pods erforderlich, 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. Wie Sie diesen Wert ermitteln, erfahren Sie unter GKE-Standardknotengrößen planen.

• Bei Standardclustern ist es wahrscheinlicher, dass die Knotenressourcennutzung einen Kubernetes-Auslagerungsgrenzwert erreicht, da GKE den Ressourcenverbrauch nicht automatisch begrenzt, wenn Sie keine Limits angeben. Pods, die den Arbeitsspeicher überlasten, werden daher mit höherer Wahrscheinlichkeit durch die Knotendruckauslagerung von Kubernetes beendet.

Nächste Schritte

• Zusätzliche Rechenkapazität für eine schnelle Pod-Skalierung bereitstellen
• Größe von GKE Standard-Arbeitslasten in großem Maßstab anpassen