Gemischte lokale SSDs für Rohblock- und sitzungsspezifischen Speicher bereitstellen und verwenden

In diesem Dokument wird beschrieben, wie Sie lokale SSDs in Google Kubernetes Engine (GKE) bereitstellen und partitionieren, um Arbeitslasten zu unterstützen, die sowohl ein standardmäßiges sitzungsspezifisches Speicherdateisystem als auch unformatierten Rohblockspeicher auf demselben Knoten erfordern.

Verwenden Sie diese Konfiguration für zustandsorientierte Anwendungen und hochoptimierte Datenbanken. Diese Arbeitslasten erfordern häufig direkten Laufwerkszugriff, um die Leistung zu steigern, benötigen aber auch standardmäßigen sitzungsspezifischen Dateispeicher für Sidecars, Logs oder Container-Caches. Durch die Verwendung einer gemischten lokalen SSD-Kapazität können Sie den Aufwand für die Clusterverwaltung reduzieren und die Hardwareauslastung maximieren, da Sie keine separaten Knoten oder vollständigen Laufwerke ausschließlich für die Rohblockinfrastruktur reservieren müssen.

Wenn Sie einen Cluster oder Knotenpool mit gemischter lokaler SSD-Kapazität erstellen, partitioniert GKE jede physisch angehängte lokale SSD so:

  • Sitzungsspezifischer Speicher: Die angeforderte sitzungsspezifische Kapazität wird gleichmäßig auf die lokalen SSDs aufgeteilt und kombiniert, um den standardmäßigen sitzungsspezifischen Dateispeicher des Knotens bereitzustellen. Wenn die sitzungsspezifische Kapazität auf mehrere lokale SSDs aufgeteilt ist, wird der Speicher in einem RAID-0-Array zusammengefasst. Sie können über standardmäßige emptyDir-Volumes auf den sitzungsspezifischen Speicher zugreifen.
  • Unformatierter Blockspeicher: Die verbleibende physische Kapazität auf jedem Laufwerk wird dem Knoten als separate, unformatierte blockorientierte Geräte präsentiert.

Dieses Dokument richtet sich an Plattformadministratoren und -operatoren sowie DevOps, die die Hardwareauslastung und Speicherleistung in GKE für spezielle Arbeitslasten optimieren möchten.

Hinweise

Zusätzlich zu den Einschränkungen für lokale SSDs in Compute Engine sollten Sie die folgenden GKE-spezifischen Überlegungen beachten, bevor Sie gemischte Modi für lokale SSDs konfigurieren:

  • Autopilot-Kompatibilität: GKE Autopilot-Cluster unterstützen keine gemischten Rohblock- und sitzungsspezifischen Speicher. Informationen zur Verwendung lokaler SSDs für standardmäßigen sitzungsspezifischen Speicher in Autopilot finden Sie unter Lokale SSDs in Autopilot-Clustern.
  • Benutzerdefinierte ComputeClasses: Benutzerdefinierte ComputeClasses unterstützen keine gemischte Konfiguration für lokale SSDs.
  • Betriebssystem: Der gemischte lokale SSD-Modus wird nur auf Linux-Knoten-Images (Container-Optimized OS und Ubuntu) unterstützt. Windows Server-Knotenpools werden nicht unterstützt.
  • Wartungsereignisse: Wir empfehlen nicht, lokale SSDs als Rohblockspeicher für speicheroptimierte Z3- oder Z4D-VMs zu verwenden. Daten auf diesen VMs bleiben bei Wartungsereignissen möglicherweise nicht erhalten. Weitere Informationen finden Sie unter Lokalen SSD-gestützten Rohblockspeicher bereitstellen und verwenden.
  • Gemeinsame E/A: Da sowohl das sitzungsspezifische RAID-0-Array als auch die Zielpartitionen für Rohblöcke auf denselben zugrunde liegenden physischen SSDs basieren, können intensive Vorgänge auf einer logischen Partition den Durchsatz der anderen beeinträchtigen. Informationen zu den maximalen Durchsatzlimits finden Sie unter Leistung lokaler SSDs.
  • Preise: Wenn Sie gemischte Modi zum Partitionieren der lokalen SSD-Kapazität verwenden, zahlen Sie für die gesamte zugrunde liegende physische lokale SSD-Kapazität, die dem Knoten zugeordnet ist, unabhängig davon, wie viel Kapazität für sitzungsspezifischen Speicher im Vergleich zu Rohblockspeicher zugewiesen ist. Weitere Informationen finden Sie unter Preise für lokale SSDs.
  • Manuelle Konfiguration: Wenn Sie lokalen SSD-gestützten Rohblockspeicher verwenden möchten, müssen Sie die Geräte manuell konfigurieren, da GKE die Rohblockpartitionen nicht formatiert oder bereitstellt. Sie sind auch für die Verwaltung der Knotenkapazität und den Umgang mit potenziellen Störungen durch gemeinsam genutzte Arbeitslasten verantwortlich. Wenn Sie ein lokales PersistentVolume-Objekt verwenden, ist die Pod-Planung integriert. Wenn Ihre Arbeitslasten keine Daten über den gesamten Lebenszyklus eines Pods hinweg beibehalten müssen oder keine besonderen Leistungsanforderungen haben, verwenden Sie stattdessen die vollständig sitzungsspezifische lokale SSD-Konfiguration. Die vollständig sitzungsspezifische Konfiguration ist für die meisten Anwendungsfälle geeignet.
  • Knotenspeicheraustausch: Sie können die gemischte lokale SSD-Kapazität mit dem Knotenspeicheraustausch kombinieren, indem Sie das Bootlaufwerkprofil oder das sitzungsspezifische lokale SSD-Profil verwenden. Das dedizierte lokale SSD-Profil wird bei gemischter lokaler SSD-Kapazität nicht unterstützt. Weitere Informationen finden Sie unter Knotenspeicher-Swap mit gemischter lokaler SSD-Kapazität.

