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

In diesem Dokument wird Schritt für Schritt beschrieben, wie Sie eine auf einer virtuellen Maschine (VM) basierende Arbeitslast in einer Installation von Google Distributed Cloud (nur Software) auf Bare-Metal-Servern mit VM Runtime auf GDC bereitstellen. Die in diesem Leitfaden verwendete Arbeitslast ist die Point of Sale Anwendung. 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 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. Anschließend muss das Image in einem Repository gehostet werden, auf das der Cluster zugreifen kann. Schließlich kann die URL dieses Images verwendet werden, um die VM zu erstellen. VM Runtime auf GDC erwartet, dass die Images im Format qcow2 vorliegen. Wenn Sie einen anderen Image-Typ angeben, wird dieser automatisch in das Format qcow2 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 ein systemd Dienst ausgeführt wird. Sie können dieselben Schritte ausführen, um Ihre eigene Anwendung bereitzustellen.

Ziele

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

Hinweise

Für dieses 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 Installation mit manuellem Load Balancer erstellt wurde. In diesem Dokument werden Netzwerkressourcen eingerichtet, damit Sie über einen Browser auf die Arbeitslast zugreifen können, die in der VM ausgeführt wird. Wenn Sie dieses Verhalten nicht benötigen, können Sie dieses Dokument mit jeder Installation von Google Distributed Cloud auf Bare-Metal-Servern 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-CLI.

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

Die benutzerdefinierte Ressourcendefinition „VM Runtime on GDC“ ist seit Version 1.10 Teil aller Bare-Metal-Cluster. Bei der Installation wird bereits eine Instanz der benutzerdefinierten Ressource VMRuntime 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 Nutzercluster Kubeconfig-Datei.

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 einer Installation von Google Distributed Cloud (nur Software) auf Bare-Metal-Servern 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 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. Ein Laufwerk-Image dieser VM zusammen mit der POS-Anwendungsarbeitslast wurde erstellt in Google Cloud. Dieses Image wurde dann exportiert in einen Cloud Storage-Bucket als ein qcow2 Image. Sie verwenden dieses vorbereitete qcow2-Image in den folgenden Schritten.

Hinweis: In diesem Dokument verwenden wir zwar eine Compute Engine-VM, die Schritte zum Erstellen eines Laufwerk-Images einer VM variieren jedoch je nach Umgebung oder Plattform, auf der Ihre bestehende VM ausgeführt wird. Sie können ein Laufwerk-Image 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. StatefulSet für MySQL bereitstellen. 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. VM-Arbeitslast mit dem vorbereiteten qcow2-Image bereitstellen:

   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 benannt ist (google-virtctl/pos-vm.yaml). Sie können sich die Datei mit der Definition von VirtualMachine und VirtualMachineDisk ansehen. 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 erzeugt, 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. Status der VM-Erstellung prüfen.

   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.
   • VirtualMachine ist die VM-Instanz selbst. Das DataVolume wird vor dem Start der VM auf dem DataVolume bereitgestellt.

   Prüfen Sie den Status von 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, dass VirtualMachine bereitgestellt wird:

   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, dass das Laufwerk-Image 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. Bestätigen Sie, dass 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 den 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 pos-systemd-services Verzeichnis.

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. Alle diese Dienste werden 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 die Pods und Services verbunden ist, 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. VM beenden. 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 Installation mit manuellem Load Balancer 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 diesen 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 Ingress-Load Balancers ab. Der Ingress-Load Balancer leitet Traffic basierend auf den Regeln der Ingress-Ressource 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 in einem Browser über die IP-Adresse des Ingress Load Balancers auf die Anwendung zu. 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. Dies zeigt, dass Sie eine VM-basierte Arbeitslast mit VM Runtime auf GDC erfolgreich in einem Cluster bereitgestellt haben.

UI der Point of Sale-Anwendung (zum Vergrößern auf das Bild 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. So 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 diesem Leitfaden 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 YAML-Datei erstellt, die nach der VM benannt ist (google-virtctl/pos-vm.yaml). Sie können sich die Datei mit der Definition von VirtualMachine und VirtualMachineDisk ansehen. Anstelle des virtctl-Plug-ins können Sie eine VM mit KRM-Definitionen bereitstellen, wie in der erstellten YAML-Datei zu sehen ist.