Sekundäre Bootlaufwerke zum Vorabladen von Daten oder Container-Images verwenden

Auf dieser Seite erfahren Sie, wie Sie die Latenz beim Starten von Arbeitslasten verbessern, indem Sie mithilfe sekundärer Bootlaufwerke in der Google Kubernetes Engine (GKE) Daten oder Container-Images auf neuen Knoten vorladen. So können Arbeitslasten schnell gestartet und die Gesamtnutzung der bereitgestellten Ressourcen verbessert werden.

Machen Sie sich vor dem Lesen dieser Seite mit Google Cloud, Kubernetes, Containern, YAML, der containerd-Laufzeit und der Google Cloud CLI vertraut.

Übersicht

Ab GKE-Version 1.28.3-gke.1067000 in Standardclustern und GKE-Version 1.30.1-gke.1329000 in Autopilot-Clustern können Sie den Knotenpool mit sekundären Boot-Laufwerken konfigurieren. Sie können GKE anweisen, die Knoten bereitzustellen und mit Daten, z. B. einem Modell für maschinelles Lernen (ML) oder einem Container-Image, vorab zu laden. Die Verwendung von vorab geladenen Container-Images oder Daten auf einem sekundären Laufwerk bietet folgende Vorteile für Ihre Arbeitslasten:

  • Geringere Latenzzeit beim Abrufen großer Container-Images oder beim Herunterladen von Daten
  • Schnelleres Autoscaling
  • Schnellere Wiederherstellung nach Störungen wie Wartungsereignissen und Systemfehlern

In den folgenden Abschnitten wird beschrieben, wie Sie das sekundäre Bootlaufwerk in GKE Autopilot- und Standardclustern konfigurieren.

Funktionsweise sekundärer Bootlaufwerke

Wenn Sie das vorab geladene Container-Image oder die Daten auf sekundären Bootlaufwerken verwenden, kann Ihre Arbeitslast schneller gestartet werden. Sekundäre Bootlaufwerke haben folgende Eigenschaften:

  • Sekundäre Bootlaufwerke sind Persistent Disks, die von verteiltem Blockspeicher unterstützt werden. Wenn das Laufwerk-Image bereits in der Zone verwendet wird, ist die Erstellungszeit aller nachfolgenden Laufwerke aus demselben Laufwerk-Image kürzer.
  • Der Typ des sekundären Bootlaufwerks ist mit dem des Knoten-Bootlaufwerks identisch.
  • Die Größe des sekundären Bootlaufwerks wird durch die Größe des Laufwerk-Images bestimmt.

Wenn Sie Ihren Knotenpools sekundäre Bootlaufwerke hinzufügen, verlängert sich die Bereitstellungszeit der Knoten nicht. GKE stellt sekundäre Bootlaufwerke parallel zur Knotenbereitstellung aus einem Laufwerk-Image bereit.

Best Practice:

Zur Unterstützung von vorab geladenen Container-Images erweitert GKE die containerd-Laufzeit um Plug-ins, die die Container-Images von sekundären Bootlaufwerken lesen. Container-Images werden von den Basisebenen wiederverwendet.

Große Basisschichten werden auf das sekundäre Bootlaufwerk vorgeladen, während die kleinen oberen Schichten aus der Containerregistrierung abgerufen werden können.

Hinweise

Führen Sie die folgenden Schritte durch, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

Voraussetzungen

Für die Verwendung des sekundären Bootlaufwerks gelten die folgenden Anforderungen:

  1. Auf Ihren Clustern wird die GKE-Version 1.28.3-gke.1067000 in GKE Standard oder die Version 1.30.1-gke.1329000 in GKE Autopilot ausgeführt.
  2. Wenn Sie das Speicherabbild ändern, müssen Sie einen neuen Knotenpool erstellen. Das Aktualisieren des Speicherabbild auf vorhandenen Knoten wird nicht unterstützt.
  3. Konfigurieren Sie das Image-Streaming, um die Funktion für das sekundäre Bootlaufwerk zu verwenden.
  4. Verwenden Sie das Container-optimierte Betriebssystem mit einem containerd-Knoten-Image. Autopilot-Knoten verwenden dieses Knoten-Image standardmäßig.

  5. Bereiten Sie das Laufwerk-Image mit Daten zur Laufzeit oder mit vorab geladenen Container-Images vor. Achten Sie darauf, dass Ihr Cluster Zugriff auf das Speicherabbild hat, das in die Knoten geladen werden soll.

    Best Practice:

    Automatisieren Sie das Laufwerk-Image in einer CI/CD-Pipeline.

