Anwendungsstart mit CPU-Boost beim Start beschleunigen

In diesem Dokument wird beschrieben, wie Sie den CPU-Startup-Boost mit dem vertikalen Pod-Autoscaler (VPA) in Google Kubernetes Engine (GKE) verwenden können, um die einem Pod während der Initialisierungsphase zugewiesenen CPU-Ressourcen vorübergehend zu erhöhen.

Der CPU-Boost beim Start beschleunigt den Anwendungsstart und verbessert die Kosteneffizienz, indem die CPU-Anforderungen während der Initialisierung vorübergehend erhöht und dann wieder auf das Ausgangsniveau zurückgesetzt werden. In diesem Dokument werden die Anforderungen, die Konfiguration (auf Pod- und Containerebene), die Überprüfung und die Best Practices für den Startup-Boost beschrieben.

Dieses Dokument richtet sich an DevOps-, Plattform- und Anwendungsentwickler, die die Startleistung von Anwendungen in GKE optimieren möchten.

Vorteile

Die Verwendung des CPU-Start-Boosts bietet folgende Vorteile:

  • Schnellerer Start: Beschleunigen Sie die Initialisierung ressourcenintensiver Anwendungen, z. B. solcher, die in Java, Node.js oder Python geschrieben wurden.
  • Kosteneffizienz: Vermeiden Sie eine Überbereitstellung von CPU für den Steady-State-Betrieb und erfüllen Sie gleichzeitig die Anforderungen beim Start. Der Steady-State-Betrieb ist der Zeitraum, nachdem eine Anwendung die Initialisierung abgeschlossen hat und die Ressourcennutzung stabilisiert wurde.
  • Keine Unterbrechung: Ressourcen mit Kubernetes IPPR (In-Place Pod Resize) ohne Neustart Ihrer Container auf das Basisniveau zurückskalieren.
  • Geringerer manueller Aufwand: Sie können Ressourcenverschwendung und den manuellen Aufwand für die Anpassung der Größe Ihrer Arbeitslasten minimieren.

Voraussetzungen

Damit Sie den CPU-Boost beim Starten verwenden können, müssen die folgenden Anforderungen erfüllt sein:

  • GKE-Version: Verwenden Sie 1.36.0-gke.4447000 und höher für Standard- und Autopilot-Cluster.
  • VPA aktiviert: Aktivieren Sie das vertikale Pod-Autoscaling in Standardclustern. In GKE ist VPA standardmäßig für Autopilot-Cluster aktiviert. Sie können VPA ausschließlich für den CPU-Boost beim Start verwenden, indem Sie einen bestimmten Aktualisierungsmodus auswählen. Informationen zum Aktivieren und Konfigurieren von VPA finden Sie unter Pod-Ressourcenanfragen automatisch festlegen.
  • Arbeitslasttyp: Verwenden Sie einen Controller wie ein Deployment oder ein StatefulSet, um Ihre Arbeitslast zu verwalten.
  • Knotenkapazität: Standardcluster müssen genügend Kapazität für den beschleunigten Pod haben. Wenn nicht genügend Kapazität vorhanden ist, begrenzt GKE die Anfrage für den Pod mit erhöhter Priorität, damit sie auf den Knoten passt.

Funktionsweise des CPU-Boost beim Start

Weitere Informationen zum Boost-Lebenszyklus und zur Berechnung von Ressourcenerhöhungen durch den CPU-Boost beim Start finden Sie unter Funktionsweise des CPU-Boost beim Start.

Hinweis

Prüfen Sie zuerst, ob das Cloud de Confiance by S3NS Projekt ausgewählt ist, das den Cluster enthält, den Sie optimieren möchten, und ob Sie die folgenden Aufgaben ausgeführt haben:

  • 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. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

  • Konfigurieren Sie die gcloud CLI so, dass das ausgewählte Projekt verwendet wird:

    gcloud config set project PROJECT_ID

    Ersetzen Sie PROJECT_ID durch die ID Ihres Projekts.

  • Prüfen Sie, ob ein GKE-Cluster vorhanden ist. Wenn Sie noch keinen haben, lesen Sie den Abschnitt Cluster erstellen.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Aktivieren und Verwenden von CPU-Startup-Boost benötigen:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

CPU-Boost beim Start aktivieren

Wenn Sie den CPU-Boost beim Start aktivieren möchten, fügen Sie Ihrem VerticalPodAutoscaler-Manifest (VPA) einen startupBoost-Konfigurationsblock hinzu. Sie können den Boost so konfigurieren, dass er auf alle Container in einem Pod angewendet wird, oder einzelne Container mit bestimmten Ressourcensteigerungen anvisieren.

Boost auf Pod-Ebene konfigurieren

Bei einem Boost auf Pod-Ebene wird für jeden Container in der Arbeitslast dieselbe CPU-Ressourcenerhöhung angewendet. Sie können den CPU-Boost beim Start mit oder ohne die kontinuierliche Ressourcenverwaltung von VPA konfigurieren.

