Lokale SSDs verwenden

Diese Seite bietet einen Überblick über die Unterstützung für lokale SSDs in Kubernetes und die Verwendung lokaler SSDs mit Google Kubernetes Engine (GKE).

Überblick

Lokale SSDs bieten leistungsstarken, sitzungsspezifischen Speicher für jeden Knoten im Cluster. Sie zeichnen sich durch einen höheren Durchsatz und eine geringere Latenz als Standardlaufwerke aus. Lokale SSDs eignen sich gut für Arbeitslasten, die lokale Caching- und Verarbeitungsvorgänge bereitstellen.

Sie können Knotenpools mit lokalen SSDs im Rahmen der Maschinentyplimits des Clusters und der Kontingente Ihres Projekts erstellen.

  • Daten, die auf eine lokale SSD geschrieben werden, sind sitzungsspezifisch und gehen verloren, wenn der Knoten gelöscht, repariert oder aktualisiert wird oder ein nicht behebbarer Fehler auftritt.

  • Eine lokale SSD ist nur mit einem einzelnen Knoten verbunden und die Knoten selbst sind auch sitzungsspezifisch. Eine Arbeitslast kann zu einer beliebigen Zeit auf einem anderen Knoten geplant werden.

Weitere Informationen zu den Vorteilen und Einschränkungen lokaler SSDs finden Sie in der Compute Engine-Dokumentation unter Lokale SSDs.

Cluster mit lokalen SSDs erstellen

Mit der Google Cloud Console oder dem gcloud-Befehlszeilentool können Sie einen Cluster erstellen oder einen Cluster zur Verwendung von lokalen SSDs aktualisieren.

Console

Über das GKE-Menü in der Cloud Console können Sie einen Cluster oder Knotenpool mit lokalen SSDs erstellen.

So erstellen Sie einen Cluster, in dem der Standardpool lokale SSD-Laufwerke verwendet:

  1. Rufen Sie in der Cloud Console das Kubernetes Engine-Menü auf.

    Zum Google Kubernetes Engine-Menü

  2. Klicken Sie auf Cluster erstellen.

  3. Klicken Sie im Navigationsbereich unter Knotenpools auf Standardpool.

  4. Geben Sie für Anzahl der Knoten den Wert 2 ein.

  5. Klicken Sie im Navigationsbereich unter Standardpool auf Knoten.

  6. Maximieren Sie das Menü CPU-Plattform und GPU.

  7. Geben Sie für Lokale SSD-Laufwerke die gewünschte Anzahl von SSDs als absolute Zahl ein.

  8. Klicken Sie auf Erstellen.

Gehen Sie so vor, um einen Knotenpool mit lokalen SSD-Laufwerken in einem vorhandenen Cluster zu erstellen:

  1. Rufen Sie in der Cloud Console das Kubernetes Engine-Menü auf.

    Zum Google Kubernetes Engine-Menü

  2. Wählen Sie den gewünschten Cluster aus.

  3. Klicken Sie auf Bearbeiten.

  4. Klicken Sie unter Knotenpools auf Knotenpool hinzufügen.

  5. Geben Sie für Größe den Wert 1 ein.

  6. Geben Sie für Lokale SSD-Laufwerke (pro Knoten) die gewünschte Anzahl von SSDs als absolute Zahl ein.

  7. Klicken Sie auf Speichern.

gcloud

Wenn Sie einen Cluster oder Knotenpool mit lokalen SSDs mit gcloud erstellen möchten, geben Sie das Flag --local-ssd count an. --local-ssd-count gibt die Anzahl der lokalen SSDs an, die pro Knoten erstellt werden sollen. Die maximale Anzahl variiert je nach Maschinentyp und Region. Bei der Erstellung von Knoten werden die lokalen SSDs automatisch formatiert und an Bereitstellungspunkten wie /mnt/disks/ssd0 für das erste Laufwerk und /mnt/disks/ssd1 für das zweite Laufwerk usw. im Dateisystem des Knotens bereitgestellt.

Führen Sie den folgenden Befehl aus, um einen Cluster zu erstellen, bei dem der Standardpool lokale SSD-Laufwerke verwendet:

gcloud container clusters create cluster-name \
  --num-nodes 2 \
  --local-ssd-count number-of-disks

Führen Sie den folgenden Befehl aus, um einen Knotenpool mit lokalen SSD-Laufwerken in einem vorhandenen Cluster zu erstellen:

gcloud container node-pools create pool-name \
  --cluster cluster-name \
  --num-nodes 1 \
  --local-ssd-count number-of-disks

