1. Übersicht
Das Umschreiben oder die Neuentwicklung vorhandener Anwendungen für 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 der Compute Engine gehostet wird, mit Migrate for Anthos zur Kubernetes Engine.
Lerninhalte
- Migrate for Anthos in einem Kubernetes-Cluster bereitstellen
- Container in einem zustandsorientierten Satz aus einer vorhandenen Compute Engine-Instanz erstellen
- Container in Kubernetes bereitstellen und mit einem Load-Balancer konfigurieren
Voraussetzungen
- Google Cloud-Projekt mit eingerichtetem Abrechnungskonto. Wenn Sie noch kein Projekt haben, müssen Sie eines erstellen.
2. Einrichtung
Dieses Codelab kann vollständig in der Google Cloud Platform ausgeführt werden, ohne dass eine lokale Installation oder Konfiguration erforderlich ist.
APIs aktivieren
Aktivieren Sie vor dem Start die erforderlichen APIs in Ihrem Google Cloud-Projekt:
Compute Engine-Webserver erstellen
Erstellen Sie eine Compute-Instanz, die als Host für den ersten NGINX-Webserver dient, sowie die Firewallregeln, mit denen Sie die Standard-Landingpage des Webservers aufrufen können. Es gibt verschiedene Möglichkeiten, dies zu tun. Zur Vereinfachung verwenden wir die 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 wird eine Firewallregel mit dem Namen „default-allow-http“ erstellt, 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 der Webserver ausgeführt wird.
Sobald die Instanz ausgeführt wird, können wir über die 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.
Prüfen Sie, ob der Webserver ausgeführt wird, indem Sie die externe IP-Adresse der Instanz aus dem vorherigen Schritt in den Browser eingeben. Sie sollten den standardmäßigen NGINX-Begrüßungsbildschirm 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, zu dem wir den Compute Engine-Webserver migrieren. Führen Sie in der Cloud Console folgenden Befehl 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 abgeschlossen ist. Nachdem der Cluster erstellt wurde, erhalten Sie eine Ausgabe mit den 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 der Compute-Instanz zum zustandsorientierten Satz
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 vor dem Fortfahren die Instanz-ID, die wir später benötigen:
gcloud compute instances describe webserver --zone us-central1-a | grep ^id
Fahren Sie die Compute Engine-Instanz herunter:
gcloud compute instances stop webserver --zone us-central1-a
Nachdem die Instanz beendet wurde, können wir mit dem folgenden Skript sicher Snapshots der Laufwerke erstellen. Fügen Sie die Projekt-ID und die Instanz-ID ein:
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 führt clone_vm_disks.py Folgendes aus:
- Prüfen, ob die GCE-Instanz beendet ist
- Snapshot von jedem Laufwerk der Instanz erstellen
- Neues Laufwerk aus jedem Snapshot erstellen
- Erstellte Snapshots löschen
- YAML-Datei im aktuellen Arbeitsverzeichnis erstellen, um einen zustandsorientierten Satz bereitzustellen, der als Host für den Webserver dient
Mit der generierten YAML-Datei wird ein zustandsorientierter Satz in unserem Kubernetes-Cluster bereitgestellt, zusammen mit den Ansprüchen auf nichtflüchtigen Speicher, die zum Einbinden der kopierten Laufwerke in den Webserver-Container erforderlich sind. Wir können diese Änderungen mit kubectl anwenden:
kubectl apply -f containerized-webserver.yaml
Prüfen Sie den Status des zustandsorientierten Webserver-Satzes auf der Seite „Arbeitslasten“:
Es ist normal, dass der Status nach dem Ausführen von kubectl apply einige Minuten lang „Pods are pending“ (Pods werden noch erstellt) lautet. Fahren Sie fort, sobald der Status „OK“ lautet.
5. Cluster für Load-Balancer freigeben
An diesem Punkt sollte unser Kubernetes-Cluster den Webserver als zustandsorientierten Satz ausführen. Wir müssen den Container jedoch auch für einen Load-Balancer freigeben, um über eine externe IP-Adresse auf den Webserver zuzugreifen. Erstellen Sie in der Cloud Shell eine neue Datei mit dem Namen loadbalancer.yaml und dem folgenden 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 sie jetzt mit kubectl an:
kubectl apply -f loadbalancer.yaml
Mit „kubectl“ können wir die externe IP-Adresse des Webserver-Containerdienstes abrufen:
kubectl get services
Wenn wir die externe IP-Adresse in den Browser eingeben, sollten wir den gleichen standardmäßigen NGINX-Begrüßungsbildschirm wie zuvor sehen:
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 der Arbeitsbereich eingerichtet ist.
Bewegen Sie den Mauszeiger nach dem Laden im linken Bereich auf „Ressourcen“ und wählen Sie im Menü „Kubernetes Engine (neu)“ aus.
Jede Zeile im Dashboard stellt eine Kubernetes-Ressource dar. Über die Links über dem Dashboard können Sie zwischen der Ansicht „Infrastruktur“, „Arbeitslasten“ oder „Dienste“ 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 „webserver-statefulset“. Hier finden Sie einige sofort einsatzbereite Messwerte, die von Stackdriver erfasst werden, darunter die Speicher- und CPU-Auslastung.
Die in diesem Dashboard angezeigten Diagramme können wir verwenden, um ein benutzerdefiniertes Dashboard zu erstellen.
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. Erstellen wir ein benutzerdefiniertes Dashboard, um einen Überblick über einige Messwerte unseres Webservers zu erhalten.
Bewegen Sie den Mauszeiger im linken Bereich auf „Dashboards“ und klicken Sie dann auf „Dashboard erstellen“.
Nachdem wir nun ein leeres Dashboard haben, können wir Messwerte hinzufügen, die wir im Auge 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 sofort einsatzbereiten Messwerte? Fügen wir ein Diagramm für die CPU-Auslastung des Containers hinzu. Geben Sie im Feld für den Diagrammtitel „CPU-Auslastung“ ein. Geben Sie im Feld „Ressourcentyp und Messwert finden“ request_utilization ein und wählen Sie in der gefilterten Liste „CPU request utilization“ (CPU-Anfrageauslastung) aus. Mit dieser Auswahl werden die Felder „Ressourcentyp“ und „Messwert“ automatisch 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 es in der gefilterten Liste aus und wählen Sie im Feld „Wert“ Ihr Projekt aus. Wir müssen auch nach „container_name“ filtern. Geben Sie im Feld „Filter“ container_name ein, wählen Sie es in 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 Messwerte bestimmte von uns festgelegte Grenzwerte erreichen. Wir können beispielsweise festlegen, dass wir von Stackdriver per E‑Mail benachrichtigt werden, wenn die CPU-Auslastung aus dem letzten Schritt über einen bestimmten Grenzwert steigt und dies über einen längeren Zeitraum anhält. Das kann auf ein Problem mit unserer Anwendung hindeuten. Um zu zeigen, wie diese Benachrichtigungen aussehen, richten wir eine Verfügbarkeitsdiagnose 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 des Load-Balancers als Hostnamen 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 „Verstoß beliebiger Zeitachse“ fest und klicken Sie auf Speichern.
Wir sind noch nicht ganz fertig. Als Nächstes geben wir einen Benachrichtigungskanal an, damit wir benachrichtigt werden, wenn unsere Benachrichtigungsrichtlinie verletzt wurde. Wählen Sie in der Drop-down-Liste „Typ Benachrichtigungskanal“ die Option „E‑Mail“ und geben Sie eine gültige E‑Mail-Adresse ein.
Klicken Sie auf Benachrichtigungskanal hinzufügen. Geben Sie unten im Formular der Richtlinie den Namen „Web App Uptime“ und klicken Sie auf „Speichern“.
Um zu sehen, wie eine Benachrichtigung aussieht, öffnen Sie in der Cloud Console noch einmal die Cloud Shell. 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 erhalten, in der Sie über den Ausfall informiert werden:
Machen wir das rückgängig. Starten Sie NGINX in der Cloud Shell neu:
kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx"
Nach einigen Minuten erhalten Sie eine weitere E‑Mail von Stackdriver, diesmal mit besseren Nachrichten als zuvor:
8. Bereinigen
Nachdem wir mit Migrate for Anthos von der Compute Engine zur Kubernetes Engine migriert haben, bereinigen wir unser Projekt von allen erstellten Ressourcen.
Projekt löschen
Sie können auch 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 Beenden.
Wenn Sie die verschiedenen Komponenten einzeln löschen möchten, fahren Sie mit dem nächsten Abschnitt fort.
Stackdriver
Dashboard
Klicken Sie auf der Dashboard-Seite oben auf der Seite auf das Symbol für die Einstellungen 
und wählen Sie Dashboard löschen aus.
Benachrichtigungsrichtlinie
Wählen Sie auf der Seite Richtlinien im Menü „Aktionen“ 
rechts für jede erstellte Richtlinie die Option Löschen aus.
Verfügbarkeitsdiagnose
Wählen Sie auf der Seite „Verfügbarkeitsdiagnosen“ im Menü „Aktionen“ rechts neben jeder 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, zustandsorientierter Satz und Load-Balancer-Dienst)
gcloud container clusters delete my-gke-cluster --zone=us-central1-a
Laufwerke
Unser zustandsorientierter Satz hat ein von uns erstelltes Laufwerk verwendet. Verwenden Sie den folgenden Befehl, um den Namen abzurufen:
gcloud compute disks list --filter=webserver
Ersetzen Sie „my-disk-name“ durch den Namen Ihres Laufwerks und löschen Sie es mit dem folgenden Befehl:
gcloud compute disks delete vls-690d-webserver --zone=us-central1-a
Alles bereinigt!
9. Das wars! Sie haben das Lab erfolgreich abgeschlossen.
Super! Sie haben Ihren Webserver mit Migrate for Anthos von einer GCE-Instanz zu einem Kubernetes-Cluster migriert.
Behandelte Themen
- Wir haben einen Webserver mit Migrate for Anthos von der Compute Engine zu einem Kubernetes-Cluster migriert.
- Wir haben unseren zustandsorientierten Webserver für die Welt geöffnet, indem wir ihn über einen Kubernetes-Load-Balancer-Dienst freigegeben haben.
- Wir haben Stackdriver aktiviert und ein benutzerdefiniertes Dashboard erstellt.
- Wir haben eine Verfügbarkeitsdiagnose zusammen mit einer Benachrichtigungsrichtlinie konfiguriert, um benachrichtigt zu werden, wenn unser Webserver ausfällt.