VM-Startroutinen konfigurieren

Vorschau

Dieses Produkt oder diese Funktion unterliegt den Bedingungen für Pre-GA-Angebote im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und ‑Funktionen sind „wie gesehen“ verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

Wenn Sie Google Distributed Cloud Version 1.13.0 und höher verwenden, können Sie Startroutinen angeben, um die Initialisierung Ihrer VM beim Start anzupassen. Sie können Ihre VM so konfigurieren, dass SSH-Schlüssel erstellt, Nutzer und Passwörter hinzugefügt, Pakete installiert, Dateien geschrieben und Netzwerkeinstellungen konfiguriert werden.

Diese Startaufgaben werden entweder mit der cloud-init API oder mit der API für Startscripts konfiguriert (nicht beides). Diese Startanweisungen werden in der YAML-Manifestdatei VirtualMachine angegeben und bei jedem Start Ihrer VM automatisch ausgeführt.

Voraussetzungen

Damit Sie eine VM mit Startanweisungen konfigurieren können, müssen die folgenden Voraussetzungen erfüllt sein:

• Aktivieren Sie die VM Runtime auf GDC.

• Verwenden Sie ein bestätigtes Linux-Gastbetriebssystem und legen Sie osType im VM-Manifest auf Linux fest. Windows-Gastbetriebssysteme werden für diese Funktion nicht unterstützt, da sie cloud-init nicht unterstützen.

• Prüfen Sie, ob cloud-init auf dem Gastbetriebssystem installiert ist. Die meisten aktuellen Linux-Betriebssysteme enthalten cloud-init.

In den folgenden Abschnitten wird beschrieben, wie Sie Startroutinen im VM-Manifest mit der cloud-init API oder Startskripts angeben.

VMs mit der cloud-init API initialisieren

Cloud-init wird häufig zur Initialisierung von Cloud-Instanzen und zur Anpassung von VMs beim Start verwendet. Die VM-Initialisierung umfasst in der Regel Aufgaben wie Paketinstallationen, Repository-Einrichtung, SSH-Schlüsselerstellung, Datenausgabe in Dateien und die Einrichtung anderer Aspekte Ihrer VM. Sie binden die cloud-init-Konfigurations-YAML mit dem Feld spec.cloudInit in die benutzerdefinierte Ressource VirtualMachine ein. Wenn Ihre VM-Instanz gestartet wird, liest cloud-init die bereitgestellten Daten und initialisiert die VM entsprechend.

Beachten Sie die folgenden Details unserer cloud-init-Implementierung:

• Sie geben cloud-init-Daten im VirtualMachine-YAML-Manifest an, wenn Sie eine VM erstellen oder aktualisieren. Eine Anleitung zum Erstellen einer VM durch Anwenden eines Manifests finden Sie unter Anleitung: Linux-VM in VM Runtime on GDC erstellen und verwalten.

• Wir verwenden die Datenquelle NoCloud>, spec.cloudInit.noCloud, in unserer VM-Spezifikation.

• Sie geben Nutzerdaten und Netzwerkdaten in separaten Abschnitten im VirtualMachine-Manifest an. Die Benennung und Struktur der Abschnitte hängen vom verwendeten Datenformat ab.

• Sie können cloud-init-Konfigurationsinformationen in den folgenden Datenformaten angeben:

  • Klartext
  • String mit base64-Codierung
  • Kubernetes Secret

Hinweis: Sie können nicht sowohl cloud-init-API-Anweisungen (spec.cloudInit) als auch Startscripts (spec.startupScripts) im selben VirtualMachine-Manifest angeben.

Um Ihnen den Einstieg zu erleichtern, haben wir einige Konfigurationsbeispiele für gängige VM-Initialisierungsaufgaben bereitgestellt.

cloud-init-Nutzerdaten

VM Runtime on GDC unterstützt cloud-init-Nutzerdaten in cloud-config-Syntax. Beginnen Sie Ihre Nutzerdaten daher mit #cloud-config. Sie können die Nutzerdaten als Klartext, als base64-codierten String oder als Kubernetes-Secret formatieren.

Hinweis: Bei der Verwendung von Klartext oder einem base64-codierten String beträgt die maximale Größe 2.048 Byte. Wenn die Größe der Nutzerdaten 2.048 Byte erreicht oder überschreitet, geben Sie sie als Kubernetes-Secret an.

Weitere Informationen zur Syntax von Nutzerdaten und zur Modulreferenz finden Sie in der cloud-init-Dokumentation.

Cloud-init-Nutzerdaten als Klartext

Das folgende Beispielmanifest zeigt, wie Nutzerdaten als Klartext angegeben werden. In diesem Fall führt cloud-init beim Start der VM einen Befehl aus:

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: "my-vm"
spec:
  ...
  cloudInit:
    noCloud:
      userData: |
        #cloud-config
        runcmd:
          - echo hello

