Zusätzliche Rechenkapazität für eine schnelle Pod-Skalierung bereitstellen


Auf dieser Seite erfahren Sie, wie Sie zusätzliche Rechenkapazität in Ihren Google Kubernetes Engine-Clustern (GKE) reservieren, damit Ihre Arbeitslasten bei hohen Trafficereignissen schnell hochskaliert werden können, ohne auf den Start neuer Knoten zu warten. Sie können diese Anleitung verwenden, um den Rechenaufwand auf konsistente Weise oder vor bestimmten Ereignissen zu reservieren.

Warum ist eine freie Kapazitätsbereitstellung nützlich?

Für GKE Autopilot-Cluster und -Standardcluster mit automatischer Knotenbereitstellung werden neue Knoten erstellt, wenn keine Knoten mit der Kapazität zum Ausführen neuer Pods vorhanden sind. Jeder neue Knoten benötigt etwa 80 bis 120 Sekunden, um zu starten. GKE wartet, bis der Knoten gestartet wurde, bevor ausstehende Pods auf dem neuen Knoten ersetzt werden. Danach können die Pods gestartet werden. In Standardclustern können Sie manuell einen neuen Knotenpool mit der zusätzlichen Kapazität erstellen, die Sie zum Ausführen neuer Pods benötigen. Diese Seite gilt für Cluster, die einen Autoscaling-Mechanismus für Knoten wie Autopilot oder automatische Knotenbereitstellung verwenden.

In einigen Fällen kann es sinnvoll sein, dass Pods während einer vertikalen Skalierung schneller starten. Wenn Sie beispielsweise eine neue Erweiterung für Ihr beliebtes Mehrspieler-Game mit Live-Service starten, können die schnelleren Bootzeiten Ihrer Gameserver-Pods die Warteschlangenzeiten für Spieler verringern, die sich am Starttag anmelden. Ein weiteres Beispiel: Wenn Sie eine E-Commerce-Plattform betreiben und für einen begrenzten Zeitraum einen Blitzverkauf planen, erwarten Sie Traffic-Bursts für die Dauer des Angebots.

Die Bereitstellung von freier Kapazität ist mit Pod-Bursting kompatibel. Damit können Pods vorübergehend Ressourcen verwenden, die von anderen Pods auf dem Knoten angefordert wurden, wenn diese Kapazität verfügbar ist und von anderen Pods nicht verwendet wird. Wenn Sie Bursting verwenden möchten, legen Sie die Ressourcenlimits höher als Ihre Ressourcenanfragen fest oder legen keine Ressourcenlimits fest. Weitere Informationen finden Sie unter Pod-Bursting in GKE konfigurieren.

So funktioniert die freie Kapazitätsbereitstellung in GKE

Zum Bereitstellen freier Kapazitäten können Sie Kubernetes-PriorityClasses und Platzhalter-Pods verwenden. Mit einer PriorityClass können Sie für GKE angeben, dass einige Arbeitslasten eine niedrigere Priorität haben als andere Arbeitslasten. Sie können Platzhalter-Pods bereitstellen, die eine PriorityClass mit niedriger Priorität verwenden und die Rechenkapazität anfordern, die Sie reservieren müssen. GKE fügt dem Cluster Kapazität hinzu, in dem es neue Knoten erstellt, um die Platzhalter-Pods unterzubringen.

Wenn Ihre Produktionsarbeitslasten hochskaliert werden, entfernt GKE die Platzhalter-Pods mit niedrigerer Priorität und plant die neuen Replikate der Produktions-Pods (die die eine PriorityClass mit höherer Priorität verwenden) an deren Stelle ein. Wenn Sie mehrere Pods mit niedriger Priorität und unterschiedlichen Prioritätsstufen haben, entfernt GKE zuerst die Pods mit der niedrigsten Priorität.

Kapazitätsbereitstellungsmethoden

