Anleitung: Vorhandene VM mithilfe der VM-Laufzeit in Google Distributed Cloud in einem GKE Enterprise-Cluster bereitstellen

Dieses Dokument enthält eine detaillierte Anleitung zum Bereitstellen einer VM-basierten Arbeitslast in GKE on Bare Metal mithilfe der VM-Laufzeit in Google Distributed Cloud. Die in diesem Leitfaden verwendete Arbeitslast ist die beispielhafte Point-of-Sale-Anwendung. Diese Anwendung stellt ein typisches Point-of-Sale-Terminal dar, das auf lokaler Hardware in einem Geschä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. Anschließend 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 in Google Distributed Cloud werden die Images im Format qcow2 erwartet. Wenn Sie einen anderen Bildtyp angeben, wird er automatisch in das Format qcow2 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, auf der die Arbeitslast als systemd-Dienst ausgeführt wird. Sie können dieselben Schritte ausführen, um Ihre eigene Anwendung bereitzustellen.

Lernziele

Hinweise

Zum Ausfüllen dieses Dokuments benötigen Sie die folgenden Ressourcen:

  • Zugriff auf einen Cluster in GKE on Bare Metal ab Version 1.12.0, der gemäß der Anleitung GKE on Bare Metal 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 Arbeitslast zugreifen können, die in der VM ausgeführt wird. Wenn Sie dieses Verhalten nicht benötigen, können Sie diesem Dokument mit einer beliebigen GKE on Bare Metal folgen.
  • Eine Workstation, die die folgenden Anforderungen erfüllt:
    • Hat Zugriff auf den Cluster über die bmctl-Befehlszeile.
    • Zugriff auf den Cluster über die kubectl-Befehlszeile hat.

VM-Laufzeit in Google Distributed Cloud aktivieren und virtctl-Plug-in installieren

Die VM-Laufzeit in Google Distributed Cloud ist seit Version 1.10 Teil aller GKE on Bare Metal-Cluster. Eine Instanz der benutzerdefinierten Ressource VMRuntime wurde bereits bei der Installation erstellt. Sie ist jedoch standardmäßig deaktiviert.

  1. Aktivieren Sie die VM-Laufzeit in Google Distributed Cloud:

    sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
    • KUBECONFIG_PATH: Pfad zur Kubernetes-Konfigurationsdatei des Nutzerclusters von GKE Enterprise

  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 sie mehrmals 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 virtctl-Plug-in mit kubectl verwendet werden kann:

    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 GKE on Bare Metal bereitstellen, erwartet die VM-Laufzeit in Google Distributed Cloud ein VM-Image. Dieses Image dient als Bootlaufwerk für die bereitgestellte VM.

In dieser Anleitung migrieren Sie eine VM-basierte Arbeitslast in Compute Engine zu einem GKE on Bare Metal-Cluster. Diese Compute Engine-VM wurde erstellt und die Beispielanwendung für den Point of Sale (PoS) 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 Bild wurde dann als qcow2-Bild in einen Cloud Storage-Bucket exportiert. Sie verwenden dieses vorbereitete qcow2-Image in den folgenden Schritten.

Der Quellcode in diesem Dokument ist im GitHub-Repository anthos-samples verfügbar. Sie verwenden Ressourcen aus diesem Repository, um die folgenden Schritte auszuführen.

  1. Stellen Sie eine MySQL-StatefulSet bereit. Die Kassenanwendung erwartet eine Verbindung zu einer MySQL-Datenbank, um Inventar- und Zahlungsinformationen zu speichern. Das Point-of-Sale-Repository hat ein Beispielmanifest, das eine MySQL-StatefulSet bereitstellt, eine verknüpfte ConfigMap und eine Kubernetes-Service konfiguriert. ConfigMap definiert die Anmeldedaten für die MySQL-Instanz. Dies sind die Anmeldedaten, die an die Point-of-Sale-Anwendung ü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 benannt ist (google-virtctl/pos-vm.yaml). Die Definition von VirtualMachine und VirtualMachineDisk finden Sie in der Datei. Anstatt das virtctl-Plug-in zu verwenden, können Sie die VM-Arbeitslast mithilfe von KRM-Definitionen (Kubernetes Resource Model) bereitstellen, wie in der erstellten YAML-Datei zu sehen.

    Wenn der Befehl erfolgreich ausgeführt wird, erzeugt er eine Ausgabe wie das folgende Beispiel, 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 Ressource vm.cluster.gke.io/v1.VirtualMachine in der VM-Laufzeit in Google Distributed Cloud identifiziert. Die Kurzform dafür ist gvm.

    Wenn Sie eine VM erstellen, werden die folgenden zwei Ressourcen erstellt:

    • Eine 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 auf 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üfe den Status von VirtualMachine. VirtualMachine hat den Status Provisioning, bis DataVolume vollständig importiert wurde:

    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. Beobachten Sie den Fortschritt während des Image-Imports:

    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 wurde, 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, 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 Point-of-Sale-Beispielanwendung. Die Anwendung ist so konfiguriert, dass sie beim Start 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, in der Sie zur Eingabe der Anmeldedaten aufgefordert werden:

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