Beschränkungen

Für sekundäre Bootlaufwerke gelten die folgenden Einschränkungen:

  • Sekundäre Bootlaufwerke für vorhandene Knoten können nicht aktualisiert werden. Wenn Sie ein neues Speicherabbild anhängen möchten, erstellen Sie einen neuen Knotenpool.

Sekundäres Bootlaufwerk vorbereiten

Wählen Sie zum Vorbereiten des sekundären Bootlaufwerks entweder den Tab Images zum Vorabladen von Container-Images oder den Tab Daten zum Vorabladen von Daten aus und führen Sie dann die folgenden Schritte aus:

Bilder

GKE bietet das Tool gke-disk-image-builder, mit dem Sie eine virtuelle Maschine (VM) erstellen, die Container-Images auf ein Laufwerk abrufen und dann ein Laufwerk-Image von diesem Laufwerk erstellen können.

So erstellen Sie ein Laufwerk-Image mit mehreren vorab geladenen Container-Images:

  1. Erstellen Sie einen Cloud Storage-Bucket zum Speichern der Ausführungslogs von gke-disk-image-builder.
  2. Erstellen Sie ein Laufwerk-Image mit gke-disk-image-builder.
go run ./cli \
    --project-name=PROJECT_ID \
    --image-name=DISK_IMAGE_NAME \
    --zone=LOCATION \
    --gcs-path=gs://LOG_BUCKET_NAME \
    --disk-size-gb=10 \
    --container-image=docker.io/library/python:latest \
    --container-image=docker.io/library/nginx:latest

Ersetzen Sie Folgendes:

  • PROJECT_ID: Der Name Ihres Google Cloud-Projekts.
  • DISK_IMAGE_NAME: Der Name des Images des Laufwerks. Beispiel: nginx-python-image
  • LOCATION: Der Clusterstandort.
  • LOG_BUCKET_NAME: Der Name des Cloud Storage-Buckets zum Speichern der Ausführungslogs. Zum Beispiel gke-secondary-disk-image-logs/.

Wenn Sie ein Laufwerk-Image mit gke-disk-image-builder erstellen, erstellt Google Cloud mehrere Ressourcen, um den Vorgang abzuschließen (z. B. eine VM-Instanz, ein temporäres Laufwerk und ein nichtflüchtiger Speicher). Nach der Ausführung bereinigt der Image Builder alle Ressourcen mit Ausnahme des von Ihnen erstellten Speicherabbild.

Daten

Erstellen Sie ein benutzerdefiniertes Speicherabbild als Datenquelle. Gehen Sie dazu so vor:

  1. VM mit einem leeren Laufwerk erstellen
  2. Stellen Sie über SSH eine Verbindung zu der VM her.
    1. Stellen Sie das leere Laufwerk bereit.
    2. Laden Sie die Daten auf ein leeres Laufwerk herunter.
  3. Erstellen Sie ein benutzerdefiniertes Image von der VM.

Sekundäres Bootlaufwerk konfigurieren

Sie können das sekundäre Bootlaufwerk in einem GKE Autopilot- oder Standardcluster konfigurieren.

Best Practices:

Verwenden Sie einen Autopilot-Cluster für eine vollständig verwaltete Kubernetes-Umgebung. Informationen zum Auswählen des GKE-Betriebsmodus, der für Ihre Arbeitslasten am besten geeignet ist, finden Sie unter GKE-Betriebsmodus auswählen.

GKE Autopilot verwenden

In diesem Abschnitt erstellen Sie eine Zulassungsliste für Speicherabbilder, um das Speicherabbild in einem vorhandenen GKE Autopilot-Cluster zuzulassen. Anschließend ändern Sie die Pod-Knotenauswahl so, dass ein sekundäres Bootlaufwerk verwendet wird.

Laufwerk-Images in Ihrem Projekt zulassen

In diesem Abschnitt erstellen Sie eine GCPResourceAllowlist, damit GKE Knoten mit sekundären Bootlaufwerken aus den Laufwerk-Images in Ihrem Google Cloud-Projekt erstellen kann.

  1. Speichern Sie das folgende Manifest als allowlist-disk.yaml:

    apiVersion: "node.gke.io/v1"
kind: GCPResourceAllowlist
metadata:
  name: gke-secondary-boot-disk-allowlist
