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

Standard

---

Vorschau

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

Auf dieser Seite erfahren Sie, wie Sie die Startlatenz von Arbeitslasten mithilfe von sekundären Bootlaufwerken in Google Kubernetes Engine (GKE) verbessern. Mit sekundären Bootlaufwerken können Sie Daten oder Container-Images auf neuen Knoten vorab laden. Dadurch können Arbeitslasten einen schnellen Kaltstart erreichen und die Gesamtnutzung der bereitgestellten Ressourcen verbessern.

Überblick

Ab Version 1.28.3-gke.1067000 können Sie den Knotenpool mit sekundären Bootlaufwerken konfigurieren. Sie können GKE anweisen, die Knoten bereitzustellen und mit Daten wie einem Modell für maschinelles Lernen oder einem Container-Image vorab zu laden. Die Verwendung von vorab geladenen Daten oder eines Container-Images auf einem sekundären Laufwerk bietet folgende Vorteile für Ihre Arbeitslasten:

• Schnelleres Autoscaling
• Geringere Latenzzeit beim Abrufen großer Images
• Schnellere Wiederherstellung nach Störungen wie Wartungsereignissen und Systemfehlern

Hinweis: Das Container-Image wird für alle Basisebenen wiederverwendet. Es wird empfohlen, große Basiscontainer vorab in das sekundäre Bootlaufwerk zu laden. Kleine obere Ebenen können weiterhin aus der Container Registry abgerufen werden.

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 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.
  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

• Aktivieren Sie die Container File System API.

  Container File System API aktivieren

• Achten Sie darauf, dass Ihr Cluster Zugriff auf das Speicherabbild hat, das in die Knoten geladen werden soll.

Voraussetzungen

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

1. Das Feature ist in der GKE-Version 1.28.3-gke.106700 und höher verfügbar.

2. Wenn Sie das Speicherabbild ändern, müssen Sie einen neuen Knotenpool erstellen. Sie können das Laufwerk-Image auf vorhandenen Knoten nicht aktualisieren.

3. Sie müssen das Image-Streaming für das Feature des sekundären Bootlaufwerks konfigurieren.

Sekundäres Bootlaufwerk konfigurieren

In den folgenden Abschnitten wird beschrieben, wie Sie das sekundäre Bootlaufwerk konfigurieren:

• Daten vorab laden
• Container-Image vorab laden

Daten vorab laden

Bevor Sie den GKE-Cluster und den Knotenpool mit einem sekundären Bootlaufwerk erstellen, empfehlen wir, das Speicherabbild vorzubereiten, wenn die Daten während der Erstellung bereit sind, idealerweise in einer CI/CD-Pipeline.

Speicherabbild vorbereiten, das die Daten enthält

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

1. VM mit einem leeren Laufwerk erstellen
2. Stellen Sie eine SSH-Verbindung zur 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.

GKE-Cluster erstellen

• Erstellen Sie mit dem Flag --enable-image-streaming einen GKE Standard-Cluster mit aktiviertem Image-Streaming:

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

  Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name Ihres Clusters.
  • LOCATION: Der Clusterstandort.
  • CLUSTER-VERSION ist die zu verwendende GKE-Version. Muss 1.28.3-gke.106700 oder höher sein.

Erstellen Sie einen Knotenpool mit einem sekundären Bootlaufwerk:

Sie können dem Knotenpool ein sekundäres Bootlaufwerk zuweisen. Das sekundäre Image kann zu Folgendem gehören:

• Erstellen Sie mit dem Flag --secondary-boot-disk=disk-image einen Knotenpool mit einem sekundären Bootlaufwerk im selben Projekt. Beispiel:

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

  Ersetzen Sie DISK_IMAGE_NAME durch den Namen Ihres Laufwerk-Images.

  GKE erstellt einen Knotenpool, in dem jeder Knoten ein sekundäres Laufwerk mit vorab geladenen Container-Images hat. Dadurch wird das sekundäre Bootlaufwerk an den Knoten angehängt und bereitgestellt.

• Erstellen Sie mit dem Flag --secondary-boot-disk 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
  
  

  Ersetzen Sie Folgendes:

  • DISK_IMAGE_NAME ist 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. Dadurch wird das sekundäre Bootlaufwerk an den Knoten angehängt und bereitgestellt.

  Um Zugriff auf Laufwerk-Images eines anderen Projekts zu gewähren, müssen Sie den Cluster-Dienstkonten die Rolle "Compute Image-Nutzer" hinzufügen:

  • Compute-Standarddienstkonto: [e-mail]
  • GKE-Dienstkonto: [e-mail]

  gcloud projects add-iam-policy-binding IMAGE_PROJECT_ID \
      --member serviceAccount:[e-mail] \
      --role roles/compute.imageUser
  
  gcloud projects add-iam-policy-binding IMAGE_PROJECT_ID \
      --member serviceAccount:[e-mail] \
      --role roles/compute.imageUser
  

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

Container-Image vorab laden

In dieser Anleitung verwenden Sie gke-disk-image-builder, um eine VM-Instanz zu erstellen und die Container-Images auf ein Laufwerk abzurufen. Die gke-disk-image-builder erstellt ein Laufwerk-Image von diesem Laufwerk. Wir empfehlen, das Laufwerk-Image direkt nach dem Build-Schritt des Container-Images vorzubereiten, idealerweise in einer CI/CD-Pipeline.

1. Erstellen Sie einen Cloud Storage-Bucket zum Speichern der Ausführungslogs von gke-disk-image-builder.

2. Erstellen Sie ein Laufwerk-Image mit vorinstallierten Container-Images.

   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 ist 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. Beispiel: gke-secondary-disk-image-logs/.

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

GKE-Cluster erstellen

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

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

Erstellen Sie einen Knotenpool mit einem sekundären Bootlaufwerk:

• Erstellen Sie mit dem Flag --secondary-boot-disk einen Knotenpool mit einem sekundären Bootlaufwerk im selben Projekt. Beispiel:

  gcloud beta 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 DISK_IMAGE_NAME durch den Namen Ihres Laufwerk-Images.

• Erstellen Sie mit dem Flag --secondary-boot-disk 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 ist 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. Dadurch wird das sekundäre Bootlaufwerk an den Knoten angehängt und bereitgestellt.

  Um Zugriff auf Laufwerk-Images eines anderen Projekts zu gewähren, müssen Sie den Cluster-Dienstkonten die Rolle "Compute Image-Nutzer" hinzufügen:

  • Compute-Standarddienstkonto: [e-mail]
  • GKE-Dienstkonto: [e-mail]

  gcloud projects add-iam-policy-binding IMAGE_PROJECT_ID \
      --member serviceAccount:[e-mail] \
      --role roles/compute.imageUser
  
  gcloud projects add-iam-policy-binding IMAGE_PROJECT_ID \
      --member serviceAccount:[e-mail] \
      --role roles/compute.imageUser
  

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

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

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

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

Nächste Schritte

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