GSP769

Überblick

Einer der vielen Vorteile von Google Cloud ist das Abrechnungsmodell, bei dem nur die genutzten Ressourcen in Rechnung gestellt werden. Deshalb ist es wichtig, dass Sie nicht nur eine passende Menge an Ressourcen für Ihre Anwendungen und Infrastruktur bereitstellen, sondern diese auch möglichst effizient nutzen. Mit GKE gibt es eine Reihe von Tools und Strategien, die die Nutzung verschiedener Ressourcen und Dienste reduzieren und gleichzeitig die Verfügbarkeit von Anwendungen verbessern können.

In diesem Lab werden einige Konzepte für bessere Ressourceneffizienz und höhere Verfügbarkeit Ihrer Arbeitslasten vorgestellt. Wenn Sie die Arbeitslast Ihres Clusters genau kennen und entsprechend fein abstimmen, sorgen Sie leichter dafür, dass nur die benötigten Ressourcen verwendet und so die Kosten des Clusters optimiert werden.

Lernziele

Aufgaben in diesem Lab:

• Containernativen Load Balancer über Ingress erstellen
• Lasttest einer Anwendung
• Aktivitäts- und Bereitschaftsprüfungen konfigurieren
• Budget für Pod-Störungen erstellen

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.

Lab-Umgebung bereitstellen

1. Standardzone auf „“ festlegen:

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

2. Klicken Sie auf Autorisieren.

3. Cluster mit drei Knoten erstellen:

gcloud container clusters create test-cluster --num-nodes=3 --enable-ip-alias

Das Flag --enable-ip-alias ist vorhanden, damit Alias-IPs für Pods verwendet werden können. Das ist für natives Load Balancing von Containern über eingehenden Traffic erforderlich.

In diesem Lab verwenden Sie eine einfache HTTP-Webanwendung, die Sie anfänglich als einzelnen Pod bereitstellen.

4. Manifest für den Pod gb-frontend erstellen:

cat << EOF > gb_frontend_pod.yaml apiVersion: v1 kind: Pod metadata: labels: app: gb-frontend name: gb-frontend spec: containers: - name: gb-frontend image: gcr.io/google-samples/gb-frontend-amd64:v5 resources: requests: cpu: 100m memory: 256Mi ports: - containerPort: 80 EOF

5. Neu erstelltes Manifest auf Cluster anwenden:

kubectl apply -f gb_frontend_pod.yaml Hinweis: Bis Sie die Punktzahl für diese Aufgabe erhalten, kann es 1 bis 2 Minuten dauern.

Klicken Sie auf Fortschritt prüfen. Lab-Umgebung bereitstellen

Aufgabe 1: Containernatives Load Balancing über Ingress

Containernatives Load Balancing ermöglicht es Load Balancern, Pods direkt anzusteuern und Traffic gleichmäßig auf Pods zu verteilen.

Ohne containernatives Load Balancing wird der Load-Balancer-Traffic erst an die Knoteninstanzgruppen und dann über iptables-Regeln an Pods weitergeleitet, die sich im selben Knoten befinden können, aber nicht müssen.

Mit containernativem Load Balancing werden Pods zum zentralen Objekt dieses Vorgangs. Dadurch kann sich die Anzahl der Netzwerk-Hops verringern:

Weitere Effekte des containernativen Load Balancing sind ein effizienteres Routing, eine deutlich geringere Netzwerkauslastung, verbesserte Leistung, gleichmäßige Verteilung des Traffics auf die Pods und Systemdiagnosen auf Anwendungsebene.

Damit Sie die Vorteile des containernativen Load Balancing nutzen können, muss die VPC-native Einstellung auf dem Cluster aktiviert sein. Dies wurde bei der Erstellung des Clusters durch das Flag --enable-ip-alias angegeben.

1. Mit dem folgenden Manifest wird ein ClusterIP-Dienst konfiguriert, der Traffic zu Ihrem Anwendungs-Pod leitet, damit GKE eine Netzwerk-Endpunktgruppe erstellen kann:

cat << EOF > gb_frontend_cluster_ip.yaml apiVersion: v1 kind: Service metadata: name: gb-frontend-svc annotations: cloud.google.com/neg: '{"ingress": true}' spec: type: ClusterIP selector: app: gb-frontend ports: - port: 80 protocol: TCP targetPort: 80 EOF