Dabei gilt:

  • cluster-name ist der Name des Clusters.
  • pool-name ist der Name des neuen Knotenpools.
  • number-of-disks ist die Anzahl der lokalen SSD-Laufwerke, die auf jedem Knoten bereitgestellt werden sollen.

Knotenpool mit sitzungsspezifischem Speicher auf lokalen SSDs erstellen

Ab 1.18 kann ein GKE-Knotenpool für die Verwendung lokaler SSDs für sitzungsspezifischen Speicher konfiguriert werden.

Führen Sie den folgenden Befehl aus, um einen Knotenpool mit sitzungsspezifischem Speicher auf lokalen SSDs zu erstellen:

gcloud beta container node-pools create pool-name \
    --ephemeral-storage local-ssd-count=number-of-disks

Dabei gilt:

  • pool-name ist der Name des neuen Knotenpools.
  • number-of-disks ist die Anzahl der lokalen SSD-Laufwerke, die auf jedem Knoten bereitgestellt werden sollen.

Knoten im Knotenpool werden mit dem Label cloud.google.com/gke-ephemeral-storage-local-ssd erstellt. Sie können die Labels mit dem folgenden Befehl prüfen:

kubectl describe node node-name

Lokale SSDs für Windows Server-Cluster formatieren

Bei der Verwendung lokaler SSDs mit Ihren Clustern, auf denen Windows Server-Knotenpools ausgeführt werden, müssen Sie sich beim Knoten anmelden und das Laufwerk formatieren, bevor Sie es verwenden können. Im folgenden Beispiel wird das lokale SSD-Laufwerk mit dem NTFS-Dateisystem formatiert. Sie können auch Verzeichnisse unter dem Laufwerk erstellen. In diesem Beispiel befinden sich die Verzeichnisse unter Laufwerk D.

PS C:\> Get-Disk | Where partitionstyle -eq 'raw' | Initialize-Disk -PartitionStyle MBR -PassThru | New-Partition -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem ntfs -Confirm:$false
PS C:\> mkdir D:\test-ss

Lokale SSDs verwenden

Im folgenden Abschnitt wird erläutert, wie Sie lokale SSDs mit GKE verwenden.

Sie haben folgende Möglichkeiten, auf lokale SSDs zuzugreifen:

  • Mit hostpath-Volumes werden folgende Einstellungen empfohlen:

    • Arbeitslasten, die DaemonSets verwenden.
    • Arbeitslasten, die dedizierte Knotenpools verwenden. Der Zugriff auf sämtliche lokale SSDs muss in allen Instanzen eines DaemonSets über denselben Pfad erfolgen.
  • Mit local PersistentVolumes; empfohlen für:

    • Arbeitslasten mit StatefulSets und volumeClaimTemplates.
    • Arbeitslasten, die sich Knotenpools teilen. Jede lokale SSD kann über einen PersistentVolumeClaim (PVC) reserviert werden. Spezifische Hostpfade werden nicht direkt in der Pod-Spezifikation codiert.
    • Pods, die Datenbindung an dieselbe lokale SSD voraussetzen. Ein Pod wird immer für denselben Knoten wie sein lokales PersistentVolume eingeplant.
  • Mit sitzungsspezifischem Speicher alsemptyDir-Volume (verfügbar als Beta in GKE-Version 1.18 oder höher); empfohlen für:

    • Anwendungen, die einen leistungsfähigen sitzungsspezifischen temporären Speicherbereich erfordern.

    Dieses Feature konfiguriert einen Knotenpool, um sitzungsspezifischen Knotenspeicher auf lokalen SSDs bereitzustellen. Pods, die emptyDir transparent verwendet werden, verwenden lokale SSD. Dies gilt jedoch für alle Pods auf allen Knoten im Knotenpool. Bestimmte Pods können keine lokalen emptyDir-SSD-Volumes verwenden und andere Pods können keine herkömmlichen emptyDir verwenden. Planen Sie für Arbeitslasten, die keine herkömmlichen emptyDir-Volumes verwenden sollen, einen Zeitplan für diese Arbeitslasten in einem anderen Knotenpool.

Beispiele für die Verwendung von hostPath-Volumes

Die folgenden Beispiele zeigen, wie Sie hostPath-Volumes für Windows und Linux verwenden.

Linux

Wenn Sie einen Knotenpool mit drei lokalen SSDs erstellen, stellt das Hostbetriebssystem die Laufwerke unter /mnt/disks/ssd0, /mnt/disks/ssd1 und /mnt/disks/ssd2 bereit. Die Kubernetes-Container greifen mit dem Parameter hostPath, der in der Konfigurationsdatei des Objekts definiert ist, auf die Laufwerke zu.