Verwenden Sie eine der folgenden Optionen, um einen Boost auf Pod-Ebene zu konfigurieren.

Option A: Start-Boost aktiviert und VPA-Aktualisierungsmodus deaktiviert

Mit dieser Option können Sie VPA ausschließlich für die CPU-Startup-Boost-Funktionen nutzen, ohne reguläre VPA-Empfehlungen zu aktivieren. Im folgenden Beispiel wird ein CPU-Multiplikationsfaktor von 2 angewendet und 10 Sekunden lang beibehalten, nachdem der Pod den Status Ready erreicht hat:

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

Option B: Sowohl Startup-Boost als auch VPA-Aktualisierungsmodus aktiviert

Wenn GKE den Startup-Boost verwalten und die Ressourcenanforderungen Ihres Pods dann basierend auf der laufenden Nutzung automatisch anpassen soll, verwenden Sie diese Option. Im folgenden Beispiel wird der Start-Boost angewendet und das Feld updateMode auf InPlaceOrRecreate festgelegt:

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

Boost auf Containerebene konfigurieren

Wenn Ihre Arbeitslast Sidecars oder andere Container enthält, für die keine zusätzlichen Ressourcen erforderlich sind, können Sie im Abschnitt resourcePolicy bestimmte Container für einen Startup-Boost festlegen. Der Wert containerName muss mit dem Feld name eines Containers in Ihrer Deployment-Spezifikation übereinstimmen.

Verwenden Sie eine der folgenden Optionen, um einen Boost auf Containerebene zu konfigurieren.

Option A: Einen bestimmten Container optimieren (VPA-Aktivierung deaktiviert)

Mit dieser Option können Sie einen Boost auf einen einzelnen Container anwenden, ohne die Ressourcenanforderungen des restlichen Pods zu ändern. Im folgenden Beispielmanifest werden dem Baseline-Request für einen Container mit dem Namen boosted-container-name zwei vCPUs hinzugefügt:

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: "boosted-container-name"
      mode: "Off"
      startupBoost:
        cpu:
          type: "Quantity"
          quantity: "2"

Option B: Bestimmten Container aus einem Boost auf Pod-Ebene deaktivieren

Verwenden Sie diese Option, wenn Sie einen Boost auf Podebene konfiguriert haben, aber einen bestimmten Container ausschließen möchten. Im folgenden Beispielmanifest wird ein CPU-Multiplikationsfaktor von 2 auf den gesamten Pod angewendet, der Boost für einen Container mit dem Namen disable-cpu-boost-for-this-container wird jedoch deaktiviert, indem sein Faktor auf 1 gesetzt wird:

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
  resourcePolicy:
    containerPolicies:
    - containerName: "disable-cpu-boost-for-this-container"
      startupBoost:
        cpu:
          type: "Factor"
          factor: 1

CPU-Boost beim Start überprüfen

Wenn Sie prüfen möchten, ob Ihre Pods den Boost erhalten, sehen Sie sich die VPA-Konfiguration, Pod-Ressourcenanforderungen, Pod-Annotationen und VPA-Ereignisse an.

VPA-Konfiguration prüfen

Führen Sie den folgenden Befehl aus, um die Details Ihres VerticalPodAutoscaler-Objekts zu prüfen:

kubectl describe vpa VPA_NAME

Ersetzen Sie VPA_NAME durch den Namen Ihres VPA-Objekts.

Anfrage für erhöhte CPU-Leistung im Pod prüfen

Führen Sie den folgenden Befehl aus, um die aktuellen Ressourcenanforderungen für Ihren Pod zu prüfen:

kubectl describe pod POD_NAME

Ersetzen Sie POD_NAME durch den Namen Ihres Clusters.

CPU-Boost mit Pod-Anmerkungen prüfen

Der VPA-Zulassungs-Webhook fügt eine Annotation mit Containerbereich ein, um die ursprünglichen Ressourcen zu verfolgen, zu denen jeder Container zurückkehren soll, wenn der Boost abläuft. Führen Sie den folgenden Befehl aus, um diese Annotationen zu prüfen:

kubectl get pod POD_NAME --output yaml

Suchen Sie im Abschnitt metadata.annotations nach einer Anmerkung im Format vpaCpuStartupBoost/CONTAINER_NAME. Beispiel:

metadata:
  annotations:
    vpaCpuStartupBoost/slow-starter: '{"requests":{"cpu":"50m","memory":"64Mi"},"limits":{"cpu":"200m","memory":"128Mi"}}'

Die Befehlsausgabe enthält eines der folgenden Überprüfungsergebnisse:

  • Erfolgreicher Boost: Der Pod hat die Annotation vpaCpuStartupBoost/CONTAINER_NAME.
  • Nicht erfolgreicher Boost: Der Vermerk fehlt vollständig. Das bedeutet, dass der Admission Controller den Boost ignoriert hat, möglicherweise aufgrund von Knotenkapazitätslimits oder Autopilot-Ressourcenbeschränkungen.

