GSP053

Übersicht

Im Zuge der Best Practices für DevOps werden häufig mehrere Deployments genutzt, um verschiedene Szenarien des Anwendungs-Deployments zu verwalten, z. B. kontinuierliche Deployments, Blau/Grün-Deployments und Canary-Deployments. In diesem Lab wird gezeigt, wie Sie Container für diese gängigen Szenarien skalieren und verwalten, bei denen mehrere heterogene Deployments verwendet werden.

Lernziele

Aufgaben in diesem Lab:

• kubectl-Tool verwenden
• yaml-Dateien für das Deployment erstellen
• Deployments bereitstellen, aktualisieren und skalieren
• Deployments aktualisieren und mehr über Deployment-Stile erfahren

Vorbereitung

Für einen maximalen Lernerfolg empfehlen wir für dieses Lab Folgendes:

• Sie haben folgende Google Cloud Skills Boost-Labs absolviert:
  • Einführung in Docker
  • Hello Node Kubernetes
• Sie haben Kenntnisse der Linux-Systemverwaltung.
• Sie wissen über die DevOps-Theorie sowie über die Konzepte des kontinuierlichen Deployments Bescheid.

Einführung in Deployments

Bei heterogenen Deployments werden in der Regel mindestens zwei Infrastrukturumgebungen oder Regionen miteinander verbunden. Auf diese Art lassen sich bestimmte technische oder betriebliche Anforderungen erfüllen. Heterogene Deployments werden je nach Typ auch als Hybrid-Cloud, Multi-Cloud oder öffentliche/private Cloud bezeichnet.

In diesem Lab umfasst der Begriff Deployments, die in Regionen innerhalb einer einzelnen Cloud-Umgebung, in mehreren öffentlichen Cloud-Umgebungen (Multi-Cloud) oder in lokalen und öffentlichen Cloud-Umgebungen (hybrid oder öffentlich/privat) bereitgestellt werden.

In Deployments, die auf eine einzelne Umgebung oder Region beschränkt sind, können verschiedene geschäftliche und technische Probleme auftreten:

• Ausgeschöpfte Ressourcen: Eine einzelne Umgebung verfügt möglicherweise nicht über die notwendigen Rechen-, Netzwerk- und Speicherressourcen, um Ihren Produktionsanforderungen gerecht zu werden. Dies gilt insbesondere für lokale Umgebungen.
• Eingeschränkte geografische Reichweite: Bei Deployments in einer einzelnen Umgebung müssen Personen, die geografisch voneinander getrennt sind, auf dasselbe Deployment zugreifen können. Der dabei erzeugte Traffic wird an einen zentralen Ort übertragen.
• Eingeschränkte Verfügbarkeit: Trafficmuster auf Webebene erfordern fehlertolerante und belastbare Anwendungen.
• Anbieterabhängigkeit: Anbietereigene Plattform- und Infrastrukturabstraktionen können das Portieren von Anwendungen verhindern.
• Unflexible Ressourcen: Ressourcen sind möglicherweise auf bestimmte Rechen-, Speicher- und Netzwerkangebote beschränkt.

Heterogene Deployments können dabei helfen, diese Herausforderungen zu bewältigen. Sie müssen jedoch mit programmatischen und deterministischen Prozessen und Verfahren entworfen werden. Einmalige oder Ad-hoc-Deployment-Verfahren können dazu führen, dass Deployments oder Prozesse problemanfällig und fehlerintolerant sind. Bei Ad-hoc-Prozessen besteht die Gefahr, dass Daten verloren gehen oder dass der Traffic abgeschnitten wird. Ein gut geeigneter Deployment-Prozess muss wiederholbar sein und bewährte Ansätze für die Verwaltung der Bereitstellung, Konfiguration und Wartung enthalten.

Für heterogene Deployments gibt es drei gängige Szenarien:

• Multi-Cloud-Deployments
• Verfügbarmachung von lokalen Daten
• Prozesse der kontinuierlichen Integration / kontinuierlichen Bereitstellung (CI/CD)

In den folgenden Übungen lernen Sie häufige Anwendungsfälle von heterogenen Deployments kennen und erfahren, wie Sie Kubernetes und andere Infrastrukturressourcen in diesen Situationen nutzen.

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.

Zone festlegen

Die Arbeitszone für Google Cloud legen Sie fest, indem Sie den folgenden Befehl ausführen und dabei us‑central1‑a durch die lokale Zone ersetzen:

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

Beispielcode für dieses Lab abrufen

1. Führen Sie den folgenden Befehl aus, um den Beispielcode zum Erstellen und Ausführen von Containern und Deployments abzurufen:

gsutil ‑m cp ‑r gs://spls/gsp053/orchestrate-with-kubernetes . cd orchestrate-with-kubernetes/kubernetes

2. Erstellen Sie einen Cluster mit drei Knoten (das kann einige Minuten dauern):

gcloud container clusters create bootcamp \ ‑‑machine-type e2‑small \ ‑‑num-nodes 3 \ ‑‑scopes "https://www.googleapis.com/auth/projecthosting,storage‑rw"

Aufgabe 1: Das Deployment-Objekt

Als Erstes prüfen Sie das Deployment-Objekt.

1. Mit dem Befehl explain in kubectl lassen sich dazu weitere Informationen abrufen.

kubectl explain deployment

2. Sie können auch alle Felder aufrufen, die die Option ‑‑recursive verwenden:

kubectl explain deployment ‑‑recursive

3. Sie haben im Laufe des Labs die Möglichkeit, sich mit dem Befehl „explain“ die Struktur von Deployment-Objekten anzusehen. So lernen Sie die Funktion der einzelnen Felder kennen.

kubectl explain deployment.metadata.name

Aufgabe 2: Deployment erstellen

1. Aktualisieren Sie die Konfigurationsdatei deployments/auth.yaml:

vi deployments/auth.yaml

2. Öffnen Sie den Editor:

i

3. Nehmen Sie im Containerabschnitt des Deployments folgende Änderungen am Image vor:

... containers: - name: auth image: "kelseyhightower/auth:1.0.0" ...

4. Speichern Sie die Datei auth.yaml. Drücken Sie <Esc> und geben Sie Folgendes ein:

:wq

5. Drücken Sie die Eingabetaste. Nun erstellen Sie ein einfaches Deployment. Sehen Sie sich dazu die Konfigurationsdatei an:

cat deployments/auth.yaml

Ausgabe:

apiVersion: apps/v1 kind: Deployment metadata: name: auth spec: replicas: 1 selector: matchLabels: app: auth template: metadata: labels: app: auth track: stable spec: containers: - name: auth image: "kelseyhightower/auth:1.0.0" ports: - name: http containerPort: 80 - name: health containerPort: 81 ...

Mit dem Deployment wird ein Replikat erstellt und die Version 1.0.0 des auth‑Containers verwendet.

Wenn Sie den Befehl kubectl create ausführen, um das auth‑Deployment zu erstellen, wird ein Pod angelegt, der den Daten im Deployment-Manifest entspricht. Dies bedeutet, dass Sie die Anzahl der Pods skalieren können, indem Sie die im Feld Replikate angegebene Zahl ändern.

6. Erstellen Sie jetzt mit kubectl create ein eigenes Deployment-Objekt:

kubectl create ‑f deployments/auth.yaml

7. Anschließend können Sie prüfen, ob es erstellt wurde:

kubectl get deployments

8. Danach wird in Kubernetes ein ReplicaSet für das Deployment erstellt. Sie können nun prüfen, ob ein ReplicaSet für das Deployment angelegt wurde:

kubectl get replicasets

Der Name des ReplicaSet muss das Format auth‑xxxxxxx haben.

9. Prüfen Sie die Pods, die im Rahmen des Deployments erstellt wurden. Der einzelne Pod wird in Kubernetes zusammen mit dem ReplicaSet angelegt:

kubectl get pods

Als Nächstes wird der Dienst für das auth‑Deployment erstellt. Da Sie Dienstmanifestdateien bereits kennen, gehen wir hier nicht weiter ins Detail.

10. Verwenden Sie dazu den Befehl kubectl create:

kubectl create ‑f services/auth.yaml

11. Wiederholen Sie diesen Schritt, um das Deployment von hello zu erstellen und freizugeben:

kubectl create ‑f deployments/hello.yaml kubectl create ‑f services/hello.yaml

12. Wiederholen Sie den Schritt noch einmal, um das Deployment von frontend zu erstellen und bereitzustellen:

kubectl create secret generic tls-certs ‑‑from-file tls/ kubectl create configmap nginx‑frontend‑conf ‑‑from-file=nginx/frontend.conf kubectl create ‑f deployments/frontend.yaml kubectl create ‑f services/frontend.yaml Hinweis: Sie haben eine ConfigMap für das Frontend erstellt.

13. Rufen Sie die externe IP-Adresse aus „frontend“ ab und senden Sie dazu den folgenden curl‑Befehl an diese Adresse:

kubectl get services frontend Hinweis: Es kann einige Sekunden dauern, bis das Feld „External‑IP“ für Ihren Dienst ausgefüllt wird. Dies ist normal. Führen Sie den obigen Befehl einfach in Abständen von wenigen Sekunden so lange wiederholt aus, bis das Feld ausgefüllt ist. curl ‑ks https://<EXTERNAL‑IP>