Diese Beispiel-Pod-Konfigurationsdatei verweist auf eine lokale SSD: /mnt/disks/ssd0:

apiVersion: v1
kind: Pod
metadata:
  name: "test-ssd"
spec:
  containers:
  - name: "shell"
    image: "ubuntu:14.04"
    command: ["/bin/sh", "-c"]
    args: ["echo 'hello world' > /test-ssd/test.txt && sleep 1 && cat /test-ssd/test.txt"]
    volumeMounts:
    - mountPath: "/test-ssd/"
      name: "test-ssd"
  volumes:
  - name: "test-ssd"
    hostPath:
      path: "/mnt/disks/ssd0"
  nodeSelector:
    cloud.google.com/gke-local-ssd: "true"

Windows

apiVersion: v1
kind: Pod
metadata:
  name: "test-ssd"
spec:
  containers:
  - name: "test"
    image: "mcr.microsoft.com/windows/servercore/iis"
    volumeMounts:
    - mountPath: "/test-ssd/"
      name: "test-ssd"
  volumes:
  - name: "test-ssd"
    hostPath:
      path: "d:\\test-ssd"
  nodeSelector:
    cloud.google.com/gke-local-ssd: "true"
    kubernetes.io/os: windows

Beispiele für die Verwendung lokaler PersistentVolumes

Lokale SSDs können als PersistentVolumes angegeben werden.

Zum Erstellen von PersistentVolumes aus lokalen SSDs können Sie entweder ein PersistentVolume manuell erstellen oder den statischen Bereitsteller für lokale Volumes ausführen.

Beschränkungen

  • Derzeit werden Cluster-Autoscaling und die dynamische Bereitstellung mit lokalen PersistentVolumes nicht unterstützt.

  • Beim Aktualisieren eines GKE-Clusters oder Reparieren von Knoten werden die Compute Engine-Instanzen gelöscht. Dadurch werden auch alle Daten auf den lokalen SSDs gelöscht.

  • Aktivieren Sie daher weder automatische Knotenupgrades noch automatische Knotenreparaturen für Cluster oder Knotenpools, die lokale SSDs für nichtflüchtige Daten verwenden. Sie müssen Ihre Anwendungsdaten zuerst sichern und dann die Daten in einem neuen Cluster oder Knotenpool wiederherstellen.

  • Lokale PersistentVolume-Objekte werden nicht automatisch bereinigt, wenn ein Knoten gelöscht, aktualisiert, repariert oder herunterskaliert wird. Es wird empfohlen, regelmäßig veraltete lokale PersistentVolume-Objekte zu prüfen und zu löschen, die mit gelöschten Knoten verknüpft sind.

PersistentVolume manuell erstellen

Sie können ein PersistentVolume für jede lokale SSD auf jedem Knoten im Cluster manuell erstellen.

Verwenden Sie das Feld nodeAffinity in einem PersistentVolume-Objekt, um auf eine lokale SSD auf einem bestimmten Knoten zu verweisen. Das folgende Linux-Beispiel ist beispielsweise eine PersistentVolume-Spezifikation für eine lokale SSD, die unter /mnt/disks/ssd0 auf Knoten gke-test-cluster-default-pool-926ddf80-f166 bereitgestellt ist:

Linux

apiVersion: v1
kind: PersistentVolume
metadata:
  name: "example-local-pv"
spec:
  capacity:
    storage: 375Gi
  accessModes:
  - "ReadWriteOnce"
  persistentVolumeReclaimPolicy: "Retain"
  storageClassName: "local-storage"
  local:
    path: "/mnt/disks/ssd0"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: "kubernetes.io/hostname"
          operator: "In"
          values: "gke-test-cluster-default-pool-926ddf80-f166"

Windows

apiVersion: v1
kind: PersistentVolume
metadata:
  name: ssd-local-pv
spec:
  capacity:
    storage: 375Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: "d:\\test-ssd"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - gke-gke-cluster-windows-dds-2263bc7c-wq6m
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: ssd-local-claim
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: local-storage
  resources:
    requests:
      storage: 37Gi

Sie können jetzt einen Pod für den Zugriff auf das Laufwerk erstellen. Sie müssen Ihrer Pod-Spezifikation einen Knotenselektor hinzufügen, um sicherzustellen, dass die Pods richtig auf Windows Server-Knoten verteilt werden:

apiVersion: v1
kind: Pod
metadata:
  name: "test-ssd"
