CSI-Treiber für nichtflüchtigen Speicher der Compute Engine verwenden

Autopilot Standard

Google Kubernetes Engine (GKE) bietet eine einfache Möglichkeit zur automatischen Bereitstellung und Verwaltung des Compute Engine persistent disk Container Storage Interface (CSI) Driver in Ihren Clustern. Der CSI-Treiber für nichtflüchtigen Speicher von Compute Engine ist in Autopilot-Clustern immer aktiviert und kann nicht deaktiviert oder bearbeitet werden. In Standardclustern müssen Sie den CSI-Treiber für den nichtflüchtigen Speicher von Compute Engine aktivieren.

Die Version des CSI-Treibers für den nichtflüchtigen Speicher von Compute Engine ist an die GKE-Versionsnummern gebunden. Die CSI-Treiberversion für nichtflüchtigen Speicher von Compute Engine ist normalerweise der neueste Treiber, der bei der Veröffentlichung der GKE-Version verfügbar ist. Die Treiber werden automatisch aktualisiert, wenn ein Upgrade des Clusters auf den neuesten GKE-Patch durchgeführt wird.

Hinweis: Da der CSI-Treiber für den nichtflüchtigen Speicher von Compute Engine und einige der zugehörigen CSI-Komponenten als separate Container bereitgestellt werden, verbrauchen sie Ressourcen (VM-CPU, Arbeitsspeicher und Bootlaufwerk) auf Kubernetes-Knoten. Die CPU-Auslastung der VM liegt in der Regel im Bereich von Zehntausenden von Millicores und die Arbeitsspeichernutzung im Bereich von Zehntausenden von MB. Die Nutzung des Bootlaufwerks wird hauptsächlich durch die Logs des CSI-Treibers und anderer Systemcontainer im Deployment bestimmt.

Vorteile

Die Verwendung des CSI-Treibers für nichtflüchtigen Speicher von Compute Engine bietet folgende Vorteile:

• Dadurch werden das automatische Deployment und die automatische Verwaltung des Treibers für nichtflüchtigen Speicher ohne manuelle Einrichtung aktiviert.
• Sie können kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEKs) verwenden. Mit diesen Schlüsseln werden Datenverschlüsselungsschlüssel verschlüsselt, die wiederum Ihre Daten verschlüsseln. Weitere Informationen zu CMEK in GKE finden Sie unter CMEK verwenden.
• Sie können Volume-Snapshots mit dem CSI-Treiber für nichtflüchtigen Speicher von Compute Engine verwenden. Mit Volume-Snapshots können Sie eine Kopie Ihres Volumes zu einem bestimmten Zeitpunkt erstellen. Mit dieser Kopie können Sie ein Volume auf einen vorherigen Zustand zurücksetzen oder ein neues Volume bereitstellen.
• Sie können das Klonen von Volumes mit dem CSI-Treiber für den nichtflüchtigen Speicher von Compute Engine in Clustern mit GKE Version 1.22 und höher verwenden. Mit dem Klonen von Volumes können Sie zu einem bestimmten Zeitpunkt ein Duplikat Ihres Volumes erstellen, das mit allen Daten des Quellvolumes ausgestattet ist.
• Fehlerkorrekturen und Funktionsupdates werden unabhängig von Kubernetes-Nebenversionen eingeführt. Dieser Releasezeitplan führt in der Regel zu einem schnelleren Releaserhythmus.

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

CSI-Treiber für nichtflüchtigen Speicher von Compute Engine aktivieren

Verwenden Sie das Google Cloud CLI oder die Google Cloud Console, um den CSI-Treiber für nichtflüchtigen Speicher von Compute Engine in vorhandenen Standard-Clustern zu aktivieren.

Führen Sie die folgenden Schritte aus, um den Treiber auf einem vorhandenen Cluster zu aktivieren:

gcloud

gcloud container clusters update CLUSTER-NAME \
   --update-addons=GcePersistentDiskCsiDriver=ENABLED

Ersetzen Sie CLUSTER-NAME durch den Namen des vorhandenen Clusters.

Console

1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

   Zur Seite "Google Kubernetes Engine"

2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.

