Anleitung: Vorhandene VM mit VM Runtime on GDC in einem Cluster bereitstellen

Mit VM Runtime on GDC können Sie VM-Arbeitslasten direkt in einer Installation von Distributed Cloud-Software nur für Bare Metal bereitstellen. In dieser Anleitung migrieren Sie eine Beispielanwendung für die Kasse, die ein POS-Terminal darstellt, von einer Compute Engine-VM in einen Bare-Metal-Cluster und greifen auf das Web-Frontend zu.

Für die Bereitstellung wird ein vorbereitetes Speicherabbild verwendet, wobei die Arbeitslast als systemd-Dienst ausgeführt wird. Sie können diese Schritte auch ausführen, um Ihre eigenen VM-basierten Anwendungen vorzubereiten und bereitzustellen.

Ziele

• VM Runtime auf GDC aktivieren und das Plug-in virtctl installieren
• VM-basierte Arbeitslast bereitstellen
• In der VM anmelden und den Anwendungsstatus prüfen
• Auf die VM-basierte Arbeitslast zugreifen

Hinweise

Zum Ausführen der Schritte in diesem Dokument benötigen Sie die folgenden Ressourcen:

• Zugriff auf einen Bare-Metal-Cluster der Version 1.12.0 oder höher, der gemäß der Anleitung Mit manuellem Load-Balancer installieren erstellt wurde. In diesem Dokument werden Netzwerkressourcen eingerichtet, damit Sie über einen Browser auf die Arbeitslast zugreifen können, die auf der VM ausgeführt wird. Wenn Sie dieses Verhalten nicht benötigen, können Sie dieses Dokument mit einer beliebigen Installation der Distributed Cloud-Software (nur für Bare Metal) verwenden.
• 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-Befehlszeile.

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

Die benutzerdefinierte Ressourcendefinition „VM Runtime on GDC“ ist seit Version 1.10 Teil aller Bare-Metal-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 der kubeconfig-Datei des 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 sie nicht bereit ist, prüfen Sie ein paar Mal hintereinander mit kurzen Abständen. Die folgende Beispielausgabe zeigt, dass der 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 einer Installation von Distributed Cloud-Software nur für Bare Metal bereitstellen, erwartet VM Runtime on GDC ein VM-Image. Dieses Image dient als Bootlaufwerk für die bereitgestellte VM.

Um eine bestehende VM in den Cluster zu migrieren, muss zuerst ein Laufwerk-Image dieser VM erstellt werden. Anschließend 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 on 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 den folgenden Schritten verwenden Sie ein vorbereitetes qcow2-Image, bei dem die Beispielarbeitslast als VM-Laufwerk-Image in Google Cloud erstellt und in einen Cloud Storage-Bucket exportiert wurde.

Hinweis: In diesem Dokument verwenden wir zwar eine Compute Engine-VM, die Schritte zum Erstellen eines Speicherabbilds einer VM variieren jedoch je nach Umgebung oder Plattform, auf der Ihre bestehende VM ausgeführt wird. Sie können ein Speicherabbild Ihrer vorhandenen VMs erstellen, wenn Sie die Schritte in diesem Dokument mit Ihrem eigenen benutzerdefinierten Image ausführen möchten.

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, wird eine Ausgabe wie im folgenden Beispiel ausgegeben, 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 Start 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 Bereitstellung von VirtualMachine:

   NAME      STATUS         AGE     IP
   pos-vm    Provisioning   1m
   

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

   kubectl get datavolume -w
   

   Die folgende Beispielausgabe zeigt, wie das Speicherabbild importiert wird:

   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
   

   Hinweis: Die Importzeit hängt von der Größe des verwendeten VM-Images ab. Das Image der Compute Engine-VM in diesem Dokument ist etwa 5 GB groß und benötigt bis zu 15 Minuten für den Import.

6. Prüfen Sie, ob der 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. Die Konfigurationsdateien der systemd-Dienste finden Sie im Verzeichnis pos-systemd-services.

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 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 sind alle über localhost miteinander verbunden. Die Anwendung stellt jedoch eine Verbindung zur MySQL-Datenbank über einen Kubernetes-Dienst mysql-db her, der im vorherigen Schritt erstellt wurde. Das bedeutet, dass die VM automatisch mit demselben Netzwerk wie Pods und Services verbunden wird, was eine nahtlose Kommunikation zwischen VM-Arbeitslasten und anderen containerisierten Anwendungen 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 die VM-basierte Arbeitslast zugreifen

Wenn Ihr Cluster nach dem Leitfaden Mit manuellem Load Balancer installieren 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, 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 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 Ingress-Load-Balancer leitet Traffic basierend auf den Ingress-Ressourcenregeln weiter. Sie haben bereits eine pos-ingress-Regel zum Weiterleiten von Anfragen an den API-Server Service. Diese 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. Rufen Sie die Anwendung in einem Browser über die IP-Adresse des Ingress-Load-Balancers auf. Die folgenden Beispiel-Screenshots zeigen den POS-Kiosk mit zwei Artikeln. Sie können die Artikel auch mehrmals anklicken, wenn Sie mehrere davon bestellen möchten, und mit dem Button Bezahlen eine Bestellung aufgeben. Diese Erfahrung zeigt, dass Sie eine VM-basierte Arbeitslast mit VM Runtime on GDC erfolgreich in einem Cluster bereitgestellt haben.

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 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 die erstellte VirtualMachineDisk erhalten. Dadurch kann dieses VM-Image wiederverwendet werden und Sie sparen Zeit beim Importieren des Images, wenn Sie eine neue VM erstellen.

  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 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 öffentlich zugänglich über den pos-vm-images-Cloud Storage-Bucket. Weitere Informationen zur Konfiguration der VM und zur Erstellung des Images finden Sie in der Anleitung im Point-of-Sale-Repository.
• Wenn Sie eine VM in einem 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. Anstelle des Plug-ins virtctl können Sie eine VM auch über KRM-Definitionen bereitstellen, wie in der erstellten YAML-Datei zu sehen ist.