pos-from-public-image login:

    Verwende das folgende Nutzerkonto und Passwort. Dieses Konto wurde in der ursprünglichen VM eingerichtet, von der aus das Image für die VM-Laufzeit in Google Distributed Cloud VirtualMachine erstellt wurde.

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

  2. Prüfen Sie den Status der Point-of-Sale-Anwendungsdienste. Die Kassenanwendung 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 über einen MySQL-DB-Kubernetes-Dienst, 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, was eine nahtlose Kommunikation zwischen VM-Arbeitslasten und anderen Containeranwendungen ermöglicht. Sie müssen nichts weiter tun, um die Kubernetes-Services über die mit der Anthos-VM-Laufzeit bereitgestellten VMs erreichbar zu machen.

    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 gemäß der Anleitung GKE on Bare Metal auf Compute Engine-VMs mit manuellem Load Balancer ausführen eingerichtet wurde, wurde bereits eine Ingress-Ressource namens pos-ingress erstellt. Diese Ressource leitet den Traffic von der öffentlichen 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
    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 diesen Service weiter:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-vmruntime/pos-service.yaml

    Die folgende Beispielausgabe bestätigt das Erstellen eines Dienstes:

    service/api-server-svc created
    anthos-vmruntime/pos-service.yaml 
    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 öffentliche IP-Adresse des Load-Balancers Ingress ab. Der Ingress-Load-Balancer leitet Traffic anhand der Ingress-Ressourcenregeln weiter. Sie haben bereits eine pos-ingress-Regel, um Anfragen an den API-Server Service weiterzuleiten. 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 Load-Balancers für eingehenden Traffic in einem Browser auf die Anwendung zu. Die folgenden Beispiel-Screenshots zeigen einen einfachen Point-of-Sale-Kiosk mit zwei Artikeln. Sie können die Artikel mehrmals anklicken, wenn Sie mehrere Artikel bestellen möchten, und dann über die Schaltfläche Bezahlen eine Bestellung aufgeben. Diese Erfahrung zeigt, dass Sie mithilfe der VM-Laufzeit in Google Distributed Cloud erfolgreich eine herkömmliche VM-basierte Arbeitslast in einem Anthos-Cluster bereitgestellt haben.

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

Bereinigen

Sie können alle in dieser Anleitung erstellten Ressourcen löschen oder nur die VM löschen und wiederverwendbare Ressourcen behalten. Unter VM in GKE on Bare Metal löschen werden die verfügbaren Optionen im Detail erläutert.

Alle löschen

  • Löschen Sie die VM-Laufzeit in Google Distributed Cloud VirtualMachine zusammen mit allen Ressourcen:

    kubectl virt delete vm pos-vm --all

    In der folgenden Beispielausgabe wird der Löschvorgang bestätigt:

    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. Dies ermöglicht die Wiederverwendung dieses VM-Images und spart Zeit beim Importieren des Images beim Erstellen einer neuen VM.

    kubectl virt delete vm pos-vm

    In der folgenden Beispielausgabe wird der Löschvorgang bestätigt:

    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 ursprüngliche VM, die in dieser Anleitung verwendet wird, 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 zur Konfiguration der VM und zum Erstellen des Images 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 Anthos-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.