Hinweis

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 dem Befehl gcloud components update ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.

Damit Sie diese Funktion verwenden können, müssen GKE-Knoten die Version 1.37.0-gke.3570000 oder höher ausführen.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Kubernetes Engine-Administrator (roles/container.admin) für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Erstellen von Clustern und Knotenpools mit gemischter lokaler SSD-Kapazität benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Cluster oder Knotenpool mit gemischtem lokalen SSD-Speicher erstellen

Sie können sitzungsspezifische Kapazität zuweisen und Rohblockpartitionen reservieren, indem Sie das Attribut capacity des Flags --ephemeral-storage-local-ssd verwenden.

Erstellen Sie Ihren Cluster oder Knotenpool, indem Sie das Unterfeld capacity mit dem Flag --ephemeral-storage-local-ssd angeben.

Wenn Ihr Maschinentyp eine konfigurierbare Anzahl von lokalen SSDs zulässt, müssen Sie auch das Unterfeld count angeben. Wenn Ihr Maschinentyp eine feste Anzahl von lokalen SSDs hat, z. B. -lssd-Typen, können Sie das Unterfeld count weglassen, da GKE die Anzahl der Laufwerke automatisch anhand der VM-Form berechnet.

Cluster mit gemischtem lokalen SSD-Speicher erstellen

Verwenden Sie zum Erstellen eines neuen Clusters den Befehl gcloud container clusters create. Diese Einstellungen gelten nur für den Standardknotenpool. Wenn nachfolgende Knotenpools gemischten lokalen SSD-Speicher benötigen, geben Sie beim Erstellen des Knotenpools das Flag --ephemeral-storage-local-ssd an. Die maximale Anzahl der Laufwerke, die Sie anhängen können, variiert je nach Maschinentyp und Region.

Wenn die Version Ihres Clusters älter als 1.37.0-gke.3570000 ist, fügen Sie den folgenden Befehlen zur Clustererstellung eines der folgenden Flags hinzu:

  • Das Flag --cluster-version=<var>VERSION</var>, wobei <var>VERSION</var> auf 1.37.0-gke.3570000 oder höher festgelegt ist, oder
  • Das Flag --release-channel=rapid.

Führen Sie für Maschinentypen mit einer konfigurierbaren Anzahl lokaler SSDs Folgendes aus:

gcloud container clusters create CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --ephemeral-storage-local-ssd count=NUMBER_OF_DISKS,capacity=CAPACITY

Führen Sie für Maschinentypen mit einer festen Anzahl von lokalen SSDs Folgendes aus:

gcloud container clusters create CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --ephemeral-storage-local-ssd capacity=CAPACITY

Ersetzen Sie Folgendes:

  • CLUSTER_NAME: der Name des Clusters, den Sie erstellen möchten.
  • MACHINE_TYPE ist der zu verwendende Maschinentyp. Eine Liste der unterstützten Maschinentypen finden Sie unter Unterstützung für Maschinenserien. Sie können lokale SSDs nicht mit dem Standardmaschinentyp e2-medium verwenden, da sie von Maschinentypen mit gemeinsam genutztem Kern nicht unterstützt werden.
  • NUMBER_OF_DISKS: Bei Maschinentypen mit einer konfigurierbaren Anzahl lokaler SSDs die Anzahl der lokalen SSD-Laufwerke, die auf jedem Knoten bereitgestellt werden sollen.

  • CAPACITY: die gesamte lokale SSD-Kapazität, die für den sitzungsspezifischen Speicher formatiert werden soll. Dieser Wert muss größer als 0 und kleiner als die gesamte physische lokale SSD-Kapazität (Anzahl der Laufwerke × Größe pro Laufwerk) sein, z. B. 200GB. Wichtige Hinweise:

    • Der Wert kann nach dem Erstellen des Clusters nicht mehr geändert werden.
    • Die GKE reserviert einen Teil dieser Kapazität für die Systemnutzung, sodass der zuweisbare sitzungsspezifische Speicher kleiner als CAPACITY ist. Weitere Informationen finden Sie unter Lokale sitzungsspezifische Speicherreservierung.

Knotenpool mit gemischtem lokalen SSD-Speicher erstellen

Verwenden Sie den Befehl gcloud container node-pools create, um einem vorhandenen Cluster einen Knotenpool hinzuzufügen.

Wenn die Version für Ihren Knotenpool älter als 1.37.0-gke.3570000 ist, müssen Sie Folgendes tun:

  • Fügen Sie den folgenden Befehlen zum Erstellen von Knotenpools das Flag --node-version=<var>VERSION</var> hinzu, wobei <var>VERSION</var> auf 1.37.0-gke.3570000 oder höher festgelegt ist.
  • Achten Sie darauf, dass die Steuerungsebene des Clusters die Version 1.37.0-gke.3570000 oder höher hat.

Führen Sie für Maschinentypen mit einer konfigurierbaren Anzahl lokaler SSDs Folgendes aus:

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --ephemeral-storage-local-ssd count=NUMBER_OF_DISKS,capacity=CAPACITY

Führen Sie für Maschinentypen mit einer festen Anzahl von lokalen SSDs Folgendes aus:

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --ephemeral-storage-local-ssd capacity=CAPACITY

Ersetzen Sie Folgendes:

  • POOL_NAME: Der Name des neuen Knotenpools, den Sie erstellen möchten.
  • CLUSTER_NAME ist der Name des Clusters.
  • MACHINE_TYPE ist der zu verwendende Maschinentyp. Eine Liste der unterstützten Maschinentypen finden Sie unter Unterstützung für Maschinenserien. Sie können lokale SSDs nicht mit dem Standardmaschinentyp e2-medium verwenden, da sie von Maschinentypen mit gemeinsam genutztem Kern nicht unterstützt werden.
  • NUMBER_OF_DISKS: Bei Maschinentypen mit einer konfigurierbaren Anzahl lokaler SSDs die Anzahl der lokalen SSD-Laufwerke, die auf jedem Knoten bereitgestellt werden sollen.

  • CAPACITY: die gesamte lokale SSD-Kapazität, die für den sitzungsspezifischen Speicher formatiert werden soll. Dieser Wert muss größer als 0 und kleiner als die gesamte physische lokale SSD-Kapazität (Anzahl der Laufwerke × Größe pro Laufwerk) sein, z. B. 200GB. Wichtige Hinweise:

    • Der Wert kann nach dem Erstellen des Knotenpools nicht mehr geändert werden.
    • Die GKE reserviert einen Teil dieser Kapazität für die Systemnutzung, sodass der zuweisbare sitzungsspezifische Speicher kleiner als CAPACITY ist. Weitere Informationen finden Sie unter Lokale sitzungsspezifische Speicherreservierung.

Knotenlabels prüfen