Das Manifest umfasst ein Feld für Annotationen, wo Sie mit der Eingabe cloud.google.com/neg das containernative Load Balancing für Ihre Anwendung aktivieren, sobald eingehender Traffic entsteht.

2. Änderung auf den Cluster anwenden:

kubectl apply -f gb_frontend_cluster_ip.yaml

3. Als Nächstes erstellen Sie eingehenden Traffic für Ihre Anwendung:

cat << EOF > gb_frontend_ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: gb-frontend-ingress spec: defaultBackend: service: name: gb-frontend-svc port: number: 80 EOF

4. Änderung auf den Cluster anwenden:

kubectl apply -f gb_frontend_ingress.yaml

Wenn Sie den eingehenden Traffic erstellt haben, wird ein HTTP(S)-Load Balancer zusammen mit einer NEG (Netzwerk-Endpunktgruppe) in jeder Zone erstellt, in der der Cluster ausgeführt wird. Nach einigen Minuten wird dem eingehenden Traffic eine externe IP-Adresse zugewiesen.

Der von ihm erstellte Load Balancer hat einen Backend-Dienst, der in Ihrem Projekt ausgeführt wird und definiert, wie Cloud Load Balancing den Traffic verteilt. Diesem Backend-Dienst ist ein Funktionszustand zugeordnet.

5. Wenn Sie den Funktionszustand des Backend-Dienstes prüfen möchten, rufen Sie als Erstes den Namen ab:

BACKEND_SERVICE=$(gcloud compute backend-services list | grep NAME | cut -d ' ' -f2)

6. Funktionszustand des Dienstes abrufen:

gcloud compute backend-services get-health $BACKEND_SERVICE --global

Es dauert ein paar Minuten, bis die Systemdiagnose den Status „fehlerfrei“ zurückgibt.

Die Ausgabe sieht in etwa so aus:

--- backend: https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-00-27ced9534cde/zones/us-central1-a/networkEndpointGroups/k8s1-95c051f0-default-gb-frontend-svc-80-9b127192 status: healthStatus: - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-00-27ced9534cde/zones/us-central1-a/instances/gke-test-cluster-default-pool-7e74f027-47qp ipAddress: 10.8.0.6 port: 80 kind: compute#backendServiceGroupHealth Hinweis: Diese Systemdiagnosen erfolgen durch den Google Cloud Load Balancer und unterscheiden sich von den Überprüfungen zur Aktivität und Bereitschaft der Kubernetes API, mit denen der Zustand einzelner Pods ermittelt werden kann. Die Systemdiagnosen des Google Cloud Load Balancer verwenden spezielle Routen außerhalb der VPC Ihres Projekts, um den Systemzustand und die erfolgreiche oder gescheiterte Ausführung des Backends zu bestimmen.

Sobald die Systemdiagnose den Status FEHLERFREI für jede Instanz ergeben hat, können Sie auf die Anwendung über deren externe IP-Adresse zugreifen.

7. Rufen Sie diese so ab:

kubectl get ingress gb-frontend-ingress

8. Mit der Eingabe der externen IP-Adresse in einem Browserfenster wird die Anwendung geladen.

Klicken Sie auf Fortschritt prüfen. Containernatives Load Balancing über Ingress

Aufgabe 2: Lasttests für eine Anwendung

Die Kapazität Ihrer Anwendung zu kennen, ist ein wichtiger Schritt beim Festlegen der Ressourcenanforderungen und ‑grenzen für die Pods Ihrer Anwendung und bei der Auswahl der besten Strategie für die automatische Skalierung.

Zu Beginn des Labs haben Sie Ihre Anwendung als einen einzelnen Pod bereitgestellt. Wenn Sie für Ihre Anwendung ohne konfigurierte Autoskalierung auf einem einzelnen Pod Lasttests machen, finden Sie heraus, wie viele gleichzeitige Anfragen Ihre Anwendung bewältigen kann, wie viel CPU und Arbeitsspeicher sie benötigt und wie sie voraussichtlich auf hohe Last reagiert.

Für diesen Lasttest Ihres Pod verwenden Sie das Open-Source-Framework Locust.

