Anleitung: Vorhandene VM mit VM Runtime on GDC in einem Google Distributed Cloud-Cluster bereitstellen

In diesem Dokument wird Schritt für Schritt beschrieben, wie Sie eine auf einer virtuellen Maschine (VM) basierende Arbeitslast in Google Distributed Cloud mit VM Runtime auf GDC bereitstellen. Die in diesem Leitfaden verwendete Arbeitslast ist die Point of Sale-Beispielanwendung. Diese Anwendung stellt ein typisches POS-Terminal dar, das in lokaler Umgebung in einem Einzelhandelsgeschäft ausgeführt wird.

In diesem Dokument migrieren Sie diese Anwendung von einer VM in einen Google Distributed Cloud-Cluster und greifen auf das webbasierte Front-End der Anwendung zu. Um eine bestehende VM in den Cluster zu migrieren, muss zuerst ein Laufwerk-Image dieser VM erstellt werden. Dann muss das Image in einem Repository gehostet werden, auf das der Cluster zugreifen kann. Schließlich kann die URL für dieses Image verwendet werden, um die VM zu erstellen. VM Runtime auf GDC erwartet, dass die Images im qcow2-Format vorliegen. Wenn Sie einen anderen Image-Typ angeben, wird dieser automatisch in das qcow2-Format konvertiert. Um eine wiederholte Konvertierung zu vermeiden und die Wiederverwendung zu ermöglichen, können Sie ein Image eines virtuellen Laufwerks konvertieren und das qcow2-Image hosten.

In diesem Dokument wird ein vorbereitetes Image einer Compute Engine-VM-Instanz verwendet, wobei die Arbeitslast als systemd-Dienst ausgeführt wird. Mit diesen Schritten können Sie Ihre eigene Anwendung bereitstellen.

Ziele

Hinweise

Zum Durcharbeiten dieses Dokuments benötigen Sie die folgenden Ressourcen:

  • Zugriff auf einen Google Distributed Cloud-Cluster der Version 1.12.0 oder höher, der mit dem Leitfaden Google Distributed Cloud auf Compute Engine-VMs mit manuellem Load Balancer ausführen erstellt wurde. In diesem Dokument werden Netzwerkressourcen eingerichtet, damit Sie über einen Browser auf die in der VM ausgeführte Arbeitslast zugreifen können. Wenn Sie dieses Verhalten nicht benötigen, können Sie diesem Dokument in jeder Google Distributed Cloud folgen.
  • Eine Workstation, die die folgenden Anforderungen erfüllt:
    • Hat Zugriff auf Ihren Cluster mithilfe der bmctl-CLI.
    • Hat Zugriff auf Ihren Cluster mithilfe der kubectl-CLI.

VM Runtime auf GDC aktivieren und das Plug-in virtctl installieren

Die benutzerdefinierte Ressourcendefinition (CRD) „VM Runtime on GDC“ ist seit Version 1.10 Teil aller Google Distributed Cloud-Cluster. Eine Instanz der benutzerdefinierten VMRuntime-Ressource wird bereits bei der Installation erstellt. Sie ist jedoch standardmäßig deaktiviert.

  1. Aktivieren Sie die VM Runtime auf GDC:

    sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
    • KUBECONFIG_PATH: Pfad zur Kubernetes-Konfigurationdatei des Nutzerclusters von Google Distributed Cloud

  2. Prüfen Sie, ob VMRuntime aktiviert ist:

    kubectl wait --for=jsonpath='{.status.ready}'=true vmruntime vmruntime

    Es kann einige Minuten dauern, bis VMRuntime bereit ist. Wenn sie nicht bereit ist, prüfen Sie ein paar Mal hintereinander mit kurzen Abständen. Die folgende Beispielausgabe zeigt, dass VMRuntime bereit ist:

    vmruntime.vm.cluster.gke.io/vmruntime condition met

  3. Installieren Sie das virtctl-Plug-in für kubectl:

    sudo -E bmctl install virtctl

    Die folgende Beispielausgabe zeigt, dass der Installationsprozess des virtctl-Plug-ins abgeschlossen ist:

    Please check the logs at bmctl-workspace/log/install-virtctl-20220831-182135/install-virtctl.log
