Anleitung: Vorhandene VM in einem GKE on Bare Metal-Cluster mit VM-Laufzeit auf GDC bereitstellen

Dieses Dokument enthält eine Schritt-für-Schritt-Anleitung zum Bereitstellen einer auf virtuellen Maschinen (VM) basierenden Arbeitslast in Google Distributed Cloud mithilfe der VM-Laufzeit auf GDC. Die in dieser Anleitung verwendete Arbeitslast ist die Beispiel-POS-Anwendung. Diese Anwendung ist ein typisches POS-Terminal, das auf lokaler Hardware in einem Einzelhandelsgeschäft ausgeführt wird.

In diesem Dokument migrieren Sie diese Anwendung von einer VM zu einem GKE on Bare Metal-Cluster und greifen auf das Web-Front-End der Anwendung zu. Zum Migrieren einer vorhandenen VM in den Cluster 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 dieses Images zum Erstellen der VM verwendet werden. Für die VM-Laufzeit auf GDC wird erwartet, dass die Images das Format qcow2 haben. Wenn Sie einen anderen Bildtyp angeben, wird dieser automatisch in das qcow2-Format konvertiert. Sie können ein virtuelles Laufwerk-Image konvertieren und das qcow2-Image hosten, um wiederholte Konvertierungen zu vermeiden und die Wiederverwendung zu ermöglichen.

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

Lernziele

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 gemäß der Anleitung 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 beliebigen Google Distributed Cloud folgen.
  • Eine Workstation, die die folgenden Anforderungen erfüllt:
    • Hat über die bmctl-Befehlszeile Zugriff auf Ihren Cluster.
    • Hat über die kubectl-CLI Zugriff auf Ihren Cluster.

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

Die benutzerdefinierte Ressourcendefinition (CRD) der VM-Laufzeit in der GDC ist seit Version 1.10 Teil aller GKE on Bare Metal-Cluster. Eine Instanz der benutzerdefinierten Ressource VMRuntime wurde bereits bei der Installation erstellt. Es ist jedoch standardmäßig deaktiviert.

  1. Aktivieren Sie die VM-Laufzeit auf GDC:

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

  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 es nicht bereit ist, prüfen Sie es einige Male mit kurzen Verzögerungen. 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 die Installation 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 für die Verwendung mit kubectl verfügbar 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 die VM-Laufzeit auf GDC ein VM-Image. Dieses Image dient als Bootlaufwerk für die bereitgestellte VM.

In dieser Anleitung migrieren Sie eine VM-basierte Compute Engine-Arbeitslast zu einem GKE on Bare Metal-Cluster. Diese Compute Engine-VM wurde erstellt und die Beispiel-PoS-Anwendung (Point of Sale) wurde für die Ausführung als systemd-Dienst konfiguriert. In Google Cloud wurde ein Laufwerk-Image dieser VM zusammen mit der Arbeitslast der PoS-Anwendung erstellt. Dieses Image wurde dann als qcow2-Image in einen Cloud Storage-Bucket exportiert. In den folgenden Schritten verwenden Sie dieses vorbereitete qcow2-Image.

Der Quellcode in diesem Dokument ist im GitHub-Repository anthos-samples verfügbar. Für die folgenden Schritte werden Ressourcen aus diesem Repository verwendet.

  1. Stellen Sie eine MySQL-StatefulSet bereit. Die Point-of-Sale-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 und ein verknüpftes ConfigMap sowie ein Kubernetes-Service konfiguriert. ConfigMap definiert die Anmeldedaten für die MySQL-Instanz. Es handelt sich dabei um dieselben Anmeldedaten, die an die Kassenanwendung übergeben werden.

    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 sich die Datei ansehen, um die Definition von VirtualMachine und VirtualMachineDisk zu sehen. Anstelle des Plug-ins virtctl hätten Sie die VM-Arbeitslast mithilfe von KRM-Definitionen (Kubernetes Resource Model) bereitstellen können, wie in der erstellten YAML-Datei zu sehen.

    Wenn der Befehl erfolgreich ausgeführt wird, gibt er eine Ausgabe wie im folgenden Beispiel aus, 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 VM-Erstellungsstatus.

    Die Ressource VirtualMachine wird durch die Ressource vm.cluster.gke.io/v1.VirtualMachine in der VM-Laufzeit 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 den der Inhalt des VM-Images importiert wird.
    • Eine VirtualMachine ist die VM-Instanz selbst. Das DataVolume wird in der VirtualMachine bereitgestellt, bevor die VM gestartet wird.

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

    kubectl get datavolume

    Die folgende Beispielausgabe zeigt den Start des Image-Imports:

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

  4. Prüfen Sie den Status von VirtualMachine. VirtualMachine hat den Status Provisioning, bis DataVolume vollständig importiert wurde:

    kubectl get gvm

    Die folgende Beispielausgabe zeigt die bereitgestellten VirtualMachine:

    NAME      STATUS         AGE     IP