Führen Sie nach der Bereitstellung den folgenden Befehl aus, um zu prüfen, ob die Knoten die richtigen Labels für den sitzungsspezifischen und den Raw-Blockspeicher haben:

kubectl describe node NODE_NAME

Die Ausgabe sollte die beiden folgenden Knotenlabels enthalten:

  • cloud.google.com/gke-ephemeral-storage-local-ssd: "true"
  • cloud.google.com/gke-local-nvme-ssd-partition: "true"

Auf die sitzungsspezifische Kapazität zugreifen

Sie können auf Ihren reservierten sitzungsspezifischen Speicher über emptyDir-Volumes genauso zugreifen wie auf jedes andere sitzungsspezifische GKE-Volume.

Auf die Rohblockkapazität zugreifen

Wenn Sie auf die Rohblockkapazität zugreifen möchten, erstellen Sie ein StorageClass-Objekt, stellen ein lokales PersistentVolume-Objekt bereit und fordern es mit einem PersistentVolumeClaim-Objekt an.

StorageClass erstellen

Da Sie Ihre PersistentVolume-Objekte ohne den statischen Community-Bereitsteller bereitstellen, empfehlen wir, ein StorageClass-Objekt mit dem Feld volumeBindingMode: WaitForFirstConsumer zu erstellen. Damit wird die Bindung bis zur Pod-Planung verzögert und Kubernetes wählt eine lokale SSD von einem geeigneten Knoten aus, der den Pod auch ausführen kann.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: "local-storage"
provisioner: "kubernetes.io/no-provisioner"
volumeBindingMode: "WaitForFirstConsumer"

PersistentVolume erstellen

Lokale PersistentVolume-Objekte haben wichtige Einschränkungen in Bezug auf Knotenupgrades, Skalierung und Cluster-Autoscaling. Bevor Sie Volumes erstellen, sollten Sie sich die Einschränkungen lokaler PersistentVolumes ansehen, um zu verstehen, wie sich Lifecycle-Events auf Ihre Daten auswirken.

Führen Sie die folgenden Schritte aus, um das PersistentVolume-Objekt zu erstellen. Suchen Sie den symbolischen Linkpfad zur lokalen SSD-Partition, ermitteln Sie die genaue verbleibende Kapazität und konfigurieren Sie das Manifest.

Partitionskapazität ermitteln

Führen Sie den folgenden Befehl auf dem Zielknoten aus, um die genaue verbleibende Rohblockkapazität für die Partition zu ermitteln.

kubectl debug node/NODE_NAME -it --image=ubuntu -- \
    sh -c 'ls -l /host/dev/disk/by-id/ | grep partition; lsblk -o NAME,SIZE,TYPE'

Ersetzen Sie NODE_NAME durch den Namen des Knotens, an den die lokale SSD angehängt ist.

Die Ausgabe zeigt die Zuordnung zwischen Gerätenamen und Partitions-Symlinks, sodass Sie prüfen können, welche Partition welchem Gerät entspricht. Außerdem werden die an den Knoten angehängten blockorientierten Geräte und ihre Größen aufgeführt.

Wenn Sie beispielsweise zwei lokale SSDs an den Knoten anhängen und 200 GB für sitzungsspezifischen Speicher (capacity=200GB) zuweisen, sieht die Ausgabe in etwa so aus:

google-local-ssd-partition0 -> /dev/nvme0n1p2
google-local-ssd-partition1 -> /dev/nvme0n2p2
NAME          SIZE TYPE
...
nvme0n1       375G disk
|-nvme0n1p1   100G part
| `-md0     199.9G raid0
`-nvme0n1p2   275G part
nvme0n2       375G disk
|-nvme0n2p1   100G part
| `-md0     199.9G raid0
`-nvme0n2p2   275G part

Notieren Sie sich die Zuordnung zwischen dem symbolischen Link google-local-ssd-partition und dem zugrunde liegenden Gerätenamen sowie die Größe dieser Partition. Sie verwenden die Größe als PARTITION_SIZE und den Symlink-Pfad als LOCAL_SSD_SYMLINK_PATH im PersistentVolume-Manifest.

In der vorherigen Ausgabe verweist der symbolische Link /dev/disk/by-id/google-local-ssd-partition0 beispielsweise auf die Partition nvme0n1p2, die eine Größe von 275G hat.