[2022-08-31 18:21:35+0000] Install virtctl succeeded

  4. Prüfen Sie die Installation des virtctl-Plug-ins:

    kubectl virt

    Die folgende Beispielausgabe zeigt, dass das Plug-in virtctl verfügbar zur Verwendung mit kubectl ist:

    Available Commands:
  addvolume         add a volume to a running VM
  completion        generate the autocompletion script for the specified shell
  config            Config subcommands.
  console           Connect to a console of a virtual machine instance.
  create            Create subcommands.
  delete            Delete  subcommands.
...

VM-basierte Arbeitslast bereitstellen

Wenn Sie eine VM in Google Distributed Cloud bereitstellen, erwartet VM Runtime auf GDC ein VM-Image. Dieses Image dient als Bootlaufwerk für die bereitgestellte VM.

In dieser Anleitung migrieren Sie eine Compute Engine-VM-basierte Arbeitslast in einen Google Distributed Cloud-Cluster. Diese Compute Engine-VM wurde erstellt und die Beispiel-POS-Anwendung (Point of Sale) wurde so konfiguriert, dass sie als systemd-Dienst ausgeführt wird. In Google Cloud wurde ein Laufwerk-Image dieser VM zusammen mit der PoS-Anwendungsarbeitslast erstellt. Dieses Image wurde dann in einen Cloud Storage-Bucket exportiert als ein qcow2-Bild exportiert. Sie verwenden in den folgenden Schritten dieses vorbereitete qcow2-Image.

Der Quellcode in diesem Dokument ist im anthos-samples-GitHub-Repository verfügbar. Sie verwenden Ressourcen aus diesem Repository, um die folgenden Schritte auszuführen.

  1. Stellen Sie eine MySQL-StatefulSet bereit. Die POS-Anwendung erwartet eine Verbindung zu einer MySQL-Datenbank, um Inventar- und Zahlungsinformationen zu speichern. Das Point of Sale-Repository enthält ein Beispielmanifest, das ein MySQL-StatefulSet bereitstellt, eine zugehörige ConfigMap und einen Kubernetes-Service konfiguriert. ConfigMap definiert die Anmeldedaten für die MySQL-Instanz. Dabei handelt es sich um dieselben Anmeldedaten, die an die Kassenanwendung übergeben wurden.

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/point-of-sale/main/k8-manifests/common/mysql-db.yaml

  2. Stellen Sie die VM-Arbeitslast mit dem vorbereiteten qcow2-Image bereit:

    kubectl virt create vm pos-vm \
    --boot-disk-size=80Gi \
    --memory=4Gi \
    --vcpu=2 \
    --image=https://storage.googleapis.com/pos-vm-images/pos-vm.qcow2

    Mit diesem Befehl wird eine YAML-Datei erstellt, die nach der VM (google-virtctl/pos-vm.yaml) benannt ist. Sie können die Datei prüfen, um die Definition von VirtualMachine und VirtualMachineDisk zu sehen. Anstelle des Plug-ins virtctl hätten Sie die VM-Arbeitslast auch über Kubernetes Resource Model (KRM)-Definitionen bereitstellen können, wie in der erstellten YAML-Datei zu sehen ist.

    Wenn der Befehl erfolgreich ausgeführt wird, erhalten Sie eine Ausgabe wie die folgende, in der die verschiedenen erstellten Ressourcen erläutert werden:

    Constructing manifest for vm "pos-vm":