Je nach Anwendungsfall können Sie zusätzliche Kapazität in Ihren GKE-Clustern auf eine der folgenden Arten bereitstellen:

  • Konsistente Kapazitätsbereitstellung: Verwenden Sie ein Deployment, um eine bestimmte Anzahl von Platzhalter-Pods mit niedriger Priorität zu erstellen, die ständig im Cluster ausgeführt werden. Wenn GKE diese Pods zur Ausführung Ihrer Produktionsarbeitslasten entfernt, sorgt der Deployment-Controller dafür, dass GKE mehr Kapazität zur Neuerstellung der entfernten Pods mit niedriger Priorität bietet. Diese Methode bietet einen konsistenten Kapazitätsaufwand für mehrfaches Hoch- und Herunterskalieren, bis Sie das Deployment löschen.
  • Kapazitätsbereitstellung mit nur einer Verwendung: Verwenden Sie einen Job, um eine bestimmte Anzahl von parallelen Platzhalter-Pods mit niedriger Priorität für einen bestimmten Zeitraum auszuführen. Wenn diese Zeit abgelaufen ist oder GKE alle Jobreplikate entfernt, ist die reservierte Kapazität nicht mehr verfügbar. Diese Methode bietet eine bestimmte Menge an verfügbarer Kapazität für einen bestimmten Zeitraum.

Preise

In GKE Autopilot werden Ihnen die Ressourcenanfragen der ausgeführten Pods in Rechnung gestellt, einschließlich der Arbeitslasten mit niedriger Priorität, die Sie bereitstellen. Weitere Informationen finden Sie unter Autopilot-Preise.

In GKE Standard werden Ihnen die von GKE bereitgestellten Compute Engine-VMs in Rechnung gestellt, unabhängig davon, ob die Pods diese Kapazität nutzen. Weitere Informationen finden Sie unter Standardpreise.

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 gcloud components update ab.
  • Achten Sie darauf, dass Sie einen GKE Autopilot-Cluster oder einen GKE-Standardcluster mit aktivierter automatischer Knotenbereitstellung haben.
  • Lesen Sie die Hinweise zur Kapazitätsbereitstellung, damit Sie in Ihren Kapazitätsanfragen die entsprechenden Werte auswählen.

PriorityClass erstellen

Wenn Sie eine der unter Bereitstellungsmethoden für die Kapazität beschriebenen Methoden verwenden möchten, müssen Sie zuerst die folgenden PriorityClasses erstellen:

  • Standard-PriorityClass: Eine globale Standard-PriorityClass, die jedem Pod zugewiesen ist, die nicht explizit eine andere PriorityClass in der Pod-Spezifikation festlegt. Pods mit dieser Standard-PriorityClass können Pods entfernen, die eine niedrigere PriorityClass verwenden.
  • Niedrige PriorityClass: Eine benutzerdefinierte PriorityClass, die in GKE auf die niedrigste Priorität gesetzt ist. Pods mit dieser PriorityClass können entfernt werden, um Pods mit höheren PriorityClasses auszuführen.
  1. Speichern Sie das folgende Manifest als priorityclasses.yaml:

    apiVersion: scheduling.k8s.io/v1
    kind: PriorityClass
    metadata:
      name: low-priority
    value: -10
    preemptionPolicy: Never
    globalDefault: false
    description: "Low priority workloads"
    ---
    apiVersion: scheduling.k8s.io/v1
    kind: PriorityClass
    metadata:
      name: default-priority
    value: 0
    preemptionPolicy: PreemptLowerPriority
    globalDefault: true
    description: "The global default priority."
    

    Dieses Manifest enthält die folgenden Felder:

    • preemptionPolicy: Gibt an, ob Pods, die eine PriorityClass verwenden, Pods mit niedrigerer Priorität entfernen können. Die PriorityClass low-priority verwendet Never und die PriorityClass default verwendet PreemptLowerPriority.
    • value: Die Priorität für Pods, die die PriorityClass verwenden. Die PriorityClass default verwendet 0. Die PriorityClass low-priority verwendet -1. In Autopilot können Sie dafür einen beliebigen Wert festlegen, der unter der Priorität der PriorityClass default liegt.

      Wenn Sie diesen Wert in der Standardeinstellung auf weniger als -10 festlegen, lösen Pods, die diese PriorityClass verwenden, keine neue Knotenerstellung aus und bleiben auf „Ausstehend“.

      Hilfe bei der Entscheidung für geeignete Werte für die Priorität finden Sie unter Priorität auswählen.

    • globalDefault: Gibt an, ob GKE Pods, die in der Pod-Spezifikation nicht explizit eine PriorityClass festlegen, die PriorityClass zuweist oder nicht. Die PriorityClass low-priority verwendet false und die PriorityClass default verwendet true.

  2. Wenden Sie das Manifest an:

    kubectl apply -f priorityclasses.yaml
    

