Mit VM-basierten Arbeitslasten arbeiten

Version 1.11 (unsupported)

• Neueste
• Version 1.16
• Frühere Versionen (nicht unterstützt)

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Funktionen sind unverändert verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Auf dieser Seite wird gezeigt, wie Sie mit Anthos VM Runtime VMs in Anthos-Cluster auf Bare-Metal bereitstellen. Anthos VM Runtime verwendet KubeVirt, um VMs in Clustern zu orchestrieren, sodass Sie mit Ihren VM-basierten Anwendungen und Arbeitslasten in einer einheitlichen Entwicklungsumgebung arbeiten können. Sie können die Anthos VM Runtime beim Erstellen eines neuen Clusters und auf vorhandenen Clustern aktivieren.

Hinweis: Ab Anthos-Clustern auf Bare Metal Release 1.10.0 verfügen neu erstellte Cluster und Cluster, die auf Version 1.10.0 oder höher aktualisiert wurden, über eine benutzerdefinierte VMRuntime-Ressource mit Cluster-Scoping. Sie verwenden anstelle der Clusterkonfigurationsdatei die benutzerdefinierte Ressource VMRuntime, um die Anthos VM-Laufzeit zu aktivieren und zu deaktivieren. Die benutzerdefinierte Ressource VMRuntime wird nur für Hybrid-, Standalone- und Nutzercluster bereitgestellt.

Hinweis

Bei dieser Anleitung wird davon ausgegangen, dass ein Cluster einsatzbereit ist. Falls nicht, können Sie der Anthos-Cluster auf Bare-Metal-Kurzanleitung folgen, um einen Cluster auf Ihrer Workstation schnell einzurichten.

Anthos VM Runtime aktivieren

Die VM-Laufzeit von Anthos ist standardmäßig deaktiviert. Bearbeiten Sie zum Aktivieren der Anthos VM-Laufzeit die benutzerdefinierte Ressource VMRuntime im Cluster. Ab Anthos-Clustern auf Bare-Metal-Version 1.10.0 wird die benutzerdefinierte Ressource VMRuntime automatisch auf Clustern installiert.

So aktivieren Sie die Anthos VM-Laufzeit:

1. Aktualisieren Sie die benutzerdefinierte Ressource VMRuntime, um enabled auf true festzulegen.

   apiVersion: vm.cluster.gke.io/v1
   kind: VMRuntime
   metadata:
     name: vmruntime
   spec:
     enabled: true
     # useEmulation default to false if not set.
     useEmulation: true
     # vmImageFormat default to "qcow2" if not set.
     vmImageFormat: qcow2
   

2. Wenn Ihr Knoten keine Hardwarevirtualisierung unterstützt oder Sie sich nicht sicher sind, setzen Sie useEmulation auf true.

   Die Hardwarevirtualisierung bietet eine bessere Leistung als die Softwareemulation. Das Feld useEmulation ist standardmäßig auf false gesetzt, wenn es nicht angegeben ist.

   apiVersion: vm.cluster.gke.io/v1
   kind: VMRuntime
   metadata:
     name: vmruntime
   spec:
     enabled: true
     # useEmulation default to false if not set.
     useEmulation: true
     # vmImageFormat default to "qcow2" if not set.
     vmImageFormat: qcow2
   

3. Um das für die von Ihnen erstellten VMs verwendete Image-Format zu ändern, legen Sie das vmImageFormat-Feld fest.

   Das Feld vmImageFormat unterstützt zwei Werte für das Laufwerk-Image-Format: raw und qcow2. Wenn Sie vmImageFormat nicht festlegen, verwendet die Anthos VM-Laufzeit das Laufwerk-Image-Format raw, um VMs zu erstellen. Das Format raw bietet möglicherweise eine bessere Leistung gegenüber qcow2, eine Kopie des Schreibformats, benötigt aber möglicherweise mehr Platz auf dem Laufwerk. Weitere Informationen zu den Image-Formaten für Ihre VM finden Sie in der QEMU-Dokumentation unter Dateiformate für Laufwerk-Images.

   apiVersion: vm.cluster.gke.io/v1
   kind: VMRuntime
   metadata:
     name: vmruntime
   spec:
     enabled: true
     # useEmulation default to false if not set.
     useEmulation: true
     # vmImageFormat default to "qcow2" if not set.
     vmImageFormat: qcow2
   