3. Klicken Sie unter Features neben dem Feld CSI-Treiber für nichtflüchtigen Speicher von Compute Engine auf CSI-Treiber für Compute Engine bearbeiten.

4. Klicken Sie auf das Kästchen CSI-Treiber für den nichtflüchtigen Speicher von Compute Engine aktivieren.

5. Klicken Sie auf Änderungen speichern.

Nachdem Sie den CSI-Treiber für nichtflüchtigen Speicher von Compute Engine aktiviert haben, können Sie den Treiber in Kubernetes-Volumes mit dem Namen des Treibers und des Bereitstellers verwenden: pd.csi.storage.gke.io.

CSI-Treiber für nichtflüchtigen Speicher der Compute Engine deaktivieren

Sie können den CSI-Treiber für den nichtflüchtigen Speicher von Compute Engine für Standardcluster mithilfe des Google Cloud CLI oder der Google Cloud Konsole deaktivieren.

Wenn Sie den Treiber deaktivieren, werden alle Pods, die aktuell zum Treiber gehörende PersistentVolumes verwenden, nicht beendet. Alle neuen Pods, die diese PersistentVolumes nutzen möchten, können auch nicht gestartet werden.

Hinweis: Wenn Sie den Volume-Typ gcePersistentDisk zum CSI-Treiber für nichtflüchtigen Speicher von Compute Engine in Version 1.22 und höher migrieren und wenn Sie später den CSI-Treiber für nichtflüchtigen Speicher deaktivieren, funktioniert der Volume-Typ gcePersistentDisk nicht mehr.

Warnung: Es gibt ein bekanntes Problem in GKE bis Version 1.21 und wenn Sie den integrierten Treiber für nichtflüchtige Speicher verwenden und regionale Laufwerke löschen möchten. Ein regionales Compute Engine-Laufwerk kann gehackt werden, wenn die zugehörige PersistentVolume-Ressource gelöscht wird. Dieses Problem kann erkannt werden, wenn Ihr API-Aufruf zum Löschen des regionalen Speichers fehlschlägt und einen anderen Fehlercode als NotFound zurückgibt. Weitere Informationen finden Sie in diesem GitHub-Problem.

Um den Treiber in einem vorhandenen Standard-Cluster zu deaktivieren, führen Sie folgende Schritte aus:

gcloud

gcloud container clusters update CLUSTER-NAME \
    --update-addons=GcePersistentDiskCsiDriver=DISABLED

Ersetzen Sie CLUSTER-NAME durch den Namen des vorhandenen Clusters.

Console

1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

   Zur Seite "Google Kubernetes Engine"

2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.

3. Klicken Sie unter Features neben dem Feld CSI-Treiber für nichtflüchtigen Speicher von Compute Engine auf CSI-Treiber für Compute Engine bearbeiten.

4. Entfernen Sie den Haken im Kästchen CSI-Treiber für nichtflüchtigen Speicher von Compute Engine aktivieren.

5. Klicken Sie auf Änderungen speichern.

CSI-Treiber für nichtflüchtigen Speicher von Compute Engine für Linux-Cluster verwenden

In den folgenden Abschnitten wird das typische Verfahren zur Verwendung eines Kubernetes-Volumes beschrieben, das von einem CSI-Treiber in GKE unterstützt wird. Diese Abschnitte gelten nur für Cluster mit Linux.

StorageClass erstellen

Nachdem Sie den CSI-Treiber für den nichtflüchtigen Speicher von Compute Engine aktiviert haben, installiert GKE die folgenden StorageClasses automatisch:

• standard-rwo mit abgestimmtem nichtflüchtigem Speicher
• premium-rwo mit nichtflüchtigem SSD-Speicher

Bei Autopilot-Clustern lautet die Standard-StorageClass standard-rwo. Diese nutzt den CSI-Treiber für nichtflüchtigen Speicher von Compute Engine. Bei Standard-Clustern verwendet die Standard-StorageClass das integrierte Kubernetes-Volume-Plug-in gcePersistentDisk.

Sie finden den Namen der installierten StorageClasses mit dem folgenden Befehl:

kubectl get sc