pos-vm    Provisioning   1m

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

    kubectl get datavolume -w

    Die folgende Beispielausgabe zeigt das zu importierende 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 und die DataVolume erstellt wurde, zeigt die folgende Beispielausgabe 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, zeigt STATUS RUNNING, wie im folgenden Beispiel gezeigt, zusammen mit der IP-Adresse der VM an:

    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 POS-Beispielanwendung. Die Anwendung ist so konfiguriert, dass sie beim Booten automatisch als systemd-Dienst gestartet wird. Die Konfigurationsdateien der systemd-Dienste finden Sie im Verzeichnis pos-systemd-services.

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

    kubectl virt console pos-vm

    Dieser Befehl erzeugt die folgende Beispielausgabe, in der Sie zur Eingabe der Anmeldedaten aufgefordert werden:

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

pos-from-public-image login:

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

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

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

    Die drei Dienste stellen über localhost eine Verbindung zueinander her. Die Anwendung stellt jedoch über einen Kubernetes-Dienst der MySQL-Datenbank, der im vorherigen Schritt erstellt wurde, eine Verbindung zur MySQL-Datenbank her. Dieses Verhalten bedeutet, dass die VM automatisch mit demselben Netzwerk wie Pods und Services verbunden ist, um eine nahtlose Kommunikation zwischen VM-Arbeitslasten und anderen Containeranwendungen zu ermöglichen. Sie müssen nichts weiter tun, damit Kubernetes Services über die VMs erreichbar ist, die mit der VM-Laufzeit auf GDC bereitgestellt werden.

    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. Verwenden Sie die Escapesequenz ^], um die Konsolenverbindung zu beenden. Drücken Sie dazu Ctrl + ].

Auf die VM-basierte Arbeitslast zugreifen

Wenn Ihr Cluster gemäß der Anleitung Google Distributed Cloud auf Compute Engine-VMs mit manuellem Load-Balancer ausführen eingerichtet wurde, ist 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, indem Sie das folgende Manifest anwenden:

    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 eine Kubernetes-Service, die Traffic an die VM weiterleitet. Die Ressource Ingress 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 basierend auf den Ressourcenregeln Ingress weiter. Du hast 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 Kassenkiosk mit zwei Artikeln. Wenn Sie mehrere Artikel bestellen möchten, können Sie mehrmals auf die Artikel klicken und dann über die Schaltfläche Bezahlen eine Bestellung aufgeben. Diese Erfahrung zeigt, dass Sie erfolgreich eine VM-basierte Arbeitslast in einem Google Distributed Cloud-Cluster mithilfe der VM-Laufzeit auf GDC bereitgestellt haben.

Benutzeroberfläche der Kassenanwendung
UI der Kassenanwendung (zum Vergrößern klicken)

Bereinigen

Sie können alle in dieser Anleitung erstellten Ressourcen löschen oder nur die VM 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-Laufzeit auf der GDC VirtualMachine zusammen mit allen Ressourcen:

    kubectl virt delete vm pos-vm --all

    Die folgende Beispielausgabe bestätigt den Löschvorgang:

    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, wird der erstellte VirtualMachineDisk beibehalten. Dies ermöglicht die Wiederverwendung dieses VM-Images und spart Zeit, die beim Erstellen einer neuen VM für den Import des Images aufgewendet werden muss.

    kubectl virt delete vm pos-vm

    Die folgende Beispielausgabe bestätigt den Löschvorgang:

    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 in dieser Anleitung verwendete ursprüngliche VM ist eine Compute Engine-Instanz, auf der Ubuntu 20.04 LTS ausgeführt wird. Das Image dieser VM ist über den Cloud Storage-Bucket pos-vm-images öffentlich zugänglich. Weitere Informationen dazu, wie die VM konfiguriert und ihr Image erstellt wurde, finden Sie in der Anleitung im Point-of-Sale-Repository.
  • Wenn Sie mit dem Befehl kubectl virt create vm pos-vm eine VM in einem Google Distributed Cloud-Cluster erstellen, wird eine YAML-Datei erstellt, die nach der VM (google-virtctl/pos-vm.yaml) benannt ist. Sie können sich die Datei ansehen, um die Definition von VirtualMachine und VirtualMachineDisk zu sehen. Anstatt das virtctl-Plug-in zu verwenden, können Sie eine VM mit KRM-Definitionen bereitstellen, wie in der erstellten YAML-Datei dargestellt.