4. Speichern Sie die Konfiguration und prüfen Sie, ob die benutzerdefinierte Ressource VMRuntime aktiviert ist:

   kubectl describe vmruntime vmruntime
   

   Die Details der benutzerdefinierten Ressource VMRuntime enthalten den Abschnitt Status. Die Anthos-VM-Laufzeit ist aktiviert und funktioniert, wenn VMRuntime.Status.Ready auf true gesetzt ist.

Cluster aktualisieren

Wichtig: Änderungen an der Anthos VM-Laufzeit in Anthos-Clustern auf Bare-Metal-Releases 1.11.2 und höher wirken sich auf Clusterupgrades aus. Beim Upgrade von Clustern auf Version 1.11.2 oder höher werden die spec.kubevirt-Einstellungen in der Clusterkonfiguration nicht mehr berücksichtigt. Aufgrund von Namespace-Änderungen müssen Sie außerdem die Anthos VM-Laufzeit deaktivieren, bevor Sie Cluster der Version 1.11.1 oder niedriger auf Version 1.11.2 oder höher aktualisieren. Wenn Sie das Upgrade abgeschlossen haben, aktivieren Sie die Anthos VM-Laufzeit wieder.

Die benutzerdefinierte Ressource VMRuntime wird automatisch auf Clustern installiert, die auf Version 1.10.0 oder höher aktualisiert wurden. Wenn Sie einen Cluster der Version 1.9.x auf Version 1.10.0 und höher aktualisieren, prüft der Upgradeprozess Ihre Clustereinstellungen und konfiguriert die benutzerdefinierte Ressource VMRuntime so, dass sie den Einstellungen der Anthos-VM-Laufzeit auf Ihrem Cluster der Version 1.9.x entspricht. Wenn spec.kubevirt in der Clusterressource der Version 1.9.x vorhanden ist, aktiviert der Upgradeprozess die Anthos-VM-Laufzeit.

Die benutzerdefinierten Ressourceneinstellungen VMRuntime haben Vorrang vor Legacy-Clustereinstellungen von Anthos-VM-Laufzeiten, z. B. spec.kubevirt.useEmulation in Clustern der Version 1.10.0 oder höher. Aktualisieren Sie die benutzerdefinierte VMRuntime-Ressource, um die Einstellungen für die Anthos VM-Laufzeit für Cluster ab Version 1.10.0 zu ändern.

virtctl installieren

1. Installieren Sie das virtctl-Befehlszeilentool als kubectl-Plug-in.

   export GOOGLE_APPLICATION_CREDENTIALS="bm-gcr.json"
   sudo -E ./bmctl install virtctl
   

2. Prüfen Sie, ob virtctl installiert ist:

   kubectl plugin list
   

   Wenn virtctl in der Antwort aufgeführt ist, wurde es erfolgreich installiert.

VM erstellen

Nachdem Sie KubeVirt auf Ihrem Cluster aktiviert und das virtctl-Plug-in für kubectl installiert haben, können Sie mit dem Befehl kubectl virt create vm VMs in Ihrem Cluster erstellen. Bevor Sie diesen Befehl ausführen, sollten Sie eine cloud-init-Datei konfigurieren, damit Sie von der Konsole aus Zugriff auf die VM haben, nachdem sie erstellt wurde.

Benutzerdefinierte cloud-init-Datei für den Konsolezugriff erstellen

Es gibt zwei Möglichkeiten, eine benutzerdefinierte cloud-init-Datei zu erstellen. Am einfachsten ist es, das Flag --os=<OPERATING_SYSTEM> beim Erstellen der VM anzugeben. Diese Methode konfiguriert automatisch eine einfache cloud-init-Datei und funktioniert für die folgenden Betriebssysteme.

• Ubuntu
• CentOS
• Debian
• Fedora

Nachdem die VM erstellt wurde, können Sie sie mit den folgenden Anmeldedaten zum ersten Mal aufrufen und dann das Passwort ändern:

user: root
password: changeme