1. Laden Sie die Docker-Image.Dateien für Locust aus Ihrer Cloud Shell herunter:

gsutil -m cp -r gs://spls/gsp769/locust-image .

Die Dateien im Verzeichnis locust-image umfassen Locust-Konfigurationsdateien.

2. Erstellen Sie das Docker-Image für Locust und speichern Sie es in der Container Registry Ihres Projekts:

gcloud builds submit \ --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/locust-tasks:latest locust-image

3. Überprüfen Sie, dass das Docker-Image in der Container-Registrierung Ihres Projekts vorhanden ist:

gcloud container images list

Erwartete Ausgabe:

Locust besteht aus einer Hauptmaschine und einer Reihe von Workern, mit denen die Last erzeugt wird.

4. Durch Kopieren und Anwenden des Manifests wird ein Single-Pod-Deployment für den Hauptteil und ein 5-Replikate-Deployment für die Worker erstellt:

gsutil cp gs://spls/gsp769/locust_deploy_v2.yaml . sed 's/${GOOGLE_CLOUD_PROJECT}/'$GOOGLE_CLOUD_PROJECT'/g' locust_deploy_v2.yaml | kubectl apply -f -

5. Rufen Sie die externe IP-Adresse des entsprechenden Load-Balancer-Dienstes ab, um auf die Locust-Benutzeroberfläche zuzugreifen:

kubectl get service locust-main

Wenn externe IP-Adresse den Wert <pending> hat, warten Sie eine Minute und wiederholen Sie den vorherigen Befehl, bis ein gültiger Wert angezeigt wird.

6. Rufen Sie in einem neuen Browserfenster [EXTERNE_IP_ADRESSE]:8089 auf, um die Locust-Website zu öffnen:

Klicken Sie auf Fortschritt prüfen. Lasttests für eine Anwendung

Locust ermöglicht das Swarming einer Anwendung mit zahlreichen gleichzeitigen Nutzerkonten. Sie können zur Simulation von Traffic eine bestimmte Anzahl von aktiven Nutzerkonten eingeben, die in einem bestimmten Rhythmus erzeugt werden.

7. In diesem Beispiel einer typischen Belastung geben Sie 200 für die Anzahl der zu simulierenden Nutzerkonten und 20 für die Erzeugungsrate ein.

8. Klicken Sie auf Start swarming (Swarm starten).

Nach ein paar Sekunden sollte der Status den Wert Running haben, mit 200 Nutzerkonten und etwa 150 Anfragen pro Sekunde (RPS).

9. Wechseln Sie zur Cloud Console und klicken Sie auf Navigationsmenü () > Kubernetes Engine.

10. Wählen Sie Arbeitslasten im linken Bereich aus.

11. Klicken Sie dann auf den bereitgestellten Pod gb-frontend.

So gelangen Sie auf die Pod-Detailseite, auf der eine Grafik der CPU- und Arbeitsspeichernutzung des Pods angezeigt wird. Sehen Sie sich die Werte verwendet und angefordert an.

Hinweis: Wenn Sie die unter dem Diagramm aufgelisteten metrischen Werte sehen möchten, klicken Sie auf die drei Punkte im oberen rechten Teil des Diagramms. Wählen Sie dann aus dem Dropdown-Menü die Option Diagrammlegende erweitern aus.

Beim aktuellen Lasttest mit etwa 150 Anfragen pro Sekunde kann die CPU-Auslastung zwischen 0,04 und 0,06 schwanken. Das entspricht 40 bis 60 % der CPU-Anforderung eines Pods. Außerdem bleibt die Arbeitsspeicherauslastung bei ca. 80 MiB, was deutlich unter dem angeforderten 256 MiB liegt. Das ist ihre Kapazität pro Pod. Diese Informationen können hier hilfreich sein: bei der Konfiguration des Cluster-Autoscalings, bei Ressourcenanforderungen und ‑begrenzungen sowie bei der Entscheidung, ob horizontales oder vertikales Pod-Autoscaling verwendet soll.

Neben einer Baseline sollten Sie auch berücksichtigen, wie Ihre Anwendung nach plötzlichen Bursts oder Spitzen funktioniert.

12. Kehren Sie zum Browserfenster mit Locust zurück und klicken Sie oben auf der Seite unter „Status“ auf Bearbeiten.

