Anleitung: Vorhandene VM in einem GKE on Bare Metal-Cluster mithilfe von VM-Laufzeit in GDC bereitstellen

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

Die VM-Laufzeit in der benutzerdefinierten Ressourcendefinition (CRD) von GDC ist seit Version 1.10 Teil aller GKE on 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 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 GKE on Bare Metal-Cluster. Diese Compute Engine-VM wurde erstellt und die Beispielanwendung für die Kasse (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 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.