spec:
  allowedResourcePatterns:
  - "projects/PROJECT_ID/global/images/.*"

    Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID, um das Laufwerk-Image zu hosten.

  2. Wenden Sie das Manifest an:

    kubectl apply -f allowlist-disk.yaml

    GKE erstellt Knoten mit sekundären Bootlaufwerken aus allen Laufwerk-Images im Projekt.

Pod-Knotenauswahl für die Verwendung eines sekundären Bootlaufwerks aktualisieren

In diesem Abschnitt ändern Sie die Pod-Spezifikation so, dass GKE die Knoten mit dem sekundären Bootlaufwerk erstellt.

  1. Fügen Sie der Pod-Vorlage einen nodeSelector hinzu:

    nodeSelector:
    cloud.google.com.node-restriction.kubernetes.io/gke-secondary-boot-disk-DISK_IMAGE_NAME=CONTAINER_IMAGE_CACHE.PROJECT_ID

    Ersetzen Sie Folgendes:

    • DISK_IMAGE_NAME: der Name des Laufwerk-Images.
    • PROJECT_ID: Ihre Projekt-ID zum Hosten des Laufwerk-Images.

  2. Verwenden Sie den Befehl kubectl apply, um die Kubernetes-Spezifikation mit der Pod-Vorlage anzuwenden.

  3. Prüfen Sie, ob der Cache des sekundären Bootlaufwerks verwendet wird:

    kubectl get events --all-namespaces

    Die Ausgabe sieht in etwa so aus:

    75s         Normal      SecondaryDiskCachin
node/gke-pd-cache-demo-default-pool-75e78709-zjfm   Image
gcr.io/k8s-staging-jobsejt/pytorch-mnist:latest is backed by secondary disk cache

  4. Prüfen Sie die Latenz beim Abrufen des Images:

    kubectl describe pod POD_NAME

    Ersetzen Sie POD_NAME durch den Namen des Pods.

    Die Ausgabe sieht in etwa so aus:

    …
  Normal  Pulled     15m   kubelet            Successfully pulled image "docker.io/library/nginx:latest" in 0.879149587s
…

Die erwartete Image-Pull-Latenz für das im Cache gespeicherte Container-Image sollte unabhängig von der Image-Größe deutlich reduziert werden.

GKE Standard verwenden

Folgen Sie der Anleitung unten, um einen GKE-Standardcluster und einen Knotenpool zu erstellen. Wählen Sie den Tab „Images“ oder „Daten“ aus, je nachdem, ob Sie Container-Images oder Daten auf das sekundäre Bootlaufwerk vorab laden möchten:

Bilder

Sie können ein sekundäres Bootlaufwerk mit der Google Cloud CLI oder Terraform konfigurieren:

gcloud

  1. Erstellen Sie einen GKE Standard-Cluster mit aktiviertem Image-Streaming:

    gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --cluster-version=VERSION \
    --enable-image-streaming

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • LOCATION: Der Clusterstandort.
    • VERSION ist die zu verwendende GKE-Version. Die GKE-Version muss 1.28.3-gke.1067000 oder höher sein.

  2. Erstellen Sie einen Knotenpool mit einem sekundären Bootlaufwerk im selben Projekt:

    gcloud container node-pools create NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--location LOCATION \
--enable-image-streaming \
--secondary-boot-disk=disk-image=global/images/DISK_IMAGE_NAME,mode=CONTAINER_IMAGE_CACHE

    Ersetzen Sie Folgendes:

    • NODE_POOL_NAME ist der Name des Knotenpools.
    • CLUSTER_NAME den Namen des vorhandenen Clusters.
    • LOCATION: die durch Komma getrennten Compute-Zonen des Clusters.
    • DISK_IMAGE_NAME: der Name des Laufwerk-Images.

    Wenn Sie einen Knotenpool mit einem sekundären Bootlaufwerk aus dem Laufwerk-Image in einem anderen Projekt erstellen möchten, folgen Sie der Anleitung unter Sekundäres Bootlaufwerk in einem anderen Projekt verwenden.

  3. Fügen Sie der Pod-Vorlage einen nodeSelector hinzu:

    nodeSelector:
    cloud.google.com/gke-nodepool: NODE_POOL_NAME

  4. Prüfen Sie, ob der Cache des sekundären Bootlaufwerks verwendet wird:

    kubectl get events --all-namespaces

    Die Ausgabe sieht in etwa so aus:

    75s       Normal      SecondaryDiskCachin
