Pod-Bursting in GKE konfigurieren

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

Was ist Bursting?

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

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-Scheduler platziert Ihre Pods auf Knoten, die genügend Kapazität für diese Ressourcenanforderungen haben.

Bei einigen Arbeitslasten werden nicht während der gesamten Laufzeit 100% der angeforderten Ressourcen verwendet. Eine Arbeitslast, die während des Bootvorgangs zusätzliche CPU-Ressourcen benötigt, erfordert für den normalen Betrieb möglicherweise nicht dieselbe Menge an Ressourcen. In diesen Fällen 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 verwenden, 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 Burstable Capacity 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 nur wenige Anfragen pro Sekunde senden, aber gelegentlich Trafficspitzen aufweisen und von zusätzlichen Ressourcen zur Verarbeitung dieser Anfragen profitieren würden.
• Ihre Arbeitslasten benötigen während des Starts mehr Ressourcen als im Normalbetrieb.
• Sie möchten die bereitgestellte Rechenkapazität optimal nutzen.

Mit Bursting können Sie nur die Ressourcen anfordern, die Ihr Pod für den Großteil seiner Laufzeit benötigt. Gleichzeitig wird dafür gesorgt, dass Ihr Pod bei Bedarf mehr Ressourcen nutzen kann. Das Bursting bietet unter anderem folgende Vorteile:

• Geringere Betriebskosten: Sie müssen nicht den erwarteten Spitzenressourcenverbrauch der Arbeitslast anfordern. Ihre Anfragen können sich auf die niedrigeren Steady-State-Werte beziehen. 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 (Burst). Ihre Arbeitslasten nutzen mit höherer Wahrscheinlichkeit alle Ihre bezahlten Ressourcen.
• Verbesserte Leistung: Pods können bei Bedarf zusätzliche Ressourcen nutzen, um die Zeit für die Verarbeitung eingehender Anfragen zu verkürzen oder bei Scale-up-Ereignissen schneller zu starten.

Wann Bursting nicht verwendet werden sollte

Kubernetes weist Pods, für die höhere Ressourcenlimits als ihre Anforderungen angegeben sind, die Burstable-QoS-Klasse zu. Burstable-QoS-Pods werden eher entfernt, wenn Kubernetes Ressourcen auf dem Knoten freigeben 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 einen GKE-Standardcluster. Informationen zum Erstellen eines neuen Clusters finden Sie unter Autopilot-Cluster erstellen.

Verfügbarkeit von Bursting in GKE

In den folgenden Situationen kann es zu einem Burst bei Arbeitslasten kommen:

Beschränkungen

• Autopilot-Arbeitslasten können Bursting nur für CPU- und Arbeitsspeicheranforderungen 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. Er muss erfolgen, nachdem auf allen Knoten eine unterstützte Version und ein unterstützter cgroup-Modus ausgeführt werden. Die Steuerungsebene wird während Vorgängen wie Skalierung, Upgrades oder Wartung etwa einmal pro Woche automatisch neu gestartet.

  So lösen Sie einen Neustart der Steuerungsebene manuell aus:

  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
     

     Auf allen Knoten in der Ausgabe muss die erforderliche Version oder höher angezeigt werden.

  2. Prüfen Sie, ob Ihr Cluster cgroupv2 ausführt. 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 Folgendes:

     • CLUSTER_NAME ist der Name Ihres vorhandenen Clusters.
     • CURRENT_CLUSTER_VERSION: Die Version, auf der Ihr 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, für die Beschleuniger oder bestimmte Maschinenserien angefordert werden, immer aktiviert. Fahren Sie mit dem Abschnitt Arbeitslast mit Burst bereitstellen fort.

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

• Autopilot-Pods, für die die Scale-Out- oder Balanced-vordefinierten Compute-Klassen angefordert werden.
• 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 im Abschnitt Verfügbarkeit von Bursting in GKE beschrieben.

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

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

Die Ausgabe sieht 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.