Daraufhin wird die Antwort „hello“ zurückgegeben.

14. Mit der Funktion für Ausgabevorlagen in kubectl lässt sich der Befehl „curl“ als Einzeiler schreiben:

curl ‑ks https://`kubectl get svc frontend ‑o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`

Abgeschlossene Aufgabe testen

Klicken Sie unten auf Fortschritt prüfen. Wenn Sie einen Kubernetes-Cluster sowie Deployments für „auth“, „hello“ und „frontend“ erstellt haben, erhalten Sie ein Testergebnis.

Kubernetes-Cluster und Deployments („auth“, „hello“ und „frontend“) erstellen

Deployment skalieren

Nachdem Sie ein Deployment erstellt haben, können Sie es skalieren. Aktualisieren Sie dazu das Feld spec.replicas.

1. Mit dem Befehl kubectl explain können Sie eine Erklärung zu dem Feld abrufen:

kubectl explain deployment.spec.replicas

2. Das Feld „spec.replicas“ lässt sich am einfachsten mit dem Befehl kubectl scale aktualisieren:

kubectl scale deployment hello ‑‑replicas=5 Hinweis: Es dauert etwa eine Minute, bis alle neuen Pods ausgeführt sind.

Nach dem Update des Deployments wird in Kubernetes automatisch das dazugehörende ReplicaSet aktualisiert. Außerdem werden so viele neue Pods gestartet, bis die Gesamtzahl fünf erreicht ist.

3. Prüfen Sie, ob jetzt fünf Pods für hello ausgeführt werden:

kubectl get pods | grep hello- | wc ‑l

4. Skalieren Sie die Anwendung nun wieder herunter:

kubectl scale deployment hello ‑‑replicas=3

5. Prüfen Sie noch einmal, ob die richtige Anzahl Pods ausgeführt wird:

kubectl get pods | grep hello- | wc ‑l

In diesem Abschnitt haben Sie Kubernetes-Deployments kennengelernt und erfahren, wie Sie eine Gruppe von Pods verwalten und skalieren.

Aufgabe 3: Rolling Update

In Deployments lassen sich Images mithilfe von Rolling Updates auf eine neuere Version aktualisieren. Bei diesem Vorgang wird ein neues ReplicaSet erstellt und die Zahl der Replikate im neuen ReplicaSet langsam gesteigert. Gleichzeitig wird die Replikatzahl im alten ReplicaSet verringert.

Rolling Update ausführen

1. Führen Sie den folgenden Befehl aus, um ein Deployment zu aktualisieren:

kubectl edit deployment hello

2. Nehmen Sie im Containerabschnitt des Deployments folgende Änderungen am Image vor:

... containers: image: kelseyhightower/hello:2.0.0 ...

3. Speichern und beenden Sie.

Das aktualisierte Deployment wird in Ihrem Cluster gespeichert und das Rolling Update in Kubernetes ausgelöst.

4. So rufen Sie das neue ReplicaSet auf, das in Kubernetes erstellt wurde:

kubectl get replicaset

5. Sie können sich auch den neuen Eintrag im Roll-out-Verlauf ansehen:

kubectl rollout history deployment/hello

Rolling Update pausieren

Falls bei einem laufenden Roll-out Probleme auftreten, können Sie es pausieren und die Aktualisierung so stoppen.

1. Führen Sie den folgenden Befehl aus, um das Roll-out zu pausieren:

kubectl rollout pause deployment/hello

2. Prüfen Sie den aktuellen Status des Roll-outs:

kubectl rollout status deployment/hello

3. Sie können ihn auch direkt auf den Pods kontrollieren:

kubectl get pods ‑o jsonpath ‑‑template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Rolling Update fortsetzen

Das Roll-out ist pausiert. Es sind also noch nicht alle Pods aktualisiert worden.

1. Mit dem Befehl resume können Sie es fortsetzen:

kubectl rollout resume deployment/hello

2. Wenn das Roll-out abgeschlossen ist, sollten Sie für den Befehl status die folgende Ausgabe erhalten:

kubectl rollout status deployment/hello

Ausgabe:

deployment "hello" successfully rolled out

Rollback für ein Update ausführen

Beispiel: In einer neuen Version wurde ein Programmfehler erkannt. Er wirkt sich auf alle Nutzer aus, die eine Verbindung zu den neuen Pods hergestellt haben.

In diesem Fall sollten Sie ein Rollback auf die vorherige Version ausführen. Dies verschafft Ihnen Zeit, um das Problem zu untersuchen und anschließend eine korrigierte Version zu veröffentlichen.