node/gke-pd-cache-demo-default-pool-75e78709-zjfm Image
gcr.io/k8s-staging-jobsejt/pytorch-mnist:latest is backed by secondary disk cache

  5. Mit dem folgenden Befehl können Sie die Image-Pull-Latenz prüfen:

    kubectl describe pod POD_NAME

    Ersetzen Sie POD_NAME durch den Namen des Pods.

    Die Ausgabe sieht in etwa so aus:

    …
  Normal  Pulled     15m   kubelet            Successfully pulled image "docker.io/library/nginx:latest" in 0.879149587s
…

Die erwartete Image-Pull-Latenz für das im Cache gespeicherte Container-Image sollte unabhängig von der Image-Größe nicht mehr als einige Sekunden betragen.

Terraform

  1. Informationen zum Erstellen eines Clusters mit dem Standardknotenpool mit Terraform finden Sie im folgenden Beispiel:

    resource "google_container_cluster" "default" {
  name               = "default"
  location           = "us-central1-a"
  initial_node_count = 1
  # Set `min_master_version` because secondary_boot_disks require GKE 1.28.3-gke.106700 or later.
  min_master_version = "1.28"
  # Setting `deletion_protection` to `true` would prevent
  # accidental deletion of this instance using Terraform.
  deletion_protection = false
}

  2. Erstellen Sie einen Knotenpool mit einem sekundären Bootlaufwerk im selben Projekt:

    resource "google_container_node_pool" "secondary-boot-disk-container" {
  name               = "secondary-boot-disk-container"
  location           = "us-central1-a"
  cluster            = google_container_cluster.default.name
  initial_node_count = 1

  node_config {
    machine_type = "e2-medium"
    image_type   = "COS_CONTAINERD"
    gcfs_config {
      enabled = true
    }
    secondary_boot_disks {
      disk_image = ""
      mode       = "CONTAINER_IMAGE_CACHE"
    }
  }
}

    Weitere Informationen zur Verwendung von Terraform finden Sie unter Terraform-Unterstützung für GKE.

  3. Fügen Sie der Pod-Vorlage einen nodeSelector hinzu:

    nodeSelector:
    cloud.google.com/gke-nodepool: NODE_POOL_NAME

  4. Prüfen Sie, ob der Cache des sekundären Bootlaufwerks verwendet wird:

    kubectl get events --all-namespaces

    Die Ausgabe sieht in etwa so aus:

    75s       Normal      SecondaryDiskCachin
node/gke-pd-cache-demo-default-pool-75e78709-zjfm Image
gcr.io/k8s-staging-jobsejt/pytorch-mnist:latest is backed by secondary disk cache

  5. Mit dem folgenden Befehl können Sie die Image-Pull-Latenz prüfen:

    kubectl describe pod POD_NAME

    Ersetzen Sie POD_NAME durch den Namen des Pods.

    Die Ausgabe sieht in etwa so aus:

    …
  Normal  Pulled     15m   kubelet            Successfully pulled image "docker.io/library/nginx:latest" in 0.879149587s
…

Die erwartete Image-Pull-Latenz für das im Cache gespeicherte Container-Image sollte unabhängig von der Image-Größe nicht mehr als einige Sekunden betragen.

Weitere Informationen zur Verwendung von Terraform finden Sie unter Terraform-Unterstützung für GKE.

Daten

Sie können ein sekundäres Bootlaufwerk konfigurieren und Daten vorab laden, indem Sie die Google Cloud CLI oder Terraform verwenden:

gcloud

  1. Erstellen Sie einen GKE Standard-Cluster mit aktiviertem Image-Streaming:

    gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --cluster-version=VERSION \
    --enable-image-streaming

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • LOCATION: Der Clusterstandort.
    • VERSION ist die zu verwendende GKE-Version. Die GKE-Version muss 1.28.3-gke.1067000 oder höher sein.

  2. Erstellen Sie mit dem --secondary-boot-disk-Flag einen Knotenpool mit einem sekundären Bootlaufwerk:

    gcloud container node-pools create NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--location LOCATION \
