GSP767

Übersicht

Die zugrunde liegende Infrastruktur eines Google Kubernetes Engine-Clusters besteht aus Knoten. Dies sind einzelne Compute-VM-Instanzen. In diesem Lab erfahren Sie, wie Sie durch die Optimierung der Clusterinfrastruktur Kosten sparen und die Architektur für Ihre Anwendungen effizienter gestalten können.

Sie lernen Strategien zur Maximierung der Auslastung und zum Vermeiden einer Unterauslastung Ihrer wertvollen Infrastrukturressourcen durch Auswahl geeigneter Maschinentypen für eine Beispielarbeitslast kennen. Neben der Art der Infrastruktur wirkt sich auch ihr geografischer Standort auf die Kosten aus. Im Rahmen dieser Übung lernen Sie, wie Sie eine kostengünstige Strategie für das Verwalten regionaler Cluster mit höherer Verfügbarkeit verfolgen können.

Lernziele

Aufgaben in diesem Lab:

• Ressourcennutzung eines Deployments ermitteln
• Deployment hochskalieren
• Arbeitslast zu einem Knotenpool mit optimiertem Maschinentyp migrieren
• Standortoptionen für den Cluster vergleichen
• Flusslogs zwischen Pods in verschiedenen Zonen überwachen
• Pod verschieben, der viel Traffic verursacht, um die Kosten für zonenübergreifenden Traffic zu minimieren

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 Google Cloud-Ressourcen für das Lab verfügbar sind.

In diesem praxisorientierten Lab können Sie die Lab-Aktivitäten in einer echten Cloud-Umgebung 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 (empfohlen), 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: Verwenden Sie für dieses Lab nur das Teilnehmerkonto. Wenn Sie ein anderes Google Cloud-Konto verwenden, fallen dafür möglicherweise Kosten an.

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 Dialogfeld 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 auf Google Cloud-Produkte und ‑Dienste zugreifen möchten, klicken Sie auf das Navigationsmenü oder geben Sie den Namen des Produkts oder Dienstes in das Feld Suchen ein.

In diesem Lab wird ein kleiner Cluster für Sie erstellt. Das Bereitstellen des Clusters dauert etwa zwei bis fünf Minuten.

Wenn Sie auf Lab starten geklickt haben und die Meldung resources being provisioned in Blau mit einem Ladekreis angezeigt wird, wird der Cluster gerade erstellt.

Während Sie warten, können Sie bereits die weitere Anleitung und die nächsten Erklärungen lesen. Shell-Befehle funktionieren jedoch erst, wenn die Bereitstellung der Ressourcen abgeschlossen ist.

Aufgabe 1: Knotenmaschinentypen kennenlernen

Allgemeiner Überblick

Ein Maschinentyp entspricht einer Reihe virtualisierter Hardwareressourcen, die einer VM-Instanz zur Verfügung stehen. Dazu gehören Systemspeichergröße, Anzahl der virtuellen CPUs (vCPUs) und maximal verfügbarer nichtflüchtiger Speicher. Maschinentypen werden für verschiedene Arbeitslasten gruppiert und nach Familien sortiert.

Maschinentypen für allgemeine Zwecke bieten für eine Vielzahl von Arbeitslasten das beste Preis-Leistungs-Verhältnis. Zu diesen Maschinentypen gehören die N-Serie und die E2-Serie:

Je nach Erfordernissen können die verschiedenen Maschinentypen für Ihre Anwendung mehr oder weniger sinnvoll sein. E2-Typen bieten in der Regel eine ähnliche Leistung wie N1-Typen, sind jedoch kostenoptimiert. Eine ausschließliche Nutzung des Maschinentyps E2 ermöglicht in der Regel Kosteneinsparungen.

In einem Cluster ist jedoch am wichtigsten, dass die genutzten Ressourcen optimal auf die Anforderungen der Anwendung zugeschnitten sind. Bei größeren Anwendungen oder Deployments, die stark skaliert werden müssen, kann es günstiger sein, die Arbeitslasten auf einige wenige optimierte Maschinen zu verteilen, anstatt auf viele für allgemeine Zwecke.