Sie können auch eine andere StorageClass installieren, die den CSI-Treiber für nichtflüchtigen Speicher von Compute Engine verwendet. Geben Sie dazu pd.csi.storage.gke.io im Feld "Bereitsteller" ein.

Sie könnten beispielsweise eine StorageClass anhand der Datei pd-example-class.yaml erstellen:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-example
provisioner: pd.csi.storage.gke.io
# Recommended setting. Delays the binding and provisioning of a PersistentVolume until a Pod that uses the
# PersistentVolumeClaim is created and scheduled on a node.
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-balanced

Sie können im type-Parameter die folgenden nichtflüchtigen Speichertypen angeben:

• pd-balanced
• pd-ssd
• pd-standard
• pd-extreme (ab GKE-Version 1.26 unterstützt)

Wenn Sie pd-standard oder pd-extreme verwenden, finden Sie unter Nicht unterstützte Maschinentypen weitere Nutzungseinschränkungen.

Wenn Sie die Option pd-extreme verwenden, müssen Sie dem Manifest auch das Feld provisioned-iops-on-create hinzufügen. Dieses Feld muss auf den gleichen Wert gesetzt werden wie der bereitgestellte IOPS-Wert, den Sie beim Erstellen des nichtflüchtigen Speichers angegeben haben.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-extreme-example
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-extreme
  provisioned-iops-on-create:'10000'

Führen Sie nach dem Erstellen der Datei pd-example-class.yaml den folgenden Befehl aus:

kubectl create -f pd-example-class.yaml

PersistentVolumeClaim erstellen

Sie können einen PersistentVolumeClaim erstellen, der auf die StorageClass des CSI-Treibers für nichtflüchtigen Speicher von Compute Engine verweist.

Die folgende Datei namens pvc-example.yaml verwendet die vorinstallierte Speicherklasse standard-rwo:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: standard-rwo
  resources:
    requests:
      storage: 6Gi

Führen Sie nach dem Erstellen des PersistentVolumeClaim-Manifests den folgenden Befehl aus:

kubectl create -f pvc-example.yaml

In der vorinstallierten StorageClass standard-rwo ist volumeBindingMode auf WaitForFirstConsumer festgelegt. Wenn volumeBindingMode auf WaitForFirstConsumer festgelegt ist, wird das PersistentVolume erst bereitgestellt, wenn ein Pod geplant ist, der auf den PersistentVolumeClaim verweist. Wenn volumeBindingMode in der StorageClass auf Immediate festgelegt ist oder ausgelassen wird, wird das durch den nichtflüchtigen Speicher gesicherte PersistentVolume bereitgestellt, nachdem der PersistentVolumeClaim erstellt wurde.

Pod erstellen, der das Volume verbraucht

Bei der Verwendung von Pods mit PersistentVolumes empfehlen wir die Verwendung eines Workload-Controllers (z. B. Deployment oder StatefulSet). Obwohl Sie normalerweise keinen eigenständigen Pod verwenden würden, wird in diesem Beispiel einer verwendet, um die Sache zu vereinfachen.

Im folgenden Beispiel wird das Volume verwendet, das Sie im vorherigen Abschnitt erstellt haben:

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  containers:
   - name: web-server
     image: nginx
     volumeMounts:
       # The path in the container where the volume will be mounted.
       - mountPath: /var/lib/www/html
         # The name of the volume that is being defined in the "volumes" section.
         name: mypvc
  volumes:
   - name: mypvc
     persistentVolumeClaim:
       # References the PersistentVolumeClaim created earlier.
       claimName: podpvc
       readOnly: false

Planung der Speicherkompatibilität in GKE Autopilot

In Autopilot-Clustern verwaltet die GKE automatisch die Knotenbereitstellung und die Ressourcenzuweisung. Damit Autopilot Knoten bereitstellt, die mit dem angeforderten Speichertyp kompatibel sind, müssen Sie den Parameter use-allowed-disk-topology: "true" in Ihrer benutzerdefinierten StorageClass-Definition angeben.

Wenn Sie diesen Parameter konfigurieren, wird das folgende Planungsverhalten erzwungen:

• Cluster Autoscaler stellt nur neue Knoten mit Maschinentypen bereit, die den angeforderten Laufwerkstyp unterstützen.
• Der Pod wird auf einem kompatiblen Knoten geplant. Durch diese Planung wird verhindert, dass der Pod im Status ContainerCreating oder Pending hängen bleibt.

