1. Übersicht
Das Umschreiben oder Umgestalten vorhandener Anwendungen für die Verwendung in Kubernetes ist nicht immer möglich oder manuell durchführbar. Mit Migrate for Anthos können Sie Ihre vorhandenen Anwendungen modernisieren und in Kubernetes ausführen. In diesem Codelab migrieren Sie eine vorhandene Webanwendung, die in Compute Engine gehostet wird, mithilfe von Migrate for Anthos zu Kubernetes Engine.
Lerninhalte
- Migrate for Anthos in einem Kubernetes-Cluster bereitstellen
- Container in einem StatefulSet aus einer vorhandenen Compute Engine-Instanz erstellen
- Container in Kubernetes bereitstellen und mit einem Load Balancer konfigurieren
Voraussetzungen
- Ein Google Cloud-Projekt mit eingerichteter Abrechnung. Wenn Sie noch kein Konto haben, müssen Sie eins erstellen.
2. Einrichtung
Dieses Codelab kann vollständig auf der Google Cloud Platform ausgeführt werden, ohne dass eine lokale Installation oder Konfiguration erforderlich ist.
APIs aktivieren
Achten Sie vor dem Start darauf, dass die erforderlichen APIs in Ihrem Google Cloud-Projekt aktiviert sind:
Compute Instance-Webserver erstellen
Erstellen wir eine Compute-Instanz, die wir zum Hosten unseres ersten NGINX-Webservers verwenden, sowie die Firewallregeln, mit denen wir die Standard-Landingpage des Webservers aufrufen können. Dafür gibt es verschiedene Möglichkeiten. Der Einfachheit halber verwenden wir Cloud Shell.
Führen Sie in Cloud Shell folgenden Befehl aus:
gcloud compute instances create webserver --zone=us-central1-a && \ gcloud compute firewall-rules create default-allow-http --allow=tcp:80
Mit der ersten Hälfte dieses Befehls wird eine Google Cloud-Instanz in der Zone „us-central1-a“ erstellt, mit der zweiten Hälfte eine Firewallregel mit dem Namen „default-allow-http“, die HTTP-Traffic in unserem Netzwerk zulässt.
Wenn die Instanz erfolgreich erstellt wurde, wird eine Tabelle mit den Details der Instanz angezeigt. Notieren Sie sich die externe IP-Adresse. Wir benötigen sie später, um zu prüfen, ob unser Webserver ausgeführt wird.

Sobald die Instanz ausgeführt wird, können wir über Cloud Shell eine SSH-Verbindung zur Instanz herstellen, um nginx zu installieren und den Webserver zu starten:
gcloud compute ssh --zone us-central1-a webserver
Installieren Sie nginx, nachdem Sie sich in unserer Compute-Instanz angemeldet haben:
sudo apt install nginx
Melden Sie sich mit dem Befehl logout von der SSH-Sitzung ab.
Wir prüfen jetzt, ob unser Webserver ausgeführt wird. Geben Sie dazu die externe IP-Adresse der Instanz aus dem vorherigen Schritt in den Browser ein. Sie sollten den nginx-Standard-Willkommensbildschirm sehen:

Dieser Webserver dient als Legacy-Webanwendung, die wir mit Migrate for Anthos zu Kubernetes migrieren.
3. Kubernetes-Cluster mit Migrate for Anthos
Als Nächstes erstellen wir einen GKE-Cluster, in den wir den Compute Engine-Webserver migrieren. Führen Sie in der Cloud Console Folgendes aus:
gcloud container clusters create my-gke-cluster \ --zone us-central1-a \ --cluster-version 1.13 \ --machine-type n1-standard-4 \ --image-type "UBUNTU" \ --num-nodes 1 \ --enable-stackdriver-kubernetes
Es kann einige Minuten dauern, bis dieser Befehl ausgeführt wird. Nachdem der Cluster erstellt wurde, erhalten Sie eine Ausgabe mit den entsprechenden Details:

Rufen Sie als Nächstes den GCP Marketplace auf, um Migrate for Anthos bereitzustellen:

Klicken Sie auf der Marketplace-Seite für Migrate for Anthos auf „Konfigurieren“ und wählen Sie bei Aufforderung Ihr Projekt aus der Liste aus. Auf der nächsten Seite wird ein Formular mit einigen Standardwerten angezeigt. Achten Sie darauf, dass der ausgewählte Cluster der ist, den wir gerade erstellt haben, und klicken Sie auf Bereitstellen:

Migrate for Anthos sollte jetzt in unserem Kubernetes-Cluster bereitgestellt werden. Wenn die Bereitstellung abgeschlossen ist, wird auf der Seite „Kubernetes Engine-Anwendungen“ der Status „OK“ angezeigt:

4. Von Compute-Instanz zu zustandsorientiertem Set
Wir haben einen Kubernetes-Cluster, auf dem Migrate for Anthos ausgeführt wird. Jetzt können wir mit der Migration beginnen. Um unsere Compute-Instanz in einem Kubernetes-Cluster bereitzustellen, fahren wir unsere Compute Engine-Instanz herunter, damit wir Snapshots der Laufwerke erstellen können. Notieren Sie sich die Instanz-ID, die wir später benötigen:
gcloud compute instances describe webserver --zone us-central1-a | grep ^id
Fahren wir die Compute-Instanz herunter:
gcloud compute instances stop webserver --zone us-central1-a
Da die Instanz jetzt gestoppt ist, können wir die Laufwerke mit dem folgenden Skript sicher als Snapshot speichern. Achten Sie darauf, Ihre Projekt-ID und Ihre Instanz-ID einzufügen:
python3 /google/migrate/anthos/gce-to-gke/clone_vm_disks.py \ -p <project-id> -i <instance-id> \ -z us-central1-a \ -T us-central1-a \ -A webserver-statefulset \ -o containerized-webserver.yaml
Mit diesen Flags wird clone_vm_disks.py:
- Prüfen, ob die GCE-Instanz ausgeschaltet ist
- Snapshot von jedem Laufwerk Ihrer Instanz erstellen
- Neues Laufwerk aus jedem Snapshot erstellen
- Von ihm erstellte Snapshots löschen
- Generieren Sie in Ihrem aktuellen Arbeitsverzeichnis eine YAML-Datei zum Bereitstellen eines StatefulSets, auf dem Ihr Webserver gehostet wird.
Mit der generierten YAML-Datei wird ein StatefulSet in unserem Kubernetes-Cluster bereitgestellt, zusammen mit den Ansprüchen auf nichtflüchtige Volumes, die zum Einbinden der kopierten Laufwerke in unseren Webserver-Container erforderlich sind. Wir können diese Änderungen mit kubectl anwenden:
kubectl apply -f containerized-webserver.yaml
Prüfen Sie den Status des StatefulSets des Webservers auf der Seite „Arbeitslasten“:
Es ist normal, dass der Status nach dem Ausführen von kubectl apply einige Minuten lang „Pods are pending“ (Pods stehen aus) lautet. Fahren Sie erst fort, wenn der Status „OK“ lautet.
5. Cluster für Load-Balancer bereitstellen
An diesem Punkt sollte unser Kubernetes-Cluster unseren Webserver als StatefulSet ausführen. Wir müssen seinen Container jedoch auch für einen Load-Balancer freigeben, um über eine externe IP-Adresse auf unseren Webserver zugreifen zu können. Erstellen Sie in Cloud Shell eine neue Datei mit dem Namen loadbalancer.yaml und folgendem Inhalt:
loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
name: webserver-loadbalancer
spec:
type: LoadBalancer
selector:
app: webserver-statefulset
ports:
- protocol: TCP
port: 80
targetPort: 80
Wenden Sie es jetzt mit kubectl an:
kubectl apply -f loadbalancer.yaml
Wir können mit kubectl die externe IP-Adresse des Dienstes „webserver-container“ abrufen:
kubectl get services
Wenn wir die externe IP-Adresse in unseren Browser eingeben, sollten wir denselben standardmäßigen nginx-Begrüßungsbildschirm wie zuvor erhalten:

Wir haben es geschafft! Unser GCE-Webserver wird jetzt in Kubernetes gehostet. Sehr gut!
6. Stackdriver Monitoring
Messwerte
Als verwalteter Kubernetes-Dienst ist Kubernetes Engine automatisch für Logging und Monitoring mit Stackdriver instrumentiert. Sehen wir uns einige der Messwerte an, die Stackdriver automatisch für uns erfasst.
Klicken Sie im Produktmenü auf den Link „Monitoring“. Wenn Sie zum ersten Mal über Ihr Projekt darauf zugreifen, kann es einige Minuten dauern, bis Ihr Arbeitsbereich eingerichtet ist.
Bewegen Sie den Mauszeiger nach dem Laden im linken Bereich auf „Ressourcen“ und wählen Sie im Menü „Kubernetes Engine NEW“ aus.

