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 Sie 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 updateab.
- 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.
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 PriorityClasslow-priorityverwendetNeverund die PriorityClassdefaultverwendetPreemptLowerPriority.value: Die Priorität für Pods, die die PriorityClass verwenden. Die PriorityClassdefaultverwendet0. Die PriorityClasslow-priorityverwendet-10. In Autopilot können Sie dafür einen beliebigen Wert festlegen, der unter der Priorität der PriorityClassdefaultliegt.Wenn Sie diesen Wert in der Standardeinstellung auf weniger als
-10festlegen, 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 PriorityClasslow-priorityverwendetfalseund die PriorityClassdefaultverwendettrue.
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
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: 500MiDieses 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.commandundspec.containers.args: Teilt den Pods mit, dass sie aktiv bleiben, bis sie von GKE entfernt werden.
Wenden Sie das Manifest an:
kubectl apply -f capacity-res-deployment.yamlRufen Sie den Status des Pods ab:
kubectl get pods -l app=reservationWarten Sie, bis die Replikate den Status
Runninghaben.
Job für die Kapazitätsbereitstellung eines einzelnen Ereignisses verwenden
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: NeverDieses 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.commandundtemplate.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.
Wenden Sie das Manifest an:
kubectl apply -f capacity-res-job.yamlRufen Sie den Jobstatus ab:
kubectl get jobsWarten Sie, bis alle Jobs den Status
Runninghaben.
Kapazitätsbereitstellung und -bereinigung testen
So prüfen Sie, ob die Kapazitätsbereitstellung wie erwartet funktioniert:
Überwachen Sie in Ihrem Terminal den Status der Arbeitslasten für die Kapazitätsbereitstellung:
Führen Sie für Deployments den folgenden Befehl aus:
kubectl get pods --label=app=reservation -wFühren Sie für Jobs den folgenden Befehl aus:
kubectl get Jobs -w
Öffnen Sie ein neues Terminalfenster und gehen Sie so vor:
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: 400MiWenden Sie das Manifest an:
kubectl apply -f test-deployment.yaml
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 5sDiese 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.