Weitere Informationen finden Sie unter Unterstützte Knotenplanung.

Neuere Maschinenserien wie C3 oder E4 erfordern Google Cloud Hyperdisk-Speicher (z. B. hyperdisk-balanced). Diese Maschinenserien unterstützen keine älteren nichtflüchtigen Speicher-Volumes wie nichtflüchtige Standardspeicher (pd-standard) oder nichtflüchtige SSD-Speicher (pd-ssd). Die Speicherkompatibilität wirkt sich so auf die Planung aus:

• Stiller Fallback: Wenn eine zustandsorientierte Arbeitslast einen älteren Persistent Disk-Volumetyp wie nichtflüchtiger Standardspeicher (pd-standard) oder nichtflüchtiger SSD-Speicher (pd-ssd) verwendet, aber keine bestimmte Maschinenreihe explizit anfordert, ordnet GKE die Pods automatisch E2-Knoten zu, da diese Persistent Disk-Volumetypen unterstützt werden. Die Arbeitslast wird im Hintergrund von der standardmäßigen neueren Hardware zurückgesetzt.
• Planungsfehler (Ausstehend): Möglicherweise haben Sie explizit eine neuere Maschinenserie angefordert, z. B. mit nodeSelector-Feldern oder einer benutzerdefinierten ComputeClass. Wenn Sie auch einen früheren Persistent Disk-Volumetyp anhängen, z. B. nichtflüchtiger Standardspeicher (pd-standard) oder nichtflüchtiger SSD-Speicher (pd-ssd), kann GKE keinen Knoten finden, der beide Einschränkungen erfüllt. Der Pod verbleibt im Status Pending.
• Konflikt mit mehreren Speichertypen (ausstehend): Wenn in einem Pod auf mehrere PVCs verwiesen wird, die unterschiedliche Speichertypen verwenden (z. B. eine Kombination aus einem früheren Persistent Disk-Volumetyp wie nichtflüchtiger Standardspeicher (pd-standard) und Google Cloud Hyperdisk-Speicher), kann GKE möglicherweise keinen Knotentyp finden, der alle Einschränkungen unterstützt. In diesem Szenario verbleibt der Pod im Status Pending.
• Unzureichende CPU-Anfrage für Extreme-Laufwerke (Ausstehend): Für Extreme-Volumetypen wie hyperdisk-extreme und pd-extreme sind große VM-Typen mit einer hohen Anzahl von vCPUs erforderlich. Wenn Ihr Pod zu wenige vCPUs anfordert, stellt GKE möglicherweise eine Knotenform bereit, die den Volume-Typ nicht unterstützt. Dadurch bleibt der Pod im Status Pending. Damit die Planung ordnungsgemäß erfolgt, geben Sie CPU-Anforderungen an, die groß genug sind, damit Autopilot eine unterstützte VM-Form bereitstellt. Eine Liste der unterstützten Maschinentypen und der Mindestanforderungen an vCPUs finden Sie unter Maschinenunterstützung.

Schritte zur Fehlerbehebung und Details dazu, wie Sie dieses Verhalten durch Untersuchen von Logs überprüfen können, finden Sie unter Arbeitslast, die auf älteren Maschinenserien geplant ist oder aufgrund von Speicherinkompatibilität im Status Pending hängen bleibt.

CSI-Treiber für nichtflüchtigen Speicher von Compute Engine für Windows-Cluster verwenden

In den folgenden Abschnitten wird das typische Verfahren zur Verwendung eines Kubernetes-Volumes beschrieben, das von einem CSI-Treiber in GKE unterstützt wird. Diese Abschnitte gelten nur für Cluster mit Windows.

Es müssen folgende Versionen vorhanden sein:

• Die Clusterversion muss 1.19.7-gke.2000, 1.20.2-gke.2000 oder höher sein.
• Die Knotenversionen müssen 1.18.12-gke.1203, 1.19.6-gke.800 oder höher sein.

StorageClass erstellen

