VM-Startroutinen konfigurieren

Version 1.13 

• 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.

Wenn Sie Anthos-Cluster auf Bare-Metal-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 unter anderem konfigurieren, um SSH-Schlüssel zu erstellen, Nutzer und Passwörter hinzuzufügen, Pakete zu installieren, Dateien zu schreiben und die Netzwerkeinstellungen zu konfigurieren.

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

Vorbereitung

Zum Konfigurieren einer VM mit Startanweisungen müssen Sie die folgenden Voraussetzungen erfüllen:

• Anthos-VM-Laufzeit aktivieren

• Verwenden Sie ein verifiziertes Linux-Gastbetriebssystem und setzen Sie osType im VM-Manifest auf Linux. Windows-Gastbetriebssysteme werden für diese Funktion nicht unterstützt, da sie Cloud-init nicht unterstützen.

• Das Gastbetriebssystem muss cloud-init installiert haben. Die neuesten Linux-Betriebssysteme enthalten cloud-init.

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

VMs mit cloud-init initialisieren

Cloud-init wird häufig für die Initialisierung von Cloud-Instanzen und für die individuelle Anpassung von VMs beim Start verwendet. Die VM-Initialisierung umfasst in der Regel Aufgaben wie Paketinstallationen, Repository-Einrichtung, SSH-Schlüsselerstellung, das Schreiben von Daten in Dateien und das Einrichten anderer Aspekte Ihrer VM. Sie binden die YAML-Konfiguration mit cloud-init in die benutzerdefinierte Ressource VirtualMachine mit dem Feld spec.cloudInit 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 YAML-Manifest VirtualMachine an, wenn Sie eine VM erstellen oder aktualisieren. Eine Anleitung zum Erstellen einer VM durch Anwenden eines Manifests finden Sie in der Anleitung: Linux-VM in der Anthos-VM-Laufzeit erstellen und verwalten.

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

• Sie geben Nutzerdaten und Netzwerkdaten in separaten Abschnitten im VirtualMachine-Manifest an. Die Benennung und Struktur des Bereichs hängen vom Datenformat ab, das Sie verwenden möchten.

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

  • Text entfernen
  • Base64-codierter String
  • Kubernetes Secret

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

Um Ihnen den Einstieg zu erleichtern, haben wir einige Konfigurationsbeispiele für häufige VM-Initialisierungsaufgaben zur Verfügung gestellt.

Cloud-init-Nutzerdaten

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

Hinweis: Wenn Sie Klartext oder einen base64-codierten String verwenden, sind maximal 2.048 Byte zulässig. Wenn die Größe der Nutzerdaten fast oder größer als 2.048 Byte ist, geben Sie sie als Kubernetes-Secret an.

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

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 für 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 für VirtualMachine und Secret. Der Abschnitt spec.cloudInit.noCloud.secretRef in der VirtualMachine-Konfiguration gibt an, dass sich die cloud-init-Nutzerdaten in einem Kubernetes-Secret mit dem Namen my-sec befinden. Die entsprechende Secret-Konfiguration gibt die Nutzerdaten als Schlüssel/Wert-Paar an. Der base64-codierte Wert ist in diesem Fall die cloud-init-Nutzerdaten in der cloud-config-Syntax.

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

In diesem Beispiel bestehen die Nutzerdaten aus demselben echo hello-Befehl wie im Beispiel für 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 Startverhalten der VM:

• Bei der VM-Erstellung erhält die VM den Status ErrorConfiguration mit einem detaillierten Grund und einer detaillierten Meldung.

• In anderen Fällen verwendet die VM weiterhin die alten cloud-init-Nutzerdaten, bis die VM korrekt konfiguriert ist. Daher werden Updates zum Aktivieren oder Deaktivieren von Gast-Agents erst wirksam, wenn die VM richtig konfiguriert ist.

Verwenden Sie den folgenden Befehl, um VM-Informationen abzurufen, einschließlich der Nutzerdaten, die von cloud-init verwendet wurden:

kubectl get vm VM_NAME -o yaml --kubeconfig KUBECONFIG_PATH

Dabei gilt:

• 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 entsprechende Kubernetes-Warnungsereignis abzurufen.

Cloud-init-Netzwerkdaten

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

Wenn Sie Klartext oder einen base64-codierten String verwenden, sind maximal 2.048 Byte zulässig. Wenn die Größe der Nutzerdaten fast oder größer als 2.048 Byte ist, geben Sie sie als Kubernetes-Secret an.