--enable-image-streaming \
--secondary-boot-disk=disk-image=global/images/DISK_IMAGE_NAME

    Ersetzen Sie Folgendes:

    • NODE_POOL_NAME ist der Name des Knotenpools.
    • CLUSTER_NAME den Namen des vorhandenen Clusters.
    • LOCATION: die durch Komma getrennten Compute-Zonen des Clusters.
    • DISK_IMAGE_NAME: der Name des Laufwerk-Images.

    Wenn Sie einen Knotenpool mit einem sekundären Bootlaufwerk aus dem Laufwerk-Image in einem anderen Projekt erstellen möchten, folgen Sie der Anleitung unter Sekundäres Bootlaufwerk in einem anderen Projekt verwenden.

    GKE erstellt einen Knotenpool, in dem jeder Knoten ein sekundäres Laufwerk mit vorab geladenen Daten hat. GKE hängt das sekundäre Bootlaufwerk an den Knoten an und stellt es bereit.

  3. Optional können Sie das sekundäre Speicherabbild mithilfe einer hostPath-Volume-Bereitstellung in den Pod-Containern bereitstellen. Verwenden Sie das folgende Manifest, um eine Pod-Ressourcen zu definieren, und verwenden Sie eine hostPath-Volume-Bereitstellung, um das Datenlaufwerk vorab in die Container zu laden:

    apiVersion: v1
kind: Pod
metadata:
  name: pod-name
spec:
  containers:
  ...
  volumeMounts:
  - mountPath: /usr/local/data_path_sbd
    name: data_path_sbd
...
volumes:
  - name: data_path_sbd
    hostPath:
        path: /mnt/disks/gke-secondary-disks/gke-DISK_IMAGE_NAME-disk

    Ersetzen Sie DISK_IMAGE_NAME durch den Namen Ihres Laufwerk-Images.

Terraform

  1. Informationen zum Erstellen eines Clusters mit dem Standardknotenpool mit Terraform finden Sie im folgenden Beispiel:

    resource "google_container_cluster" "default" {
  name               = "default"
  location           = "us-central1-a"
  initial_node_count = 1
  # Set `min_master_version` because secondary_boot_disks require GKE 1.28.3-gke.106700 or later.
  min_master_version = "1.28"
  # Setting `deletion_protection` to `true` would prevent
  # accidental deletion of this instance using Terraform.
  deletion_protection = false
}

  2. Erstellen Sie einen Knotenpool mit einem sekundären Bootlaufwerk im selben Projekt:

    resource "google_container_node_pool" "secondary-boot-disk-data" {
  name               = "secondary-boot-disk-data"
  location           = "us-central1-a"
  cluster            = google_container_cluster.default.name
  initial_node_count = 1

  node_config {
    machine_type = "e2-medium"
    image_type   = "COS_CONTAINERD"
    gcfs_config {
      enabled = true
    }
    secondary_boot_disks {
      disk_image = ""
    }
  }
}

    Weitere Informationen zur Verwendung von Terraform finden Sie unter Terraform-Unterstützung für GKE.

  3. Optional können Sie das sekundäre Speicherabbild mithilfe einer hostPath-Volume-Bereitstellung in den Pod-Containern bereitstellen. Verwenden Sie das folgende Manifest, um eine Pod-Ressourcen zu definieren, und verwenden Sie eine hostPath-Volume-Bereitstellung, um das Datenlaufwerk vorab in die Container zu laden:

    apiVersion: v1
kind: Pod
metadata:
  name: pod-name
spec:
  containers:
  ...
  volumeMounts:
  - mountPath: /usr/local/data_path_sbd
    name: data_path_sbd
...
volumes:
  - name: data_path_sbd
    hostPath:
        path: /mnt/disks/gke-secondary-disks/gke-DISK_IMAGE_NAME-disk

    Ersetzen Sie DISK_IMAGE_NAME durch den Namen Ihres Laufwerk-Images.

Cluster-Autoscaling mit sekundären Bootlaufwerken

Verwenden Sie die Google Cloud CLI, um einen Knotenpool zu erstellen und die Cluster-Autoscaling auf einem sekundären Bootlaufwerk zu konfigurieren:

  gcloud container node-pools create NODE_POOL_NAME \
      --cluster=CLUSTER_NAME \
      --location LOCATION \
      --enable-image-streaming \
      --secondary-boot-disk=disk-image=global/images/DISK_IMAGE_NAME,mode=CONTAINER_IMAGE_CACHE \
      --enable-autoscaling \
      --num-nodes NUM_NODES \
      --min-nodes MIN_NODES \
      --max-nodes MAX_NODES

