Anleitung: Vorhandene VM in einem Anthos-Cluster mit Anthos-VM-Laufzeit bereitstellen

Dieses Dokument enthält eine Schritt-für-Schritt-Anleitung zum Bereitstellen einer Arbeitslast (VM) auf Anthos-Bare-Metal-Cluster mit Anthos-VM-Laufzeit. Die in diesem Leitfaden 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 in einen Anthos-Cluster auf 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. Die Anthos-VM-Laufzeit erwartet, dass die Images das Format qcow2 haben. Wenn Sie einen anderen Bildtyp angeben, wird dieser 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 vorab vorbereitetes Image einer Compute Engine-VM-Instanz verwendet, auf der die Arbeitslast als systemd-Dienst ausgeführt wird. Führen Sie dieselben Schritte aus, um Ihre eigene Anwendung bereitzustellen.

Lernziele

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

Hinweis

Für dieses Dokument benötigen Sie die folgenden Ressourcen:

Zugriff auf einen Cluster von Anthos on Bare Metal-Version 1.12.0 oder höher, der gemäß der Anleitung Anthos-Cluster auf Bare-Metal-VMs mit manuellen 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 dieses Dokument mit jedem Anthos-Cluster auf Bare Metal verfolgen.
Eine Workstation, die die folgenden Anforderungen erfüllt:
- Hat Zugriff auf Ihren Cluster über die bmctl-CLI.
- Hat Zugriff auf Ihren Cluster über die kubectl-CLI.

Anthos-VM-Laufzeit aktivieren und das `virtctl`-Plug-in installieren

Die benutzerdefinierte Ressourcendefinition (VM) für Anthos-VM-Laufzeit (CRD) ist seit Version 1.10 Teil aller Anthos-Cluster auf Bare-Metal-Clustern. Eine Instanz der benutzerdefinierten Ressource VMRuntime wird bei der Installation bereits erstellt. Sie ist jedoch standardmäßig deaktiviert.

Aktivieren Sie die Anthos-VM-Laufzeit:
```
sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
```
- KUBECONFIG_PATH: Pfad zur Kubernetes-Konfigurationsdatei des Anthos-Nutzerclusters
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
```

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

Prüfen Sie, ob das Plug-in virtctl installiert ist:

kubectl virt

Die folgende Beispielausgabe zeigt, dass das virtctl-Plug-in für kubectl verfügbar 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 auf Anthos-Bare-Metal-Clustern bereitstellen, erwartet Anthos VM Runtime 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 in einen Anthos-Cluster auf Bare-Metal-Cluster. Diese Compute Engine-VM wurde erstellt und die Beispiel-Point-of-Sale-Anwendung (PoS) wurde so konfiguriert, dass sie als systemd-Dienst ausgeführt wird. In Google Cloud wurde ein Laufwerk-Image dieser VM zusammen mit der PoS-Anwendungsarbeitslast 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 die Ressourcen aus diesem Repository, um die folgenden Schritte auszuführen.

MySQL-StatefulSet bereitstellen Die Kasse wird mit einer MySQL-Datenbank verbunden, 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. Hierbei handelt es sich um dieselben Anmeldedaten, die an die Kassenanwendung übergeben werden.
```
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/point-of-sale/main/k8-manifests/common/mysql-db.yaml
```
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
```
Dieser Befehl erstellt eine YAML-Datei, 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. Anstatt das Plug-in virtctl zu verwenden, können Sie die VM-Arbeitslast mit KRM-Definitionen (Kubernetes Resource Model) bereitstellen, wie in der erstellten YAML-Datei dargestellt.

