GSP768

Übersicht

Die Google Kubernetes Engine bietet horizontale und vertikale Lösungen für die automatische Skalierung Ihrer Pods und Ihrer Infrastruktur. Wenn es um Kostenoptimierung geht, sind diese Tools äußerst nützlich, um sicherzustellen, dass Ihre Arbeitslasten so effizient wie möglich ausgeführt werden und dass Sie nur für das bezahlen, was Sie tatsächlich nutzen.

In diesem Lab werden horizontales Pod-Autoscaling und vertikales Pod-Autoscaling für die Skalierung auf Pod-Ebene sowie Cluster Autoscaler (horizontale Infrastrukturlösung) und automatische Knotenbereitstellung (vertikale Infrastrukturlösung) für Skalierung auf Knotenebene eingerichtet und beobachtet. Zuerst verwenden Sie diese Tools zur automatischen Skalierung, um so viele Ressourcen wie möglich einzusparen und die Größe Ihres Clusters in Zeiträumen mit weniger Nachfrage zu verringern. Dann werden Sie die Nachfrage Ihres Clusters erhöhen und beobachten, wie die automatische Skalierung die Verfügbarkeit aufrechterhält.

Lernziele

Aufgaben in diesem Lab:

• Die Anzahl der Replikate für ein Deployment mit horizontalem Pod-Autoscaling verringern
• Die CPU-Anforderung eines Deployments mit vertikalem Pod-Autoscaling verringern
• Die Anzahl der im Cluster verwendeten Knoten mit Cluster-Autoscaling verringern
• Einen optimierten Knotenpool für Arbeitslasten mit automatischer Knotenbereitstellung erstellen
• Testen des Autoscaling-Verhaltens bei Nachfragespitzen
• Überdimensionierung Ihres Clusters mit Pausen-Pods

Einrichtung und Anforderungen

Vor dem Klick auf „Start Lab“ (Lab starten)

Lesen Sie diese Anleitung. Labs sind zeitlich begrenzt und können nicht pausiert werden. Der Timer beginnt zu laufen, wenn Sie auf Lab starten klicken, und zeigt Ihnen, wie lange die Ressourcen für das Lab verfügbar sind.

In diesem praxisorientierten Lab können Sie die Lab-Aktivitäten in einer echten Cloud-Umgebung selbst durchführen – nicht in einer Simulations- oder Demo-Umgebung. Dazu erhalten Sie neue, temporäre Anmeldedaten, mit denen Sie für die Dauer des Labs auf Google Cloud zugreifen können.

Für dieses Lab benötigen Sie Folgendes:

• Einen Standardbrowser (empfohlen wird Chrome)

Hinweis: Nutzen Sie den privaten oder Inkognitomodus, um dieses Lab durchzuführen. So wird verhindert, dass es zu Konflikten zwischen Ihrem persönlichen Konto und dem Teilnehmerkonto kommt und zusätzliche Gebühren für Ihr persönliches Konto erhoben werden.

• Zeit für die Durchführung des Labs – denken Sie daran, dass Sie ein begonnenes Lab nicht unterbrechen können.

Hinweis: Wenn Sie über ein persönliches Google Cloud-Konto oder -Projekt verfügen, verwenden Sie es nicht für dieses Lab. So werden zusätzliche Kosten für Ihr Konto vermieden.

Lab starten und bei der Google Cloud Console anmelden

1. Klicken Sie auf Lab starten. Wenn Sie für das Lab bezahlen müssen, wird ein Pop-up-Fenster geöffnet, in dem Sie Ihre Zahlungsmethode auswählen können. Auf der linken Seite befindet sich der Bereich Details zum Lab mit diesen Informationen:

   • Schaltfläche Google Cloud Console öffnen
   • Restzeit
   • Temporäre Anmeldedaten für das Lab
   • Ggf. weitere Informationen für dieses Lab

2. Klicken Sie auf Google Cloud Console öffnen (oder klicken Sie mit der rechten Maustaste und wählen Sie Link in Inkognitofenster öffnen aus, wenn Sie Chrome verwenden).

   Im Lab werden Ressourcen aktiviert. Anschließend wird ein weiterer Tab mit der Seite Anmelden geöffnet.

   Tipp: Ordnen Sie die Tabs nebeneinander in separaten Fenstern an.

   Hinweis: Wird das Dialogfeld Konto auswählen angezeigt, klicken Sie auf Anderes Konto verwenden.

3. Kopieren Sie bei Bedarf den folgenden Nutzernamen und fügen Sie ihn in das Dialogfeld Anmelden ein.

   {{{user_0.username | "Username"}}}

   Sie finden den Nutzernamen auch im Bereich Details zum Lab.

4. Klicken Sie auf Weiter.

5. Kopieren Sie das folgende Passwort und fügen Sie es in das Dialogfeld Willkommen ein.

   {{{user_0.password | "Password"}}}

   Sie finden das Passwort auch im Bereich Details zum Lab.

6. Klicken Sie auf Weiter.

   Wichtig: Sie müssen die für das Lab bereitgestellten Anmeldedaten verwenden. Nutzen Sie nicht die Anmeldedaten Ihres Google Cloud-Kontos. Hinweis: Wenn Sie Ihr eigenes Google Cloud-Konto für dieses Lab nutzen, können zusätzliche Kosten anfallen.

7. Klicken Sie sich durch die nachfolgenden Seiten:

   • Akzeptieren Sie die Nutzungsbedingungen.
   • Fügen Sie keine Wiederherstellungsoptionen oder Zwei-Faktor-Authentifizierung hinzu (da dies nur ein temporäres Konto ist).
   • Melden Sie sich nicht für kostenlose Testversionen an.

Nach wenigen Augenblicken wird die Google Cloud Console in diesem Tab geöffnet.