Ersetzen Sie Folgendes:

  • NODE_POOL_NAME ist der Name des Knotenpools.
  • CLUSTER_NAME den Namen des vorhandenen Clusters.
  • LOCATION: die durch Komma getrennten Compute-Zonen des Clusters.
  • DISK_IMAGE_NAME: der Name des Laufwerk-Images.
  • MIN_NODES: Die Mindestanzahl der Knoten, die automatisch für den angegebenen Knotenpool pro Zone skaliert werden sollen. Verwenden Sie --total-min-nodes, um die Mindestanzahl der Knoten für den gesamten Knotenpool in GKE-Version 1.24 und höher anzugeben. Die Flags --total-min-nodes und --total-max-nodes einerseits und die Flags --min-nodes und --max-nodes andererseits schließen sich gegenseitig aus.
  • MAX_NODES: Die maximale Anzahl der Knoten, die automatisch für den angegebenen Knotenpool pro Zone skaliert werden sollen. Verwenden Sie --total-max-nodes, um die maximale Anzahl der Knoten für den gesamten Knotenpool in GKE-Version 1.24 und höher anzugeben. Die Flags --total-min-nodes und --total-max-nodes einerseits und die Flags --min-nodes und --max-nodes andererseits schließen sich gegenseitig aus.

Automatische Knotenbereitstellung mit sekundären Bootlaufwerken

In GKE 1.30.1-gke.1329000 und höher können Sie die automatische Knotenbereitstellung konfigurieren, um Knotenpools automatisch zu erstellen und zu löschen, um die Ressourcenanforderungen Ihrer Arbeitslasten zu erfüllen.

  1. Erstellen Sie eine benutzerdefinierte Ressource für die Zulassungsliste von Speicherabbildern für das sekundäre Bootlaufwerk für die automatische Bereitstellung von GKE-Knoten. Sie sollte in etwa so aussehen:

    apiVersion: "node.gke.io/v1"
kind: GCPResourceAllowlist
metadata:
  name: gke-secondary-boot-disk-allowlist
spec:
  allowedResourcePatterns:
  - "projects/<PROJECT_ID>/global/images/.*"

    Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID, um das Laufwerk-Image zu hosten.

  2. Führen Sie den folgenden Befehl aus, um die benutzerdefinierte Zulassungsliste im Cluster bereitzustellen:

    kubectl apply -f ALLOWLIST_FILE

    Ersetzen Sie ALLOWLIST_FILE durch den Dateinamen des Manifests.

  3. Aktualisieren Sie die Pod-Knotenselektoren, damit das sekundäre Bootlaufwerk verwendet wird:

    nodeSelector:
    cloud.google.com.node-restriction.kubernetes.io/gke-secondary-boot-disk-DISK_IMAGE_NAME=CONTAINER_IMAGE_CACHE.PROJECT_ID

    Ersetzen Sie Folgendes:

    • DISK_IMAGE_NAME: der Name des Laufwerk-Images.
    • PROJECT_ID: Ihre Projekt-ID zum Hosten des Laufwerk-Images.

Sekundäres Bootlaufwerk in einem anderen Projekt verwenden

Wenn Sie einen Knotenpool mit einem sekundären Bootlaufwerk erstellen, können Sie GKE mit dem Flag --secondary-boot-disk anweisen, das Laufwerk-Image in einem anderen Projekt zu verwenden.

  1. Erstellen Sie mit dem --secondary-boot-disk-Flag einen Knotenpool mit einem sekundären Bootlaufwerk aus dem Laufwerk-Image in einem anderen Projekt. Beispiel:

    gcloud beta container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location LOCATION \
    --enable-image-streaming \
    --secondary-boot-disk=disk-image=projects/IMAGE_PROJECT_ID/global/images/DISK_IMAGE_NAME,mode=CONTAINER_IMAGE_CACHE

    Ersetzen Sie Folgendes:

    • DISK_IMAGE_NAME: der Name des Laufwerk-Images.
    • IMAGE_PROJECT_ID ist der Name des Projekts, zu dem das Laufwerk-Image gehört.

    GKE erstellt einen Knotenpool, in dem jeder Knoten ein sekundäres Laufwerk mit vorab geladenen Daten hat. GKE hängt das sekundäre Bootlaufwerk an den Knoten und stellt es bereit.

  2. Gewähren Sie Zugriff auf Speicherabbilder, die zu einem anderen Projekt gehören, indem Sie den Clusterdienstkonten die Rolle „Compute-Image-Nutzer“ zuweisen:

    • Compute-Standarddienstkonto: CLUSTER_PROJECT_NUMBER@cloudservices.gserviceaccount.com
    • GKE-Dienstkonto: service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
    gcloud projects add-iam-policy-binding IMAGE_PROJECT_ID \
    --member serviceAccount:CLUSTER_PROJECT_NUMBER@cloudservices.gserviceaccount.com \
    --role roles/compute.imageUser

gcloud projects add-iam-policy-binding IMAGE_PROJECT_ID \
    --member serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role roles/compute.imageUser

Nächste Schritte