Diese Seite wurde von der Cloud Translation API übersetzt.

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

Autopilot Standard

Auf dieser Seite erfahren Sie, wie Sie die Startlatenz von Arbeitslasten mithilfe von sekundären Bootlaufwerken in Google Kubernetes Engine (GKE) verbessern können, um Daten oder Container-Images auf neuen Knoten vorzuladen. So können Arbeitslasten einen schnellen Kaltstart durchführen und die bereitgestellten Ressourcen insgesamt besser nutzen.

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 Bootlaufwerken 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, vorzuladen. Die Verwendung vorgeladener 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 vorgeladene Container-Images oder Daten auf sekundären Bootlaufwerken verwenden, kann Ihre Arbeitslast schneller gestartet werden. Sekundäre Bootlaufwerke haben die folgenden Eigenschaften:

Sekundäre Bootlaufwerke sind Persistent Disks, die von verteiltem Blockspeicher unterstützt werden.
Der nichtflüchtige Speicher wird aus Laufwerk-Images instanziiert, die Sie im Voraus erstellen.
Aus Skalierbarkeitsgründen erhält jeder Knoten eine eigene Instanz des nichtflüchtigen Speichers, die aus dem Laufwerk-Image erstellt wird. Diese Persistent Disk-Instanzen werden gelöscht, wenn der Knoten gelöscht wird.
Wenn das Speicherabbild bereits in der Zone verwendet wird, ist die Erstellungszeit aller nachfolgenden Laufwerke aus demselben Speicherabbild kürzer.
Der Typ des sekundären Bootlaufwerks ist derselbe wie der des Knoten-Bootlaufwerks.
Die Größe des sekundären Bootlaufwerks wird durch die Größe des Speicherabbilds bestimmt.

Das Hinzufügen sekundärer Bootlaufwerke zu Ihren Knotenpools verlängert die Bereitstellungszeit für Knoten normalerweise nicht. GKE stellt sekundäre Bootlaufwerke parallel zur Knotenbereitstellung aus dem Speicherabbild bereit.

Best Practice:

Zur Unterstützung von vorgeladenen 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 Basisebenen werden auf das sekundäre Bootlaufwerk vorgeladen, während die kleinen oberen Ebenen aus der Containerregistrierung abgerufen werden können.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Aktivieren Sie die Google Kubernetes Engine API.

Google Kubernetes Engine API aktivieren

Wenn Sie die Google Cloud CLI für diesen Task 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 dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

Aktivieren Sie die Container File System API.

Container File System API aktivieren

Voraussetzungen

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

Auf Ihren Clustern wird GKE-Version 1.28.3-gke.1067000 in GKE Standard oder Version 1.30.1-gke.1329000 in GKE Autopilot ausgeführt.
Wenn Sie das Speicherabbild ändern, müssen Sie einen neuen Knotenpool erstellen. Das Aktualisieren des Speicherabbild auf vorhandenen Knoten wird nicht unterstützt.
Konfigurieren Sie Image-Streaming, um das sekundäre Bootlaufwerk zu verwenden.
Verwenden Sie das Container-Optimized OS mit einem containerd-Knoten-Image. Autopilot-Knoten verwenden dieses Knoten-Image standardmäßig.
Bereiten Sie das Speicherabbild mit Daten zur Laufzeit oder mit vorgeladenen 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 Speicherabbild in einer CI/CD-Pipeline.

Beschränkungen

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

Preise

Wenn Sie Knotenpools mit sekundären Bootlaufwerken erstellen, hängt GKE jedem Knoten im Knotenpool einen nichtflüchtigen Speicher an. Die Abrechnung von nichtflüchtigen Speichern erfolgt gemäß den Compute Engine-Preisen für Laufwerke.

Image des sekundären Bootlaufwerks vorbereiten

Wählen Sie zum Vorbereiten des sekundären Bootlaufwerk-Images 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 stellt das Tool gke-disk-image-builder bereit, mit dem Sie eine virtuelle Maschine (VM) erstellen können, die Container-Images auf ein Laufwerk abrufen und dann ein Laufwerk-Image von diesem Laufwerk erstellen können.

So erstellen Sie ein Speicherabbild mit mehreren vorgeladenen Container-Images:

Erstellen Sie einen Cloud Storage-Bucket zum Speichern der Ausführungslogs von gke-disk-image-builder.
Erstellen Sie ein Speicherabbild 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 Speicherabbild mit gke-disk-image-builder erstellen, erstelltGoogle Cloud mehrere Ressourcen, um den Vorgang abzuschließen (z. B. eine VM-Instanz, ein temporäres Laufwerk und einen nichtflüchtigen 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:

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 ein Speicherabbild in einem vorhandenen GKE Autopilot-Cluster zuzulassen. Anschließend ändern Sie die Pod-Knotenauswahl, um ein sekundäres Bootlaufwerk zu verwenden.

Speicherabbilder in Ihrem Projekt zulassen

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

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 Speicherabbild zu hosten.

Wenden Sie das Manifest an:
```
kubectl apply -f allowlist-disk.yaml
```
GKE erstellt Knoten mit sekundären Bootlaufwerken aus allen Speicherabbildern 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.

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: Name des Speicherabbilds.
- PROJECT_ID: Projekt-ID zum Hosten des Speicherabbilds.
Verwenden Sie den Befehl kubectl apply, um die Kubernetes-Spezifikation mit der Pod-Vorlage anzuwenden.
Prüfen Sie, ob der Cache des sekundären Bootlaufwerks verwendet wird:
```
kubectl get events --all-namespaces
```
Die Ausgabe sieht 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
```
Hinweis :Kubernetes kann Ereignisse drosseln, wenn das Volumen hoch ist. Das fehlende Ereignis ist kein eindeutiger Hinweis darauf, dass das sekundäre Bootlaufwerk nicht verwendet wurde. Der nächste Schritt ist eine zuverlässigere Methode, um zu prüfen, ob das sekundäre Bootlaufwerk verwendet wurde.
So können Sie zuverlässiger prüfen, ob der Cache des sekundären Bootlaufwerks verwendet wird:

Fragen Sie das Log vom gewünschten Knoten mit diesem Log-Namen ab:
```
logName="projects/PROJECT_ID/logs/gcfs-snapshotter"
```
Ersetzen Sie dabei PROJECT_ID durch die ID Ihres Projekts in Google Cloud .

Ein Log, das so aussieht: Image gcr.io/k8s-staging-jobsejt/pytorch-mnist:latest is backed by secondary boot disk caching by 100.0%..., weist darauf hin, dass der Cache des sekundären Bootlaufwerks verwendet wurde.

Latenz beim Abrufen von Images 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 deutlich reduziert sein.

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 vorladen möchten:

Bilder

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

gcloud

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: Die zu verwendende GKE-Version. Die GKE-Version muss 1.28.3-gke.1067000 oder höher sein.
So 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 kommagetrennten Compute-Zonen des Clusters.
- DISK_IMAGE_NAME: Name des Speicherabbilds.
Wenn Sie einen Knotenpool mit einem sekundären Bootlaufwerk aus dem Speicherabbild in einem anderen Projekt erstellen möchten, folgen Sie der Anleitung unter Sekundäres Bootlaufwerk in einem anderen Projekt verwenden.

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

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

Prüfen Sie, ob der Cache des sekundären Bootlaufwerks verwendet wird:
```
kubectl get events --all-namespaces
```
Die Ausgabe sieht 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
```
Hinweis :Kubernetes kann Ereignisse drosseln, wenn das Volumen hoch ist. Das fehlende Ereignis ist kein eindeutiger Hinweis darauf, dass das sekundäre Bootlaufwerk nicht verwendet wurde. Der nächste Schritt ist eine zuverlässigere Methode, um zu prüfen, ob das sekundäre Bootlaufwerk verwendet wurde.
So können Sie zuverlässiger prüfen, ob der Cache des sekundären Bootlaufwerks verwendet wird:

Fragen Sie das Log vom gewünschten Knoten mit diesem Log-Namen ab:
```
logName="projects/PROJECT_ID/logs/gcfs-snapshotter"
```
Ersetzen Sie dabei PROJECT_ID durch die ID Ihres Projekts in Google Cloud .

Ein Log, das so aussieht: Image gcr.io/k8s-staging-jobsejt/pytorch-mnist:latest is backed by secondary boot disk caching by 100.0%..., weist darauf hin, dass der Cache des sekundären Bootlaufwerks verwendet wurde.

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

Informationen zum Erstellen eines Clusters mit dem Standard-Knotenpool mit Terraform finden Sie im folgenden Beispiel:

resource "google_container_cluster" "default" {
  name               = "default"
  location           = "us-central1-a"
  initial_node_count = 1

  # secondary_boot_disks require GKE 1.28.3-gke.106700 or later, which should
  # be true for all release channels apart from EXTENDED.
  # If required, Use `release_channel = "EXTENDED"` and set `min_master_version`.
}

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

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

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

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

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 vorladen, indem Sie die Google Cloud CLI oder Terraform verwenden:

gcloud

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: Die zu verwendende GKE-Version. Die GKE-Version muss 1.28.3-gke.1067000 oder höher sein.
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 kommagetrennten Compute-Zonen des Clusters.
- DISK_IMAGE_NAME: Name des Speicherabbilds.
Wenn Sie einen Knotenpool mit einem sekundären Bootlaufwerk aus dem Speicherabbild 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.
Um auf die Daten zuzugreifen, stellen Sie das sekundäre Bootlaufwerk-Image mithilfe einer hostPath-Volume-Bereitstellung in den Pod-Containern bereit. Legen Sie /usr/local/data_path_sbd auf den Pfad in Ihrem Container fest, in dem sich die Daten befinden sollen:
```
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 Speicherabbilds.

Hinweis :Die sekundäre Startdisk wird von allen Containern auf demselben Knoten gemeinsam genutzt. Alle Daten, die von einem Container auf das sekundäre Bootlaufwerk geschrieben werden, sind für alle anderen Container auf dem Knoten sichtbar, die es einbinden. Um versehentliche Änderungen zu vermeiden, können Sie das Volume im schreibgeschützten Modus einbinden.

Terraform

Informationen zum Erstellen eines Clusters mit dem Standard-Knotenpool mit Terraform finden Sie im folgenden Beispiel:

resource "google_container_cluster" "default" {
  name               = "default"
  location           = "us-central1-a"
  initial_node_count = 1

  # secondary_boot_disks require GKE 1.28.3-gke.106700 or later, which should
  # be true for all release channels apart from EXTENDED.
  # If required, Use `release_channel = "EXTENDED"` and set `min_master_version`.
}

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

Um auf die Daten zuzugreifen, stellen Sie das sekundäre Bootlaufwerk-Image mithilfe einer hostPath-Volume-Bereitstellung in den Pod-Containern bereit. Legen Sie /usr/local/data_path_sbd auf den Pfad in Ihrem Container fest, in dem sich die Daten befinden sollen:

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

Cluster-Autoscaling mit sekundären Bootlaufwerken

Verwenden Sie die Google Cloud CLI, um einen Knotenpool zu erstellen und 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 kommagetrennten Compute-Zonen des Clusters.
DISK_IMAGE_NAME: Name des Speicherabbilds.
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 und so die Ressourcenanforderungen Ihrer Arbeitslasten zu erfüllen.

Erstellen Sie eine benutzerdefinierte Ressource für die Zulassungsliste für Speicherabbilder für das sekundäre Bootlaufwerk für die automatische Knotenbereitstellung in GKE, ähnlich der folgenden:
```
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 Speicherabbild zu hosten.
Führen Sie den folgenden Befehl aus, um die benutzerdefinierte Ressource für die Zulassungsliste im Cluster bereitzustellen:
```
kubectl apply -f ALLOWLIST_FILE
```
Ersetzen Sie ALLOWLIST_FILE durch den Namen der Manifestdatei.
Aktualisieren Sie den Knotenselektor des Pods, um das sekundäre Bootlaufwerk zu verwenden:
```
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: Name des Speicherabbilds.
- PROJECT_ID: Projekt-ID zum Hosten des Speicherabbilds.

Sekundäres Bootlaufwerk in einem anderen Projekt verwenden

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

Erstellen Sie mit dem --secondary-boot-disk-Flag einen Knotenpool mit einem sekundären Bootlaufwerk aus dem Speicherabbild in einem anderen Projekt. Beispiele:
```
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: Name des Speicherabbilds.
- IMAGE_PROJECT_ID: der Name des Projekts, zu dem das Speicherabbild 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.

Gewähren Sie Zugriff auf Speicherabbilder, die zu einem anderen Projekt gehören, indem Sie die Rollen „Compute-Image-Nutzer“ für die Clusterdienstkonten hinzufügen:

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

Verwenden Sie Image-Streaming, um Container-Images abzurufen, um Container-Images abzurufen. Streamen Sie dazu die Image-Daten je nachdem, was Ihre Arbeitslasten brauchen.
Unter Arbeitslasteffizienz mit NCCL Fast Socket verbessern erfahren Sie, wie Sie das NVIDIA Collective Communication Library (NCCL) Fast Socket-Plug-in verwenden können.

Sekundäre Bootlaufwerke zum Vorabladen von Daten oder Container-Images verwenden Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Übersicht

Funktionsweise sekundärer Bootlaufwerke

Hinweise

Voraussetzungen

Beschränkungen

Preise

Image des sekundären Bootlaufwerks vorbereiten

Bilder

Daten

Sekundäres Bootlaufwerk konfigurieren

GKE Autopilot verwenden

Speicherabbilder in Ihrem Projekt zulassen

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

GKE Standard verwenden

Bilder

gcloud

Terraform

Daten

gcloud

Terraform

Cluster-Autoscaling mit sekundären Bootlaufwerken

Automatische Knotenbereitstellung mit sekundären Bootlaufwerken

Sekundäres Bootlaufwerk in einem anderen Projekt verwenden

Nächste Schritte

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