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 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 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. Das Image muss dann 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. Sie können dieselben Schritte ausführen, um Ihre eigene Anwendung bereitzustellen.

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 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. Installation des virtctl-Plug-ins prüfen:

   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 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. In Google Cloudwurde ein Laufwerk-Image dieser VM zusammen mit der PoS-Anwendung erstellt. Dieses Bild wurde dann in einen Cloud Storage-Bucket exportiert als ein qcow2-Bild exportiert. Sie verwenden in den folgenden Schritten dieses vorbereitete qcow2-Image.

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. 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 nach der VM benannte YAML-Datei (google-virtctl/pos-vm.yaml) erstellt. 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 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. 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 lautet 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 des VirtualMachineDisk. Intern wird durch VirtualMachineDisk eine DataVolume-Ressource erstellt. 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 Bildimports:

   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, wie VirtualMachine bereitgestellt wird:

   NAME      STATUS         AGE     IP
   pos-vm    Provisioning   1m
   

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

   kubectl get datavolume -w
   

   Die folgende Beispielausgabe zeigt, wie das Festplattenimage 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 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. Alle diese Dienste werden als Systemdienste ausgeführt.

   Die drei Dienste sind alle über localhost miteinander verbunden. Die Anwendung stellt jedoch über einen mysql-db Kubernetes-Dienst, der im vorherigen Schritt erstellt wurde, eine Verbindung zur MySQL-Datenbank her. Das bedeutet, dass die VM automatisch mit demselben Netzwerk wie Pods und Services verbunden ist. So ist eine nahtlose Kommunikation zwischen VM-Arbeitslasten und anderen containerisierten Anwendungen möglich. 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 ein Kubernetes-Service, das 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 den Traffic anhand der 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 über die IP-Adresse des Ingress-Load-Balancers in einem Browser 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 der Schaltfläche Bezahlen eine Bestellung aufgeben. Diese Erfahrung zeigt, dass Sie eine VM-basierte Arbeitslast mit VM Runtime on GDC in einem Cluster bereitgestellt haben.

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