Manifest for vm "pos-vm" is saved to /home/tfadmin/google-virtctl/pos-vm.yaml
Applying manifest for vm "pos-vm"
Created gvm "pos-vm"

  3. Prüfen Sie den Status der VM-Erstellung.

    Die Ressource VirtualMachine wird durch die vm.cluster.gke.io/v1.VirtualMachine-Ressource in der VM Runtime auf GDC identifiziert. Die Kurzform dafür ist gvm.

    Wenn Sie eine VM erstellen, werden die folgenden beiden Ressourcen erstellt:

    • VirtualMachineDisk ist der nichtflüchtige Speicher, in das der Inhalt des VM-Images importiert wird.
    • Eine VirtualMachine ist die VM-Instanz selbst. Das DataVolume wird vor dem Start der VM auf dem DataVolume bereitgestellt.

    Prüfen Sie den Status der VirtualMachineDisk. VirtualMachineDisk erstellt intern eine DataVolume-Ressource. Das Image der VM wird in das DataVolume importiert, das in der VM bereitgestellt wird:

    kubectl get datavolume

    Die folgende Beispielausgabe zeigt den Beginn des Image-Imports:

    NAME              PHASE             PROGRESS   RESTARTS   AGE
pos-vm-boot-dv    ImportScheduled   N/A                   8s

  4. Prüfen Sie den Status des VirtualMachine: VirtualMachine befindet sich im Provisioning-Status, bis DataVolume vollständig importiert ist:

    kubectl get gvm

    Die folgende Beispielausgabe zeigt die bereitgestellte VirtualMachine:

    NAME      STATUS         AGE     IP
pos-vm    Provisioning   1m

  5. Warten Sie, bis das VM-Image vollständig in DataVolume importiert wurde. Beobachten Sie weiter den Fortschritt während des Imports des Images:

    kubectl get datavolume -w

    Die folgende Beispielausgabe zeigt das importierte Laufwerk-Image:

    NAME              PHASE              PROGRESS   RESTARTS   AGE
pos-vm-boot-dv   ImportInProgress   0.00%                 14s
...
...
pos-vm-boot-dv   ImportInProgress   0.00%                 31s
pos-vm-boot-dv   ImportInProgress   1.02%                 33s
pos-vm-boot-dv   ImportInProgress   1.02%                 35s
...

    Wenn der Import abgeschlossen ist und DataVolume erstellt ist, zeigt die folgende Beispielausgabe den PHASE von Succeeded:

    kubectl get datavolume

    NAME              PHASE             PROGRESS   RESTARTS   AGE
pos-vm-boot-dv    Succeeded         100.0%                14m18s

  6. Prüfen Sie, ob VirtualMachine erfolgreich erstellt wurde:

    kubectl get gvm

    Wenn die Erstellung erfolgreich war, wird im STATUS RUNNING angezeigt, wie im folgenden Beispiel gezeigt, zusammen mit der IP-Adresse der VM:

    NAME      STATUS    AGE     IP
pos-vm    Running   40m     192.168.3.250

Verbindung zur VM herstellen und Anwendungsstatus prüfen

Das für die VM verwendete Image enthält die Beispielanwendung für den Point of Sale. Die Anwendung ist so konfiguriert, dass sie beim Booten automatisch als systemd-Dienst gestartet wird. Sie können die Konfigurationsdateien der systemd-Dienste im Verzeichnis pos-systemd-services einsehen.

  1. Stellen Sie eine Verbindung zur VM-Konsole her: Führen Sie den folgenden Befehl aus und drücken Sie die Eingabetaste⏎, nachdem die Meldung Successfully connected to pos-vm… angezeigt wird:

    kubectl virt console pos-vm

    Dieser Befehl erzeugt die folgende Beispielausgabe, die Sie auffordert, die Anmeldedaten einzugeben:

    Successfully connected to pos-vm console. The escape sequence is ^]