Hinweis: Wenn Sie sich eine Liste der Google Cloud-Produkte und ‑Dienste ansehen möchten, klicken Sie oben links auf das Navigationsmenü.

Cloud Shell aktivieren

Cloud Shell ist eine virtuelle Maschine, auf der Entwicklertools installiert sind. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud. Mit Cloud Shell erhalten Sie Befehlszeilenzugriff auf Ihre Google Cloud-Ressourcen.

1. Klicken Sie oben in der Google Cloud Console auf Cloud Shell aktivieren .

Wenn Sie verbunden sind, sind Sie bereits authentifiziert und das Projekt ist auf Ihre Project_ID, eingestellt. Die Ausgabe enthält eine Zeile, in der die Project_ID für diese Sitzung angegeben ist:

Ihr Cloud-Projekt in dieser Sitzung ist festgelegt als {{{project_0.project_id | "PROJECT_ID"}}}

gcloud ist das Befehlszeilentool für Google Cloud. Das Tool ist in Cloud Shell vorinstalliert und unterstützt die Tab-Vervollständigung.

2. (Optional) Sie können den aktiven Kontonamen mit diesem Befehl auflisten:

gcloud auth list

3. Klicken Sie auf Autorisieren.

Ausgabe:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} Um das aktive Konto festzulegen, führen Sie diesen Befehl aus: $ gcloud config set account `ACCOUNT`

4. (Optional) Sie können die Projekt-ID mit diesem Befehl auflisten:

gcloud config list project

Ausgabe:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Hinweis: Die vollständige Dokumentation für gcloud finden Sie in Google Cloud in der Übersicht zur gcloud CLI.

Bereitstellung einer Testumgebung

1. Stellen Sie Ihre Standardzone auf ein:

gcloud config set compute/zone {{{project_0.default_zone | zone}}}

2. Führen Sie den folgenden Befehl aus, um einen Drei-Knoten-Cluster in der Zone zu erstellen:

gcloud container clusters create scaling-demo --num-nodes=3 --enable-vertical-pod-autoscaling

Um die horizontale Pod-Autoskalierung zu demonstrieren, verwendet dieses Lab ein benutzerdefiniertes Docker-Image, das auf dem php-apache Image basiert. Es definiert eine index.php Seite, die einige CPU-intensive Berechnungen durchführt. Sie überwachen das Deployment dieses Images.

3. Erstellen Sie ein Manifest für ein php-apache Deployment:

cat << EOF > php-apache.yaml apiVersion: apps/v1 kind: Deployment metadata: name: php-apache spec: selector: matchLabels: run: php-apache replicas: 3 template: metadata: labels: run: php-apache spec: containers: - name: php-apache image: k8s.gcr.io/hpa-example ports: - containerPort: 80 resources: limits: cpu: 500m requests: cpu: 200m --- apiVersion: v1 kind: Service metadata: name: php-apache labels: run: php-apache spec: ports: - port: 80 selector: run: php-apache EOF

4. Wenden Sie das neu erstellte Manifest auf Ihren Cluster an:

kubectl apply -f php-apache.yaml

Klicken Sie auf Fortschritt prüfen. Bereitstellung einer Testumgebung

Aufgabe 1: Pods mit horizontalem Pod-Autoscaling skalieren

Horizontales Pod-Autoscaling ändert die Form Ihrer Kubernetes-Arbeitslast, indem die Anzahl der Pods in Abhängigkeit von der CPU- oder Speicherauslastung der Arbeitslast automatisch erhöht oder verringert wird. Dies kann auch als Reaktion auf benutzerdefinierte Messwerte erfolgen, die innerhalb von Kubernetes gemeldet werden, oder als Reaktion auf externe Messwerte aus Quellen außerhalb Ihres Clusters.

1. Führen Sie in Cloud Shell den folgenden Befehl aus, um die Deployments Ihres Clusters zu überprüfen:

kubectl get deployment

Sie sollten jetzt das php-apache Deployment mit 3/3 ausgeführten Pods sehen:

NAME READY UP-TO-DATE AVAILABLE AGE php-apache 3/3 3 3 91s Hinweis: Wenn Sie keine 3 verfügbaren Pods sehen, warten Sie eine Minute, bis die Pods erstellt sind, und führen Sie den vorherigen Befehl erneut aus. Wenn Sie 1/1 verfügbare Pods sehen, ist wahrscheinlich genug Zeit verstrichen, um Ihre Bereitstellung herunterzuskalieren.

2. Wenden Sie horizontales Autoscaling auf das php-apache Deployment an:

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

Klicken Sie auf Fortschritt prüfen. Pods mit horizontalem Pod-Autoscaling skalieren

Mit diesem autoscale-Befehl wird ein horizontales Pod-Autoscaling konfiguriert, das zwischen 1 und 10 Replikate der Pods verwaltet, die von der php-apache Bereitstellung gesteuert werden. Der cpu-percent-Flag gibt 50 % als angestrebte durchschnittliche CPU-Auslastung der angeforderten CPU über alle Pods hinweg an. HPA passt die Anzahl der Replikate (über die Bereitstellung) an, um eine durchschnittliche CPU-Auslastung von 50 % über alle Pods hinweg aufrechtzuerhalten.

3. Überprüfen Sie den aktuellen Status Ihres horizontalen Pod-Autoscalers:

kubectl get hpa

In der Spalte Ziele sollten Sie 1 %/50 % sehen.

Dies bedeutet, dass die Pods in Ihrem Deployment derzeit 1 % ihrer durchschnittlichen Ziel-CPU-Auslastung erreicht haben. Dies ist zu erwarten, da die Anwendung php-apache im Moment keinen Traffic erhält.

Hinweis: Sehen Sie <unknown>/50%, warten Sie eine Minute und führen Sie den Befehl kubectl get hpa erneut aus. Ihr HPA hat bisher keine Bewertung erstellt.