13. Geben Sie diesmal 900 als Anzahl der Nutzerkonten und 300 als Erzeugungsrate ein.

14. Klicken Sie auf Start swarming (Swarm starten).

Der Pod erhält plötzlich 700 zusätzliche Anfragen innerhalb von 2 bis 3 Sekunden. Wenn der RPS-Wert etwa 150 erreicht hat und der Status 900 aktive Nutzerkonten anzeigt, wechseln Sie zurück zur Seite „Pod-Details“ und sehen Sie sich die Änderungen der Diagramme an.

Während die Arbeitsspeicherauslastung gleich bleibt, ist zu sehen, dass die CPU einen Spitzenwert von fast 0,07 erreicht hat, also 70 % der CPU-Anforderung Ihres Pods. Wenn es sich bei dieser Anwendung um ein Deployment handelt, können Sie wahrscheinlich die gesamte Speicheranforderung auf einen niedrigeren Wert reduzieren und Ihr horizontales Autoscaling so konfigurieren, dass es bei CPU-Auslastung ausgelöst wird.

Aufgabe 3: Bereitschafts- und Aktivitätsprüfungen

Aktivitätsprüfung einrichten

Eine Aktivitätsprüfung wird kontinuierlich ausgeführt, wenn das in den technischen Daten des Kubernetes-Pods oder Deployments konfiguriert wurde. Sie ermittelt, ob ein Container einen Neustart benötigt, und löst diesen Neustart dann aus. Das dient dem automatischen Neustart von blockierten Anwendungen, die möglicherweise noch den Status „wird ausgeführt“ haben. Ein von Kubernetes verwalteter Load Balancer (z. B. ein Dienst) würde beispielsweise nur dann Traffic an ein Pod-Backend weiterleiten, wenn alle Container die Bereitschaftsprüfung bestehen.

1. Zur Demonstration einer Aktivitätsprüfung wird im Folgenden ein Manifest für einen Pod mit einer solchen generiert. Dies basiert auf der Ausführung des cat-Befehls für eine bei der Erstellung generierte Datei:

cat << EOF > liveness-demo.yaml apiVersion: v1 kind: Pod metadata: labels: demo: liveness-probe name: liveness-demo-pod spec: containers: - name: liveness-demo-pod image: centos args: - /bin/sh - -c - touch /tmp/alive; sleep infinity livenessProbe: exec: command: - cat - /tmp/alive initialDelaySeconds: 5 periodSeconds: 10 EOF

2. Wenden Sie das Manifest zum Erstellen des Pods an:

kubectl apply -f liveness-demo.yaml

Der Wert initialDelaySeconds gibt an, wann die erste Prüfung nach dem Hochfahren des Containers durchgeführt werden soll. Der Wert periodSeconds gibt an, wie oft die Prüfung durchgeführt werden soll.

Hinweis: Pods können so konfiguriert werden, dass sie startupProbe enthalten. Dieser Wert gibt an, ob eine Anwendung im Container gestartet wurde. Wenn der Wert startupProbe vorhanden ist, werden keine weiteren Prüfungen durchgeführt, bis der Status Erfolgreich lautet. Dies wird für Anwendungen mit variierenden Startzeiten empfohlen, um Unterbrechungen durch eine Aktivitätsprüfung zu vermeiden.

In diesem Beispiel wird im Wesentlichen geprüft, ob die Datei /tmp/alive im Dateisystem des Containers vorhanden ist.

3. Sie können den Zustand des Pod-Containers überprüfen, wenn Sie die Ereignisse des Pods kontrollieren:

kubectl describe pod liveness-demo-pod

Am unteren Ende der Ausgabe sollte der Abschnitt „Ereignisse“ die letzten 5 Ereignisse des Pods auflisten. Derzeit sollte diese Liste nur Ereignisse im Zusammenhang mit der Pod-Erstellung und seinem Start enthalten:

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 19s default-scheduler Successfully assigned default/liveness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Normal Pulling 18s kubelet Pulling image "centos" Normal Pulled 18s kubelet Successfully pulled image "centos" Normal Created 18s kubelet Created container liveness-demo-pod Normal Started 18s kubelet Started container liveness-demo-pod

