Pod-Bursting in GKE konfigurieren

Auf dieser Seite wird beschrieben, wie Sie Pods so konfigurieren, dass sie auf die verfügbare, nicht verwendete Kapazität auf Google Kubernetes Engine-Knoten (GKE) zugreifen.

Was ist Bursting?

Bursting beschreibt die Aktion von Pods, vorübergehend mehr Rechenkapazität auf dem Knoten zu verwenden, 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. Sie legen diese Anfragen in Ihrem Pod-Manifest fest. Der Kubernetes-Scheduler platziert Ihre Pods auf Knoten, die genügend Kapazität haben, um diese Ressourcenanfragen zu erfüllen.

Einige Arbeitslasten verwenden nicht 100% der angeforderten Ressourcen für die gesamte Laufzeit. Eine Arbeitslast, die während des Bootvorgangs zusätzliche CPU-Kapazität verbraucht, benötigt beispielsweise für den normalen Betrieb möglicherweise nicht dieselbe Menge an Ressourcen. 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. GKE ermöglicht es der Arbeitslast, vorübergehend mehr Ressourcen zu verwenden, als Sie in den Anfragen angegeben haben, wenn diese Kapazität verfügbar ist.

Weitere Informationen zur Funktionsweise dieses Prozesses in GKE finden Sie auf dieser Seite unter Bursting-fähige 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. Beispielszenarien:

• Sie haben Gruppen von Arbeitslasten, die oft im Leerlauf sind und eine geringe Anzahl von Anfragen pro Sekunde senden, aber gelegentlich Trafficspitzen aufweisen und von zusätzlichen Ressourcen profitieren würden, um diese Anfragen zu verarbeiten.
• Ihre Arbeitslasten benötigen während des Starts mehr Ressourcen als im normalen Betrieb.
• Sie möchten die Nutzung der von Ihnen bereitgestellten Rechenkapazität maximieren.

Mit Bursting können Sie nur die Ressourcen anfordern, die Ihr Pod für den Großteil seiner Laufzeit benötigt. Außerdem wird sichergestellt, dass Ihr Pod bei Bedarf mehr Ressourcen verbrauchen kann. Vorteile des Bursting:

• Geringere Betriebskosten: Sie müssen nicht den erwarteten Spitzenverbrauch an Ressourcen der Arbeitslast anfordern. Ihre Anfragen können für die niedrigeren Werte im stabilen Zustand gelten. In Autopilot zahlen Sie für die Summe Ihrer Pod-Ressourcenanfragen, sodass Ihre Betriebskosten niedriger sind.
• Effizientere Ressourcennutzung: Sie vermeiden ungenutzte Rechenkapazität, da Ihre Pods auf nicht verwendete Kapazität zugreifen. Ihre Arbeitslasten verwenden mit größerer Wahrscheinlichkeit alle Ressourcen, für die Sie bezahlt haben.
• Verbesserte Leistung: Pods können bei Bedarf zusätzliche Ressourcen verwenden, um die Zeit für die Verarbeitung eingehender Anfragen zu verkürzen oder bei Skalierungsereignissen schneller zu starten.

Fälle, in denen Bursting nicht verwendet werden sollte

Kubernetes weist Pods, die höhere Ressourcenlimits als ihre Anfragen angeben, die Dienstqualitätsklasse (Quality of Service, QoS) Burstable zu. Es ist wahrscheinlicher, dass Burstable-QoS-Pods entfernt werden, wenn Kubernetes Ressourcen auf dem Knoten freigeben muss. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Burstable-Dienstqualitätklasse.

Hinweis

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, installieren und dann initialisieren Sie die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem gcloud components update Befehl ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.

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

Verfügbarkeit von Bursting in GKE

Arbeitslasten können in den folgenden Situationen Bursts verursachen:

Einschränkungen

• Autopilot-Arbeitslasten können Bursting nur für CPU- und Arbeitsspeicheranfragen verwenden.