Beachten Sie auch die Spalte Replikate. Zu Beginn wird der Wert 3 verwendet. Diese Zahl wird beim Autoscaling geändert, wenn sich die Anzahl der benötigten Pods ändert.

In diesem Fall skaliert der Autoscaler das Deployment auf die minimale Anzahl von Pods herunter, die beim Ausführen des Befehls autoscale angegeben wird. Das horizontale Pod-Autoscaling dauert 5–10 Minuten und erfordert je nach Skalierungsrichtung das Herunterfahren oder Starten neuer Pods.

Fahren Sie mit dem nächsten Schritt des Labs fort. Sie werden die Ergebnisse des Autoscalings später überprüfen.

Hinweis: Während Sie in diesem Lab cpu-percent als Zielmesswert für Ihren Autoscaler verwenden, ermöglicht HPA die Definition benutzerdefinierter Messwerte, sodass Sie Ihre Pods auf der Grundlage anderer nützlicher Messwerte skalieren können, die in den Protokollen erfasst werden.

Aufgabe 2: Die Größe der Pods mit vertikalem Pod-Autoscaling skalieren

Dank vertikalem Pod-Autoscaling müssen Sie sich keine Gedanken mehr über die Werte machen, die Sie für die CPU‑ und Speicheranforderungen eines Containers angeben. Das Autoscaling kann Werte für CPU‑ und Speicheranforderungen und Limits empfehlen oder die Werte automatisch aktualisieren.

Hinweis: Vertikales Pod-Autoscaling sollte nicht zusammen mit horizontalem Pod-Autoscaling für CPU oder Speicher verwendet werden. Beide versuchen, auf Nachfrageänderungen anhand derselben Messwerte zu reagieren, und geraten dabei in Konflikt. Um Überschneidungen zu vermeiden, kann VPA auf CPU oder Speicher jedoch zusammen mit HPA auf benutzerdefinierten Messwerten verwendet werden.

Vertikales Pod-Autoscaling wurde bereits auf dem scaling-demo Cluster aktiviert.

1. Führen Sie zur Überprüfung Folgendes aus:

gcloud container clusters describe scaling-demo | grep ^verticalPodAutoscaling -A 1

Die Ausgabe sollte enabled: true sein.

Hinweis: Vertikales Pod-Autoscaling kann auf einem bestehenden Cluster mit gcloud container clusters update scaling-demo --enable-vertical-pod-autoscaling aktiviert werden

Um VPA zu demonstrieren, stellen Sie die Anwendung hello-server bereit.

2. Wenden Sie das Deployment hello-server auf Ihren Cluster an:

kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0

3. Prüfen Sie, ob das Deployment erfolgreich erstellt wurde:

kubectl get deployment hello-server

4. Weisen Sie dem Deployment eine CPU-Ressourcenanforderung von 450m zu:

kubectl set resources deployment hello-server --requests=cpu=450m

5. Führen Sie als Nächstes diesen Befehl aus, um die Container-Spezifikationen des hello-server-Pods zu überprüfen:

kubectl describe pod hello-server | sed -n "/Containers:$/,/Conditions:/p"

• In der Ausgabe finden Sie Anfragen. Beachten Sie, dass dieser Pod derzeit die von Ihnen zugewiesene CPU-Kapazität von 450m anfordert.

6. Erstellen Sie ein Manifest für Ihren vertikalen Pod-Autoscaler:

cat << EOF > hello-vpa.yaml apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: hello-server-vpa spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: hello-server updatePolicy: updateMode: "Off" EOF

Im obigen Beispiel wird ein vertikaler Pod-Autoscaler erstellt, der auf das Deployment hello-server mit einer Update-Richtlinie von Off abzielt. Ein VPA kann eine von drei verschiedenen Update-Richtlinien haben, die je nach Anwendung nützlich sein können:

• Off: Diese Richtlinie bedeutet, dass der VPA auf der Grundlage von Verlaufsdaten Empfehlungen erstellt, die Sie manuell anwenden können.
• Initial: VPA-Empfehlungen werden einmalig zum Erstellen neuer Pods verwendet. Die Pod-Größe wird danach nicht mehr geändert.
• Auto: Pods werden regelmäßig gelöscht und neu erstellt, um der Größe der Empfehlungen zu entsprechen.

7. Wenden Sie das Manifest auf hello-vpa an:

kubectl apply -f hello-vpa.yaml

8. Warten Sie eine Minute und rufen Sie dann den VerticalPodAutoscaler auf:

kubectl describe vpa hello-server-vpa

Suchen Sie am Ende der Ausgabe nach den „Container-Empfehlungen“. Wenn Sie diese nicht sehen, warten Sie noch etwas und führen Sie den vorherigen Befehl erneut aus. Sobald sie angezeigt werden, sehen Sie mehrere unterschiedliche Empfehlungstypen, jeweils mit Werten für CPU und Speicher:

• Untergrenze: Dies ist die untere Grenze, die der VPA zum Auslösen einer Größenänderung betrachtet. Wenn Ihre Pod-Auslastung darunter fällt, löscht der VPA den Pod und verkleinert ihn.
• Ziel: Dies ist der Wert, den der VPA beim Ändern der Größe des Pods verwendet.
• Unbegrenztes Ziel: Wenn dem VPA keine Mindest‑ oder Maximalkapazität zugewiesen ist, ist dies die Zielauslastung für den VPA.
• Obergrenze: Dies ist die Obergrenze, die der VPA zum Auslösen einer Größenänderung betrachtet. Wenn Ihre Pod-Auslastung diesen Wert überschreitet, löscht der VPA den Pod und skaliert ihn hoch.