Nach Herunterskalierungsereignissen suchen

Prüfen Sie die Clusterereignisse, indem Sie den folgenden Befehl ausführen, um zu prüfen, ob GKE die CPU-Ressourcenzuweisung erfolgreich auf den Baseline-Wert reduziert hat:

kubectl get events --field-selector reason=InPlaceResizedByVPA

Die Befehlsausgabe enthält eines der folgenden Überprüfungsergebnisse:

  • Erfolgreiches Herunterstufen: Sie sehen ein InPlaceResizedByVPA-Ereignis mit einer Meldung, die angibt, dass die Größe des Pods vom VPA Updater direkt geändert wurde. Das bestätigt, dass die CPU-Anfrage ohne Neustart des Containers zum Baseline-Wert zurückgekehrt ist.
  • Nicht erfolgreiche Aufhebung der Steigerung: Die Anmerkung vpaCpuStartupBoost/CONTAINER_NAME bleibt lange nach Ablauf der Steigerung im Pod und es gibt kein InPlaceResizedByVPA-Ereignis.

Best Practices und Einschränkungen

Beachten Sie Folgendes, wenn Sie den CPU-Boost beim Starten verwenden.

Interaktionen mit horizontalem Pod-Autoscaling

Wenn Sie das horizontale Pod-Autoscaling (HPA) mit CPU-Startup-Boost verwenden, beachten Sie die folgenden Richtlinien:

  • Systemdiagnosen definieren: Sie müssen eine readinessProbe für Ihre Arbeitslasten definieren.
  • Verzögerung für die Dauer konfigurieren: Sie müssen den Parameter durationSeconds auf 0 festlegen. Diese Konfiguration verhindert, dass HPA Ihre Anwendung aufgrund einer hohen CPU-Auslastung während des Startvorgangs vorzeitig skaliert.

Cluster-Autoscaler und Löschschleifen

Wenn Sie den Cluster Autoscaler in GKE Standard-Clustern verwenden, sollten Sie die folgenden Knotenverhaltensweisen berücksichtigen:

  • Potenzielle Löschungsschleifen: Ein temporärer CPU-Boost kann eine Aufstockung des Knotens auslösen. Nachdem der Pod bereit ist und herunterskaliert wird, kann eine Unterauslastung eine Knotenherunterskalierung auslösen und den Pod entfernen, was zu einer Endlosschleife führt.
  • Abhilfe: Wir empfehlen dringend, GKE Autopilot zu verwenden, um Probleme mit der Knotendefragmentierung und dem Eviction-Loop zu beheben.

Container-Neustarts

Die folgenden Verhaltensweisen zeigen, wie sich Containerneustarts auf den CPU-Boost beim Start auswirken:

  • Nur bei der Pod-Erstellung: Der CPU-Start-Boost wird nur während der ersten Phase der Pod-Erstellung angewendet.
  • Kein Boost beim Neustart: Wenn ein Container neu gestartet wird, z. B. aufgrund eines OOMKill-Ereignisses, der Pod aber aktiv bleibt, wendet GKE den Boost nicht noch einmal an. Dieses Verhalten tritt auf, weil der Pod-Zulassungs-Webhook nur während des anfänglichen Pod-Erstellungsprozesses ausgelöst wird.

Bereinigen

Da Sie den CPU-Startup-Boost für vorhandene Arbeitslasten konfigurieren, sollten Sie Folgendes beachten, um Unterbrechungen der Arbeitslast zu vermeiden:

  • Sie müssen keine Kubernetes-Ressourcen löschen.
  • Wenn Ihr VerticalPodAutoscaler-Objekt oder Ihre Arbeitslastcontroller (z. B. Deployments oder StatefulSets) für den stabilen Betrieb weiterhin benötigt werden, löschen Sie sie nicht.

  • Wenn Sie keinen CPU-Start-Boost benötigen, können Sie ihn mit einer der folgenden Methoden deaktivieren:

    • Boost für die gesamte Arbeitslast deaktivieren: Löschen Sie den Block startupBoost aus der Spezifikation Ihres VerticalPodAutoscaler-Objekts und wenden Sie das aktualisierte Manifest auf Ihren Cluster an.

    • Boost für einen bestimmten Container deaktivieren: Wenn Sie einen bestimmten Container von einem Boost auf Pod-Ebene ausschließen möchten, fügen Sie im Abschnitt containerPolicies eine Containerrichtlinie hinzu und legen Sie den CPU-Multiplikatorfaktor auf 1 fest.

        startupBoost:
    cpu:
      type: "Factor"
      factor: 1

      Weitere Informationen finden Sie unter Container-Level-Boost konfigurieren.

Nächste Schritte