• Wenn Sie ein Upgrade eines Autopilot-Clusters auf eine unterstützte Version durchführen, aktualisiert GKE die Worker-Knoten im Laufe der Zeit auf die Version der Steuerungsebene. Ein Neustart der Steuerungsebene ist erforderlich, um Bursting zu aktivieren. Dies muss erfolgen, nachdem auf allen Knoten eine unterstützte Version und ein unterstützter cgroup-Modus ausgeführt werden. Die Steuerungsebene wird etwa einmal pro Woche automatisch neu gestartet, z. B. bei Skalierungen, Upgrades oder Wartungen.

  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
     

     In der Ausgabe muss für alle Knoten die erforderliche Version oder höher angezeigt werden.

  2. Prüfen Sie, ob auf Ihrem Cluster cgroupv2 ausgeführt wird. Eine Anleitung finden Sie unter cgroup-Modus prüfen.

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

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

     Ersetzen Sie dabei Folgendes:

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

Prüfen, ob Ihr Cluster Bursting unterstützt

Bursting ist in Clustern im Standardmodus und für Arbeitslasten im Autopilot-Modus, die Beschleuniger oder bestimmte Maschinenserien anfordern, immer aktiviert. Fahren Sie mit dem Abschnitt Bursting-fähige Arbeitslast bereitstellen fort.

Die folgenden Arten von Autopilot-Arbeitslasten können nur dann Bursts verursachen, wenn ein von GKE verwaltetes DaemonSet mit dem Namen efficiency-daemon im Cluster ausgeführt wird:

• Autopilot-Pods, die die Scale-Out oder Balanced vordefinierten Compute-Klassen anfordern.
• Autopilot-Pods, die keine Compute-Klasse anfordern.

GKE stellt das efficiency-daemon DaemonSet bereit, wenn Ihr Autopilot-Cluster die Anforderungen für Bursting erfüllt, wie in dem Abschnitt Verfügbarkeit von Bursting in GKE beschrieben.

Führen Sie den folgenden Befehl aus, um zu prüfen, ob das DaemonSet efficiency-daemon in Ihrem Cluster vorhanden ist:

kubectl get daemonset --namespace=kube-system efficiency-daemon

Die Ausgabe sieht in etwa so aus:

NAME                DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
efficiency-daemon   1         1         1       1            1           <none>          105d

Wenn die Ausgabe leer ist, prüfen Sie, ob der Cluster alle Anforderungen und Einschränkungen im Abschnitt Vorbereitung erfüllt.

Bursting-fä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 hat die folgenden Felder, um Bursting zu aktivieren:

   • resources.requests: Die Ressourcen, die der Container für die Funktion benötigt. Legen Sie diesen Wert auf die Kapazität fest, die Ihr Container im stabilen Zustand benötigt.
   • resources.limits: Die maximale Ressourcenkapazität, die der Container verwenden kann. Wenn Sie die Limits höher als die Anfragen festlegen, können Pods bis zum angegebenen Limit Bursts verursachen, wenn diese Kapazität auf dem Knoten verfügbar ist. Wenn Sie dieses Feld weglassen, können die Pods bis zur verfügbaren Bursting-fähigen Kapazität auf dem Knoten Bursts verursachen. 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 Bursting-fähigen Pods zu erstellen. GKE wendet auf diese neuen Knoten Markierungen an, um zu verhindern, dass andere Pods, z. B. 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.

2. Arbeitslast bereitstellen:

   kubectl apply -f burstable-deployment.yaml
   

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

3. QoS-Klasse eines Pods prüfen:

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

   Die Ausgabe sieht so aus:

   QoS Class: Burstable
   

Bursting-fähige Kapazität in GKE

Um Pod-Bursting zu ermöglichen, berechnet GKE die Bursting-fähige Kapazitä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 Maschinenserien anfordern: Die zuweisbare Ressourcenkapazität des Knotens, d. h. die Kapazität, die für die Arbeitslastnutzung verfügbar ist. Weitere Informationen finden Sie unter Zuweisbare Knotenressourcen.
  • 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, verringert sich die Bursting-fähige Kapazität um die Anfragen dieses Pods. Der Teil der Bursting-fähigen Kapazität, der nicht von ausgeführten Pods verwendet wird, kann zugewiesen werden, wenn einer der Pods Bursts verursachen muss.

  Autopilot fügt der Bursting-fähigen Kapazität auch einen vordefinierten Puffer hinzu, damit alle System-Pods auf dem Knoten, die Bursts über ihre Anfragen hinaus verursachen, Ihre eigenen Bursting-fähigen Pods nicht beeinträchtigen.

• Standardcluster: Die zuweisbare Ressourcenkapazität des Knotens, d. h. die Kapazität, die für die Arbeitslastnutzung verfügbar ist. Weitere Informationen finden Sie unter Zuweisbare Knotenressourcen.