1. Verwenden Sie dafür den Befehl rollout:

kubectl rollout undo deployment/hello

2. Prüfen Sie im Rollbackverlauf, ob der Vorgang erfolgreich war:

kubectl rollout history deployment/hello

3. Untersuchen Sie zum Schluss, ob das Rollback für alle Pods ausgeführt wurde:

kubectl get pods ‑o jsonpath ‑‑template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Sehr gut. Sie haben gelernt, wie ein Rolling Update für Kubernetes-Deployments ausgeführt wird und wie Anwendungen ohne Ausfallzeit aktualisiert werden.

Aufgabe 4: Canary-Deployments

Wenn bestimmte Nutzer in der Produktion ein neues Deployment testen sollen, bietet sich ein Canary-Deployment an. Damit können Sie eine Änderung für eine kleine Nutzergruppe implementieren und so das Risiko verringern, das mit neuen Releases einhergeht.

Canary-Deployments erstellen

Canary-Deployments bestehen aus einem separaten Deployment, das die neue Version enthält, und einem Dienst, der sowohl das normale, stabile Deployment als auch das Canary-Deployment adressiert.

1. Erstellen Sie zuerst ein Canary-Deployment für die neue Version:

cat deployments/hello-canary.yaml

Ausgabe:

apiVersion: apps/v1 kind: Deployment metadata: name: hello-canary spec: replicas: 1 selector: matchLabels: app: hello template: metadata: labels: app: hello track: canary # Use ver 2.0.0 so it matches version on service selector version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 ...

2. Erstellen Sie nun das Canary-Deployment:

kubectl create ‑f deployments/hello-canary.yaml

3. Anschließend sollten Sie zwei Deployments haben: hello und hello-canary. Dies lässt sich mit dem folgenden kubectl-Befehl prüfen:

kubectl get deployments

Im Dienst hello wird der Selektor app:hello verwendet, der den Pods im Produktions- und im Canary-Deployment entspricht. Da das Canary-Deployment weniger Pods hat, ist es auch für weniger Nutzer sichtbar.

Canary-Deployment prüfen

1. Mit dieser Anfrage können Sie überprüfen, welche Version von hello bereitgestellt wird:

curl ‑ks https://`kubectl get svc frontend ‑o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

2. Führen Sie die Anfrage mehrmals aus. Sie werden sehen, dass einige der Anfragen von hello 1.0.0 und wiederum ein Teil davon (1/4 = 25 %) von hello 2.0.0 beantwortet werden.

Abgeschlossene Aufgabe testen

Klicken Sie unten auf Fortschritt prüfen. Wenn Sie ein Canary-Deployment erstellt haben, erhalten Sie ein Testergebnis.

Canary-Deployment

Canary-Deployments in der Produktion: Sitzungsaffinität

In diesem Lab durfte jede Anfrage, die an den Nginx-Dienst gesendet wurde, vom Canary-Deployment beantwortet werden. Was aber, wenn Nutzer eben nicht das Canary-Deployment nutzen sollen? Dies kann z. B. hilfreich sein, wenn sich die UI einer Anwendung geändert hat und Sie den Nutzer nicht verwirren möchten. In diesem Fall ist es besser, wenn der Nutzer das ursprüngliche Deployment weiterverwendet.

Dazu müssen Sie einen Dienst mit Sitzungsaffinität erstellen. So ist garantiert, dass ein Nutzer immer dieselbe Version verwendet. Im Beispiel unten wird wieder der Dienst „hello“ verwendet. Es wurde jedoch ein neues Feld sessionAffinity hinzugefügt und dafür der Wert ClientIP festgelegt. Wenn Clients dieselbe IP‑Adresse haben, werden die von Ihnen gesendeten Anfragen also an dieselbe Version der Anwendung hello gerichtet.

kind: Service apiVersion: v1 metadata: name: "hello" spec: sessionAffinity: ClientIP selector: app: "hello" ports: - protocol: "TCP" port: 80 targetPort: 80

Da es schwer ist, hierfür eine Testumgebung einzurichten, wird der Schritt in diesem Lab ausgelassen. Für Canary-Deployments in Produktionsumgebungen ist sessionAffinity jedoch gut geeignet.

Aufgabe 5: Blau/Grün-Deployments

Rolling Updates sind die ideale Lösung, denn sie ermöglichen es Ihnen, eine Anwendung nach und nach mit minimalem Aufwand sowie geringsten Leistungseinbußen und Ausfallzeiten bereitzustellen. Bei einigen Instanzen sollten Sie Load Balancer so ändern, dass sie erst dann auf die neue Version verweisen, wenn diese vollständig bereitgestellt wurde. Hier sind Blau/Grün-Deployments die beste Wahl.