Sie werden feststellen, dass der VPA empfiehlt, die CPU-Anforderung für diesen Container auf 25m anstelle der vorherigen 100m festzulegen und Ihnen außerdem einen Wert für die anzufordernde Speichermenge vorschlägt. An diesem Punkt können diese Empfehlungen manuell auf das hello-server-Deployment angewendet werden.

Hinweis: Vertikales Pod-Autoscaling basiert seine Empfehlungen auf Verlaufsdaten des Containers. In der Praxis empfiehlt es sich, mindestens 24 Stunden zu warten, um Empfehlungsdaten zu erheben, bevor man Änderungen vornimmt.

9. Um den VPA und seine Auswirkungen in diesem Lab zu beobachten, ändern Sie die hello-vpa-Update-Richtlinie auf Auto und beobachten die Skalierung.

10. Aktualisieren Sie das Manifest, um die Richtlinie auf Auto zu setzen und wenden Sie die Konfiguration an:

sed -i 's/Off/Auto/g' hello-vpa.yaml kubectl apply -f hello-vpa.yaml

Um die Größe eines Pods zu ändern, muss der vertikale Pod-Autoscaler diesen Pod löschen und in der gewünschten Größe neu erstellen. Um Ausfallzeiten zu vermeiden, löscht der VPA standardmäßig nicht den letzten aktiven Pod und passt auch dessen Größe nicht an. Aus diesem Grund benötigen Sie mindestens zwei Replikate, um zu sehen, dass der VPA Änderungen vornimmt.

11. Skalieren Sie das hello-server-Deployment auf zwei Replikate:

kubectl scale deployment hello-server --replicas=2

12. Sehen Sie sich jetzt Ihre Pods an:

kubectl get pods -w

13. Warten Sie, bis Sie Ihre hello-server-xxx-Pods im Status Wird beendet oder im Status Ausstehend sehen (oder gehen Sie zu Kubernetes Engine > Arbeitslasten):

Dies ist ein Zeichen dafür, dass Ihr VPA Ihre Pods löscht und deren Größe ändert. Sobald Sie dies sehen, drücken Sie Strg + c, um den Befehl zu beenden.

Klicken Sie auf Fortschritt prüfen. Die Größe der Pods mit vertikalem Pod-Autoscaling skalieren

Aufgabe 3: HPA-Ergebnisse

An diesem Punkt wird der horizontale Pod-Autoscaler wahrscheinlich Ihr php-apache-Deployment herunterskaliert haben.

1. Führen Sie diesen Befehl aus, um Ihren HPA zu überprüfen:

kubectl get hpa

• Schauen Sie in der Spalte Replikate nach. Sie werden sehen, dass Ihr php-apache-Deployment auf 1 Pod herunterskaliert wurde.

Hinweis: Wenn Sie immer noch 3 Replikate für Ihr php-apache-Deployment sehen, warten Sie noch ein paar Minuten, bis der Autoscaler aktiv wird.

• Der HPA nutzt die Tatsache, dass die Anwendung gerade inaktiv ist und entfernt alle ungenutzten Ressourcen. Außerdem würde die Anwendung php-apache bei einer höheren Nachfrage wieder skalieren, um die Last zu bewältigen.

Hinweis: Wenn die Verfügbarkeit Ihrer Anwendung ein Hauptanliegen ist, gilt es als bewährte Praxis, einen etwas höheren Puffer als Mindestanzahl von Pods für Ihren horizontalen Pod-Autoscaler zu belassen, um die für die Skalierung erforderliche Zeit zu berücksichtigen.

Dies ist besonders mit Blick auf Kostenoptimierung äußerst nützlich. Ein gut abgestimmter Autoscaler bedeutet, dass Ihre Anwendung hochgradig verfügbar bleibt, und Sie dabei nur für die Ressourcen zahlen, die zur Aufrechterhaltung dieser Verfügbarkeit erforderlich sind, unabhängig von der Nachfrage.

Aufgabe 4: VPA-Ergebnisse

Jetzt sollte der VPA die Größe Ihrer Pods im Deployment hello-server angepasst haben.

1. Überprüfen Sie Ihre Pods:

kubectl describe pod hello-server | sed -n "/Containers:$/,/Conditions:/p"

2. Suchen Sie das Feld Anfragen:.

• Ihr vertikaler Pod-Autoscaler hat die Pods mit ihren Zielauslastungen neu erstellt. Jetzt sollte er eine geringere Menge an CPU und auch eine bestimmte Kapazität an Speicher anfordern:

Requests: cpu: 25m memory: 262144k Hinweis: Wenn Sie immer noch eine CPU-Anforderung von 450m für einen der Pods sehen, setzen Sie die CPU-Ressource manuell mit diesem Befehl auf das Ziel: kubectl set resources deployment hello-server --requests=cpu=25m . Manchmal braucht der VPA im Automodus sehr lange oder legt ungenaue obere oder untere Grenzwerte fest, wenn keine Zeit für die Erfassung genauer Daten bleibt. Um keine Zeit im Lab zu verlieren, können Sie einfach die Empfehlung so verwenden, als ob sie im „Off“-Modus wäre.

In diesem Fall ist der VPA ein hervorragendes Instrument zur Optimierung der Ressourcennutzung und damit zur Kosteneinsparung. Die ursprüngliche Anforderung von 400m CPU war höher als der Bedarf dieses Containers. Indem Sie die Anforderung auf die empfohlenen 25m anpassen, können Sie weniger CPU aus dem Knotenpool verwenden, sodass möglicherweise weniger Knoten im Cluster bereitgestellt werden müssen.