Best Practices für Bursting

Verwenden Sie die folgenden Best Practices für Pod-Bursting:

• Legen Sie für alle Pods, die kritische Funktionen in Ihrer Umgebung bereitstellen, die Ressourcenanfragen auf die Limits fest. So wird sichergestellt, dass diese Pods die Kubernetes-Dienstqualitätsklasse (Quality of Service, QoS) Guaranteed erhalten.
• Konfigurieren Sie Arbeitsspeicher-Bursting nur für Pods, die entfernt werden können, wenn Kubernetes Arbeitsspeicher auf dem Knoten freigeben 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-fähige 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 ein Beispiel-Deployment mit den folgenden Bursting-fähigen Pods verwendet, um zu veranschaulichen, 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 gesamte Bursting-fähige Kapazität auf dem Knoten beträgt 450 m CPU (die Summe der Ressourcenanfragen). Jeder Pod verwendet nur 100 m CPU für die Ausführung, was bedeutet, dass der Knoten eine verbleibende Bursting-fähige Kapazität von 250 m hat.

Sehen Sie sich die folgenden Szenarien an, in denen eine Trafficspitze auftritt:

• Pod 1 benötigt zusätzliche 300 m CPU: Er kann Bursts verursachen und 250 m CPU verwenden, 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 Bursts verursachen 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 Bursts verursachen und 150 m CPU verwenden, wodurch die Gesamtnutzung für Pod 2 auf 250 m CPU steigt. Pod 2 hat ein CPU-Limit von 250 m und kann nicht über dieses Limit hinaus Bursts verursachen.

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. GKE beendet zuerst ressourcenintensive Container in Pods mit einer niedrigeren QoS.

Wir empfehlen, immer genügend Arbeitsspeicher für den normalen Pod-Betrieb anzufordern. Wenn ein Container für die normale Funktion auf Arbeitsspeicher-Bursting angewiesen ist, kann er wiederholt abstürzen, wenn dieser Arbeitsspeicher nicht verfügbar ist.

Pod-Bursting mit Bereitstellung von freier Kapazität verwenden

Mit GKE können Sie Pods im Leerlauf bereitstellen, um zusätzliche Rechenkapazität für eine schnellere Pod-Skalierung bei zukünftigen Trafficspitzen wie Flash-Sales in Onlineshops zu reservieren. Andere Pods auf demselben Knoten können auf diese nicht verwendete reservierte Kapazität zugreifen, sodass die Kapazität in der Zeit bis zum Ereignis mit hohem Traffic nicht im Leerlauf 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-Bursting, indem die Limits höher als die Anfragen festgelegt oder Limits weggelassen werden. In Standard-Clustern müssen Sie jedoch Knotenpools mit der entsprechenden Ressourcenkapazität erstellen und konfigurieren, um Bursting zu unterstützen. Um die potenziellen Kosteneinsparungen von Bursting-fähigen Pods in Standard-Clustern zu erzielen, ist eine sorgfältigere Knotenplanung und Bin-Packing von Pods erforderlich, da Sie für die zugrunde liegenden Compute Engine-VMs bezahlen.

Beachten Sie in Standard-Clustern Folgendes:

• Das Limit für den maximalen Ressourcenverbrauch, das die Kubernetes-Entfernung oder die CPU-Drosselung auslöst, ist die zuweisbare Ressourcenkapazität auf dem Knoten. Informationen zum Bestimmen dieses Werts finden Sie unter GKE-Standardknotengrößen planen.

• Die Knotenauslastung in Standard-Clustern erreicht mit größerer Wahrscheinlichkeit einen Kubernetes-Entfernungsschwellenwert, da GKE den Ressourcenverbrauch nicht automatisch begrenzt, wenn Sie keine Limits angeben. Pods, die auf Arbeitsspeicher zugreifen, werden daher mit größerer Wahrscheinlichkeit durch die Kubernetes Entfernung aufgrund von Knotendruck beendet.

Nächste Schritte

• Informationen zum Bereitstellen zusätzlicher Rechenkapazität für eine schnelle Pod-Skalierung
• Informationen zum Anpassen der Größe von GKE Standard-Arbeitslasten in großem Maßstab
• Informationen zur Fehlerbehebung bei Autopilot-Clustern.