Das Erstellen einer StorageClass für Windows ist dem für Linux sehr ähnlich. Beachten Sie aber, dass die standardmäßig installierte StorageClass für Windows nicht funktioniert, da sich deren Dateisystemtyp unterscheidet. Der CSI-Treiber für nichtflüchtigen Speicher von Compute Engine erfordert NTFS als Dateisystemtyp.

Sie können beispielsweise eine StorageClass anhand der Datei pd- windows-class.yaml erstellen. Fügen Sie der Parameterliste csi.storage.k8s.io/fstype: NTFS hinzu:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-sc-windows
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-balanced
  csi.storage.k8s.io/fstype: NTFS

PersistentVolumeClaim erstellen

Nach dem Anlegen einer StorageClass für Windows können Sie einen PersistentVolumeClaim erstellen, der auf diese StorageClass verweist:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc-windows
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: pd-sc-windows
  resources:
    requests:
      storage: 6Gi

Pod erstellen, der das Volume verbraucht

Im folgenden Beispiel wird das Volume verwendet, das Sie in der vorherigen Aufgabe erstellt haben:

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  # Node selector to ensure the Pod runs on a Windows node.
  nodeSelector:
    kubernetes.io/os: windows
  containers:
    - name: iis-server
      # The container image to use.
      image: mcr.microsoft.com/windows/servercore/iis
      ports:
      - containerPort: 80
      volumeMounts:
      # The path in the container where the volume will be mounted.
      - mountPath: /var/lib/www/html
        name: mypvc
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        # References the PersistentVolumeClaim created earlier.
        claimName: podpvc-windows
        readOnly: false

IOPS und Durchsatz von Hyperdisk dynamisch mit VolumeAttributeClass ändern

Sie können VolumeAttributesClass mit dem CSI-Treiber für nichtflüchtigen Speicher von Compute Engine verwenden, um Attribute für nichtflüchtigen Speicher, einschließlich IOPS und Durchsatz, dynamisch zu ändern. Achten Sie darauf, dass die GKE-Clusterversion 1.34 oder höher ist.

In diesem Abschnitt wird gezeigt, wie Sie VolumeAttributesClass verwenden, um die Volume-Leistung dynamisch zu ändern. Sie erstellen zwei VolumeAttributesClass-Ressourcen, silver und gold, um verschiedene IOPS- und Durchsatzstufen zu definieren. Anschließend erstellen Sie ein StorageClass, ein PersistentVolumeClaim, das auf die silver-Stufe verweist, und einen Pod, der das Volume nutzt. Schließlich aktualisieren Sie die PersistentVolumeClaim, um auf die gold-Stufe zu verweisen. Dadurch werden die Leistungseinstellungen des Volumes dynamisch aktualisiert.

Hinweis :StorageClass- und Pod-Manifeste für die allgemeine Verwendung von Persistent Disk-Volumes werden zwar weiter oben auf dieser Seite behandelt, der folgende Workflow ist jedoch erforderlich, um die spezifischen Leistungsmerkmale von Google Cloud Hyperdisk zu konfigurieren und zu überprüfen.

VolumeAttributesClass erstellen, um Leistungsstufen zu definieren

In diesem Abschnitt werden VolumeAttributesClass-Ressourcen mit den Beispielstufen silver und gold definiert.

1. Speichern Sie das folgende Manifest als vac-classes.yaml:

   apiVersion: storage.k8s.io/v1
   kind: VolumeAttributesClass
   metadata:
     name: silver
   driverName: pd.csi.storage.gke.io
   parameters:
     iops: "3000"
     throughput: "188Mi"
   ---
   apiVersion: storage.k8s.io/v1
   kind: VolumeAttributesClass
   metadata:
     name: gold
   driverName: pd.csi.storage.gke.io
   parameters:
     iops: "6000"
     throughput: "345Mi"
   

2. Wenden Sie das Manifest an:

   kubectl apply -f vac-classes.yaml
   

StorageClass für Hyperdisk erstellen

In diesem Abschnitt wird eine StorageClass-Ressource zum Bereitstellen von Hyperdisk-Volumes definiert.

1. Speichern Sie das folgende Manifest als hyperdisk-sc.yaml:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: hyperdisk-example
   provisioner: pd.csi.storage.gke.io
   volumeBindingMode: WaitForFirstConsumer
   allowVolumeExpansion: true
   parameters:
     type: hyperdisk-balanced
   