pos-from-public-image login:

    Verwenden Sie das folgende Nutzerkonto und das folgende Passwort. Dieses Konto wurde in der ursprünglichen VM eingerichtet, von der das Image für die VM Runtime auf GDC-VirtualMachine erstellt wurde.

    • Nutzername für Anmeldung: abmuser
    • Passwort: abmworks

  2. Prüfen Sie den Status der Point-of-Sale-Anwendungsdienste. Die Point-of-Sale-Anwendung umfasst drei Dienste: API, Inventar und Zahlungen. Diese Dienste werden alle als Systemdienste ausgeführt.

    Die drei Dienste verbinden sich alle über localhost. Die Anwendung stellt jedoch eine Verbindung zur MySQL-Datenbank über den mysql-db Kubernetes Service her, der im vorherigen Schritt erstellt wurde. Dieses Verhalten bedeutet, dass die VM automatisch mit demselben Netzwerk wie Pods und Services verbunden ist, was eine nahtlose Kommunikation zwischen VM-Arbeitslasten und anderen Containeranwendungen ermöglicht. Sie müssen nichts weiter tun, um den Kubernetes-Services von den VMs aus erreichbar zu machen, die mit VM Runtime auf GDC bereitgestellt wurden.

    sudo systemctl status pos*

    Die folgende Beispielausgabe zeigt den Status der drei Dienste und des Root-Systemdienstes, pos.service:

    ● pos_payments.service - Payments service of the Point of Sale Application
    Loaded: loaded (/etc/systemd/system/pos_payments.service; enabled; vendor >
    Active: active (running) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago
  Main PID: 750 (payments.sh)
      Tasks: 27 (limit: 4664)
    Memory: 295.1M
    CGroup: /system.slice/pos_payments.service
            ├─750 /bin/sh /pos/scripts/payments.sh
            └─760 java -jar /pos/jars/payments.jar --server.port=8083

● pos_inventory.service - Inventory service of the Point of Sale Application
    Loaded: loaded (/etc/systemd/system/pos_inventory.service; enabled; vendor>
    Active: active (running) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago
  Main PID: 749 (inventory.sh)
      Tasks: 27 (limit: 4664)
    Memory: 272.6M
    CGroup: /system.slice/pos_inventory.service
            ├─749 /bin/sh /pos/scripts/inventory.sh
            └─759 java -jar /pos/jars/inventory.jar --server.port=8082

● pos.service - Point of Sale Application
    Loaded: loaded (/etc/systemd/system/pos.service; enabled; vendor preset: e>
    Active: active (exited) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago
  Main PID: 743 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 4664)
    Memory: 0B
    CGroup: /system.slice/pos.service

Jun 21 18:55:30 pos-vm systemd[1]: Starting Point of Sale Application...
Jun 21 18:55:30 pos-vm systemd[1]: Finished Point of Sale Application.

● pos_apiserver.service - API Server of the Point of Sale Application
    Loaded: loaded (/etc/systemd/system/pos_apiserver.service; enabled; vendor>
    Active: active (running) since Tue 2022-06-21 18:55:31 UTC; 1h 10min ago
  Main PID: 751 (api-server.sh)
      Tasks: 26 (limit: 4664)
    Memory: 203.1M
    CGroup: /system.slice/pos_apiserver.service
            ├─751 /bin/sh /pos/scripts/api-server.sh
            └─755 java -jar /pos/jars/api-server.jar --server.port=8081

  3. Beenden Sie die VM. Um die Konsolenverbindung zu beenden, verwenden Sie die Escapesequenz ^] indem Sie Ctrl + ] drücken.

Auf VM-basierte Arbeitslast zugreifen

Wenn Ihr Cluster nach dem Leitfaden Google Distributed Cloud auf Compute Engine-VMs mit manuellem Load Balancer ausführen eingerichtet wurde, wurde bereits eine Ingress-Ressource mit dem Namen pos-ingress erstellt. Diese Ressource leitet den Traffic von der externen IP-Adresse des Ingress-Load-Balancers an den API-Serverdienst der Point-of-Sale-Beispielanwendung weiter.

  1. Wenn Ihr Cluster diese Ingress-Ressource nicht hat, erstellen Sie sie mit dem folgenden Manifest:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-gcp-terraform/resources/manifests/pos-ingress.yaml

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: pos-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-server-svc
            port:
              number: 8080

  2. Erstellen Sie einen Kubernetes-Service, der Traffic an die VM weiterleitet. Die Ingress-Ressource leitet Traffic an diese Service weiter:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-vmruntime/pos-service.yaml

    Die folgende Beispielausgabe bestätigt die Erstellung eines Dienstes:

    service/api-server-svc created

    apiVersion: v1
kind: Service
metadata:
  name: api-server-svc
spec:
  selector:
    kubevirt/vm: pos-vm
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8081

  3. Rufen Sie die externe IP-Adresse des Load-Balancers Ingress ab. Der Load-Balancer Ingress leitet den Traffic anhand der Ingress-Ressourcenregeln weiter. Sie haben bereits eine pos-ingress-Regel zum Weiterleiten von Anfragen an den API-Server Service. Dieser Service leitet die Anfragen an die VM weiter:

    INGRESS_IP=$(kubectl get ingress/pos-ingress -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
echo $INGRESS_IP

    Die folgende Beispielausgabe zeigt die IP-Adresse des Load Balancers Ingress:

    172.29.249.159 # you might have a different IP address

  4. Greifen Sie über die IP-Adresse des Ingress-Load-Balancers in einem Browser auf die Anwendung zu. Die folgenden Beispiel-Screenshots zeigen den einfachen POS-Kiosk mit zwei Artikeln. Sie können die Artikel auch mehrmals anklicken, wenn Sie mehrere davon bestellen möchten, und mit der Schaltfläche Bezahlen eine Bestellung aufgeben. Dieses Ergebnis zeigt, dass Sie mithilfe von VM Runtime auf GDC eine VM-basierte Arbeitslast in einem Google Distributed Cloud-Cluster bereitgestellt haben.

Benutzeroberfläche der Point-of-Sale-Anwendung
Benutzeroberfläche der Point-of-Sale-Anwendung (zum Vergrößern klicken)

Bereinigen

Sie können alle in diesem Tutorial erstellten Ressourcen löschen oder nur die VM löschen und wiederverwendbare Ressourcen behalten. Unter VM in Google Distributed Cloud löschen werden die verfügbaren Optionen ausführlich erläutert.

Alle löschen

  • Löschen Sie die VM Runtime auf GDC VirtualMachine zusammen mit allen Ressourcen:

    kubectl virt delete vm pos-vm --all

    Die folgende Beispielausgabe bestätigt das Löschen:

    vm "pos-vm" used the following resources: 
    gvm: pos-vm
    VirtualMachineDisk: pos-vm-boot-dv
Start deleting the resources:
    Deleted gvm "pos-vm".
    Deleted VirtualMachineDisk "pos-vm-boot-dv".

Nur VM löschen

  • Wenn Sie nur die VM löschen, bleibt der erstellte VirtualMachineDisk erhalten. Dadurch wird die Wiederverwendung dieses VM-Images ermöglicht und Zeit gespart, wenn das Image beim Erstellen einer neuen VM importiert wird.

    kubectl virt delete vm pos-vm

    Die folgende Beispielausgabe bestätigt das Löschen:

    vm "pos-vm" used the following resources: 
    gvm: pos-vm
    VirtualMachineDisk: pos-vm-boot-dv
Start deleting the resources:
    Deleted gvm "pos-vm".

Nächste Schritte

  • Die ursprüngliche VM, die in dieser Anleitung verwendet wird, ist eine Compute Engine-Instanz, auf der Ubuntu 20.04 LTS ausgeführt wird. Das Image dieser VM ist öffentlich zugänglich über den pos-vm-images-Cloud Storage-Bucket. Weitere Informationen zur Konfiguration der VM und zum Erstellen des Images finden Sie in der Anleitung im Point-of-Sale-Repository.
  • Wenn Sie eine VM in einem Google Distributed Cloud-Cluster mit dem Befehl kubectl virt create vm pos-vm erstellen, wird eine nach der VM (google-virtctl/pos-vm.yaml) benannte YAML-Datei erstellt. Sie können sich die Datei mit der Definition von VirtualMachine und VirtualMachineDisk ansehen. Anstatt das virtctl-Plug-in zu verwenden, können Sie eine VM mit KRM-Definitionen bereitstellen, wie in der erstellten YAML-Datei gezeigt.