Dieses Protokoll enthält alle fehlgeschlagenen Aktivitätsprüfungen sowie die daraufhin ausgelösten Neustarts.

4. Löschen Sie manuell die von der Aktivitätsprüfung verwendete Datei:

kubectl exec liveness-demo-pod -- rm /tmp/alive

5. Sobald die Datei entfernt wurde, sollte der von der Aktivitätsprüfung verwendete Befehl cat einen Exit-Code ungleich Null ausgeben.

6. Überprüfen Sie noch einmal die Pod-Ereignisse:

kubectl describe pod liveness-demo-pod

Wenn die Aktivitätsprüfung fehlschlägt, werden dem Protokoll Ereignisse mit einer Reihe von ausgelösten Schritten hinzugefügt. Diese beginnen mit dem Fehlschlagen der Aktivitätsprüfung (Aktivitätsprüfung fehlgeschlagen: cat: /tmp/alive: Datei oder Verzeichnis nicht vorhanden) und endet mit dem Container-Neustart (Container gestartet):

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m21s default-scheduler Successfully assigned default/liveness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Warning Unhealthy 36s (x3 over 56s) kubelet Liveness probe failed: cat: /tmp/alive: No such file or directory Normal Killing 36s kubelet Container liveness-demo-pod failed liveness probe, will be restarted Normal Pulling 6s (x2 over 2m20s) kubelet Pulling image "centos" Normal Pulled 6s (x2 over 2m20s) kubelet Successfully pulled image "centos" Normal Created 6s (x2 over 2m20s) kubelet Created container liveness-demo-pod Normal Started 6s (x2 over 2m20s) kubelet Started container liveness-demo-pod Hinweis: Das Beispiel in dieser Übung verwendet eine Befehlsprüfung für seine livenessProbe, die vom Exit-Code eines bestimmten Befehls abhängt. Zusätzlich zu einer Befehlsüberprüfung kann eine livenessProbe als HTTP-Überprüfung konfiguriert werden, die von einer HTTP-Antwort abhängig ist, oder als TCP-Überprüfung, die vom Herstellen einer TCP-Verbindung zu einem bestimmten Port abhängig ist.

Bereitschaftsüberprüfung einrichten

Auch wenn ein Pod erfolgreich startet und von einer Aktivitätsüberprüfung als funktionsfähig eingestuft wird, ist er eventuell nicht sofort bereit, Traffic zu verarbeiten. Dies ist häufig bei Deployments der Fall, die als Backend für einen Dienst wie einen Load Balancer eingesetzt werden. Mit einer Bereitschaftsüberprüfung wird ermittelt, ob ein Pod und seine Container für die Verarbeitung von Traffic bereit sind.

1. Erstellen Sie zur Demonstration dessen ein Manifest für einen einzelnen Pod, der als Test-Webserver zusammen mit einem Load Balancer dient:

cat << EOF > readiness-demo.yaml apiVersion: v1 kind: Pod metadata: labels: demo: readiness-probe name: readiness-demo-pod spec: containers: - name: readiness-demo-pod image: nginx ports: - containerPort: 80 readinessProbe: exec: command: - cat - /tmp/healthz initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: readiness-demo-svc labels: demo: readiness-probe spec: type: LoadBalancer ports: - port: 80 targetPort: 80 protocol: TCP selector: demo: readiness-probe EOF

2. Wenden Sie das Manifest auf Ihren Cluster an und erstellen Sie damit einen Load Balancer:

kubectl apply -f readiness-demo.yaml

3. Rufen Sie die externe IP-Adresse ab, die Ihrem Load Balancer zugewiesen wurde (es kann etwa eine Minute nach dem vorherigen Befehl dauern, bis eine Adresse zugewiesen wurde):

kubectl get service readiness-demo-svc

4. Wenn Sie die IP-Adresse in ein Browserfenster eingeben, wird eine Fehlermeldung angezeigt, dass die Website nicht erreichbar ist.

5. Überprüfen Sie die Pod-Ereignisse:

kubectl describe pod readiness-demo-pod