Zusätzliche Rechenkapazität bereitstellen

In den folgenden Abschnitten wird ein Beispiel vorgestellt, in dem Sie Kapazitäten für ein einzelnes Ereignis oder konsistent in einem Zeitraum bereitstellen.

Deployment für konsistente Kapazitätsbereitstellung verwenden

  1. Speichern Sie das folgende Manifest als capacity-res-deployment.yaml:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: capacity-res-deploy
    spec:
      replicas: 10
      selector:
        matchLabels:
          app: reservation
      template:
        metadata:
          labels:
            app: reservation
        spec:
          priorityClassName: low-priority
          terminationGracePeriodSeconds: 0
          containers:
          - name: ubuntu
            image: ubuntu
            command: ["sleep"]
            args: ["infinity"]
            resources:
              requests:
                cpu: 500m
                memory: 500Mi
    

    Dieses Manifest enthält die folgenden Felder:

    • spec.replicas: Ändern Sie diesen Wert, um Ihre Anforderungen zu erfüllen.
    • spec.resources.requests: Ändern Sie die CPU- und Speicheranforderungen, um Ihre Anforderungen zu erfüllen. Folgen Sie der Anleitung unter Kapazitätsgröße auswählen, um die richtigen Anfragewerte zu finden.
    • spec.containers.command und spec.containers.args: Teilt den Pods mit, dass sie aktiv bleiben, bis sie von GKE entfernt werden.
  2. Wenden Sie das Manifest an:

    kubectl apply -f capacity-res-deployment.yaml
    
  3. Rufen Sie den Status des Pods ab:

    kubectl get pods -l app=reservation
    

    Warten Sie, bis die Replikate den Status Running haben.

Job für die Kapazitätsbereitstellung eines einzelnen Ereignisses verwenden

  1. Speichern Sie das folgende Manifest als capacity-res-job.yaml:

    apiVersion: batch/v1
    kind: Job
    metadata:
      name: capacity-res-job
    spec:
      parallelism: 4
      backoffLimit: 0
      template:
        spec:
          priorityClassName: low-priority
          terminationGracePeriodSeconds: 0
          containers:
          - name: ubuntu-container
            image: ubuntu
            command: ["sleep"]
            args: ["36000"]
            resources:
              requests:
                cpu: "16"
          restartPolicy: Never
    

    Dieses Manifest enthält die folgenden Felder:

    • spec.parallelism: Ändern Sie die Anzahl der Jobs, die Sie parallel ausführen möchten, um Kapazitäten zu reservieren.
    • spec.backoffLimit: 0: Verhindern Sie, dass der Jobcontroller entfernte Jobs neu erstellt.
    • template.spec.resources.requests: Ändern Sie die CPU- und Speicheranforderungen, um Ihre Anforderungen zu erfüllen. Verwenden Sie die Anleitung unter Hinweise, um die richtigen Werte zu bestimmen.
    • template.spec.containers.command und template.spec.containers.args: Teilen Sie den Jobs mit, dass sie für den Zeitraum in Sekunden aktiv sein sollen, in dem Sie die zusätzliche Kapazität benötigen.
  2. Wenden Sie das Manifest an:

    kubectl apply -f capacity-res-job.yaml
    
  3. Rufen Sie den Jobstatus ab:

    kubectl get jobs
    

    Warten Sie, bis alle Jobs den Status Running haben.

Kapazitätsbereitstellung und -bereinigung testen

