Pod-Bursting in GKE konfigurieren

Auf dieser Seite erfahren Sie, wie Sie Pods so konfigurieren, dass sie auf verfügbare, nicht genutzte Kapazität auf GKE-Knoten (Google Kubernetes Engine) zugreifen können.

Was ist Bursting?

Bursting beschreibt die Aktion von Pods, die vorübergehend mehr Rechenkapazität auf dem Knoten 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-Planer platziert Ihre Pods auf Knoten, die genügend Kapazität haben, um diese Ressourcenanfragen zu erfüllen.

Einige Arbeitslasten nutzen während ihrer gesamten Laufzeit nicht 100 % der angeforderten Ressourcen. Beispielsweise benötigt eine Arbeitslast, die während des Bootvorgangs zusätzliche CPU verbraucht, 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. Die GKE ermöglicht es der Arbeitslast, vorübergehend mehr Ressourcen zu 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 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 inaktiv sind und eine kleine Anzahl von Anfragen pro Sekunde senden, aber gelegentlich Traffic-Spitzen aufweisen und von zusätzlichen Ressourcen zur Verarbeitung dieser Anfragen profitieren würden.
  • Ihre Arbeitslasten benötigen beim Start mehr Ressourcen als im Normalbetrieb.
  • 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 so sichergestellt, dass Ihr Pod bei Bedarf mehr Ressourcen verbrauchen kann. Bursting bietet unter anderem folgende Vorteile:

  • Niedrigere laufende Kosten: Sie müssen nicht den erwarteten Spitzenressourcenverbrauch der Arbeitslast anfordern. Ihre Anfragen können für die niedrigeren Steady-State-Werte gelten. In Autopilot zahlen Sie für die Summe Ihrer Pod-Ressourcenanfragen, sodass Ihre laufenden Kosten niedriger sind.
  • Effizientere Ressourcennutzung: Sie vermeiden ungenutzte Rechenkapazität, da Ihre Pods auf ungenutzte Kapazität zugreifen. Ihre Arbeitslasten nutzen mit höherer Wahrscheinlichkeit alle Ihre kostenpflichtigen Ressourcen.
  • Verbesserte Leistung: Pods können nach Bedarf zusätzliche Ressourcen verwenden, um die Zeit für die Verarbeitung eingehender Anfragen zu verkürzen oder beim Hochskalieren schneller zu starten.

Wann 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. Burstable-QoS-Pods werden eher entfernt, wenn Kubernetes Ressourcen auf dem Knoten zurückfordern 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, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.
  • Sie benötigen einen GKE Autopilot-Cluster mit Version 1.30.2-gke.1394000 oder höher oder eine beliebige Version eines GKE Standard-Clusters. 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 burstfähig sein:

Verfügbarkeit von Bursting
GKE Autopilot-Modus

Die folgenden Pod-Typen können in jeder GKE-Version, die die von den Pods angeforderte Hardware unterstützt, Bursting ausführen:

Für alle anderen Pod-Typen wird Bursting verfügbar, wenn Sie die Steuerungsebene neu starten, nachdem Sie sichergestellt haben, dass der Cluster alle folgenden Bedingungen erfüllt:

  • Auf dem Cluster wird cgroupv2 ausgeführt. Cluster, die mit der GKE-Version 1.26 oder höher erstellt wurden oder zu cgroupv2 migriert wurden, erfüllen diese Bedingung. Unter cgroup-Modus prüfen können Sie die aktuelle cgroup-Version ermitteln und bei Bedarf migrieren.
  • Auf dem Cluster wird die GKE-Version 1.30.2-gke.1394000 oder höher ausgeführt.

Weitere Informationen finden Sie unter Einschränkungen.
GKE-Standardmodus Pods können in jeder GKE-Version burstfähig sein.

Beschrä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. Zum Aktivieren von Bursting ist ein Neustart der Steuerungsebene erforderlich. Dieser 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, wenn Vorgänge wie Skalierung, Upgrades oder Wartung ausgeführt werden.

    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

      Alle Knoten in der Ausgabe müssen die erforderliche Version oder höher aufweisen.

    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 die Version, die der Cluster bereits verwendet.

      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.

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 Burstable-Arbeitslast bereitstellen fort.

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

GKE stellt das DaemonSet efficiency-daemon bereit, wenn Ihr Autopilot-Cluster die Anforderungen für Bursting erfüllt, wie im Abschnitt Bursting-Verfügbarkeit 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.

Burstable-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 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 skalieren, sofern 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 burstfähig sein. Diese Kapazität wird so berechnet:
      • Autopilot-Modus: Nicht verwendete Kapazität in der Summe der Ressourcenanfragen von Pods auf dem Knoten.
      • Standardmodus: Nicht genutzte 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 burstfähigen Pods zu erstellen. 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 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. 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 Pod-Bursting zu ermöglichen, berechnet die GKE die Bursting-fähige 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 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, 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 einen Burst benötigt.

    Autopilot fügt der Bursting-fähigen Kapazität außerdem einen vordefinierten Puffer hinzu, damit System-Pods auf dem Knoten, die über ihre Anfragen hinausgehen, 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 Ressourcen für Knoten.

Best Practices für Bursting

Beachten Sie bei der Verwendung von Pod-Bursting die folgenden Best Practices:

  • Legen Sie für alle Pods, die wichtige 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 Memory Bursting nur für Pods, die entfernt werden können, wenn Kubernetes Speicher auf dem Knoten freigeben muss.
  • Fordern Sie immer genügend Arbeitsspeicher für das Booten 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

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 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 anhand eines Beispiel-Deployments mit den folgenden burstfähigen 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-fähige Kapazität auf dem Knoten beträgt 450m CPU (die Summe der Ressourcenanfragen). Jeder Pod benötigt nur 100 m CPU, um ausgeführt zu werden. Das bedeutet, dass der Knoten eine verbleibende verfügbare Bursting-fähige Kapazität von 250 m hat.

Sehen Sie sich die folgenden Szenarien an, in denen ein Traffic-Anstieg auftritt:

  • Pod 1 benötigt zusätzliche 300 m CPU: Er kann die Bursting-Funktion nutzen 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 einen Burst ausführen und zusätzliche 150 m CPU verwenden. Der Knoten hat dann noch 100 m CPU an verfügbarer Bursting-fähiger Kapazität.
  • Pod 2 benötigt zusätzliche 200 m CPU: Er kann Bursts verwenden und 150 m CPU nutzen, was die Gesamtnutzung für Pod 2 auf 250 m CPU erhöht. 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. Die 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 von Memory Bursting abhängig ist, kann er wiederholt abstürzen, wenn dieser Arbeitsspeicher nicht verfügbar ist.

Pod-Bursting mit Bereitstellung von Reservekapazitä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 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 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-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 potenzielle Kostensenkung durch burstfähige Pods in Standard-Clustern zu erreichen, ist eine sorgfältigere Knotenplanung und ein Bin-Packing der Pods erforderlich, da Sie für die zugrunde liegenden Compute Engine-VMs bezahlen.

Beachten Sie bei Standardclustern Folgendes:

  • Das maximale Ressourcenverbrauchslimit, das die Kubernetes-Entfernung oder 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 Ressourcennutzung von Knoten in Standard-Clustern erreicht eher einen Kubernetes-Entfernungsschwellenwert, da GKE den Ressourcenverbrauch nicht automatisch begrenzt, wenn Sie keine Limits angeben. Pods, die den Arbeitsspeicher überlasten, werden daher eher durch die Knotendruck-Entfernung von Kubernetes beendet.

Nächste Schritte