Wenn das Image ein anderes Linux-basiertes Betriebssystem enthält oder Sie eine erweiterte Konfiguration benötigen, können Sie manuell eine benutzerdefinierte cloud-init-Datei erstellen und den Pfad zu dieser Datei mit dem Flag --cloud-init-file=<path/to/file> angeben. In ihrer grundlegendsten Form ist die cloud-init-Datei eine YAML-Datei, die Folgendes enthält:

#cloud-config
user: root
password: changeme
lock_passwd: false
chpasswd: {expire: false}
disable_root: false
ssh_authorized_keys:
- <ssh-key>

Erweiterte Konfigurationen finden Sie unter Cloud-Konfigurationsbeispiele.

Nachdem Sie entschieden haben, welche Methode Sie verwenden möchten, können Sie eine VM erstellen.

Befehl kubectl virt create vm ausführen

Sie können VMs aus öffentlichen oder benutzerdefinierten Images erstellen.

Öffentliches Image

Wenn Ihr Cluster eine externe Verbindung hat, können Sie mit dem folgenden Befehl eine VM aus einem öffentlichen Image erstellen:

kubectl virt create vm VM_NAME \
    --boot-disk-access-mode=MODE \
    --boot-disk-size=DISK_SIZE \
    --boot-disk-storage-class="DISK_CLASS" \
    --cloud-init-file=FILE_PATH \
    --cpu=CPU_NUMBER \
    --image=IMAGE_NAME \
    --memory=MEMORY_SIZE

Dabei gilt:

• VM_NAME durch den Namen der VM, die Sie erstellen möchten.
• MODE durch den Zugriffsmodus des Bootlaufwerks. Mögliche Werte sind ReadWriteOnce (Standardeinstellung) oder ReadWriteMany.
• DISK_SIZE durch die gewünschte Größe für das Bootlaufwerk. Der Standardwert ist 20Gi
• DISK_CLASS durch die Speicherklasse des Bootlaufwerks. Der Standardwert ist local-shared. Führen Sie den Befehl kubectl get storageclass aus, um eine Liste der verfügbaren Speicherklassen aufzurufen.
• FILE_PATH durch den vollständigen Pfad der benutzerdefinierten cloud-init-Datei. Je nach Image ist es möglicherweise erforderlich, dass die Konsole Zugriff auf die VM hat, nachdem sie erstellt wurde. Wenn Sie die cloud-init-Datei automatisch mit dem Flag --os konfigurieren möchten, geben Sie das Flag --cloud-init-file nicht an. Wenn Sie das Flag --cloud-init-file angeben, wird das Flag --os ignoriert. Zulässige Werte für --os sind ubuntu, centos, debian und fedora.
• CPU_NUMBER durch die Anzahl der CPUs, die Sie für die VM konfigurieren möchten. Der Standardwert ist 1.
• IMAGE_NAME durch das VM-Image, das ubuntu20.04 (Standardeinstellung), centos8 oder eine URL des Images sein kann.
• MEMORY_SIZE durch die Speichergröße der VM. Der Standardwert ist 4Gi.

Benutzerdefiniertes Image

Beim Erstellen einer VM aus einem benutzerdefinierten Image können Sie entweder ein Image von einem HTTP-Image-Server oder ein lokal gespeichertes Image angeben.

HTTP-Image-Server

Sie können einen HTTP-Server mit Apache oder nginx einrichten und das benutzerdefinierte Image in seinen freigegebenen Ordner hochladen. Anschließend können Sie mit dem folgenden Befehl eine VM aus dem benutzerdefinierten Image erstellen:

kubectl virt create vm VM_NAME \
    --boot-disk-access-mode=DISK_ACCESS_MODE \
    --boot-disk-size=DISK_SIZE \
    --boot-disk-storage-class=DISK_CLASS \
    --cloud-init-file=FILE_PATH \
    --cpu=CPU_NUMBER \
    --image=http://SERVER_IP/IMAGE_NAME \
    --memory=MEMORY_SIZE

Dabei gilt:

• VM_NAME durch den Namen der VM, die Sie erstellen möchten.
• DISK_ACCESS_MODE durch den Zugriffsmodus des Bootlaufwerks. Mögliche Werte sind ReadWriteOnce (Standardeinstellung) oder ReadWriteMany.
• DISK_SIZE durch die gewünschte Größe für das Bootlaufwerk. Der Standardwert ist 20Gi
• DISK_CLASS durch die Speicherklasse des Bootlaufwerks. Der Standardwert ist local-shared Führen Sie den Befehl kubectl get storageclass aus, um eine Liste der verfügbaren Speicherklassen aufzurufen.
• FILE_PATH durch den vollständigen Pfad der benutzerdefinierten cloud-init-Datei. Je nach Image ist es möglicherweise erforderlich, dass die Konsole Zugriff auf die VM hat, nachdem sie erstellt wurde. Wenn Sie die cloud-init-Datei automatisch mit dem Flag --os konfigurieren möchten, geben Sie das Flag --cloud-init-file nicht an. Wenn Sie das Flag --cloud-init-file angeben, wird das Flag --os ignoriert. Die akzeptablen Werte für --os sind ubuntu, centos, debian und fedora.
• CPU_NUMBER durch die Anzahl der CPUs, die Sie für die VM konfigurieren möchten. Der Standardwert ist 1.
• SERVER_IP durch die IP-Adresse des Servers, der das Image hostet.
• IMAGE_NAME durch den Dateinamen des benutzerdefinierten Images.
• MEMORY_SIZE durch die Speichergröße der VM. Der Standardwert ist 4Gi.

Lokal gespeichertes Image

Mit dem folgenden Befehl können Sie das benutzerdefinierte Image lokal speichern und daraus eine VM erstellen:

kubectl virt create vm VM_NAME \
    --boot-disk-access-mode=DISK_ACCESS_MODE \
    --boot-disk-size=DISK_SIZE \
    --boot-disk-storage-class=DISK_CLASS \
    --cloud-init-file=FILE_PATH \
    --cpu=CPU_NUMBER \
    --image=IMAGE_PATH \
    --memory=MEMORY_SIZE \

Dabei gilt:

• VM_NAME durch den Namen der VM, die Sie erstellen möchten.
• DISK_ACCESS_MODE durch den Zugriffsmodus des Bootlaufwerks. Mögliche Werte sind ReadWriteOnce (Standardeinstellung) oder ReadWriteMany.
• DISK_SIZE durch die gewünschte Größe für das Bootlaufwerk. Der Standardwert ist 20Gi
• DISK_CLASS durch die Speicherklasse des Bootlaufwerks. Der Standardwert ist local-shared
• FILE_PATH durch den vollständigen Pfad der benutzerdefinierten cloud-init-Datei. Je nach Image ist es möglicherweise erforderlich, dass die Konsole Zugriff auf die VM hat, nachdem sie erstellt wurde. Wenn Sie die cloud-init-Datei automatisch mit dem Flag --os konfigurieren möchten, geben Sie das Flag --cloud-init-file nicht an. Wenn Sie das Flag --cloud-init-file angeben, wird das Flag --os ignoriert. Die akzeptablen Werte für --os sind ubuntu, centos, debian und fedora.
• CPU_NUMBER durch die Anzahl der CPUs, die Sie für die VM konfigurieren möchten. Der Standardwert ist 1.
• IMAGE_PATH durch den lokalen Dateipfad zum benutzerdefinierten Image.
• MEMORY_SIZE durch die Speichergröße der VM. Der Standardwert ist 4Gi.

Standardwerte für Flags ändern

Der Befehl kubectl virt create vm verwendet beim Ausführen Standardwerte, um nicht angegebene Flags automatisch auszufüllen. Sie können diese Standardwerte mit dem folgenden Befehl ändern:

kubectl virt config default FLAG

Ersetzen Sie FLAG durch das Flag des Parameters, für den Sie den Standardwert ändern möchten.

Beispiel: Mit dem folgenden Befehl wird die Standard-CPU-Konfiguration von der anfänglichen Standardeinstellung 1 in 2 geändert:

kubectl virt config default --cpu=2

Führen Sie folgenden Befehl aus, um eine Liste der unterstützten Flags und ihrer aktuellen Standardwerte aufzurufen:

kubectl virt config default -h