Dabei werden in Kubernetes zwei separate Deployments erstellt: eine für die ältere "blaue" und eine andere für die neue "grüne" Version. Verwenden Sie für das „blaue“ Deployment die vorhandene Version von hello. Der Zugriff auf die Deployments erfolgt über einen Dienst, der als Router fungiert. Sobald die neue „grüne“ Version ausgeführt wird, wechseln Sie mit einem Dienstupdate dorthin.

Hinweis: Ein großer Nachteil von Blau/Grün-Deployments ist, dass Sie mindestens zweimal so viele Ressourcen in Ihrem Cluster benötigen, um eine Anwendung zu hosten, wie bei einem normalen Deployment. Wenn Sie beide Versionen der Anwendung gleichzeitig bereitstellen, müssen im Cluster also genügend Ressourcen vorhanden sein.

Der Dienst

Verwenden Sie den bestehenden Dienst „hello“, aber aktualisieren Sie ihn, sodass er über den Selektor app:hello, version: 1.0.0, verfügt. Der Selektor entspricht dem vorhandenen „blauen“ Deployment. Der Selektor entspricht nicht dem neuen „grünen“ Deployment, da dieses eine andere Version verwendet.

• Aktualisieren Sie zuerst den Dienst:

kubectl apply ‑f services/hello-blue.yaml Hinweis: Ignorieren Sie die Warnung resource service/hello is missing, da dies automatisch eingefügt wird.

Updates mithilfe eines Blau/Grün-Deployments

Damit Blau/Grün-Deployments unterstützt werden, erstellen Sie ein neues „grünes“ Deployment für die neue Version. Damit werden das Versionslabel und der Image-Pfad aktualisiert.

apiVersion: apps/v1 kind: Deployment metadata: name: hello-green spec: replicas: 3 selector: matchLabels: app: hello template: metadata: labels: app: hello track: stable version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 resources: limits: cpu: 0.2 memory: 10Mi livenessProbe: httpGet: path: /healthz port: 81 scheme: HTTP initialDelaySeconds: 5 periodSeconds: 15 timeoutSeconds: 5 readinessProbe: httpGet: path: /readiness port: 81 scheme: HTTP initialDelaySeconds: 5 timeoutSeconds: 1

1. Erstellen Sie das „grüne“ Deployment:

kubectl create ‑f deployments/hello-green.yaml

2. Wenn das neue Deployment richtig ausgeführt wird, sollten Sie prüfen, ob die aktuelle Version 1.0.0 weiterhin verwendet wird:

curl ‑ks https://`kubectl get svc frontend ‑o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

3. Aktualisieren Sie den Dienst, sodass er auf die neue Version verweist:

kubectl apply ‑f services/hello-green.yaml

4. Anschließend wird sofort das neue „grüne“ Deployment verwendet. Sie können nun prüfen, ob dies immer der Fall ist.

curl ‑ks https://`kubectl get svc frontend ‑o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

Blau/Grün-Rollback

Bei Bedarf können Sie auf dieselbe Weise ein Rollback auf die ältere Version durchführen.

1. Stellen Sie einfach die ältere Version des Dienstes wieder her, während die bestehende Version noch ausgeführt wird:

kubectl apply ‑f services/hello-blue.yaml

2. Durch das Update wird auch das Rollback wirksam. Überprüfen Sie, ob jetzt die richtige Version verwendet wird:

curl ‑ks https://`kubectl get svc frontend ‑o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

Geschafft! Sie kennen sich jetzt mit Blau/Grün-Deployments aus und wissen, wie Sie Updates bereitstellen, wenn gleichzeitig bei mehreren Anwendungen die Version geändert werden soll.

Das wars! Sie haben das Lab erfolgreich abgeschlossen.

Sie haben das Befehlszeilentool kubectl praktisch angewendet und gelernt, wie Sie mithilfe von YAML-Dateien und vielen verschiedenen Deployment-Konfigurationen Deployments starten, aktualisieren und skalieren. Nach diesem Lab können Sie die erworbenen Fähigkeiten sicher in Ihre DevOps-Arbeit einfließen lassen.

Weitere Informationen

• Deployment-Muster in Kubernetes.

• DevOps-Lösungen und ‑Leitfäden (Google Cloud-Dokumentation).

• Auf der Kubernetes-Website können Sie eine Verbindung zur Kubernetes-Community herstellen!

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 2. April 2024 aktualisiert

Lab zuletzt am 14. August 2023 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.