Wenn der Befehl erfolgreich ausgeführt wird, wird eine Ausgabe wie im folgenden Beispiel erstellt, 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"
```
Prüfen Sie den Status der VM-Erstellung.

Die Ressource VirtualMachine wird durch die Ressource vm.cluster.gke.io/v1.VirtualMachine in der Anthos-VM-Laufzeit identifiziert. Die Kurzform lautet gvm.

Wenn Sie eine VM erstellen, werden die folgenden zwei Ressourcen erstellt:
- Ein 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 in VirtualMachine bereitgestellt.
Prüfen Sie den Status des VirtualMachineDisk. VirtualMachineDisk erstellt eine DataVolume-Ressource intern. Das VM-Image wird in das auf der VM bereitgestellte DataVolume importiert:
```
kubectl get datavolume
```
Die folgende Beispielausgabe zeigt den Beginn des Bildimports:
```
NAME              PHASE             PROGRESS   RESTARTS   AGE
pos-vm-boot-dv    ImportScheduled   N/A                   8s
```
Prüfe den Status von VirtualMachine. VirtualMachine hat den Status Provisioning, bis DataVolume vollständig importiert wurde:
```
kubectl get gvm
```
Die folgende Beispielausgabe zeigt die bereitgestellte VirtualMachine:
```
NAME      STATUS         AGE     IP
pos-vm    Provisioning   1m
```
Warten Sie, bis das VM-Image vollständig in DataVolume importiert wurde. Sehen Sie sich den Fortschritt während des Imports weiter an:
```
kubectl get datavolume -w
```
Die folgende Beispielausgabe zeigt das importierte 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, sehen Sie in der folgenden Beispielausgabe die 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 Compute Engine-VM-Image in diesem Dokument ist etwa 5 GB groß und der Import kann bis zu 15 Minuten dauern.
Prüfen Sie, ob VirtualMachine erstellt wurde:
```
kubectl get gvm
```
Wenn die Erstellung erfolgreich war, zeigt STATUS wie im folgenden Beispiel zusammen mit der IP-Adresse der VM RUNNING 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 Systemstart automatisch als systemd-Dienst gestartet wird. Sie finden die Konfigurationsdateien der systemd-Dienste im Verzeichnis pos-systemd-services.

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 wurde:
```
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:
```
Verwenden Sie das folgende Nutzerkonto und Passwort. Dieses Konto wurde in der ursprünglichen VM eingerichtet, von der das Image für die Anthos-VM-Laufzeit VirtualMachine erstellt wurde.
- Nutzername: abmuser
- Passwort: abmworks

Prüfen Sie den Status der Kassen-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 über localhost miteinander. 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 unternehmen, um den Kubernetes-Services von den VMs aus zu erreichen, die über die Anthos-VM-Laufzeit bereitgestellt werden.

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

Beenden Sie die VM. Verwende zum Beenden der Konsolenverbindung die Escape-Sequenz ^] durch Drücken von Ctrl + ].

Auf die VM-basierte Arbeitslast zugreifen

Wenn Ihr Cluster gemäß der Anleitung Anthos-Cluster auf Bare-Metal-VMs 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 öffentlichen IP-Adresse des Ingress-Load-Balancers an den API-Serverdienst der Beispiel- Kassenanwendung weiter.

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

anthos-bm-gcp-terraform/resources/manifests/pos-Ingress.yaml

Auf GitHub ansehen

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

Erstellen Sie eine Kubernetes-Service, die Traffic an die VM weiterleitet. Die Ressource Ingress 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

anthos-vmruntime/pos-service.yaml

Auf GitHub ansehen

apiVersion: v1
kind: Service
metadata:
  name: api-server-svc
spec:
  selector:
    kubevirt/vm: pos-vm
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8081

Rufen Sie die öffentliche 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, um Anfragen an den API-Server Service weiterzuleiten. Service leitet 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
```
Greifen Sie über die IP-Adresse des Ingress-Load-Balancers in einem Browser auf die Anwendung zu. Die folgenden Beispielscreenshots zeigen den einfachen Point-of-Sale-Kiosk mit zwei Artikeln. Wenn Sie mehrere Artikel gleichzeitig bestellen möchten, können Sie mehrmals darauf klicken und dann mit der Schaltfläche Bezahlen eine Bestellung aufgeben. Diese Erfahrung zeigt, dass Sie eine traditionelle VM-basierte Arbeitslast mithilfe der Anthos-VM-Laufzeit erfolgreich in einem Anthos-Cluster bereitgestellt haben.

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

Bereinigen

Sie können alle in dieser Anleitung erstellten Ressourcen oder nur die VM löschen und wiederverwendbare Ressourcen beibehalten. Unter VM in Anthos-Clustern auf Bare Metal löschen werden die verfügbaren Optionen ausführlich erläutert.

Alles löschen

Löschen Sie die Anthos-VM-Laufzeit VirtualMachine zusammen mit allen Ressourcen:

kubectl virt delete vm pos-vm --all

Die folgende Beispielausgabe bestätigt den Löschvorgang:

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 der erstellte VirtualMachineDisk beibehalten. Dies ermöglicht die Wiederverwendung dieses VM-Images und spart beim Importieren einer neuen VM Zeit beim Importieren des Images.
```
kubectl virt delete vm pos-vm
```
Die folgende Beispielausgabe bestätigt den Löschvorgang:
```
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 diesem Leitfaden 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 dazu, wie die VM konfiguriert und ihr Image erstellt wurde, finden Sie in der Anleitung im Point-of-Sale-Repository.
Wenn Sie eine VM in einem Anthos-Cluster mit dem Befehl kubectl virt create vm pos-vm erstellen, wird eine YAML-Datei erstellt, die nach der VM (google-virtctl/pos-vm.yaml) benannt ist. In der Datei finden Sie eine Definition für VirtualMachine und VirtualMachineDisk. Statt das Plug-in virtctl zu verwenden, können Sie eine VM mit KRM-Definitionen wie in der erstellten YAML-Datei bereitstellen.