Die Details der Anwendung genau zu kennen, ist für diesen Prozess zur Entscheidungsfindung äußerst wichtig. Achten Sie auf einen angemessenen Maschinentyp für die spezifischen Anforderungen Ihrer Anwendung.

Im folgenden Abschnitt sehen Sie sich eine Demo-App an und migrieren diese zu einem Knotenpool mit einem geeigneten Maschinentyp.

Aufgabe 2: Passenden Maschinentyp für die Hello-App auswählen

Anforderungen des Hello-Demo-Clusters kennenlernen

Beim Start des Labs wurde ein Hello-Demo-Cluster mit zwei Knoten vom Typ „e2-medium“ (2 vCPUs, 4 GB Arbeitsspeicher) erstellt. Über diesen Cluster wird ein Replikat einer einfachen Web-Anwendung namens Hello-App bereitgestellt. Dies ist ein in Go geschriebener Webserver, der auf alle Anfragen mit der Nachricht „Hello, World!“ reagiert.

1. Nachdem die Lab-Bereitstellung abgeschlossen ist, klicken Sie in der Cloud Console auf das Navigationsmenü und dann auf Kubernetes Engine.

2. Wählen Sie im Fenster Kubernetes-Cluster den Cluster hello-demo-cluster aus.

3. Wechseln Sie im nächsten Fenster zum Tab Knoten:

Es wird eine Liste der Clusterknoten angezeigt:

Sehen Sie sich an, wie die GKE die Ressourcen des Clusters genutzt hat. Sie sehen, wie viel CPU-Kapazität und Arbeitsspeicher von jedem Knoten angefragt wird und wie viel die Knoten potenziell zuweisen können.

4. Klicken Sie auf den ersten Knoten des Clusters.

Sehen Sie sich den Abschnitt Pods an. Dort sollte der Pod hello-server im Namespace default aufgeführt sein. Falls Sie den Pod hello-server nicht sehen, wählen Sie stattdessen den zweiten Knoten des Clusters aus.

Hier ist ebenfalls zu sehen, dass der Pod hello-server 400 mCPU anfordert. Außerdem werden weitere kube-system-Pods ausgeführt. Diese werden geladen, um Clusterdienste der GKE wie das Monitoring zu unterstützen.

5. Klicken Sie auf Zurück, um zur vorherigen Seite Knoten zurückzukehren.

Wie Sie sehen, sind zwei Knoten vom Typ „e2-medium“ nötig, um ein Replikat der Hello-App sowie die grundlegenden kube-system-Dienste auszuführen. Während dafür ein Großteil der CPU-Ressourcen des Clusters benötigt wird, nutzen Sie bisher nur etwa ein Drittel des zuweisbaren Arbeitsspeichers.

Wäre die Arbeitslast dieser App komplett statisch, könnten Sie einen benutzerdefinierten Maschinentyp mit genau der benötigten CPU‑ und Arbeitsspeicherkapazität erstellen. Dadurch würden Sie bei den Kosten für die gesamte Clusterinfrastruktur sparen.

Auf GKE-Clustern werden jedoch oft mehrere Arbeitslasten ausgeführt und diese müssen meist hoch‑ und herunterskaliert werden.

Was würde passieren, wenn die Hello-App hochskaliert würde?

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 .

2. Klicken Sie sich durch die folgenden Fenster:

   • Fahren Sie mit dem Informationsfenster zu Cloud Shell fort.
   • Autorisieren Sie Cloud Shell, Ihre Anmeldedaten für Google Cloud API-Aufrufe zu verwenden.

Wenn eine Verbindung besteht, sind Sie bereits authentifiziert und das Projekt ist auf 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.

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

gcloud auth list