Weitere Informationen zur Syntax von Netzwerkdaten und den zugehörigen Details finden Sie in der Dokumentation zu cloud-init in der Netzwerkkonfiguration Version 2.

Tipp: In den folgenden Abschnitten wird veranschaulicht, wie Sie cloud-init-Netzwerkdaten in verschiedenen Formaten in der VirtualMachine-Konfiguration angeben. Die Beispielnetzwerkdaten ermöglichen DHCP für alle Ethernetgeräte mit Namen, die mit „e“ beginnen. Diese spezifische cloud-init-Anweisung zum Aktivieren von DHCP ist 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 mit Namen, die mit einem „e“ (e*) beginnen:

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 für 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 für VirtualMachine und Secret. Der Abschnitt spec.cloudInit.noCloud.networkDataSecretRef in der VirtualMachine-Konfiguration gibt an, dass sich die cloud-init-Netzwerkdaten in einem Kubernetes-Secret mit dem Namen my-sec befinden. Die entsprechende Secret-Konfiguration gibt die Netzwerkdaten als Schlüssel/Wert-Paar an. Der base64-codierte Wert ist in diesem Fall die cloud-init-Netzwerkdaten.

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

In diesem Beispiel bestehen die Netzwerkdaten aus derselben DHCP-Konfiguration, die im Beispiel für 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

Die folgenden Abschnitte enthalten Klartextbeispiele 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 Standard-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

Neue Nutzer hinzufügen

Im folgenden Beispiel für Nutzerdaten wird der Nutzer test erstellt und test vollständiger sudo-Zugriff gewährt. In diesem Beispiel wird dem Nutzer das nicht ablaufende Passwort 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 mit Nutzerdaten werden der Befehl echo und der Befehl ls ausgeführt. Sie können Befehle verwenden, um beim Start Ihrer VM Pakete 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-Skript in die Datei test im Verzeichnis /var/lib/google Ihrer VM geschrieben. Die cloud-init-Anweisungen legen die Dateiberechtigungen für den Dateieigentümer zum 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 mit 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 einer Ebene von DEBUG oder höher in dieses Log.

• /var/log/cloud-init-output.log: Standardmäßig leitet cloud-init sowohl stdout als auch ifmobile von allen cloud-init-Phasen zu diesem Log weiter.

VMs mit Startskripts initialisieren

Startskripts führen Aufgaben während des Startvorgangs einer VM-Instanz aus. Sie können im Abschnitt spec.startupScripts der Spezifikation VirtualMachine ein oder mehrere Skripts 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, das Schreiben von Daten in Dateien und das Einrichten anderer Aspekte Ihrer VM.

Beachten Sie die folgenden Details für Startskripts:

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

• Die angegebenen Skripts werden bei jedem Start der VM ausgeführt.

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

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

Hinweis: Wenn Sie Anthos-Cluster auf Bare-Metal-Version 1.13.0 verwenden, müssen Sie die VM zweimal starten, damit Startskripts unter bestimmten Umständen wirksam werden. Dieses VM-Startverhalten gilt nur, wenn Sie eine vorhandene VM ohne Startskripts entsprechend aktualisieren. Dieses Problem wurde in Anthos-Clustern mit Bare-Metal-Release 1.13.1 und höher behoben.

Skriptformate

Sie können Startskripts in den folgenden Datenformaten angeben:

• Text entfernen
• Base64-codierter String
• Kubernetes Secret

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

• Wenn Sie Klartext oder einen base64-codierten String verwenden, beträgt die maximale Größe für Skriptinhalte 2.048 Byte. Wenn der Inhalt des Skripts fast oder größer als 2.048 Byte ist, geben Sie die Skripts als Kubernetes-Secret an.

• Verwenden Sie bei Verwendung eines Kubernetes-Secrets den Datenschlüssel script im referenzierten Secret, um den Skriptinhalt anzugeben.

• Wenn ein referenziertes Secret nicht gefunden wird oder der Datenschlüssel script nicht im referenzierten Secret vorhanden ist, führt die VM das Skript weiter aus. Die Skriptinhalte werden von der VM jedoch nicht geschrieben oder aktualisiert. In diesem Fall finden Sie das Kubernetes-Warnungsereignis entweder mit kubectl get event oder mit kubectl describe gvm.

Das folgende YAML-Manifestbeispiel VirtualMachine enthält drei Skripts, eines in jedem der unterstützten Formate. In diesem Fall führt jedes Skript den echo hello-Befehl in myscript1 aus, dem Klartextbeispiel.

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=

Skriptfehler beheben

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.