Dedizierte nichtflüchtige Speicher als sitzungsspezifische Volumes verwenden

Auf dieser Seite wird gezeigt, wie Sie externe Speicherhardware wie nichtflüchtige Compute Engine-Speicher als sitzungsspezifische Volumes in Ihren GKE-Arbeitslasten (Google Kubernetes Engine) verwenden. Sie sollten mit den Volumes und StorageClasses von Kubernetes vertraut sein.

Wann sitzungsspezifischer Speicher in Kubernetes verwendet werden sollte

Sitzungsspezifischer Speicher ist immer dann nützlich, wenn Ihre Arbeitslasten die Daten nur während des Lebenszyklus der Anwendung benötigen, z. B. für Datenverarbeitungspipelines, Jobs für maschinelles Lernen, Batchverarbeitung, lokales Caching oder Analysen. Standardmäßig ist ein Teil des GKE-Knoten-Bootlaufwerks als sitzungsspezifischer Speicher in Ihren Pods verfügbar. Dieser Ansatz erfordert oft eine sorgfältige Speicherplatzplanung.

Mit generischen sitzungsspezifischen Volumes von Kubernetes können Sie mithilfe von PersistentVolumeClaims explizit sitzungsspezifischen Speicher für Ihre Pods anfordern. GKE stellt nichtflüchtige Speicher von Compute Engine dynamisch bereit und hängt die Laufwerke an Ihre Knoten an. Diese Art von sitzungsspezifischem Speicher ist in Situationen wie den folgenden nützlich:

  • Da Ihre Arbeitslasten hohe Leistungsanforderungen haben, müssen Sie die Speicherhardware steuern.
  • Sie benötigen einen kurzfristigen, containerspezifischen sitzungsspezifischen Speicher.
  • Sie möchten nicht emptyDir verwenden, um sitzungsspezifischen Speicher bereitzustellen. emptyDir-Volumes sind weiterhin nützlich, wenn mehrere Container die Daten im sitzungsspezifischen Speicher freigeben sollen.
  • Sie möchten mehr sitzungsspezifische Speicherkapazität haben, als die in GKE integrierten Standardeinstellungen bieten.
  • Sie möchten vermeiden, dass die Größe und der Typ von Knoten-Bootlaufwerken für GKE-Cluster im Standardmodus im Voraus geplant werden müssen.

Sitzungsspezifische Speichertypen in GKE

Im Allgemeinen können Sie die Speicherkapazität des Bootlaufwerks oder dedizierte nichtflüchtige Speicher als sitzungsspezifischen Speicher in den Pods und den Containern verwenden. In der folgenden Tabelle werden die Unterschiede beschrieben:

Speichertyp Wie sie eingesetzt wird Beschreibung
Bootlaufwerk – Nichtflüchtige Speicher

Stellen Sie ein Volume mit emptyDir in der Pod-Spezifikation bereit und fordern Sie die benötigte Kapazität an.

Eine Anleitung finden Sie unter Volumes erstellen.

Der angeforderte sitzungsspezifische Speicher stammt aus einem reservierten Teil des Knoten-Bootlaufwerks. Dies ist sowohl in Autopilot- als auch in Standard-Clustern die Standardeinstellung.

Verwenden Sie diese Option, wenn Pods kleine sitzungsspezifische Speicheranfragen haben oder wenn Sie die sitzungsspezifischen Daten mit mehreren Containern im Pod teilen möchten.

Autopilot

  • Die Anfrage muss zwischen 10 MiB und 10 GiB liegen.
  • Der Speicherhardwaretyp ist vorkonfiguriert.

Standard

Kein Größenlimit, erfordert jedoch eine sorgfältige Planung der Größe des Knoten-Bootlaufwerks und des Speicherhardwaretyps.

Weitere Informationen dazu, wie GKE die sitzungsspezifische Speicherreservierung auf dem Knoten-Bootlaufwerk berechnet, finden Sie unter Lokale sitzungsspezifische Speicherreservierung.
Lokale SSDs
  1. Erstellen Sie einen Knotenpool mit angehängten lokalen SSD-Laufwerken und einer kompatiblen Maschinenserie.
  2. Stellen Sie ein Volume mit emptyDir und der erforderlichen Kapazität bereit.
  3. Verwenden Sie einen nodeSelector, um Pods auf Knoten mit angehängten lokalen SSD-Laufwerken zu platzieren.

Eine Anleitung finden Sie unter Sitzungsspezifischen Speicher mit lokalen SSDs bereitstellen.

 Lokale SSD-Laufwerke verwenden feste 375-GB-Schritte, die in GKE-Clustern im Standard-Modus und in Autopilot-Knoten, die A100-GPUs (80 GB) ausführen, unterstützt werden.

Verwenden Sie diese Option, wenn Sie sitzungsspezifischen Speicher mit hohem Durchsatz benötigen.

Weitere Informationen finden Sie unter Lokale SSDs für GKE.
Dedizierte nichtflüchtige Speicher
  1. Erstellen Sie optional eine Kubernetes-StorageClass für die Hardware.
  2. Stellen Sie ein Volume mit dem Volume-Typ ephemeral in der Pod-Spezifikation bereit.

In diesem Dokument wird erläutert, wie Sie diesen sitzungsspezifischen Speichertyp anfordern.

Google Cloud stellt die angeforderte externe Hardware dynamisch bereit, hängt sie an Ihre Knoten an und stellt das angeforderte Volume in Ihrem Pod bereit.