Mit dem Befehl kubectl debug wird ein temporärer Pod im Standard-Namespace ausgeführt. Damit er keine Ressourcen verbraucht, löschen Sie diesen Pod mit dem folgenden Befehl:

kubectl delete pod DEBUG_POD_NAME

Ersetzen Sie DEBUG_POD_NAME durch den Namen des Pods, der mit dem Befehl kubectl debug erstellt wurde. Dieser wird ausgegeben, wenn Sie den Befehl ausführen.

PersistentVolume-Manifest konfigurieren

Konfigurieren Sie das Volume-Manifest mit der ermittelten Partitionsgröße. Das Feld nodeAffinity ist für lokale Volumes erforderlich. So wird sichergestellt, dass Kubernetes Pods, die dieses Volume beanspruchen, auf dem spezifischen Knoten plant, an den die lokale SSD physisch angehängt ist. Das folgende Beispiel zeigt ein Manifest für eine lokale SSD-Partition mit Rohblock:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: "example-local-pv"
spec:
  capacity:
    storage: PARTITION_SIZE
  accessModes:
  - "ReadWriteOnce"
  volumeMode: "Block"
  persistentVolumeReclaimPolicy: "Retain"
  storageClassName: "local-storage"
  local:
    path: "LOCAL_SSD_SYMLINK_PATH"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: "kubernetes.io/hostname"
          operator: "In"
          values:
          - "NODE_NAME"

Ersetzen Sie Folgendes:

  • PARTITION_SIZE: die tatsächliche verbleibende Rohblockkapazität, die Sie im ersten Schritt ermittelt haben. Verwenden Sie das Suffix Gi (z. B. 275Gi), damit der Wert genau der Kapazität der Partition entspricht.
  • NODE_NAME: der Name des Knotens, an den die lokale SSD angehängt ist.
  • LOCAL_SSD_SYMLINK_PATH: der symbolische Linkpfad zur unformatierten lokalen SSD-Partition, die Sie im ersten Schritt gefunden haben. Das Hostbetriebssystem erstellt für jede lokale SSD, die Sie an den Knotenpool anhängen, einen symbolischen Link, um auf die verbleibende Rohblockkapazität zuzugreifen. Die Pfade folgen einem nullindexierten Muster. Wenn Sie beispielsweise drei lokale SSDs anhängen, lauten die Rohblockpfade für die Partitionen so:
    • /dev/disk/by-id/google-local-ssd-partition0
    • /dev/disk/by-id/google-local-ssd-partition1
    • /dev/disk/by-id/google-local-ssd-partition2

PersistentVolumeClaim erstellen

Erstellen Sie ein PersistentVolumeClaim-Objekt, um das Volume zu beanspruchen. Die entsprechende Spezifikation sieht so aus:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: "example-local-pvc"
spec:
  accessModes:
  - "ReadWriteOnce"
  volumeMode: "Block"
  storageClassName: "local-storage"
  resources:
    requests:
      storage: PARTITION_SIZE

Volume in einem Pod verwenden

Sie können das PersistentVolume-Objekt in einem Pod verwenden, indem Sie in einer volumeDevices-Spezifikation auf das PersistentVolumeClaim-Objekt verweisen. Das folgende Beispiel zeigt ein Pod-Manifest, das den example-local-pvc-Anspruch verwendet:

apiVersion: v1
kind: Pod
metadata:
  name: "example-pod"
spec:
  containers:
  - name: "app"
    image: "ubuntu:22.04"
    command: ["/bin/sh", "-c"]
    args: ["tail -f /dev/null"]
    volumeDevices:
    - name: "raw"
      devicePath: "/dev/xvda"
  volumes:
  - name: "raw"
    persistentVolumeClaim:
      claimName: "example-local-pvc"

Da Sie den Bereitsteller kubernetes.io/no-provisioner verwenden, werden lokale Volumes von GKE nicht automatisch bereinigt. Wenn Sie das PersistentVolume-Objekt löschen, müssen Sie die Daten auf dem zugrunde liegenden Laufwerk manuell löschen, bevor das Laufwerk sicher wiederverwendet werden kann.

Fehlerbehebung

Eine Anleitung zur Fehlerbehebung finden Sie unter Fehlerbehebung bei Speicherproblemen in GKE.

Nächste Schritte