So prüfen Sie, ob die Kapazitätsbereitstellung wie erwartet funktioniert:

  1. Überwachen Sie in Ihrem Terminal den Status der Arbeitslasten für die Kapazitätsbereitstellung:

    1. Führen Sie für Deployments den folgenden Befehl aus:

      kubectl get pods --label=app=reservation -w
      
    2. Führen Sie für Jobs den folgenden Befehl aus:

      kubectl get Jobs -w
      
  2. Öffnen Sie ein neues Terminalfenster und gehen Sie so vor:

    1. Speichern Sie das folgende Manifest als test-deployment.yaml:

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: helloweb
        labels:
          app: hello
      spec:
        replicas: 5
        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: 400m
                  memory: 400Mi
      
    2. Wenden Sie das Manifest an:

      kubectl apply -f test-deployment.yaml
      
  3. Beachten Sie im ursprünglichen Terminalfenster, dass GKE einige der Kapazitätsbereitstellungsarbeitslasten beendet, um Ihre neuen Replikate zu planen, ähnlich dem folgenden Beispiel:

    NAME                                         READY   STATUS    RESTARTS   AGE
    capacity-res-deploy-6bd9b54ffc-5p6wc         1/1     Running   0          7m25s
    capacity-res-deploy-6bd9b54ffc-9tjbt         1/1     Running   0          7m26s
    capacity-res-deploy-6bd9b54ffc-kvqr8         1/1     Running   0          2m32s
    capacity-res-deploy-6bd9b54ffc-n7zn4         1/1     Running   0          2m33s
    capacity-res-deploy-6bd9b54ffc-pgw2n         1/1     Running   0          2m32s
    capacity-res-deploy-6bd9b54ffc-t5t57         1/1     Running   0          2m32s
    capacity-res-deploy-6bd9b54ffc-v4f5f         1/1     Running   0          7m24s
    helloweb-85df88c986-zmk4f                    0/1     Pending   0          0s
    helloweb-85df88c986-lllbd                    0/1     Pending   0          0s
    helloweb-85df88c986-bw7x4                    0/1     Pending   0          0s
    helloweb-85df88c986-gh8q8                    0/1     Pending   0          0s
    helloweb-85df88c986-74jrl                    0/1     Pending   0          0s
    capacity-res-deploy-6bd9b54ffc-v6dtk   1/1     Terminating   0          2m47s
    capacity-res-deploy-6bd9b54ffc-kvqr8   1/1     Terminating   0          2m47s
    capacity-res-deploy-6bd9b54ffc-pgw2n   1/1     Terminating   0          2m47s
    capacity-res-deploy-6bd9b54ffc-n7zn4   1/1     Terminating   0          2m48s
    capacity-res-deploy-6bd9b54ffc-2f8kx   1/1     Terminating   0          2m48s
    ...
    helloweb-85df88c986-lllbd              0/1     Pending       0          1s
    helloweb-85df88c986-gh8q8              0/1     Pending       0          1s
    helloweb-85df88c986-74jrl              0/1     Pending       0          1s
    helloweb-85df88c986-zmk4f              0/1     Pending       0          1s
    helloweb-85df88c986-bw7x4              0/1     Pending       0          1s
    helloweb-85df88c986-gh8q8              0/1     ContainerCreating   0          1s
    helloweb-85df88c986-zmk4f              0/1     ContainerCreating   0          1s
    helloweb-85df88c986-bw7x4              0/1     ContainerCreating   0          1s
    helloweb-85df88c986-lllbd              0/1     ContainerCreating   0          1s
    helloweb-85df88c986-74jrl              0/1     ContainerCreating   0          1s
    helloweb-85df88c986-zmk4f              1/1     Running             0          4s
    helloweb-85df88c986-lllbd              1/1     Running             0          4s
    helloweb-85df88c986-74jrl              1/1     Running             0          5s
    helloweb-85df88c986-gh8q8              1/1     Running             0          5s
    helloweb-85df88c986-bw7x4              1/1     Running             0          5s
    

    Diese Ausgabe zeigt, dass es fünf Sekunden dauerte, bis das neue Deployment von „Ausstehend“ zu „Aktiv“ wechselt.

Hinweise zur Kapazitätsbereitstellung

Konsistente Kapazitätsbereitstellung

  • Evaluieren Sie die Anzahl der benötigten Pod-Replikate und die Größe der Anfragen in jedem Replikat. Die Replikate mit niedriger Priorität sollten mindestens dieselbe Kapazität anfordern wie Ihre größte Produktionsarbeitslast, damit diese Arbeitslasten in die Kapazität passen, die von Ihrer Arbeitslast mit niedriger Priorität reserviert ist.
  • Wenn Sie eine große Anzahl von Produktionsarbeitslasten im großen Maßstab nutzen, sollten Sie die Ressourcenanfragen Ihrer Platzhalter-Pods auf Werte festlegen, die genügend Kapazität zum Ausführen mehrerer Produktionsarbeitslasten anstelle von nur einem bieten.