Die Standardkonfigurationen werden clientseitig als lokale Datei mit dem Namen ~/.virtctl.default gespeichert. Sie können die Standardkonfigurationen ändern, indem Sie diese Datei auch bearbeiten.

Auf die VM zugreifen

Sie haben folgende Möglichkeiten, auf VMs zuzugreifen:

Konsolenzugriff

Führen Sie folgenden Befehl aus, um über die Konsole auf eine VM zuzugreifen:

kubectl virt console VM_NAME

Ersetzen Sie VM_NAME durch den Namen der VM, auf die Sie zugreifen möchten.

VNC-Zugriff

Führen Sie folgenden Befehl aus, um mit VNC auf eine VM zuzugreifen:

# This requires remote-viewer from the virt-viewer package and a graphical desktop from where you run virtctl
kubectl virt vnc VM_NAME

Ersetzen Sie VM_NAME durch den Namen der VM, auf die Sie zugreifen möchten.

Interner Zugriff

Auf die IP-Adressen Ihrer Cluster-VMs können alle anderen Pods im Cluster direkt zugreifen. Führen Sie Folgendes aus, um die IP-Adresse einer VM zu ermitteln:

kubectl get vmi VM_NAME

Ersetzen Sie VM_NAME durch den Namen der VM, auf die Sie zugreifen möchten.

Der Befehl gibt etwa Folgendes zurück:

NAME     AGE   PHASE     IP              NODENAME
vm1      13m   Running   192.168.1.194   upgi-bm002

Externer Zugriff

In Ihrem Cluster erstellte VMs haben Pod-Netzwerkadressen, auf die nur von innerhalb des Clusters zugegriffen werden kann. So greifen Sie extern auf Cluster-VMs zu:

1. Geben Sie die VM als Load-Balancer-Dienst frei:

   kubectl virt expose vm VM_NAME \
       --port=LB_PORT \
       --target-port=VM_PORT \
       --type=LoadBalancer \
       --name=SERVICE_NAME
   

   Dabei gilt:

   • VM_NAME durch den Namen der VM, auf die Sie zugreifen möchten.
   • LB_PORT durch den Port des freigegebenen Load-Balancer-Dienstes.
   • VM_PORT durch den Port auf der VM, auf die Sie über den Load-Balancer-Dienst zugreifen möchten.
   • SERVICE_NAME durch den Namen, den Sie diesem Load-Balancer-Dienst geben möchten.

2. Rufen Sie die externe IP-Adresse des Load-Balancer-Dienstes ab:

   kubectl get svc SERVICE_NAME
   

   Ersetzen Sie SERVICE_NAME durch den Namen des Load-Balancer-Dienstes, der die VM freigibt.

   Sie können auf den Zielport der VM über die IP-Adresse zugreifen, die im Feld EXTERNAL-IP der Antwort aufgeführt ist.

Beispiel

Wenn Sie eine VM mit dem Namen galaxy haben, auf die Sie von außerhalb des Clusters mit SSH zugreifen möchten, führen Sie Folgendes aus:

kubectl virt expose vm galaxy \
   --port=25022 \
   --target-port=22 \
   --type=LoadBalancer \
   --name=galaxy-ssh

Rufen Sie die IP-Adresse des Load-Balancers ab:

kubectl get svc galaxy-ssh

Der Befehl gibt etwa Folgendes zurück:

NAME        TYPE          CLUSTER-IP     EXTERNAL-IP   PORT(S)           AGE
galaxy-ssh  LoadBalancer  10.96.250.76   21.1.38.202   25000:30499/TCP   4m40s

Jetzt können Sie mit SSH über 21.1.38.202:25022 (VIP:Port) von außerhalb des Clusters auf die VM zugreifen:

ssh root@21.1.38.202:22 -p 25022

VM-Telemetrie und Konsolenlogs prüfen

VM-Telemetrie und -Konsolenlogs wurden in die Google Cloud Console eingebunden. Telemetrieinformationen und Logdaten sind für das Monitoring des Status Ihrer VMs und die Fehlerbehebung bei Problemen mit Ihren Cluster-VMs entscheidend.

VM-Telemetrie

Im Dashboard VM-Status von Anthos-Clustern finden Sie Live-Telemetriedaten für Ihre Cluster-VMs.