Cloud-init-Nutzerdaten als base64-codierter String

Das folgende Beispiel zeigt, wie Nutzerdaten im base64-codierten Format angegeben werden. In diesem Beispiel bestehen die Nutzerdaten aus demselben echo hello-Befehl wie im Beispiel mit Klartext:

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: "my-vm"
spec:
  ...
  cloudInit:
    noCloud:
      userDataBase64: I2Nsb3VkLWNvbmZpZwpydW5jbWQ6CiAgLSBlY2hvIGhlbGxvCg==

cloud-init-Nutzerdaten als Kubernetes-Secret

Das folgende Beispiel zeigt ein YAML-Manifest sowohl für ein VirtualMachine als auch für ein Secret. Der Abschnitt spec.cloudInit.noCloud.secretRef in der VirtualMachine-Konfiguration gibt an, dass sich die cloud-init-Nutzerdaten in einem Kubernetes-Secret namens my-sec befinden. In der entsprechenden Secret-Konfiguration werden die Nutzerdaten als Schlüssel/Wert-Paar angegeben. Der base64-codierte Wert sind in diesem Fall die cloud-init-Nutzerdaten in cloud-config-Syntax.

Verwenden Sie im referenzierten Secret den Datenschlüssel userData (siehe Abbildung) oder userdata, um die cloud-init-Nutzerdaten anzugeben.

In diesem Beispiel bestehen die Nutzerdaten aus demselben echo hello-Befehl wie im Beispiel mit Klartext:

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: "my-vm"
spec:
  ...
  cloudInit:
    noCloud:
      secretRef:
        name: my-sec
---
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: my-sec
data:
  userData: I2Nsb3VkLWNvbmZpZwpydW5jbWQ6CiAgLSBlY2hvIGhlbGxvCg==

Wenn das referenzierte Secret nicht gefunden wird oder der Datenschlüssel userData oder userdata nicht im Secret vorhanden ist, beachten Sie das folgende VM-Startverhalten:

• Beim Erstellen einer VM wird die VM in den Status ErrorConfiguration versetzt. Es wird ein detaillierter Grund und eine Nachricht angezeigt.

• In anderen Fällen verwendet die VM weiterhin die alten cloud-init-Nutzerdaten, bis sie richtig konfiguriert ist. Daher werden Aktualisierungen für die Aktivierung oder Deaktivierung des Gast-Agents erst wirksam, wenn die VM richtig konfiguriert ist.

Mit dem folgenden Befehl können Sie VM-Informationen abrufen, einschließlich der verwendeten cloud-init-Nutzerdaten:

kubectl get vm VM_NAME -o yaml --kubeconfig KUBECONFIG_PATH

Ersetzen Sie Folgendes:

• VM_NAME ist der Name Ihrer VM.

• KUBECONFIG_PATH: der Pfad zur kubeconfig-Datei für den Cluster, der Ihre VM enthält.

Verwenden Sie kubectl get event oder kubectl describe gvm, um das zugehörige Kubernetes-Warnereignis abzurufen.

Cloud-init-Netzwerkdaten

Ähnlich wie bei Nutzerdaten können Sie die Netzwerkdaten als Klartext, als base64-codierten String oder als Kubernetes-Secret formatieren. Anders als bei Nutzerdaten wird für Netzwerkdaten keine cloud-config-Syntax verwendet.

Bei der Verwendung von Klartext oder einem base64-codierten String beträgt die maximale Größe 2.048 Byte. Wenn die Größe der Nutzerdaten 2.048 Byte erreicht oder überschreitet, geben Sie sie als Kubernetes-Secret an.

Weitere Informationen zur Syntax von Netzwerkdaten und zugehörigen Details finden Sie in der cloud-init-Dokumentation unter Networking Config Version 2.

Tipp: :n den folgenden Abschnitten wird gezeigt, wie Sie cloud-init-Netzwerkdaten in der VirtualMachine-Konfiguration in verschiedenen Formaten angeben. Die Beispielnetzwerkdaten aktivieren DHCP für alle Ethernet-Geräte, deren Namen mit „e“ beginnen. Diese spezielle cloud-init-Anweisung zum Aktivieren von DHCP wird automatisch in die VM eingebettet, sodass Sie sie nicht selbst angeben müssen.

Cloud-init-Netzwerkdaten als Klartext

Das folgende Beispielmanifest zeigt, wie Netzwerkdaten als Klartext angegeben werden. In diesem Fall aktiviert cloud-init DHCP für alle Ethernet-Geräte, deren Namen mit „e“ beginnen (e*):

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: "my-vm"
spec:
  ...
  cloudInit:
    noCloud:
      userData: |
        #cloud-config
        runcmd:
          - echo hello
      networkData: |
        version: 2
        ethernets:
          alleths:
            match:
              name: e*
            dhcp4: true