2. Wenden Sie das Manifest an:

   kubectl apply -f hyperdisk-sc.yaml
   

PVC mit einer anfänglichen Leistungsstufe erstellen

In diesem Abschnitt wird ein PVC erstellt und die anfängliche Stufe mit dem Namen silver verwendet.

1. Speichern Sie das folgende Manifest als vac-silver-pvc.yaml:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: test-pv-claim
   spec:
     accessModes:
     - ReadWriteOnce
     storageClassName: hyperdisk-example
     volumeAttributesClassName: silver
     resources:
       requests:
         storage: 200Gi
   

2. Wenden Sie das Manifest an:

   kubectl apply -f vac-silver-pvc.yaml
   

3. Um ein PersistentVolume bereitzustellen, erstellen Sie einen Pod, der den PVC verwendet. Die im vorherigen Abschnitt erstellte StorageClass legt volumeBindingMode: WaitForFirstConsumer fest, wodurch die Volume-Bereitstellung verzögert wird, bis ein Pod den PVC verwendet. Speichern Sie das folgende Manifest als test-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: test-pvc-pod
   spec:
     containers:
       - name: nginx-container
         image: nginx:latest
         ports:
           - containerPort: 80
         volumeMounts:
           - name: pvc-storage
             mountPath: /usr/share/nginx/html
     volumes:
       - name: pvc-storage
         persistentVolumeClaim:
           claimName: test-pv-claim
   

4. Wenden Sie das Manifest an:

   kubectl apply -f test-pod.yaml
   

5. Informationen zum Prüfen der Einstellungen für die Laufwerksleistung finden Sie unter Einstellungen für die Laufwerksleistung in der Google Cloud Console prüfen. Die bereitgestellten IOPS sollten 3000 und der bereitgestellte Durchsatz 188 sein.

PVC für die Verwendung einer anderen Leistungsstufe aktualisieren

In diesem Abschnitt wird der PVC so aktualisiert, dass er das Tier gold anstelle des Tiers silver verwendet.

1. Speichern Sie das folgende Manifest als vac-gold-pvc.yaml:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: test-pv-claim
   spec:
     accessModes:
     - ReadWriteOnce
     storageClassName: hyperdisk-example
     volumeAttributesClassName: gold
     resources:
       requests:
         storage: 200Gi
   

2. Wenden Sie das Manifest an:

   kubectl apply -f vac-gold-pvc.yaml
   

3. Informationen zum Prüfen, ob die Einstellungen für die Laufwerksleistung aktualisiert wurden, finden Sie unter Einstellungen für die Laufwerksleistung in der Google Cloud Console prüfen. Die bereitgestellten IOPS sollten 6000 und der bereitgestellte Durchsatz sollte 345 sein.

Einstellungen für die Datenträgerleistung in der Google Cloud -Konsole prüfen

Sie können prüfen, ob die IOPS- und Durchsatzeinstellungen auf den nichtflüchtigen Speicher angewendet wurden, indem Sie die Festplattendetails in der Google Cloud -Konsole aufrufen.

1. Rufen Sie den Namen des Laufwerks ab:

   PV_NAME=$(kubectl get pvc test-pv-claim -o=jsonpath='{.spec.volumeName}')
   DISK_NAME=$(kubectl get pv $PV_NAME -o=jsonpath='{.spec.csi.volumeHandle}' | sed 's|.*/||')
   echo "Persistent disk name: $DISK_NAME"
   

2. Rufen Sie in der Google Cloud Console die Seite Laufwerke auf.

   Zur Seite „Laufwerke“

3. Klicken Sie auf den Namen des nichtflüchtigen Speichers, der mit dem Laufwerksnamen aus der Ausgabe des vorherigen Schritts übereinstimmt.

4. Sehen Sie sich auf der Seite Laufwerkdetails im Abschnitt Leistung die Werte für Bereitgestellte IOPS und Bereitgestellter Durchsatz an.

Weitere Informationen finden Sie unter Bereitgestellte Leistungseinstellungen für Hyperdisk aufrufen.