Einmalige Kapazitätsbereitstellung

  • Legen Sie die Dauer der Platzhalterjobs für den Zeitraum fest, in dem Sie zusätzliche Kapazität benötigen. Wenn Sie beispielsweise die zusätzliche Kapazität für einen 24-Stunden-Einführungstag eines Spiels verwenden möchten, legen Sie die Dauer auf 86.400 Sekunden fest. Dadurch wird sichergestellt, dass die bereitgestellte Kapazität nicht länger dauert als benötigt.
  • Legen Sie ein Wartungsfenster für den Zeitraum fest, in dem Sie die Kapazität reservieren. Dadurch wird verhindert, dass Jobs mit niedriger Priorität während eines Knotenupgrades entfernt werden. Das Festlegen eines Wartungsfensters ist auch eine gute Vorgehensweise, wenn Sie eine hohe Nachfrage nach Ihrer Arbeitslast erwarten.
  • Wenn Sie eine große Anzahl von Produktionsarbeitslasten im großen Maßstab nutzen, sollten Sie die Ressourcenanfragen Ihrer Platzhalter-Jobs auf Werte festlegen, die genügend Kapazität zum Ausführen mehrerer Produktionsarbeitslasten anstelle von nur einem bieten.

Die Kapazität wird nur für ein einzelnes Skalierungsereignis bereitgestellt. Wenn Sie die Kapazität hoch- und herunterskalieren, ist diese Kapazität für ein weiteres vertikales Ereignis nicht mehr verfügbar. Wenn Sie mehrfaches Hoch- und Herunterskalieren erwarten, verwenden Sie die konsistente Kapazitätsreservierungsmethode und passen Sie die Größe der Reservierung nach Bedarf an. Beispiel: Die Pod-Anforderungen werden vor einem Ereignis größer und nach einem Ereignis kleiner oder gleich null.

Priorität auswählen

Legen Sie die Priorität in „PriorityClasses“ auf weniger als 0 fest.

Sie können in Ihrem Cluster mehrere PriorityClasses definieren und für Arbeitslasten mit unterschiedlichen Anforderungen verwenden. Sie können beispielsweise eine PriorityClass mit einer Priorität von -10 für die Bereitstellung von einmaliger Kapazität und eine PriorityClass mit einer Priorität von -9 für eine konsistente Bereitstellung von Kapazitäten erstellen. Sie können dann mit der PriorityClass mit einer Priorität von -9 konsistente Kapazität bereitstellen und, wenn Sie für ein besonderes Ereignis mehr Kapazität benötigen, können Sie neue Jobs bereitstellen, die die PriorityClass mit der Priorität -10 verwenden. GKE entfernt zuerst die Arbeitslasten mit der niedrigsten Priorität.

Sie können auch andere PriorityClasses verwenden, um Arbeitslasten mit niedriger Priorität auszuführen, die tatsächliche Aufgaben ausführen, z. B. fehlertolerante Batcharbeitslasten mit einer Priorität, die niedriger als Ihre Produktionsarbeitslasten, aber höher als Ihr Platzhalter-Pods ist. Zum Beispiel -5.

Kapazitätsgröße auswählen

Legen Sie die Replikatanzahl und die Ressourcenanfragen Ihrer Platzhalterarbeitslast auf größer oder gleich der Kapazität fest, die Ihre Produktionsarbeitslasten beim Hochskalieren benötigen.

Die gesamte bereitgestellte Kapazität basiert auf der Anzahl der von Ihnen bereitgestellten Platzhalter-Pods und den Ressourcenanfragen der einzelnen Replikate. Wenn Ihre vertikale Skalierung mehr Kapazität erfordert, als GKE für Ihre Platzhalter-Pods bereitstellt, verbleiben einige Ihrer Produktionsarbeitslasten in Pending, bis GKE mehr Kapazität bereitstellen kann.

Nächste Schritte