Cloud-init-Netzwerkdaten als base64-codierter String

Das folgende Beispiel zeigt, wie Netzwerkdaten im base64-codierten Format angegeben werden. In diesem Beispiel bestehen die Netzwerkdaten aus derselben DHCP-Konfiguration, die im Beispiel im Klartext angegeben ist:

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: "my-vm"
spec:
  ...
  cloudInit:
    noCloud:
      networkDataBase64: dmVyc2lvbjogMgpldGhlcm5ldHM6CiAgYWxsZXRoczoKICAgIG1hdGNoOgogICAgICBuYW1lOiBlKgogICAgZGhjcDQ6IHRydWUK

Cloud-init-Netzwerkdaten als Kubernetes-Secret

Das folgende Beispiel zeigt ein YAML-Manifest sowohl für ein VirtualMachine als auch für ein Secret. Der Abschnitt spec.cloudInit.noCloud.networkDataSecretRef in der VirtualMachine-Konfiguration gibt an, dass sich die cloud-init-Netzwerkdaten in einem Kubernetes-Secret namens my-sec befinden. In der entsprechenden Secret-Konfiguration werden die Netzwerkdaten als Schlüssel/Wert-Paar angegeben. Der base64-codierte Wert sind in diesem Fall die cloud-init-Netzwerkdaten.

Verwenden Sie im referenzierten Secret den Datenschlüssel networkData (siehe Abbildung) oder networkdata, um die cloud-init-Netzwerkdaten anzugeben.

In diesem Beispiel bestehen die Netzwerkdaten aus derselben DHCP-Konfiguration, die im Beispiel im Klartext angegeben ist:

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: "my-vm"
spec:
  ...
  cloudInit:
    noCloud:
      networkDataSecretRef:
        name: my-sec
---
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: my-sec
data:
  networkData: dmVyc2lvbjogMgpldGhlcm5ldHM6CiAgYWxsZXRoczoKICAgIG1hdGNoOgogICAgICBuYW1lOiBlKgogICAgZGhjcDQ6IHRydWUK

Cloud-init-Beispiele

In den folgenden Abschnitten finden Sie Beispiele für einige gängige Anwendungsfälle für die VM-Initialisierung mit cloud-init:

• Autorisierte SSH-Schlüssel konfigurieren
• Neuen Nutzer hinzufügen
• Befehle beim ersten Start ausführen
• Dateien schreiben

Autorisierte SSH-Schlüssel konfigurieren

Im folgenden Beispiel für Nutzerdaten wird der autorisierte SSH-Schlüssel ssh-rsa AAAAB3NzaK8L93bWxnyp dem Standardnutzer zugewiesen.

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: "my-vm"
spec:
  ...
  cloudInit:
    noCloud:
      userData: |
        #cloud-config
        ssh_authorized_keys:
          - ssh-rsa AAAAB3NzaK8L93bWxnyp

Neuen Nutzer hinzufügen

Im folgenden Beispiel für Nutzerdaten wird ein Nutzer test erstellt und test erhält vollen Sudo-Zugriff. In diesem Beispiel wird dem Nutzer ein nicht ablaufendes Passwort von pwd zugewiesen.

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: "my-vm"
spec:
  ...
  cloudInit:
    noCloud:
      userData: |
        #cloud-config
        users:
        - default
        - name: test
          sudo: ALL=(ALL) NOPASSWD:ALL
        chpasswd:
          list: |
            test:pwd
          expire: False

Befehle beim ersten Start ausführen

Im folgenden Beispiel für Nutzerdaten werden ein echo- und ein ls-Befehl ausgeführt. Sie können Befehle verwenden, um beim Starten der VM Pakete und mehr zu installieren.

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: "my-vm"
spec:
  ...
  cloudInit:
    noCloud:
      userData: |
        #cloud-config
        runcmd:
          - [ echo, hello ]
          - [ ls, -l, / ]

Dateien schreiben

Im folgenden Beispiel für Nutzerdaten wird ein Bash-Script in die Datei test im Verzeichnis /var/lib/google Ihrer VM geschrieben. Die cloud-init-Anweisung legt die Dateiberechtigungen für den Inhaber der Datei auf Lesen, Schreiben und Ausführen (0744) fest.

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: "my-vm"
spec:
  ...
  cloudInit:
    noCloud:
      userData: |
        #cloud-config
        write_files:
        - path: /var/lib/google/test
          permissions: 0744
          content: |
            #!/bin/bash
            echo hello