4. 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`

5. (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.

Hello-App hochskalieren

1. Rufen Sie die Anmeldedaten des Clusters auf:

gcloud container clusters get-credentials hello-demo-cluster --zone {{{project_0.default_zone | "ZONE"}}}

2. Skalieren Sie hello-server hoch:

kubectl scale deployment hello-server --replicas=2

Klicken Sie auf Fortschritt prüfen. Hello-App hochskalieren

3. Klicken Sie in der Console im Menü Kubernetes Engine auf der linken Seite auf Arbeitslasten.

Möglicherweise wird Ihnen der Pod hello-server mit dem Fehlerstatus Keine Mindestverfügbarkeit vorhanden angezeigt.

Hinweis: Möglicherweise sehen Sie den Fehler im Lab nicht. Abhängig von der Kubernetes-Version Ihres Clusters können die „kube-system“-Pods geringere Ressourcenanfragen haben. In diesem Fall kann der Cluster die neue Arbeitslast bewältigen. Sollte der Fehler nicht angezeigt werden, ist dies nicht weiter problematisch. Er hat keine Auswirkungen auf das Absolvieren des Labs.

4. Klicken Sie auf die Fehlermeldung, um die Statusdetails einzublenden. Als Grund wird Ihnen Insufficient cpu angezeigt.

Das ist nicht überraschend, denn der Cluster hatte praktisch keine verfügbaren CPU-Ressourcen mehr und Sie haben mit einem zweiten Replikat von hello-server weitere 400 mCPU angefragt.

5. Erweitern Sie den Knotenpool, um die neue Anfrage zu verarbeiten:

gcloud container clusters resize hello-demo-cluster --node-pool my-node-pool \ --num-nodes 3 --zone {{{project_0.default_zone | "ZONE"}}}

6. Wenn Sie gefragt werden, ob Sie fortfahren möchten, geben Sie y ein und drücken Sie die Eingabetaste.

7. Aktualisieren Sie in der Console die Seite Arbeitslasten, bis für den Status der Arbeitslast von hello-server der Wert Ok angezeigt wird:

Cluster untersuchen

Nachdem Sie die Arbeitslast hochskaliert haben, kehren Sie zum Tab „Knoten“ des Clusters zurück.

1. Klicken Sie auf hello-demo-cluster:

2. Klicken Sie auf den Tab Knoten.

Der größere Knotenpool kann die höhere Arbeitslast bewältigen, aber sehen Sie sich einmal an, wie die Ressourcen der Infrastruktur genutzt werden.

Obwohl die GKE die Ressourcen eines Clusters bestmöglich nutzt, gibt es hier noch Optimierungsbedarf. Wie Sie sehen, wird der Arbeitsspeicher des einen Knotens fast vollständig genutzt, während der Arbeitsspeicher von zwei weiteren Knoten kaum ausgelastet ist.

Wenn Sie die App weiter hochskalieren würden, könnten Sie ein ähnliches Muster beobachten. Kubernetes würde versuchen, für jedes neue Replikat des Deployments hello-server einen Knoten zu finden. Dies würde fehlschlagen und das System würde einen neuen Knoten mit ca. 600 mCPU erstellen.

Bin-Packing-Problem

Ein Bin-Packing-Problem tritt auf, wenn Sie Elemente mit unterschiedlichem Volumen oder unterschiedlicher Form in einer begrenzten Anzahl herkömmlich geformter „Bins“ oder Container unterbringen müssen. Die Herausforderung besteht darin, die Elemente so effizient wie möglich in die geringstmögliche Anzahl an Behältern zu „packen“.

Das Optimieren von Kubernetes-Clustern für die Anwendungen, die auf ihnen ausgeführt werden, funktioniert ähnlich. Dabei müssen Sie für mehrere Anwendungen, die vermutlich unterschiedliche Ressourcenanforderungen hinsichtlich Arbeitsspeicher und CPU haben, so effizient wie möglich passende Infrastrukturressourcen finden, die Kubernetes für Sie verwaltet. Hier fallen voraussichtlich die höchsten Kosten für Ihren Cluster an.

Der Hello-Demo-Cluster geht das Bin-Packing-Problem nicht sehr effizient an. Es wäre kostengünstiger, Kubernetes für die Verwendung eines Maschinentyps zu konfigurieren, der besser zu dieser Arbeitslast passt.

Hinweis: In diesem Lab kümmern wir uns der Einfachheit halber nur um die Optimierung für eine Anwendung. In der Realität werden auf einem Kubernetes-Cluster in der Regel viele Anwendungen mit unterschiedlichen Anforderungen ausgeführt. Kubernetes bietet Tools, mit denen Sie die Anwendungsarbeitslasten besser auf verschiedene Maschinen abstimmen können, auf die Kubernetes zugreift. Mit mehreren GKE-Knotenpools können Sie einen Kubernetes-Cluster verschiedene Maschinentypen verwalten lassen.

Zu optimiertem Knotenpool migrieren

• Erstellen Sie einen neuen Knotenpool mit einem größeren Maschinentyp:

gcloud container node-pools create larger-pool \ --cluster=hello-demo-cluster \ --machine-type=e2-standard-2 \ --num-nodes=1 \ --zone={{{project_0.default_zone | "ZONE"}}}

Klicken Sie auf Fortschritt prüfen. Knotenpool erstellen

Jetzt können Sie Pods zum neuen Knotenpool migrieren:

1. Vorhandenen Knotenpool sperren: Durch diesen Vorgang werden die Knoten im vorhandenen Knotenpool node als nicht mehr planbar gekennzeichnet. Sobald Sie die Knoten als nicht mehr planbar gekennzeichnet haben, stellt Kubernetes die Zuweisung von neuen Pods für die Knoten ein.
2. Vorhandenen Knotenpool leeren: Durch diesen Vorgang werden die Arbeitslasten entfernt, die auf den Knoten des vorhandenen Knotenpools node ausgeführt werden.

• Sperren Sie zuerst den ursprünglichen Knotenpool:

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

• Leeren Sie als Nächstes den Pool:

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

Nun ist erkennbar, dass die Pods auf dem neuen Knotenpool larger-pool ausgeführt werden:

kubectl get pods -o=wide

3. Nachdem die Pods migriert wurden, können Sie den alten Knotenpool löschen:

gcloud container node-pools delete my-node-pool --cluster hello-demo-cluster --zone {{{project_0.default_zone | "ZONE"}}}

4. Wenn Sie gefragt werden, ob Sie fortfahren möchten, geben Sie y ein und drücken Sie die Eingabetaste.

Das Löschen kann etwa zwei Minuten dauern. Während Sie warten, können Sie sich schon einmal den nächsten Abschnitt durchlesen.

Kostenanalyse

Sie führen jetzt dieselbe Arbeitslast, für die bisher drei Maschinen des Typs e2-medium erforderlich waren, auf einer e2-standard-2-Maschine aus.

Sehen wir uns einmal die stündlichen Kosten für „e2-standard“-Maschinentypen und solche mit gemeinsam genutztem Kern an:

Standard:

Gemeinsam genutzter Kern:

Die Kosten von drei e2-medium-Maschinen belaufen sich auf etwa 0,1 $ pro Stunde, während eine e2-standard-2-Maschine ca. 0,067 $ pro Stunde kostet.

Eine Ersparnis von 0,04 $ pro Stunde erscheint gering, aber im Laufe der Lebenszeit einer Anwendung macht dies doch einen deutlichen Unterschied. In einem größeren Maßstab wäre es noch deutlicher erkennbar. Da die e2-standard-2-Maschine die Arbeitslast effizienter bewältigen kann, bleibt weniger Speicherplatz ungenutzt und die Skalierungskosten steigen langsamer.

Dies ist interessant, da der Maschinentyp e2-medium einer mit gemeinsam genutztem Kern ist. Dieser Typ ist für kleine, nicht ressourcenintensive Anwendungen besonders kostengünstig. Für die aktuelle Arbeitslast der Hello-App ist die Wahl eines Knotenpools mit einem größeren Maschinentyp jedoch im Hinblick auf die Kosten die bessere Strategie.

In der Cloud Console befinden Sie sich immer noch im Tab Knoten des Clusters hello-demo. Aktualisieren Sie den Tab und sehen Sie sich die Felder Angeforderte CPU und Zuweisbare CPU für den Knoten larger-pool an.

Hier gibt es noch Optimierungsmöglichkeiten. Der neue Knoten hätte noch Platz für ein weiteres Replikat der Arbeitslast, ohne dass ein zusätzlicher Knoten bereitgestellt werden müsste. Alternativ könnten Sie einen benutzerdefinierten Maschinentyp auswählen, der genau die CPU‑ und Arbeitsspeicheranforderungen der Anwendung erfüllt. Dadurch könnten Sie sogar noch mehr Ressourcen sparen.

Die Preise hängen allerdings auch vom Standort des Clusters ab. Daher geht es im nächsten Abschnitt dieses Labs um die Auswahl der am besten geeigneten Region und die Verwaltung eines regionalen Clusters.

Geeigneten Standort für einen Cluster auswählen

Überblick über Regionen und Zonen

Die Compute Engine-Ressourcen, die für die Knoten Ihres Clusters verwendet werden, befinden sich an unterschiedlichen Standorten auf der ganzen Welt. Diese Standorte setzen sich aus Regionen und Zonen zusammen. Eine Region ist ein geografisches Gebiet, in dem Sie Ressourcen hosten können. Regionen haben mindestens drei Zonen.

Ressourcen, die sich in einer Zone befinden, wie Instanzen virtueller Maschinen oder zonale nichtflüchtige Speicher, werden als zonale Ressourcen bezeichnet. Andere Ressourcen wie statische externe IP-Adressen zählen zur Region. Regionale Ressourcen können von jeder Ressource in dieser Region unabhängig von der Zone genutzt werden, während zonale Ressourcen nur von anderen Ressourcen in derselben Zone genutzt werden können.

Bedenken Sie bei der Auswahl einer Region oder Zone Folgendes:

1. Umgang mit Ausfällen: Wenn sich die Ressourcen für Ihre Anwendung in nur einer Zone befinden und diese nicht mehr verfügbar ist, ist auch Ihre Anwendung nicht mehr verfügbar. Für umfangreichere, sehr gefragte Anwendungen wird daher empfohlen, die Ressourcen auf mehrere Zonen oder Regionen zu verteilen.
2. Geringere Netzwerklatenz: Zur Verringerung der Netzwerklatenz sollten Sie eine Region oder Zone wählen, die sich in der Nähe Ihres Point of Service befindet. Wenn Sie beispielsweise vor allem Kunden an der Ostküste der USA haben, sollten Sie möglichst eine Primärregion und ‑zone wählen, die sich in der Nähe dieses Bereichs befinden.

Best Practices für Cluster

Die Kosten hängen von der Region sowie weiterer Faktoren ab. Ressourcen in der Region us-west2 sind beispielsweise in der Regel teurer als solche in der Region us-central1.

Überlegen Sie bei der Auswahl einer Region oder Zone für den Cluster, was genau Ihre Anwendung tut. Bei einer latenzempfindlichen Produktionsumgebung erzielen Sie mit einer Region/Zone mit geringerer Netzwerklatenz und höherer Effizienz vermutlich das beste Preis-Leistungs-Verhältnis für Ihre Anwendung.

Eine weniger latenzempfindliche Entwicklungsumgebung könnten Sie dagegen in einer kostengünstigeren Region ansiedeln.

Hinweis: Weitere Informationen zu VMs und den Preisen pro Region finden Sie unter Preise für VM-Instanzen.

Clusterverfügbarkeit

Zu den verfügbaren GKE-Clustertypen gehören zonale (ein- oder multizonale) und regionale Cluster. Ein einzonaler Cluster scheint erst einmal die kostengünstigste Option zu sein. Damit Ihre Anwendungen hochverfügbar sind, ist es jedoch besser, die Clusterressourcen auf mehrere Zonen zu verteilen.

In vielen Fällen erzielen Sie mit einem multizonalen oder regionalen Cluster, bei dem die Verfügbarkeit im Vordergrund steht, das beste Preis-Leistungs-Verhältnis.

Hinweis: Bei einem multizonalen Cluster ist mindestens eine weitere Zone definiert, aber es wird nur ein Replikat der Steuerungsebene in einer Zone ausgeführt. So können Arbeitslasten auch während eines Ausfalls der Zone der Steuerungsebene weiter ausgeführt werden, aber Konfigurationen des Clusters sind erst möglich, wenn die Steuerungsebene wieder verfügbar ist.

Ein regionaler Cluster verfügt über mehrere Replikate der Steuerungsebene, die in mehreren Zonen innerhalb einer bestimmten Region ausgeführt werden. Knoten werden auch in jeder Zone ausgeführt, in der ein Replikat der Steuerungsebene ausgeführt wird. Regionale Cluster verbrauchen deutlich mehr Ressourcen, bieten aber auch die höchste Verfügbarkeit.

Weitere Informationen finden Sie unter Auswahlmöglichkeiten für Clusterkonfiguration.

Aufgabe 3: Regionalen Cluster verwalten

Einrichtung

Das Verwalten der Ressourcen Ihres Clusters in verschiedenen Zonen ist etwas komplexer. Wenn Sie nicht aufpassen, fallen möglicherweise zusätzliche Kosten durch unnötige interzonale Kommunikation zwischen den Pods an.

In diesem Abschnitt beobachten Sie den Netzwerk-Traffic Ihres Clusters und verschieben zwei Pods mit hohem Traffic untereinander in dieselbe Zone.

1. Erstellen Sie im Tab Cloud Shell einen neuen regionalen Cluster. Das Ausführen dieses Befehls dauert einige Minuten:

gcloud container clusters create regional-demo --region={{{project_0.default_region | "REGION"}}} --num-nodes=1

Zum Simulieren von Traffic zwischen den Pods und Knoten erstellen Sie zwei Pods in separaten Knoten in Ihrem regionalen Cluster. Mit ping erzeugen Sie Traffic von einem Pod zum anderen, den Sie dann überwachen können.

2. Führen Sie den folgenden Befehl aus, um ein Manifest für den ersten Pod zu erstellen:

cat << EOF > pod-1.yaml apiVersion: v1 kind: Pod metadata: name: pod-1 labels: security: demo spec: containers: - name: container-1 image: wbitt/network-multitool EOF

3. Mit diesem Befehl erstellen Sie den ersten Pod in Kubernetes:

kubectl apply -f pod-1.yaml

4. Führen Sie als Nächstes den folgenden Befehl aus, um ein Manifest für den zweiten Pod zu erstellen:

cat << EOF > pod-2.yaml apiVersion: v1 kind: Pod metadata: name: pod-2 spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - demo topologyKey: "kubernetes.io/hostname" containers: - name: container-2 image: gcr.io/google-samples/node-hello:1.0 EOF

5. Erstellen Sie den zweiten Pod in Kubernetes:

kubectl apply -f pod-2.yaml

Klicken Sie auf Fortschritt prüfen. Pod-Erstellung prüfen

Die von Ihnen erstellten Pods verwenden den Container node-hello und geben die Nachricht Hello Kubernetes aus, wenn sie angefragt werden.

In der Datei pod-2.yaml, die Sie erstellt haben, gibt es eine definierte Regel für die Pod-Anti-Affinität. Damit können Sie sicherstellen, dass der Pod nicht auf demselben Knoten wie pod-1 geplant ist. Dies erfolgt durch den Abgleich eines Ausdrucks mit dem Label security: demo von pod-1. Die Pod-Affinität stellt sicher, dass Pods auf demselben Knoten geplant werden, während die Pod-Anti-Affinität dafür sorgt, dass Pods nicht auf demselben Knoten geplant werden.

Hinweis: In Kubernetes gibt es auch das Konzept der Knotenaffinität. Somit lässt sich die Auswahl von Anwendungen und ausführenden Maschinentypen optimieren.

In diesem Fall wird die Pod-Anti-Affinität verwendet, um den Traffic zwischen Knoten klarer darzustellen. Aber durch einen intelligenten Einsatz von Pod-Anti-Affinität und Pod-Affinität können Sie die Ressourcen Ihres regionalen Clusters noch besser nutzen.

6. Sehen Sie sich die erstellten Pods an:

kubectl get pod pod-1 pod-2 --output wide

Beide Pods werden mit dem Status Running und internen IP-Adressen ausgegeben.

Beispielausgabe: NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-1 1/1 Running 0 4m40s 10.60.0.7 gke-regional-demo-default-pool-abb297f1-tz3b pod-2 1/1 Running 0 4m31s 10.60.2.3 gke-regional-demo-default-pool-28b6c708-qn7q

Notieren Sie sich die IP-Adresse von pod-2. Sie benötigen sie im nächsten Befehl.

Traffic simulieren

1. Rufen Sie für den Container pod-1 eine Shell ab:

kubectl exec -it pod-1 -- sh

2. Senden Sie in der Shell eine Anfrage an pod-2 und ersetzen Sie [POD-2-IP] durch die für pod-2 angezeigte interne IP-Adresse:

ping [POD-2-IP]

Notieren Sie sich die durchschnittliche Latenz eines Pings von pod-1 an pod-2.

Flusslogs untersuchen

Wenn pod-1 Pings an pod-2 sendet, können Sie in dem Subnetz der VPC, in dem der Cluster erstellt wurde, Flusslogs aktivieren, um den Traffic zu beobachten.

1. Rufen Sie in der Cloud Console das Navigationsmenü auf und wählen Sie im Abschnitt Netzwerk die Option VPC-Netzwerk aus.

2. Klicken Sie auf das Standardnetzwerk default. Suchen Sie im Tab Subnetze in der Region das Subnetz default und klicken Sie darauf.

3. Klicken Sie oben auf der Seite auf Bearbeiten.

4. Wählen Sie für Flusslogs die Einstellung An aus.

5. Klicken Sie auf Speichern.

6. Klicken Sie dann auf Flusslogs im Log-Explorer ansehen.

Sie sehen jetzt eine Liste mit Logs, die viele Informationen enthalten. Jedes Mal, wenn die Instanzen etwas gesendet oder empfangen haben, wird dort ein Eintrag erstellt.

Falls keine Logs erzeugt werden, ersetzen Sie das Zeichen / vor „vpc_flows“ durch %2F, wie im obigen Screenshot gezeigt.

Dies erschwert möglicherweise den Lesevorgang. Exportieren Sie die Daten daher in eine BigQuery-Tabelle, um die relevanten Informationen abfragen zu können.

7. Klicken Sie auf Aktionen > Senke erstellen.

8. Geben Sie der Senke den Namen FlowLogsSample.

9. Klicken Sie auf Weiter.

Senkenziel

• Wählen Sie als Senkendienst die Option BigQuery-Dataset aus.
• Wählen Sie unter BigQuery-Dataset die Option Neues BigQuery-Dataset erstellen aus.
• Geben Sie dem Dataset den Namen us_flow_logs und klicken Sie auf Dataset erstellen.

Alles andere können Sie unverändert lassen.

1. Klicken Sie auf Senke erstellen.

2. Sehen Sie sich nun das neu erstellte Dataset an. Klicken Sie dazu in der Cloud Console im Navigationsmenü im Abschnitt Analysen auf BigQuery.

3. Klicken Sie auf Fertig.

4. Klicken Sie auf den Projektnamen und dann auf us_flow_logs, um die neu erstellte Tabelle zu öffnen. Falls keine Tabelle angezeigt wird, aktualisieren Sie die Ansicht, bis die Tabelle erstellt ist.

5. Klicken Sie unter dem Dataset us_flow_logs auf die Tabelle compute_googleapis_com_vpc_flows_xxx.

6. Klicken Sie auf Abfrage > In neuem Tab.

7. Fügen Sie im BigQuery-Editor den folgenden Code zwischen SELECT und FROM ein:

jsonPayload.src_instance.zone AS src_zone, jsonPayload.src_instance.vm_name AS src_vm, jsonPayload.dest_instance.zone AS dest_zone, jsonPayload.dest_instance.vm_name

8. Klicken Sie auf Ausführen.

Jetzt werden Ihnen die Flusslogs gefiltert nach source zone, source vm, destination zone und destination vm angezeigt.

Suchen Sie einige Zeilen mit Aufrufen zwischen zwei verschiedenen Zonen im Cluster regional-demo.

Hinweis: Die numerischen Werte der Logs auf dem Beispielbild weichen von denen Ihrer Logs ab.

An den Flusslogs können Sie ablesen, dass es viel Traffic zwischen den verschiedenen Zonen gibt.

Als Nächstes verschieben Sie die Pods in dieselbe Zone und sehen sich an, welche Vorteile dies hat.

Pod mit hohem Traffic zur Kostenminimierung verschieben

1. Drücken Sie in Cloud Shell die Tastenkombination Strg + C, um den Befehl ping zu beenden.

2. Führen Sie den Befehl exit aus, um die Shell von pod-1 zu verlassen:

exit

3. Führen Sie den folgenden Befehl aus, um das Manifest von pod-2 zu bearbeiten:

sed -i 's/podAntiAffinity/podAffinity/g' pod-2.yaml

Dadurch wird die Regel Pod Anti Affinity in eine Pod Affinity-Regel geändert. Die Logik bleibt jedoch unverändert. Nun wird pod-2 auf demselben Knoten geplant wie pod-1.

4. Löschen Sie den aktuell ausgeführten Pod pod-2:

kubectl delete pod pod-2

5. Nachdem Sie pod-2 gelöscht haben, erstellen Sie ihn mit dem bearbeiteten Manifest neu:

kubectl create -f pod-2.yaml

Klicken Sie auf Fortschritt prüfen. Traffic simulieren

6. Sehen Sie sich die erstellten Pods an und achten Sie darauf, dass beide den Status Running haben:

kubectl get pod pod-1 pod-2 --output wide

Die Ausgabe zeigt, dass pod-1 und pod-2 nun auf demselben Knoten ausgeführt werden.

Notieren Sie sich die IP-Adresse von pod-2. Sie benötigen sie im nächsten Befehl.

7. Rufen Sie für den Container pod-1 eine Shell ab:

kubectl exec -it pod-1 -- sh

8. Senden Sie in der Shell eine Anfrage an pod-2 und ersetzen Sie [POD-2-IP] durch die interne IP-Adresse für pod-2 aus dem vorherigen Befehl:

ping [POD-2-IP]

Wie Sie sehen, ist die durchschnittliche Ping-Zeit zwischen diesen Pods nun viel kürzer.

Kehren Sie jetzt zu den Flusslogs im BigQuery-Dataset zurück und vergewissern Sie sich anhand der letzten Logs, dass keine unerwünschte interzonale Kommunikation mehr stattfindet.

Kostenanalyse

Sehen Sie sich die Preise für ausgehenden Traffic von VM zu VM in Google Cloud an:

Pings zwischen den Pods in verschiedenen Zonen kosteten 0,01 $ pro GB. Dieser Betrag erscheint gering, kann aber in einem großen Cluster mit mehreren Diensten, die häufige Aufrufe zwischen verschiedenen Zonen ausführen, schnell steigen.

Nachdem Sie die Pods in dieselbe Zone verschoben hatten, kostete das Pingen nichts mehr.

Das wars! Sie haben das Lab erfolgreich abgeschlossen.

Sie haben Möglichkeiten zur Kostenoptimierung virtueller Maschinen kennengelernt, die Teil eines GKE-Clusters sind. Zuerst haben Sie eine Arbeitslast in einen Knotenpool mit einem besser geeigneten Maschinentyp migriert. Dann haben Sie die Vor‑ und Nachteile verschiedener Regionen kennengelernt. Abschließend haben Sie einen Pod mit hohem Traffic innerhalb eines regionalen Clusters in dieselbe Zone verschoben wie der Pod, mit dem er kommuniziert hat.

Sie haben in diesem Lab kostengünstige Tools und Strategien für GKE-VMs kennengelernt. Das Optimieren virtueller Maschinen erfordert jedoch eine genaue Kenntnis der Anwendungen und Anforderungen. In der Regel wird die Entscheidung darüber, welcher Standort und Maschinentyp für die virtuellen Maschinen des GKE-Clusters am besten geeignet ist, von diesen Faktoren beeinflusst: Informationen über die Arten von Arbeitslasten, die Sie ausführen möchten, sowie eine Einschätzung der Anforderungen Ihrer Anwendung.

Die effiziente Nutzung der Clusterinfrastruktur ist ein entscheidender Schritt zur Kostenoptimierung.

Weitere Informationen

• Leitfaden zu Ressourcen und Vergleichen für Maschinenfamilien
• Best Practices zum Ausführen kostenoptimierter Kubernetes-Anwendungen in GKE: Richtigen Maschinentyp auswählen
• Best Practices zum Ausführen kostenoptimierter Kubernetes-Anwendungen in GKE: Geeignete Region auswählen

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 14. Mai 2025 aktualisiert

Lab zuletzt am 14. Mai 2025 getestet

© 2025 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.