Mit der Auto-Update-Richtlinie würde Ihr VPA die Pods des hello-server-Deployment während der gesamten Lebensdauer löschen und ihre Größe ändern. Bei größeren Anfragen könnten Pods hochskaliert werden, um starken Traffic zu bewältigen, und während einer Ausfallzeit wieder herunterskaliert werden. Dies kann bei einer stetig steigenden Nachfrage nach Ihrer Anwendung von Nutzen sein. Es besteht jedoch das Risiko eines Verfügbarkeitsverlusts bei starken Spitzenwerten.

Je nach Anwendung ist es im Allgemeinen am sichersten, den VPA mit der Update-Richtlinie Off zu aktualisieren und die Empfehlungen nach Bedarf zu befolgen, um sowohl die Ressourcennutzung zu optimieren als auch die Verfügbarkeit Ihres Clusters zu maximieren.

In den nächsten Abschnitten erfahren Sie, wie Sie Ihre Ressourcennutzung mit dem Cluster Autoscaler und der automatischen Knotenbereitstellung weiter optimieren können.

Aufgabe 5: Cluster Autoscaler

Der Cluster Autoscaler ist so konzipiert, dass Knoten je nach Bedarf hinzugefügt oder entfernt werden können. Wenn die Nachfrage hoch ist, fügt der Cluster Autoscaler dem Knotenpool Knoten hinzu, um die Nachfrage zu decken. Wenn die Nachfrage gering ist, skaliert der Cluster Autoscaler Ihren Cluster zurück, indem er Knoten entfernt. Auf diese Weise können Sie die hohe Verfügbarkeit Ihres Clusters aufrechterhalten und gleichzeitig überflüssige Kosten im Zusammenhang mit zusätzlichen Maschinen minimieren.

1. Aktivieren Sie Autoscaling für Ihren Cluster:

gcloud beta container clusters update scaling-demo --enable-autoscaling --min-nodes 1 --max-nodes 5

Das dauert einige Minuten.

Bei der Skalierung eines Clusters ist die Entscheidung, wann ein Knoten entfernt werden soll, ein Kompromiss zwischen der Optimierung der Auslastung und der Verfügbarkeit von Ressourcen. Mit dem Entfernen zu wenig genutzter Knoten wird die Clusterauslastung verbessert, neue Arbeitslasten müssen jedoch vor ihrer Ausführung möglicherweise warten, bis Ressourcen wieder bereitgestellt werden.

Sie können angeben, welches Autoscaling-Profil bei solchen Entscheidungen verwendet werden soll. Derzeit sind folgende Profile verfügbar:

• Ausgeglichen: Das Standardprofil.
• Auslastung optimieren: Die Optimierung der Auslastung hat Vorrang vor dem Vorhalten freier Ressourcen im Cluster. Wenn diese Option ausgewählt ist, skaliert der Cluster Autoscaler den Cluster aggressiver herunter. Es können mehr Knoten in kürzerer Zeit entfernt werden. Dieses Profil wurde für die Verwendung mit Batch-Arbeitslasten optimiert, die nicht anfällig für Startlatenz sind.

2. Wechseln Sie auf das Autoscaling-Profil Auslastung optimieren, sodass Sie die Auswirkungen der Skalierung in vollem Umfang beobachten können:

gcloud beta container clusters update scaling-demo \ --autoscaling-profile optimize-utilization

3. Beobachten Sie Ihren Cluster bei aktivierter automatischer Skalierung in der Cloud Console. Klicken Sie auf die drei Balken oben links, um das Navigationsmenü zu öffnen.

4. Klicken Sie im Navigationsmenü auf Kubernetes Engine > Cluster.

5. Wählen Sie auf der Seite Cluster den Cluster scaling-demo.

6. Wählen Sie auf der Clusterseite der Skalierungsdemo den Tab Knoten.

7. Werfen Sie einen Blick auf die Übersicht zur Ressourcenauslastung Ihrer 3 Knoten.

Hinweis: Ihre Zahlen können von den abgebildeten abweichen. Die Bereitstellung und Zuweisung von Ressourcen durch Kubernetes erfolgt nicht jedes Mal auf die gleiche Weise

Kombiniert man die Werte von angeforderte CPU und zuweisbare CPU für die 3 Knoten, wären die Gesamtmengen 1555m bzw. 2820m. Dies bedeutet, dass im gesamten Cluster insgesamt 1265m CPU-Kapazitäten zur Verfügung stehen. Dies ist mehr, als von einem Knoten bereitgestellt werden könnte.

Um die Auslastung zu optimieren, könnte die derzeitige Arbeitslast bei ihrem aktuellen Bedarf auf 2 statt 3 Knoten konsolidiert werden. Ihr Cluster hat sich jedoch noch nicht automatisch herunterskaliert. Der Grund dafür sind die über den Cluster verteilten System-Pods.

Ihr Cluster führt eine Reihe von Deployments unter dem Namenspace kube-system aus, die das Funktionieren der verschiedenen GKE-Dienste wie Protokollierung, Überwachung, automatische Skalierung usw. ermöglichen.

8. Dies kann durch Ausführen dieses Befehls in Cloud Shell überprüft werden:

kubectl get deployment -n kube-system

Standardmäßig verhindern die meisten System-Pods aus diesen Deployments, dass der Cluster Autoscaler sie komplett offline nimmt, um sie neu zu planen. Im Allgemeinen ist dies erwünscht, da viele dieser Pods Daten erfassen, die in anderen Deployments und Diensten verwendet werden. Ein vorübergehender Ausfall von metrics-agent würde beispielsweise zu einer Lücke in den für VPA und HPA erfassten Daten führen. Der Ausfall des fluentd-Pods könnte eine Lücke in Ihren Cloud-Protokollen verursachen.

In diesem Lab wenden Sie Budget für Pod-Störungen auf Ihre kube-system-Pods an, was es dem Cluster Autoscaler ermöglicht, sie sicher auf einem anderen Knoten neu zu planen. So haben Sie genügend Platz, um Ihren Cluster zu verkleinern.