Die Ausgabe zeigt an, dass die Bereitschaftsprüfung fehlgeschlagen ist:

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m24s default-scheduler Successfully assigned default/readiness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Normal Pulling 2m23s kubelet Pulling image "nginx" Normal Pulled 2m23s kubelet Successfully pulled image "nginx" Normal Created 2m23s kubelet Created container readiness-demo-pod Normal Started 2m23s kubelet Started container readiness-demo-pod Warning Unhealthy 35s (x21 over 2m15s) kubelet Readiness probe failed: cat: /tmp/healthz: No such file or directory

Im Gegensatz zur Aktivitätsprüfung wird bei einer nicht erfolgreichen Bereitschaftsprüfung der Pod nicht neu gestartet.

6. Verwenden Sie den folgenden Befehl zum Erstellen der Datei für die Bereitschaftsprüfung:

kubectl exec readiness-demo-pod -- touch /tmp/healthz

Der Abschnitt Conditions der Pod-Beschreibung sollte True als den Wert für Ready anzeigen.

kubectl describe pod readiness-demo-pod | grep ^Conditions -A 5

Ausgabe:

Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True

7. Aktualisieren Sie jetzt den Browsertab mit der externen IP-Adresse des readiness-demo-svc. Es sollte die Meldung „Willkommen bei nginx!“ korrekt angezeigt werden.

Durch das Festlegen sinnvoller Bereitschaftsprüfungen für Ihre Anwendungscontainer wird sichergestellt, dass die Pods nur dann Traffic empfangen, wenn sie dazu bereit sind. Beispielsweise ist es sinnvoll, als Bereitschaftsprüfung zu ermitteln, ob ein für die Anwendung erforderlicher Cache beim Start geladen wurde.

Klicken Sie auf Fortschritt prüfen. Bereitschafts- und Aktivitätsprüfungen

Aufgabe 4: Budget für Pod-Störungen

Zur Gewährleistung der Zuverlässigkeit und Verfügbarkeit Ihrer GKE-Anwendung gehört der Einsatz eines Budgets für Pod-Störungen (pdp). PodDisruptionBudget ist eine Kubernetes-Ressource, die die Anzahl der Pods einer replizierten Anwendung begrenzt, die gleichzeitig aufgrund von freiwilligen Unterbrechungen außer Betrieb sein können.

Zu freiwilligen Unterbrechungen zählen administrative Aufgaben wie das Löschen eines Deployments, das Aktualisieren der Pod-Vorlage eines Deployments und die Durchführung eines Rolling Update, das Leeren von Knoten, auf denen sich die Pods einer Anwendung befinden, oder das Verschieben von Pods auf andere Knoten.

Als Erstes müssen Sie Ihre Anwendung als Deployment bereitstellen.

1. Single-Pod-Anwendung löschen:

kubectl delete pod gb-frontend

2. Manifest für ein 5-Replikate-Deployment erzeugen:

cat << EOF > gb_frontend_deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: gb-frontend labels: run: gb-frontend spec: replicas: 5 selector: matchLabels: run: gb-frontend template: metadata: labels: run: gb-frontend spec: containers: - name: gb-frontend image: gcr.io/google-samples/gb-frontend-amd64:v5 resources: requests: cpu: 100m memory: 128Mi ports: - containerPort: 80 protocol: TCP EOF

3. Deployment auf das Cluster anwenden:

kubectl apply -f gb_frontend_deployment.yaml

Klicken Sie auf Fortschritt prüfen. Budgets für Pod-Störungen erstellen

Bevor Sie ein PDB erstellen, müssen Sie die Knoten des Clusters leeren und das Verhalten Ihrer Anwendung ohne PDB beobachten.

4. Um die Knoten zu leeren, lassen Sie die Ausgabe der Knoten des default-pool in einer Schleife durchlaufen und führen Sie den Befehl kubectl drain auf jedem einzelnen Knoten aus:

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do kubectl drain --force --ignore-daemonsets --grace-period=10 "$node"; done

Der obige Befehl entfernt Pods vom angegebenen Knoten und sperrt den Knoten, sodass keine neuen Pods auf ihm erstellt werden können. Wenn die verfügbaren Ressourcen es zulassen, werden die Pods auf andere Knoten umverteilt.

5. Sobald der Knoten entleert wurde, prüfen Sie die Replikatanzahl des Deployments mit gb-frontend:

kubectl describe deployment gb-frontend | grep ^Replicas

Die Ausgabe sollte in etwa so aussehen:

Replicas: 5 desired | 5 updated | 5 total | 0 available | 5 unavailable

Nach dem Leeren eines Knotens sind eventuell 0 Replikate für das Deployment verfügbar, wie aus der obigen Ausgabe hervorgeht. Ohne verfügbare Pods ist die Anwendung praktisch außer Betrieb. Versuchen wir noch einmal, die Knoten zu leeren, aber diesmal mit einem Budget für Pod-Störungen in der Anwendung.

6. Zuerst werden die geleerten Knoten durch Entsperren reaktiviert. Mit dem nachstehenden Befehl können die Pods wieder auf dem Knoten geplant werden:

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do kubectl uncordon "$node"; done

7. Prüfen Sie nochmal den Status des Deployments:

kubectl describe deployment gb-frontend | grep ^Replicas

Die Ausgabe sollte nun in etwa so aussehen, wobei alle 5 Replikate verfügbar sind:

Replicas: 5 desired | 5 updated | 5 total | 5 available | 0 unavailable

8. Erstellen Sie ein Budget für Pod-Störungen mit einer Mindestanzahl der verfügbaren Pods von 4:

kubectl create poddisruptionbudget gb-pdb --selector run=gb-frontend --min-available 4

9. Leeren Sie wieder einen der Knoten im Cluster und sehen Sie sich die Ausgabe an:

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do kubectl drain --timeout=30s --ignore-daemonsets --grace-period=10 "$node"; done

Nachdem ein Pod Ihrer Anwendung erfolgreich ausgeworfen wurde, durchläuft er folgende Schleife:

evicting pod default/gb-frontend-597d4d746c-fxsdg evicting pod default/gb-frontend-597d4d746c-tcrf2 evicting pod default/gb-frontend-597d4d746c-kwvmv evicting pod default/gb-frontend-597d4d746c-6jdx5 error when evicting pod "gb-frontend-597d4d746c-fxsdg" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget. error when evicting pod "gb-frontend-597d4d746c-tcrf2" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget. error when evicting pod "gb-frontend-597d4d746c-6jdx5" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget. error when evicting pod "gb-frontend-597d4d746c-kwvmv" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

10. Drücken Sie STRG + C, um den Befehl zu stoppen.

11. Prüfen Sie wieder den Status des Deployments:

kubectl describe deployment gb-frontend | grep ^Replicas

Die Ausgabe sollte nun so aussehen:

Replicas: 5 desired | 5 updated | 5 total | 4 available | 1 unavailable

Bis Kubernetes in der Lage ist, einen fünften Pod auf einem anderen Knoten bereitzustellen, um den nächsten auszuwerfen, bleiben die restlichen Pods verfügbar, damit das PDB eingehalten wird. In diesem Beispiel wurde das Budget für Pod-Störungen mit min-available konfiguriert, aber sie können es auch mit max-unavailable konfigurieren. Beide Werte können als Ganzzahl ausgedrückt werden, die entweder die Anzahl oder einen Prozentsatz aller Pods darstellt.

Das wars! Sie haben das Lab erfolgreich abgeschlossen.

Sie haben gelernt, wie Sie einen containernativen Load Balancer mit eingehendem Traffic erstellen können, um ein effizienteres Load Balancing und Routing zu nutzen. Sie haben einen einfachen Lasttest mit einer GKE-Anwendung durchgeführt und die Baseline der CPU- und Arbeitsspeichernutzung sowie die Reaktion auf Traffic-Spitzen beobachtet. Zusätzlich haben Sie Aktivitäts- und Bereitschaftsprüfungen sowie ein Budget für Pod-Störungen konfiguriert, um die Verfügbarkeit Ihrer Anwendungen zu wahren. Diese Tools und Techniken steigern gemeinsam die Gesamteffizienz Ihrer Anwendung auf GKE, weil sie überflüssigen Netzwerk-Traffic minimieren, aussagekräftige Indikatoren für eine gut funktionierende Anwendung festlegen und die Verfügbarkeit der Anwendung verbessern.

Weitere Informationen

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

• Best Practices für kostenoptimierte Kubernetes-Anwendungen auf GKE: cloudbasierte Kubernetes-Anwendungen vorbereiten

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 12. März 2024 aktualisiert

Lab zuletzt am 12. März 2024 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.