Jede Zeile im hier gezeigten Dashboard steht für eine Kubernetes-Ressource. Über die Links über dem Dashboard können Sie zwischen der Infrastruktur-, Arbeitslasten- und Diensteansicht wechseln.

Maximieren Sie in der Ansicht „Arbeitslasten“ „my-gke-cluster“ und führen Sie einen Drilldown zu „default“ > „webserver-statefulset“ > „webserver-statefulset-0“ > „webserver-statefulset“ durch. Klicken Sie auf den Container des StatefulSet für den Webserver. Hier finden Sie einige Standardmesswerte, die von Stackdriver erfasst werden, darunter die Speicher- und CPU-Auslastung.

Die in diesem Dashboard angezeigten Diagramme können wir zum Erstellen eines benutzerdefinierten Dashboards verwenden.
Benutzerdefinierte Dashboards
Mit Stackdriver können wir benutzerdefinierte Dashboards erstellen, mit denen wir Diagramme und Grafiken für alle verfügbaren Messwertdaten organisieren können. Wir erstellen ein benutzerdefiniertes Dashboard, um einige Messwerte unseres Webservers auf einen Blick zu sehen.
Bewegen Sie den Mauszeiger in der linken Seitenleiste auf „Dashboards“ und klicken Sie dann auf „Dashboard erstellen“.

Nachdem wir unser leeres Dashboard erstellt haben, können wir Messwerte hinzufügen, die wir im Blick behalten möchten. Geben Sie dem unbenannten Dashboard einen aussagekräftigen Namen wie „Meine Webserver-Container“ und klicken Sie rechts oben auf „Diagramm hinzufügen“:

Erinnern Sie sich an die Standardmesswerte? Fügen wir ein Diagramm für die Container-CPU-Auslastung hinzu. Geben Sie im Feld „Diagrammtitel“ „CPU-Auslastung“ ein. Geben Sie im Feld „Ressourcentyp und Messwert finden“ request_utilization ein und wählen Sie aus der gefilterten Liste „CPU request utilization“ (CPU-Anfrageauslastung) aus. Durch diese Auswahl werden sowohl die Felder „Ressourcentyp“ als auch „Messwert“ ausgefüllt.
Als Nächstes filtern wir nach „project_id“ (wenn wir mehrere Projekte haben) und „container_name“. Geben Sie im Feld „Filter“ project_id ein, wählen Sie die Option aus der gefilterten Liste aus und wählen Sie Ihr Projekt im Feld „Wert“ aus. Außerdem müssen wir nach „container_name“ filtern. Geben Sie im Feld „Filter“ container_name ein, wählen Sie den Eintrag aus der gefilterten Liste aus und wählen Sie im Feld „Wert“ „webserver-statefulset“ aus. Klicken Sie auf „Speichern“.
Wir haben jetzt ein Dashboard mit unserem ersten Diagramm.

7. Verfügbarkeitsdiagnose und Benachrichtigungsrichtlinie
Mit Stackdriver können wir Benachrichtigungen einrichten, die uns informieren, wenn ein Messwert einen von uns angegebenen Grenzwert erreicht. Wir können beispielsweise festlegen, dass wir von Stackdriver per E-Mail benachrichtigt werden, wenn die CPU-Auslastung des letzten Schritts über einen längeren Zeitraum einen bestimmten Grenzwert überschreitet. Das kann auf ein Problem mit unserer App hinweisen. Um zu zeigen, wie solche Benachrichtigungen aussehen, richten wir einen Uptime-Check ein und simulieren dann einen Ausfall.
Wählen Sie im linken Bereich „Verfügbarkeitsdiagnosen“ und dann „Verfügbarkeitsdiagnosen: Übersicht“ aus:

Wie auf der Seite „Verfügbarkeitsdiagnosen“ vorgeschlagen, richten wir unsere erste Verfügbarkeitsdiagnose ein. Klicken Sie rechts oben auf der Seite auf die Schaltfläche Verfügbarkeitsdiagnose hinzufügen.
Geben Sie im folgenden Formular „Endpoint Uptime“ als Titel und die externe IP-Adresse Ihres Load-Balancers als Hostname ein.

Klicken Sie auf Speichern. Sie werden aufgefordert, eine zugehörige Benachrichtigungsrichtlinie zu erstellen:

Klicken Sie auf Benachrichtigungsrichtlinie erstellen.
Nennen wir sie „Endpoint Uptime Policy“. Legen Sie im Abschnitt Konfiguration für „Bedingung erfüllt, wenn“ die Option „Bei jedem Verstoß“ fest und klicken Sie auf Speichern.

Wir sind noch nicht ganz fertig. Als Nächstes legen wir einen Benachrichtigungskanal fest, damit wir benachrichtigt werden, wenn gegen unsere Benachrichtigungsrichtlinie verstoßen wurde. Wählen Sie im Drop-down-Menü „Typ Benachrichtigungskanal“ die Option „E-Mail“ und dann eine gültige E-Mail-Adresse aus.

Klicken Sie auf Benachrichtigungskanal hinzufügen. Geben Sie unten im Formular den Namen „Web App Uptime“ für die Richtlinie ein und klicken Sie auf „Save“ (Speichern).
Wenn Sie sehen möchten, wie eine Benachrichtigung aussieht, öffnen Sie Cloud Shell noch einmal in der Cloud Console. Mit dem folgenden Befehl wird der Nginx-Dienst beendet, der in unserem Webserver-Pod ausgeführt wird:
kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx -s stop"
Nach einigen Minuten sollten Sie eine E‑Mail mit einer Benachrichtigung über den Ausfall erhalten:

Machen wir das rückgängig. Starten wir nginx in Cloud Shell neu:
kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx"
Nach einigen Minuten erhalten Sie eine weitere Stackdriver-E-Mail, diesmal mit besseren Neuigkeiten als zuvor:

8. Bereinigen
Nachdem wir mit Migrate for Anthos von GCE zu GKE migriert sind, bereinigen wir unser Projekt von allen Ressourcen, die wir erstellt haben.
Projekt löschen
Wenn Sie möchten, können Sie das gesamte Projekt löschen. Rufen Sie in der GCP Console die Seite Cloud Resource Manager auf:
Wählen Sie in der Projektliste das Projekt aus, in dem wir gearbeitet haben, und klicken Sie auf Löschen. Sie werden aufgefordert, die Projekt-ID einzugeben. Geben Sie sie ein und klicken Sie auf Herunterfahren.
Wenn Sie die einzelnen Komponenten lieber einzeln löschen möchten, fahren Sie mit dem nächsten Abschnitt fort.
Stackdriver
Dashboard
Klicken Sie auf der Dashboard-Seite oben auf das Symbol für die Einstellungen
und wählen Sie Dashboard löschen aus.
Benachrichtigungsrichtlinie
Wählen Sie auf der Seite „Richtlinien“ für jede von Ihnen erstellte Richtlinie rechts im Menü „Aktionen“
die Option Löschen aus.
Verfügbarkeitsdiagnose
Wählen Sie auf der Seite „Verfügbarkeitsdiagnosen“ im Menü „Aktionen“ rechts neben jeder von Ihnen erstellten Diagnose die Option Löschen aus.
GCE und Kubernetes
Google Compute Engine-Instanz
gcloud compute instances delete webserver --zone=us-central1-a
Kubernetes-Cluster (einschließlich Migrate for Anthos, StatefulSet und Load-Balancer-Dienst)
gcloud container clusters delete my-gke-cluster --zone=us-central1-a
Laufwerke
Unser zustandsorientiertes Set hat ein von uns erstelltes Laufwerk verwendet. Verwenden Sie den folgenden Code, um den Namen abzurufen:
gcloud compute disks list --filter=webserver
Löschen Sie das Laufwerk mit Ihrem Laufwerksnamen anstelle meines:
gcloud compute disks delete vls-690d-webserver --zone=us-central1-a
Alles bereinigt!
9. Glückwunsch!
Weiter so! Sie haben Ihren Webserver mithilfe von Migrate for Anthos von einer GCE-Instanz zu einem Kubernetes-Cluster migriert.
Behandelte Themen
- Wir haben einen Webserver mit Migrate for Anthos von GCE zu einem Kubernetes-Cluster migriert.
- Wir haben unseren zustandsorientierten Webserver für die Außenwelt geöffnet, indem wir ihn über einen Kubernetes-Load-Balancer-Dienst bereitgestellt haben.
- Wir haben Stackdriver aktiviert und ein benutzerdefiniertes Dashboard erstellt.
- Wir haben eine Verfügbarkeitsdiagnose zusammen mit einer Benachrichtigungsrichtlinie konfiguriert, damit wir benachrichtigt werden, wenn unser Webserver ausfällt.