Budgets für Pod-Störungen (PDB) legen fest, wie Kubernetes mit Störungen wie Upgrades, Pod-Entfernungen, fehlenden Ressourcen usw. umgehen soll. In PDBs können Sie die max-unavailable- und/oder die min-available-Anzahl an Pods festlegen, die ein Deployment haben sollte.

9. Führen Sie diese Befehle aus, um die Budgets für Pod-Störungen für jeden Ihrer kube-system-Pods zu erstellen:

kubectl create poddisruptionbudget kube-dns-pdb --namespace=kube-system --selector k8s-app=kube-dns --max-unavailable 1 kubectl create poddisruptionbudget prometheus-pdb --namespace=kube-system --selector k8s-app=prometheus-to-sd --max-unavailable 1 kubectl create poddisruptionbudget kube-proxy-pdb --namespace=kube-system --selector component=kube-proxy --max-unavailable 1 kubectl create poddisruptionbudget metrics-agent-pdb --namespace=kube-system --selector k8s-app=gke-metrics-agent --max-unavailable 1 kubectl create poddisruptionbudget metrics-server-pdb --namespace=kube-system --selector k8s-app=metrics-server --max-unavailable 1 kubectl create poddisruptionbudget fluentd-pdb --namespace=kube-system --selector k8s-app=fluentd-gke --max-unavailable 1 kubectl create poddisruptionbudget backend-pdb --namespace=kube-system --selector k8s-app=glbc --max-unavailable 1 kubectl create poddisruptionbudget kube-dns-autoscaler-pdb --namespace=kube-system --selector k8s-app=kube-dns-autoscaler --max-unavailable 1 kubectl create poddisruptionbudget stackdriver-pdb --namespace=kube-system --selector app=stackdriver-metadata-agent --max-unavailable 1 kubectl create poddisruptionbudget event-pdb --namespace=kube-system --selector k8s-app=event-exporter --max-unavailable 1

Klicken Sie auf Fortschritt prüfen. Cluster Autoscaler

In jedem dieser Befehle wählen Sie einen anderen kube-system-Deployment-Pod auf der Grundlage eines bei der Erstellung definierten Labels und mit der Angabe, dass für jedes dieser Deployments ein nicht verfügbarer Pod vorhanden sein kann. Dadurch kann der Autoscaler die System-Pods neu einplanen.

Mit den PDBs sollte Ihr Cluster in 1 oder 2 Minuten von 3 auf 2 Knoten skaliert werden.

10. Führen Sie diesen Befehl in Cloud Shell erneut aus, bis Sie insgesamt nur noch 2 Knoten sehen:

kubectl get nodes

Aktualisieren Sie in der Cloud Console den Tab Knoten Ihrer scaling-demo, um zu überprüfen, wie Ihre Ressourcen gepackt wurden:

Sie haben eine Automatisierung eingerichtet, die Ihren Cluster von 3 auf 2 Knoten verkleinert.

Was die Kosten angeht, so werden Ihnen durch die Verkleinerung Ihres Knotenpools in Zeiten geringerer Nachfrage in Ihrem Cluster weniger Maschinen in Rechnung gestellt. Diese Skalierung könnte sogar noch dramatischer ausfallen, wenn Ihr Bedarf während des Tages zwischen Zeiten mit hohem und niedrigem Bedarf schwanken würde.

Beachten Sie, dass der Cluster Autoscaler zwar einen unnötigen Knoten entfernt hat, aber das vertikale Pod-Autoscaling und das horizontale Pod-Autoscaling dazu beigetragen haben, die CPU-Nachfrage so weit zu reduzieren, dass der Knoten nicht mehr benötigt wurde. Die Kombination dieser Tools ist eine hervorragende Möglichkeit, Ihre Gesamtkosten und Ihren Ressourcenverbrauch zu optimieren.

Der Cluster Autoscaler hilft also beim Hinzufügen und Entfernen von Knoten als Reaktion auf Pods, die geplant werden müssen. GKE verfügt jedoch über eine weitere Funktion zur vertikalen Skalierung, die automatische Knotenbereitstellung.

Aufgabe 6: Automatische Knotenbereitstellung

Automatische Knotenbereitstellung (NAP) fügt tatsächlich neue Knotenpools hinzu, die der Nachfrage entsprechend dimensioniert sind. Ohne die automatische Knotenbereitstellung erstellt der Cluster Autoscaler nur neue Knoten in den von Ihnen angegebenen Knotenpools, d. h., die neuen Knoten sind vom gleichen Maschinentyp wie die anderen Knoten in diesem Pool. Dies ist ideal, um die Ressourcennutzung für Batch-Workloads und andere Anwendungen zu optimieren, die keine extreme Skalierung benötigen, da die Erstellung eines Knotenpools, der speziell für Ihren Anwendungsfall optimiert ist, mehr Zeit in Anspruch nehmen kann als das Hinzufügen weiterer Knoten zu einem bestehenden Pool.

• Automatische Knotenbereitstellung (Node Auto Provisioning – NAP) aktivieren:

gcloud container clusters update scaling-demo \ --enable-autoprovisioning \ --min-cpu 1 \ --min-memory 2 \ --max-cpu 45 \ --max-memory 160

In diesem Befehl geben Sie eine Mindest- und Höchstzahl für Ihre CPU- und Speicherressourcen an. Dies gilt für den gesamten Cluster.

NAP kann etwas Zeit in Anspruch nehmen, und es ist auch sehr wahrscheinlich, dass kein neuer Knotenpool für den scaling-demo Cluster in seinem aktuellen Zustand erstellt wird.

In den nächsten Abschnitten werden Sie die Nachfrage nach Ihrem Cluster erhöhen und die Aktionen Ihrer Autoscaler sowie von NAP beobachten.