So rufen Sie Telemetriedaten für Ihre Cluster-VMs auf:

1. Wählen Sie in der Google Cloud Console Monitoring aus oder klicken Sie auf die folgende Schaltfläche:

   Zu Monitoring

2. Wählen Sie Dashboards aus.

   

3. Klicken Sie in der Liste Alle Dashboards auf VM-Clusterstatus von Anthos.

   

VM-Konsolenlogs

Logs von seriellen Konsolen-VMs werden an Cloud Logging gestreamt und können im Log-Explorer aufgerufen werden.

VMs und ihre Ressourcen löschen

Nur die VM löschen

kubectl virt delete vm VM_NAME

Ersetzen Sie VM_NAME durch den Namen der VM, die Sie löschen möchten.

Nur VM-Laufwerke löschen

kubectl virt delete disk DISK_NAME

Ersetzen Sie DISK_NAME durch den Namen des Laufwerks, das Sie löschen möchten. Wenn Sie versuchen, ein VM-Laufwerk zu löschen, bevor Sie die VM löschen, wird das Laufwerk zum Löschen markiert, für den Fall dass die VM gelöscht wird.

VM und Ressourcen löschen

kubectl virt delete vm VM_NAME --all

Ersetzen Sie VM_NAME durch den Namen der VM, die Sie löschen möchten.

Wenn Sie die Ressourcen prüfen möchten, die von der gelöschten VM verwendet werden, können Sie das Flag --dry-run zusammen mit --all angeben.

Anthos VM Runtime deaktivieren

Wenn Sie Anthos-VM-Laufzeit nicht mehr verwenden müssen, können Sie diese Funktion deaktivieren.

bmctl

• Verwenden Sie das Tool bmctl, um die Laufzeit zu aktivieren:

  bmctl disable vmruntime --kubeconfig KUBECONFIG_PATH \
    --timeout TIMEOUT_IN_MINUTES \
    --force true
  

  Geben Sie den Pfad zur kubeconfig-Datei für Ihren Cluster und die Werte für die folgenden Konfigurationsoptionen an:

  • --timeout: TIMEOUT_IN_MINUTES die gewartet werden, bis vorhandene VM-Ressourcen gelöscht werden. Der Standardwert ist 10 Minuten.
  • --force: Gesetzt auf true, um zu bestätigen, dass Sie vorhandene VM-Ressourcen löschen möchten. Der Standardwert ist false.

Benutzerdefinierte Ressource

Bevor Sie die Anthos VM-Laufzeit in einem Cluster deaktivieren können, indem Sie die benutzerdefinierte Ressource VMRuntime bearbeiten, müssen Sie prüfen, ob alle VMs in diesem Cluster gelöscht wurden.

Zum Deaktivieren der Laufzeit aktualisieren Sie die benutzerdefinierte Ressource VMRuntime:

1. Suchen Sie nach vorhandenen VMs im Cluster:

   kubectl get vm
   

   Wenn der Befehl anzeigt, dass sich in Ihrem Cluster noch VMs befinden, müssen Sie diese löschen, bevor Sie fortfahren.

2. Bearbeiten Sie die benutzerdefinierte VMRuntime-Ressource:

   kubectl edit vmruntime
   

3. Legen Sie enabled:false in der Spezifikation fest:

   apiVersion: vm.cluster.gke.io/v1`
   kind: VMRuntime
   metadata:
     name: vmruntime
   spec:
     enabled: false
     useEmulation: true
     vmImageFormat: qcow2
   

4. Speichern Sie die aktualisierte benutzerdefinierte Ressourcenspezifikation in Ihrem Editor.

5. Wenn Sie prüfen möchten, ob die benutzerdefinierte Ressource VMRuntime deaktiviert ist, rufen Sie die Pods auf, die im Namespace vm-system ausgeführt werden:

   kubectl get pods --namespace vm-system
   

   Die Anthos-VM-Laufzeit wurde deaktiviert, wenn nur die Pods, die zur Bereitstellung vmruntime-controller-manager gehören, im Namespace ausgeführt werden.

Nächste Schritte

• Bekannte Probleme mit Anthos VM Runtime
• KubeVirt-Nutzerhandbuch