Verwenden Sie diese Option, wenn Pods große sitzungsspezifische Speicheranfragen haben oder Sie den zugrunde liegenden nichtflüchtigen Speichertyp steuern möchten. Diese Volumes haben folgende Attribute:

  • Bis zu 64 TiB im Autopilot-Modus und Standard-Modus
  • Spezialisierte Hardware wie SSD-gestützte Volumes wird unterstützt.
  • Network Attached Storage.
  • Verwendet Kubernetes-Volumes, um Speicher abzurufen, statt emptyDir zu verwenden, um das Knoten-Bootlaufwerk freizugeben.

Weitere Informationen zu diesem sitzungsspezifischen Volume finden Sie unter Generische sitzungsspezifische Volumes.

Preise

Der Speicherplatz, den Sie über generische sitzungsspezifische Volumes bereitstellen, wie in diesem Leitfaden beschrieben, wird auf Basis der Laufwerkspreise für Compute Engine abgerechnet.

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.
  • Achten Sie darauf, dass Sie einen GKE-Autopilot- oder -Standard-Cluster mit Version 1.23 oder höher haben.
  • Prüfen Sie, ob in Ihrem Google Cloud-Projekt ein ausreichendes Kontingent für die Speicherhardware vorhanden ist. Informationen zum Verwalten Ihres Kontingents finden Sie unter Kontingente für Ihr Projekt ansehen.

StorageClass erstellen

Durch das Erstellen einer benutzerdefinierten Kubernetes-StorageClass können Sie den Speichertyp angeben, der auf der Grundlage Ihrer Preis- und Leistungsanforderungen bereitgestellt werden soll. Dieser Schritt ist optional, wird aber empfohlen. Wenn Sie die Standard-StorageClass von GKE mit dem nichtflüchtigen Speichertyp pd-balanced verwenden möchten, überspringen Sie diesen Schritt.

  1. Speichern Sie das folgende Manifest als ephemeral-pd-class.yaml:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ephemeral-ssd
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: STORAGE_TYPE

    Ersetzen Sie STORAGE_TYPE durch den Namen des gewünschten nichtflüchtigen Speichertyps, z. B. pd-ssd. Eine Liste der unterstützten Typen finden Sie in der Compute Engine-Dokumentation unter Nichtflüchtige Speichertypen.

  2. StorageClass erstellen:

    kubectl create -f ephemeral-pd-class.yaml

Sitzungsspezifische Speicherkapazität in einem Pod anfordern

Wenn Sie externe Hardware als sitzungsspezifischen Speicher bereitstellen, anhängen und verwenden möchten, fügen Sie das entsprechende Volume Ihrem Pod-Manifest hinzu und fügen Sie der Containerspezifikation eine Volume-Bereitstellung hinzu.

  1. Speichern Sie das folgende Manifest als ephemeral-ssd-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: ephemeral-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      storage: ephemeral
  template:
    metadata:
      labels:
        storage: ephemeral
    spec:
      containers:
      - name: ephemeral-container
        image: nginx
        resources:
          requests:
            cpu: 500m
            memory: 2Gi
            ephemeral-storage: 2Gi
        volumeMounts:
        - mountPath: "/short-term"
          name: ephemeral-volume
      volumes:
      - name: ephemeral-volume
        ephemeral:
          volumeClaimTemplate:
            metadata:
              labels:
                type: ephemeral
            spec:
              accessModes: ["ReadWriteOnce"]
              storageClassName: "ephemeral-ssd"
              resources:
                requests:
                  storage: 1Ti

    Dieses Manifest erstellt einen neuen Kubernetes-PersistentVolumeClaim, der ein neues PersistentVolume mit dem Namen ephemeral-volume mit den folgenden Attributen anfordert:

    • spec.volumes.ephemeral: Der Volume-Typ ephemeral.
    • .spec.accessModes: Der Volume-Zugriffsmodus, der den Lese-/Schreibzugriff von Pods und die Volume-Freigabe zwischen Knoten bestimmt. In diesem Beispiel wird ReadWriteOnce verwendet, womit das PersistentVolume auf einem einzelnen Knoten bereitgestellt wird, um Zugriff durch einen oder mehrere Pods auf dem Knoten zu ermöglichen. Weitere Informationen finden Sie unter Zugriffsmodi.
    • .spec.storageClassName: Optional der Name der StorageClass, die Sie erstellt haben. Wenn Sie dieses Feld weglassen, verwendet GKE die Standard-StorageClass und stellt einen nichtflüchtigen pd-balanced-Speicher bereit.
    • .spec.resources.requests.storage: Die gewünschte Speicherkapazität.

  2. Erstellen Sie das Deployment:

    kubectl create -f ephemeral-ssd-deployment.yaml

GKE stellt ein Compute Engine-Laufwerk bereit, das die Anforderungen des PersistentVolumeClaim erfüllt und das Laufwerk an den Knoten anhängt. GKE stellt das Volume im Pod bereit und stellt für den Container die angeforderte Kapazität bereit.

Prüfen, ob GKE ein sitzungsspezifisches Volume bereitgestellt hat

  1. Erstellen Sie eine Shell-Sitzung im Pod:

    kubectl exec -it deploy/ephemeral-deployment -- bash

  2. Prüfen Sie die bereitgestellten Volumes:

    df -h

    Die Ausgabe sieht in etwa so aus:

    Filesystem                Size      Used Available Use% Mounted on
...
/dev/sdb               1006.9G     28.0K   1006.8G   0% /short-term
/dev/sda1                94.3G      3.6G     90.6G   4% /etc/hosts
/dev/sda1                94.3G      3.6G     90.6G   4% /dev/termination-log
/dev/sda1                94.3G      3.6G     90.6G   4% /etc/hostname
/dev/sda1                94.3G      3.6G     90.6G   4% /etc/resolv.conf
...

  3. Beenden Sie die Shell-Sitzung:

    exit

Nächste Schritte