Fehlerbehebung bei cloud-init

Wenn Probleme bei der VM-Initialisierung auftreten und Sie cloud-init verwenden, prüfen Sie die folgenden cloud-init-Logs in Ihrer VM:

• /var/log/cloud-init.log: Standardmäßig schreibt cloud-init alle Ereignisse mit der Stufe DEBUG oder höher in dieses Log.

• /var/log/cloud-init-output.log: Standardmäßig leitet cloud-init sowohl stdout als auch stderr aus allen cloud-init-Phasen in dieses Log um.

VMs mit Startskripts initialisieren

Startskripts führen während des Startvorgangs einer VM-Instanz Aufgaben aus. Sie können ein oder mehrere Skripts im Abschnitt spec.startupScripts der VirtualMachine-Spezifikation angeben. Startskripts können zum Initialisieren Ihrer VM verwendet werden. Die VM-Initialisierung umfasst in der Regel Aufgaben wie Paketinstallationen, Repository-Einrichtung, SSH-Schlüsselerstellung, Datenausgabe in Dateien und die Einrichtung anderer Aspekte Ihrer VM.

Beachten Sie die folgenden Details zu Startskripts:

• Sie geben Startskripts im VirtualMachine-YAML-Manifest an, wenn Sie eine VM erstellen oder aktualisieren. Eine Anleitung zum Erstellen einer VM durch Anwenden eines Manifests finden Sie unter Anleitung: Linux-VM in VM Runtime on GDC erstellen und verwalten.

• Angegebene Skripts werden jedes Mal ausgeführt, wenn die VM gestartet wird.

• Fügen Sie #!/bin/... oben in das Skript ein, um den Skriptinterpreter anzugeben. Fügen Sie beispielsweise #!/bin/bash hinzu, um das Skript mit der Bash-Shell auszuführen.

• Sie können nicht sowohl cloud-init-API-Anweisungen (spec.cloudInit) als auch Startscripts (spec.startupScripts) im selben VirtualMachine-Manifest angeben.

Hinweis :Wenn Sie Google Distributed Cloud-Version 1.13.0 verwenden, müssen Sie die VM unter bestimmten Umständen zweimal starten, damit die Startskripts wirksam werden. Dieses Verhalten beim Starten der VM gilt nur, wenn Sie eine vorhandene VM, die keine Startskripts hat, mit Startskripts aktualisieren. Dieses Problem wurde in Google Distributed Cloud-Version 1.13.1 und höher behoben.

Skriptformate

Sie können Startskripts in den folgenden Datenformaten angeben:

• Klartext
• String mit base64-Codierung
• Kubernetes Secret

Beachten Sie die folgenden Regeln für die Arbeit mit verschiedenen Skriptformaten:

• Bei der Verwendung von Klartext oder einem base64-codierten String beträgt die maximale Größe des Script-Inhalts 2.048 Byte. Wenn die Größe des Script-Inhalts 2.048 Byte erreicht oder überschreitet, geben Sie Scripts als Kubernetes-Secret an.

• Wenn Sie ein Kubernetes-Secret verwenden, geben Sie den Inhalt des Skripts mit dem Datenschlüssel script im referenzierten Secret an.

• Wenn ein referenziertes Secret nicht gefunden wird oder der Datenschlüssel script im referenzierten Secret nicht vorhanden ist, wird das Skript auf der VM weiter ausgeführt. Die VM schreibt oder aktualisiert jedoch nicht den Skriptinhalt. In diesem Fall finden Sie das Kubernetes-Warnereignis entweder mit kubectl get event oder kubectl describe gvm.

Das folgende VirtualMachine-YAML-Beispielmanifest enthält drei Scripts, eines in jedem der unterstützten Formate. In diesem Fall wird in jedem Skript der echo hello-Befehl aus dem Beispiel in myscript1 ausgeführt.

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: "my-vm"
spec:
  ...
  startupScripts:
  - name: myscript1
    script: |
      #!/bin/bash
      echo hello
  - name: myscript2
    scriptBase64: IyEvYmluL2Jhc2gKICAgICAgZWNobyBoZWxsbwo=
  - name: myscript3
    scriptSecretRef:
      name: my-sec
---
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: my-sec
data:
  script: IyEvYmluL2Jhc2gKICAgICAgZWNobyBoZWxsbwo=

Fehlerbehebung für Skripts

Führen Sie den folgenden Befehl aus, um die Skriptergebnisse oder ‑logs zu prüfen:

journalctl -u cloud-final

Die Logeinträge des Startskripts beginnen mit dem folgenden Text:

started to run the command /var/lib/google/startup-scripts/SCRIPT_NAME ...

Der Logeintrag enthält SCRIPT_NAME, den Namen des Startskripts.