spec:
  containers:
  - name: "test"
    image: "mcr.microsoft.com/windows/servercore/iis"
    volumeMounts:
    - mountPath: "/test-ssd/"
      name: "test-ssd"
  volumes:
  - name: "test-ssd"
    persistentVolumeClaim:
      claimName: ssd-local-claim
  nodeSelector:
    cloud.google.com/gke-local-ssd: "true"
  tolerations:
  - key: "node.kubernetes.io/os"
    value: "windows"
    operator: "Equal"
    effect: "NoSchedule"

Wenn Sie das PersistentVolume löschen, müssen Sie die Daten manuell vom Laufwerk löschen.

Statischen Bereitsteller für lokale Volumes ausführen

Mit dem statischen Bereitsteller für lokale Volumes können Sie PersistentVolumes für lokale SSDs automatisch erstellen. Der Bereitsteller ist ein DaemonSet, das die lokalen SSDs auf jedem Knoten verwaltet, die PersistentVolumes für diese Knoten erstellt und löscht und die Daten auf der lokalen SSD bereinigt, wenn das PersistentVolume freigegeben wird.

So führen Sie den statischen Bereitsteller für lokale Volumes aus:

  1. Laden Sie die Spezifikation gke.yaml aus dem Repository "sig-storage-local-static-deployer" herunter und ändern Sie die Felder der Spezifikation namespace nach Bedarf.

    Die Spezifikation enthält:

    • ServiceAccount für den Bereitsteller
    • ClusterRole und ClusterRoleBindings für Berechtigungen zum:
      • Erstellen und Löschen von PersistentVolume-Objekten
      • Abrufen von Node-Objekten
    • ConfigMap mit Einstellungen für den Bereitsteller für GKE
    • DaemonSet zum Ausführen des Bereitstellers
  2. Stellen Sie den Bereitsteller bereit:

    kubectl apply -f gke.yaml
    

Wenn der Bereitsteller erfolgreich ausgeführt wird, erstellt er ein PersistentVolume-Objekt für jede lokale SSD im Cluster.

Verzögerte Volume-Bindung aktivieren

Zur Verbesserung der Planung empfiehlt es sich außerdem, eine StorageClass mit volumeBindingMode: WaitForFirstConsumer zu erstellen. Damit wird die PersistentVolumeClaim-Bindung (PVC) bis zur Pod-Planung verzögert und eine lokale SSD von einem geeigneten Knoten ausgewählt, der den Pod auch ausführen kann. Dieses verbesserte Planungsverhalten bedeutet, dass bei der Auswahl eines Knotens für einen ausführbaren Pod nicht nur die Knoten berücksichtigt werden, die verfügbare lokale SSDs haben, sondern auch CPU- und Arbeitsspeicheranfragen des Pods, Knotenaffinität, Pod-Affinität und -Antiaffinität sowie mehrere PVC-Anfragen.

In diesem Beispiel wird der Modus für verzögerte Volume-Bindung verwendet:

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

Wenn Sie Cluster mit Windows Server-Knotenpools verwenden, sollten Sie eine StorageClass erstellen, da die Standard-StorageClass als Dateisystemtyp "ext4" verwendet, was nur für Linux-Container funktioniert.

Die folgende YAML-Datei namens storageclass-name verwendet einen nichtflüchtigen Compute Engine-Speicher mit NTFS als Dateispeichertyp. Sie können diese StorageClass verwenden, wenn Sie mit Windows-Clustern arbeiten.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: storageclass-name
parameters:
  type: pd-standard
  fstype: NTFS
provisioner: kubernetes.io/gce-pd
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Um eine StorageClass mit verzögerter Bindung zu erstellen, speichern Sie das YAML-Manifest in einer lokalen Datei und wenden Sie es mit dem folgenden Befehl auf den Cluster an:

kubectl apply -f filename

Beispiel, um flüchtigen Speicher als emptyDir-Volume zu verwenden

Ein GKE-Knotenpool kann für die Verwendung lokaler SSDs für sitzungsspezifischen Speicher, einschließlich emptyDir-Volumes, konfiguriert werden.

Hier ist ein Beispiel für eine YAML-Datei für einen Pod, der ein emptyDir und einen Knotenselektor von cloud.google.com/gke-ephemeral-storage-local-ssd verwendet. Sie können ein ähnliches Verfahren für Deployments oder StatefulSets anwenden.

apiVersion: v1
kind: Pod
metadata:
  name: pod-name
spec:
  containers:
    - name: container-name
      image: "k8s.gcr.io/pause"
      resources:
        requests:
          ephemeral-storage: "400Gi"
      volumeMounts:
        - mountPath: /cache
          name: scratch-volume
  nodeSelector:
    cloud.google.com/gke-ephemeral-storage-local-ssd: "true"
  volumes:
    - name: scratch-volume
      emptyDir: {}

Nächste Schritte