Überlegungen zur dynamischen Änderung

• Vorherige Konfigurationen noch einmal anwenden:Wenn ein PVC aufgrund eines Fehlers, z. B. nicht verfügbarer Ressourcen, nicht an eine Volume-Attributklasse gebunden werden kann, können Sie das vorherige PVC problemlos noch einmal anwenden.
• Kontingentunterstützung: Die Kubernetes-Steuerungsebene kann Kontingente für PVCs erzwingen, die auf eine bestimmte VolumeAttributesClass verweisen, indem scopeSelector in ResourceQuota verwendet wird.

CSI-Treiber für nichtflüchtigen Speicher von Compute Engine mit nicht standardmäßigen Dateisystemtypen verwenden

Der Standarddateisystemtyp für Compute Engine Persistent Disks in GKE ist ext4. Sie können auch den Speichertyp xfs verwenden, sofern Ihr Knoten-Image dies unterstützt. Unter Unterstützung für Speichertreiber finden Sie eine Liste der unterstützten Treiber nach Knoten-Image.

Das folgende Beispiel zeigt, wie Sie xfs als Standarddateisystemtyp anstelle von ext4 mit dem CSI-Treiber für den nichtflüchtigen Speicher von Compute Engine verwenden.

StorageClass erstellen

1. Speichern Sie dieses Manifest als YAML-Datei mit dem Namen pd-xfs-class.yaml:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: xfs-class
   provisioner: pd.csi.storage.gke.io
   parameters:
     # The type of Compute Engine persistent disk to provision.
     type: pd-balanced
     # Specify "xfs" as the filesystem type.
     csi.storage.k8s.io/fstype: xfs
   volumeBindingMode: WaitForFirstConsumer
   

2. Wenden Sie das Manifest an:

   kubectl apply -f pd-xfs-class.yaml
   

PersistentVolumeClaim erstellen

1. Speichern Sie das folgende Manifest als pd-xfs-pvc.yaml:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: xfs-pvc
   spec:
     # References the StorageClass created earlier.
     storageClassName: xfs-class
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         # The amount of storage requested.
         storage: 10Gi
   

2. Wenden Sie das Manifest an:

   kubectl apply -f pd-xfs-pvc.yaml
   

Pod erstellen, der das Volume verbraucht

1. Speichern Sie das folgende Manifest als pd-xfs-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: pd-xfs-pod
   spec:
     containers:
     - name: cloud-sdk
       image: google/cloud-sdk:slim
       # Keep the container running for 1 hour.
       args: ["sleep","3600"]
       volumeMounts:
       # The path in the container where the volume will be mounted.
       - mountPath: /xfs
         name: xfs-volume
     # Define the volumes available to the containers in the Pod.
     volumes:
     - name: xfs-volume
       persistentVolumeClaim:
         # References the PersistentVolumeClaim created earlier.
         claimName: xfs-pvc
   

2. Wenden Sie das Manifest an:

   kubectl apply -f pd-xfs-pod.yaml
   

Korrekte Bereitstellung des Volume prüfen

1. Öffnen Sie eine Shell-Sitzung im Pod:

   kubectl exec -it pd-xfs-pod -- /bin/bash
   

2. Suchen Sie nach xfs-Partitionen:

   df -aTh --type=xfs
   

   Die Ausgabe sollte in etwa so aussehen:

   Filesystem     Type  Size  Used Avail Use% Mounted on
   /dev/sdb       xfs    30G   63M   30G   1% /xfs
   

Logs für den CSI-Treiber für nichtflüchtigen Speicher von Compute Engine ansehen

In Cloud Logging haben Sie die Möglichkeit, Ereignisse aufzurufen, die sich auf den Compute Engine-CSI-Treiber für nichtflüchtigen Speicher beziehen. Logs können Ihnen bei der Fehlerbehebung helfen.

Weitere Informationen zu Cloud Logging finden Sie unter GKE-Logs ansehen.

Führen Sie die folgenden Schritte aus, um Logs für den CSI-Treiber für nichtflüchtigen Speicher von Compute Engine aufzurufen:

1. Rufen Sie in der Google Cloud Console die Seite Cloud Logging auf.

   Zu Cloud Logging