Klicken Sie auf Fortschritt prüfen. Automatische Knotenbereitstellung

Aufgabe 7: Test mit höherer Nachfrage

Bisher haben Sie analysiert, wie HPA, VPA und Cluster Autoscaler dazu beitragen können, Ressourcen und Kosten zu sparen, wenn Ihre Anwendung nur eine geringe Nachfrage hat. Jetzt werden Sie sehen, wie diese Tools die Verfügbarkeit bei erhöhter Nachfrage handhaben.

1. Öffnen Sie einen neuen Tab in Cloud Shell, indem Sie auf das Symbol + klicken:

2. Führen Sie auf dem neuen Tab diesen Befehl aus, um eine Endlosschleife von Abfragen an den Dienst php-apache zu senden:

kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

3. Gehen Sie auf Ihren ursprünglichen Cloud Shell -Tab zurück.

4. Innerhalb von etwa einer Minute sollten Sie die höhere CPU-Auslastung Ihres HPA erkennen, indem Sie Folgendes ausführen:

kubectl get hpa

Warten Sie und führen Sie den Befehl erneut aus, bis Ihr Ziel über 100 % liegt.

5. Überwachen Sie nun, wie Ihr Cluster die erhöhte Last bewältigt, indem Sie regelmäßig diesen Befehl ausführen:

kubectl get deployment php-apache

Sie können Ihren Cluster auch überwachen, indem Sie den Tab Knoten in Ihrer Cloud Console aktualisieren.

Warten Sie ein paar Minuten, bis etwas passiert.

• Zuerst wird Ihr php-apache Deployment von HPA automatisch hochskaliert, um die erhöhte Last zu bewältigen.
• Dann muss der Cluster Autoscaler neue Knoten bereitstellen, um die erhöhte Nachfrage zu bewältigen.
• Schließlich wird durch die automatische Knotenbereitstellung ein Knotenpool erstellt, der für die CPU- und Speicheranforderungen der Arbeitslasten Ihres Clusters optimiert ist. In diesem Fall sollte es sich um einen Knotenpool mit hoher CPU-Leistung und wenig Arbeitsspeicher handeln, da der Belastungstest an die Grenzen der CPU geht.

Warten Sie, bis Ihr Deployment php-apache auf sieben Replikate hochskaliert ist und Ihr Knoten-Tab in etwa so aussieht:

6. Kehren Sie zum Tab Cloud Shell zurück, in dem Sie den Lasttest ausgeführt haben, und brechen Sie mit Strg + c ab. Ihr Cluster wird nun schließlich wieder verkleinert, wenn die Nachfrage wieder sinkt.

Ihr Cluster skaliert effizient, um eine höhere Nachfrage zu bedienen. Beachten Sie jedoch, wie lange es gedauert hat, diese Nachfragespitze zu bewältigen. Für viele Anwendungen kann der Verlust der Verfügbarkeit bei der Bereitstellung neuer Ressourcen ein Problem darstellen.

Aufgabe 8: Größere Lasten optimieren

Bei der Skalierung für größere Lasten werden bei der horizontalen Pod-Autoskalierung neue Pods hinzugefügt, während bei der vertikalen Pod-Autoskalierung die Größe der Pods je nach Ihren Einstellungen angepasst wird. Wenn auf einem vorhandenen Knoten Platz ist, kann er das Abrufen des Images überspringen und sofort mit der Ausführung der Anwendung auf einem neuen Pod beginnen. Wenn Sie mit einem Knoten arbeiten, der Ihre Anwendung noch nicht bereitgestellt hat, kann es etwas länger dauern, bis er die Container-Images heruntergeladen hat, bevor er sie ausführt.

Wenn Sie also nicht genügend Platz auf Ihren vorhandenen Knoten haben und den Cluster Autoscaler verwenden, kann es sogar noch länger dauern. Jetzt muss er einen neuen Knoten bereitstellen, ihn einrichten, dann das Image herunterladen und die Pods starten. Wenn das Auto-Provisioning einen neuen Knotenpool erstellt, wie es in Ihrem Cluster der Fall war, benötigen Sie sogar noch mehr Zeit, da Sie zuerst den neuen Knotenpool bereitstellen und dann die gleichen Schritte für den neuen Knoten durchführen müssen.

Hinweis: In der Praxis ist es wichtig, dass Ihre Anwendung so kleine Container-Images wie möglich verwendet. Kleinere Images verbessern die Kaltstartzeit eines Pods, denn je kleiner das Image ist, desto schneller kann der Knoten es herunterladen, wenn der Cluster Autoscaler einen neuen Knoten für Ihren Cluster bereitstellt. Darüber hinaus können größere Images zu längeren Pod-Startzeiten führen, was bei Trafficspitzen zu einer schlechten Leistung bei der Bereitstellung neuer Knoten führt.

Um diese unterschiedlichen Latenzen beim Autoscaling zu bewältigen, sollten Sie etwas mehr überdimensionieren, damit Ihre Anwendungen beim automatischen Hochskalieren weniger unter Druck geraten. Dies ist für die Kostenoptimierung sehr wichtig. Schließlich wollen Sie vermeiden, mehr für Ressourcen zu bezahlen, als Sie benötigen. Allerdings wollen Sie auch nicht, dass die Leistung Ihrer Anwendungen beeinträchtigt wird.

Um herauszufinden, wie hoch die Überdimensionierung sein sollte, können Sie diese Formel verwenden:

Denken Sie beispielsweise an die CPU-Auslastung für Ihren Cluster. Sie möchten nicht, dass 100 % erreicht werden, daher könnten Sie einen Puffer von 15 % wählen, um einen Sicherheitsabstand einzuhalten. Die Traffic-Variable in der Formel wäre dann der Prozentsatz des geschätzten Traffic-Wachstums in den nächsten zwei bis drei Minuten. In dem Belastungstest, den Sie vorhin durchgeführt haben, war 0 % auf 150 % ein ziemlich extremes Wachstumsbeispiel. Stellen Sie sich stattdessen ein mehr dem Durchschnitt entsprechendes Traffic-Wachstum von 30 % vor.