Arbeitslast mit Burst 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 ermöglichen:

   • 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 Steady State 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 bursten, sofern diese Kapazität auf dem Knoten verfügbar ist. Wenn Sie dieses Feld weglassen, können die Pods die verfügbare Bursting-Kapazität auf dem Knoten nutzen. Diese Kapazität wird so berechnet:
     • Autopilot-Modus: Nicht verwendete Kapazität in der Summe der Ressourcenanfragen von Pods auf dem Knoten.
     • Standardmodus: Ungenutzte 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 zum Ausführen der burstable Pods erstellt. GKE wendet Markierungen auf diese neuen Knoten an, um zu verhindern, dass andere Pods, z. B. 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. 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 burstable capacity (Bursting-Kapazität) für jeden Knoten in einem Cluster. Die Berechnung für einen bestimmten Knoten sieht so aus:

• Autopilot-Cluster:

  • Pods, die Beschleuniger oder bestimmte Maschinenreihen 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 Ressourcen von Knoten.
  • Alle anderen Pods: Die Summe der Ressourcenanforderungen aller Pods auf diesem Knoten, unabhängig von der tatsächlichen Ressourcenkapazität des Knotens. Wenn ein Pod beendet wird, verringert sich die Bursting-Kapazität um die Anforderungen dieses Pods. Der Teil der Bursting-Kapazität, der nicht von ausgeführten Pods verwendet wird, kann zugewiesen werden, wenn einer der Pods einen Burst benötigt.

  Autopilot fügt der Bursting-Kapazität auch einen vordefinierten Puffer hinzu, damit alle System-Pods auf dem Knoten, die über ihre Anfragen hinaus bursten, 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 von Knoten.

Best Practices für Bursting

Beachten 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-QoS-Klasse (Quality of Service) Guaranteed erhalten.
• Konfigurieren Sie Memory Bursting nur für Pods, die beendet werden können, wenn Kubernetes Speicher auf dem Knoten freigeben muss.
• Fordern Sie immer genügend Arbeitsspeicher für den Start Ihres 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

Im Autopilot-Modus wird die Bursting-Kapazität als Summe der Ressourcenanfragen aller Pods auf einem bestimmten Knoten berechnet, 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 kann nicht garantiert werden.

• 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 burstable Pods veranschaulicht, 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-Kapazität auf dem Knoten beträgt 450 mCPU (die Summe der Ressourcenanforderungen). Jeder Pod benötigt nur 100 mCPU für die Ausführung. Der Knoten hat also eine verbleibende verfügbare Bursting-fähige Kapazität von 250 mCPU.

Hier sind einige Szenarien, in denen es zu einem Traffic-Anstieg kommen kann:

• Pod 1 benötigt zusätzliche 300 mCPU: Er kann bursten und 250 mCPU 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 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 bursten und 150 m CPU verwenden, wodurch die Gesamtauslastung für Pod 2 auf 250 m CPU steigt. 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. GKE beendet zuerst ressourcenintensive Container in Pods mit einer niedrigeren QoS-Klasse.

Wir empfehlen, immer genügend Arbeitsspeicher für den normalen Pod-Betrieb anzufordern. Wenn ein Container für die normale Funktion auf Memory Bursting angewiesen ist, kann es zu wiederholten Abstürzen kommen, wenn dieser Arbeitsspeicher nicht verfügbar ist.

Pod-Bursting mit Bereitstellung von 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 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 vor dem 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-Standardclustern

GKE Standard-Cluster unterstützen auch Pod-Bursting, indem die Limits höher als die Anfragen festgelegt oder Limits weggelassen werden. In Standardclustern müssen Sie jedoch Knotenpools mit der entsprechenden Ressourcenkapazität erstellen und konfigurieren, um Bursting zu unterstützen. Um die potenziellen Kostensenkungen durch burstable Pods in Standardclustern 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 Standardclustern Folgendes:

• Das maximale Limit für den Ressourcenverbrauch, das die Kubernetes-Entfernung oder 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 Knotenauslastung in Standardclustern erreicht mit höherer Wahrscheinlichkeit einen Kubernetes-Ausschlussgrenzwert, da GKE den Ressourcenverbrauch nicht automatisch begrenzt, wenn Sie keine Grenzwerte angeben. Pods, die in den Arbeitsspeicher platzen, werden daher mit größerer Wahrscheinlichkeit von Kubernetes durch Entfernung aufgrund von Knotendruck 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