2. Wenn Sie Logeinträge so filtern möchten, dass nur die Einträge angezeigt werden, die sich auf den CSI-Treiber beziehen, der in Ihrem Namespace ausgeführt wird, führen Sie die folgende Cloud Logging-Abfrage aus:

    resource.type="k8s_container"
    resource.labels.project_id="PROJECT_ID"
    resource.labels.location="LOCATION"
    resource.labels.cluster_name="CLUSTER_NAME"
    resource.labels.namespace_name="kube-system"
    resource.labels.container_name="gce-pd-driver"
   

   Ersetzen Sie Folgendes:

   • PROJECT_ID: Name Ihres Projekts
   • LOCATION: Die Compute Engine-Region oder -Zone des Clusters.
   • CLUSTER_NAME: Der Name Ihres Clusters.

Bekannte Probleme

Nicht unterstützte Maschinentypen

Wenn Sie die Maschinenfamilie der C3-Serie verwenden, wird der nichtflüchtige Speichertyp pd-standard nicht unterstützt.

Planung der Autopilot-Speicherkompatibilität

Für Arbeitslasten, die im Autopilot-Modus ausgeführt werden (entweder in Autopilot-Clustern oder in Standard-Clustern mit Autopilot-ComputeClasses), werden Pods mit angehängtem nichtflüchtigem Speicher nur auf kompatiblen Maschinenserien geplant:

• Nichtflüchtige Speicher der alten Generation: Pods, die pd-standard-Speicher der alten Generation verwenden, werden nur auf Maschinenserien ausgeführt, die sie unterstützen, z. B. E2-Knoten.
• Hyperdisk: Pods, die Speicher der nächsten Generation wie hyperdisk-balanced verwenden, werden auf neueren Maschinenserien wie C3-Knoten ausgeführt.
• Status „Ausstehend“: Wenn Sie einen Pod explizit für die Ausführung auf einer neueren Maschinenserie konfigurieren (z. B. durch Verwendung von Knotenauswahlen zum Anfordern von C3-Knoten oder durch Konfiguration einer benutzerdefinierten ComputeClass), aber eine alte pd-standard-Festplatte anhängen, bleibt der Pod auf unbestimmte Zeit im Status Pending. Dies liegt daran, dass GKE keinen Knoten finden kann, der sowohl die Kompatibilitätseinschränkungen für den Maschinentyp als auch für das Laufwerk erfüllt. Wenn Sie explizit eine Maschinenreihe auswählen, sind Sie dafür verantwortlich, dass PersistentVolume und Festplatte kompatibel sind.

Wenn Sie versuchen, einen Pod auf einem Computer auszuführen, und der Pod einen nicht unterstützten nichtflüchtigen Speichertyp verwendet, wird eine Warnmeldung wie die folgende auf dem Pod ausgegeben:

AttachVolume.Attach failed for volume "pvc-d7397693-5097-4a70-9df0-b10204611053" : rpc error: code = Internal desc = unknown Attach error: failed when waiting for zonal op: operation operation-1681408439910-5f93b68c8803d-6606e4ed-b96be2e7 failed (UNSUPPORTED_OPERATION): [pd-standard] features are not compatible for creating instance.

Wenn Ihr Cluster mehrere Knotenpools mit unterschiedlichen Maschinenfamilien hat, können Sie mit Knotenmarkierungen und Knotenaffinität begrenzen, wo die Arbeitslasten geplant werden können. Mit diesem Ansatz können Sie beispielsweise eine Arbeitslast mit pd-standard daran hindern, auf einer nicht unterstützten Maschinenfamilie ausgeführt zu werden.

Wenn Sie den nichtflüchtigen Speichertyp pd-extreme verwenden, müssen Sie dafür sorgen, dass Ihr Laufwerk an eine VM-Instanz mit einer geeigneten Maschinenform angehängt ist. Weitere Informationen finden Sie unter Unterstützung von Maschinenformen.

Nächste Schritte

• Weitere Informationen zur Verwendung der Volume-Erweiterung
• Volume-Snapshots verwenden
• Volumes klonen
• Regionale nichtflüchtige Speicher erstellen
• Weitere Informationen zum Treiber auf GitHub