Mit diesen Zahlen lässt sich ein Sicherheitspuffer von ca. 65 % errechnen. Dies bedeutet, dass Sie Ihre Ressourcen möglicherweise um etwa 65 % überdimensionieren sollten, um eine Skalierung zu bewältigen und gleichzeitig etwaige Probleme zu minimieren.

Eine effiziente Strategie zur Überdimensionierung eines Clusters mit Cluster-Autoscaling ist die Verwendung von Pausen-Pods.

Pausen-Pods sind Deployments mit niedriger Priorität, die entfernt und durch Deployments mit hoher Priorität ersetzt werden können. Das bedeutet, dass Sie Pods mit niedriger Priorität erstellen können, die eigentlich nichts tun, außer Pufferplatz zu reservieren. Wenn der Pod mit höherer Priorität Platz benötigt, werden die Pausen-Pods entfernt und auf einen anderen oder neuen Knoten verschoben, und der Pod mit höherer Priorität bekommt den Platz, den er für eine schnelle Planung benötigt.

1. Erstellen Sie ein Manifest für einen Pausen-Pod:

cat << EOF > pause-pod.yaml --- apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: overprovisioning value: -1 globalDefault: false description: "Priority class used by overprovisioning." --- apiVersion: apps/v1 kind: Deployment metadata: name: overprovisioning namespace: kube-system spec: replicas: 1 selector: matchLabels: run: overprovisioning template: metadata: labels: run: overprovisioning spec: priorityClassName: overprovisioning containers: - name: reserve-resources image: k8s.gcr.io/pause resources: requests: cpu: 1 memory: 4Gi EOF

2. Wenden Sie es auf Ihren Cluster an:

kubectl apply -f pause-pod.yaml

3. Warten Sie nun eine Minute und aktualisieren Sie dann den Tab Knoten Ihres Skalierungsdemo-Clusters.

Beobachten Sie, wie ein neuer Knoten erstellt wird, wahrscheinlich in einem neuen Knotenpool, der zu Ihrem neu erstellten Pausen-Pod passt. Wenn Sie den Belastungstest jetzt erneut ausführen und einen zusätzlichen Knoten für Ihr php-apache-Deployment benötigen, kann dieser auf dem Knoten mit Ihrem Pausen-Pod geplant werden, während Ihr Pausen-Pod stattdessen auf einem neuen Knoten platziert wird. Dies ist hervorragend, da Ihre Dummy-Pausen-Pods es Ihrem Cluster ermöglichen, im Voraus einen neuen Knoten bereitzustellen, sodass Ihre eigentliche Anwendung viel schneller skaliert werden kann. Wenn Sie mit einem höheren Datenverkehr rechnen, können Sie weitere Pausen-Pods hinzufügen. Es wird jedoch als bewährte Methode angesehen, nicht mehr als einen Pausen-Pod pro Knoten hinzuzufügen.

Klicken Sie auf Fortschritt prüfen. Größere Lasten optimieren

Das wars!

Sie haben das Lab erfolgreich abgeschlossen. In diesem Lab haben Sie einen Cluster so konfiguriert, dass er je nach Bedarf automatisch und effizient nach oben oder unten skaliert wird. Horizontales Pod-Autoscaling und vertikales Pod-Autoscaling bieten Lösungen für die automatische Skalierung der Bereitstellungen Ihres Clusters, während der Cluster Autoscaler und die automatische Knotenbereitstellung Lösungen für die automatische Skalierung der Infrastruktur Ihres Clusters bieten.

Wie immer hängt es von Ihrer Arbeitslast ab, welches dieser Tools Sie verwenden sollten. Durch sorgfältigen Einsatz dieser Autoscaler können Sie die Verfügbarkeit bei Bedarf maximieren und in Zeiten geringer Nachfrage nur für das bezahlen, was Sie benötigen. Im Hinblick auf die Kosten bedeutet dies, dass Sie Ihre Ressourcennutzung optimieren und Geld sparen.

Weitere Informationen

Mit diesen Ressourcen können Sie weitere Informationen zu den in diesem Lab behandelten Themen abrufen:

• Best Practices zum Ausführen kostenoptimierter Kubernetes-Anwendungen auf GKE: Feinabstimmung der automatischen Skalierung von GKE
• Dokumentation Cluster Autoscaler
• Dokumentation horizontaler Pod-Autoscaler
• Dokumentation Vertikaler Pod-Autoscaler

Google Cloud-Schulungen und -Zertifizierungen

In unseren Schulungen erfahren Sie alles zum optimalen Einsatz unserer Google Cloud-Technologien und können sich entsprechend zertifizieren lassen. Unsere Kurse vermitteln technische Fähigkeiten und Best Practices, damit Sie möglichst schnell mit Google Cloud loslegen und Ihr Wissen fortlaufend erweitern können. Wir bieten On-Demand-, Präsenz- und virtuelle Schulungen für Anfänger wie Fortgeschrittene an, die Sie individuell in Ihrem eigenen Zeitplan absolvieren können. Mit unseren Zertifizierungen weisen Sie nach, dass Sie Experte im Bereich Google Cloud-Technologien sind.

Anleitung zuletzt am 1. Februar 2024 aktualisiert

Lab zuletzt am 20. September 2023 getestet

© 2024 Google LLC. Alle Rechte vorbehalten. Google und das Google-Logo sind Marken von Google LLC. Alle anderen Unternehmens- und Produktnamen können Marken der jeweils mit ihnen verbundenen Unternehmen sein.