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

Dieses Dokument enthält eine detaillierte Anleitung zum Bereitstellen einer Arbeitslast auf einer virtuellen Maschine (VM) in GKE on Bare Metal mithilfe der VM-Laufzeit auf GDC. Die in dieser Anleitung verwendete Arbeitslast ist die Beispiel-Point-of-Sale-Anwendung. Diese Anwendung stellt ein typisches Point-of-Sale-Terminal dar, das auf lokaler Hardware in einem Einzelhandelsgeschä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. Damit Sie eine vorhandene VM in den Cluster migrieren können, 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. Die VM-Laufzeit auf GDC erwartet, dass die Images das Format qcow2 haben. 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, in 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 GKE on Bare Metal-Cluster ab Version 1.12.0, der gemäß der Anleitung GKE in 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 über die bmctl-Befehlszeile Zugriff auf den Cluster.
    • Zugriff auf Ihren Cluster über die kubectl CLI.

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

Die VM-Laufzeit in der benutzerdefinierten Ressourcendefinition (CRD) in GDC ist seit Version 1.10 Teil aller GKE on Bare Metal-Cluster. Eine Instanz der benutzerdefinierten Ressource VMRuntime wird bereits bei der Installation erstellt. Sie ist jedoch standardmäßig deaktiviert.

  1. Aktivieren Sie die VM-Laufzeit auf GDC:

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

  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 er nicht bereit ist, prüfen Sie ihn mehrmals mit kurzer Verzögerung. Die folgende Beispielausgabe zeigt, dass VMRuntime bereit ist:

    vmruntime.vm.cluster.gke.io/vmruntime condition met

  3. Installieren Sie das Plug-in virtctl 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 GDC ein VM-Image. Dieses Image dient als Bootlaufwerk für die bereitgestellte VM.

In dieser Anleitung migrieren Sie eine VM-basierte Arbeitslast von Compute Engine zu einem GKE on Bare Metal-Cluster. Diese Compute Engine-VM wurde erstellt und die exemplarische Point of Sale-Anwendung (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 Image wurde dann als qcow2-Image 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 herzustellen, um Inventar- und Zahlungsinformationen zu speichern. Das Point-of-Sale-Repository hat ein Beispielmanifest, das ein MySQL-StatefulSet bereitstellt, ein verknüpftes ConfigMap und ein Kubernetes-Service konfiguriert. ConfigMap definiert die Anmeldedaten für die MySQL-Instanz. Dies sind dieselben 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 (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 die VM-Arbeitslast mithilfe von Definitionen von Kubernetes-Ressourcenmodellen (KRM) bereitstellen, wie in der erstellten YAML-Datei zu sehen.

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

    Beim Erstellen einer VM werden die folgenden beiden 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 vor dem Booten der VM auf der VirtualMachine bereitgestellt.

    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 Beginn des Image-Imports:

    NAME              PHASE             PROGRESS   RESTARTS   AGE
pos-vm-boot-dv    ImportScheduled   N/A                   8s

  4. Prüfe den Status von VirtualMachine. Das VirtualMachine befindet sich im Status Provisioning, bis das DataVolume vollständig importiert wurde:

    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. Während das Image importiert wird, können Sie den Fortschritt beobachten:

    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 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 den 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 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, 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 auf GDC VirtualMachine erstellt wurde.

    • Log-in-Nutzername: 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 mit einem 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 VMs erreichbar zu machen, die mit der VM-Laufzeit 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 ^] durch Drücken von Ctrl + ].

Auf VM-basierte Arbeitslast zugreifen

Wenn Ihr Cluster gemäß der Anleitung GKE in 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 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 Ressource Ingress leitet den 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 Load-Balancers Ingress ab. Der Ingress-Load-Balancer leitet 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 einen einfachen Point-of-Sale-Kiosk mit zwei Artikeln. Sie können die Artikel mehrmals anklicken, wenn Sie mehrere Artikel bestellen möchten, und eine Bestellung über die Schaltfläche Bezahlen aufgeben. Diese Erfahrung zeigt, dass Sie mithilfe der VM-Laufzeit auf GDC erfolgreich eine VM-basierte Arbeitslast in einem GKE on Bare Metal-Cluster bereitgestellt haben.

Benutzeroberfläche der Point-of-Sale-Anwendung
Benutzeroberfläche der Kassenanwendung (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 beibehalten. 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 auf der 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, wird die VirtualMachineDisk beibehalten, die erstellt wird. 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

    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 ursprüngliche VM in dieser Anleitung ist eine Compute Engine-Instanz, die Ubuntu 20.04 LTS ausführt. 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 ihres 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 GKE on Bare Metal-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. Statt das virtctl-Plug-in zu verwenden, können Sie eine VM mit KRM-Definitionen bereitstellen, wie in der erstellten YAML-Datei zu sehen.