Nichtflüchtige Volumes und dynamische Bereitstellung

Diese Seite bietet einen Überblick über nichtflüchtige Volumes und Anforderungen in Kubernetes und deren Verwendung mit Google Kubernetes Engine (GKE). Der Schwerpunkt dieses Artikels ist das Speichern in nichtflüchtigem Compute Engine-Speicher.

Diese Seite richtet sich an Speicherspezialisten, die Speicherplatz erstellen und zuweisen sowie Datensicherheit, Datenschutz sowie Zugriff und Berechtigungen konfigurieren und verwalten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

PersistentVolumes

Ressourcen vom Typ PersistentVolume dienen zur Verwaltung von dauerhaftem Speicher in einem Cluster. In GKE wird für PersistentVolume normalerweise ein nichtflüchtiger Speicher unterstützt.

Sie können stattdessen andere Speicherlösungen wie NFS verwenden. Filestore ist eine NFS-Lösung in Google Cloud. Informationen zum Einrichten einer Filestore-Instanz als NFS-PV-Lösung für Ihre GKE-Cluster finden Sie in der Filestore-Dokumentation unter Mit dem Filestore-CSI-Treiber auf Filestore-Instanzen zugreifen.

Der Lebenszyklus von PersistentVolume wird in Kubernetes verwaltet. Ein PersistentVolume kann dynamisch bereitgestellt werden. Sie müssen den permanenten Speicher nicht manuell erstellen und löschen.

PersistentVolume sind von Pods unabhängige Clusterressourcen. Dies bedeutet, dass der mit einem PersistentVolume verbundene Speicher und die Daten bestehen bleiben, wenn sich der Cluster ändert und Pods gelöscht und neu erstellt werden. PersistentVolume-Ressourcen können dynamisch über PersistentVolumeClaims bereitgestellt oder explizit von einem Clusteradministrator erstellt werden.

Weitere Informationen zu PersistentVolume-Ressourcen finden Sie in der Kubernetes-Dokumentation zu nichtflüchtigen Volumes und in der Referenz zur Persistent Volumes API.

PersistentVolumeClaims

Ein PersistentVolumeClaim ist die Anfrage eines PersistentVolume und der Anspruch darauf. PersistentVolumeClaim-Objekte fordern eine bestimmte Größe, einen Zugriffsmodus und eine StorageClass für das PersistentVolume an. Wenn ein für die Anfrage geeignetes PersistentVolume vorhanden ist oder bereitgestellt werden kann, wird das PersistentVolumeClaim-Objekt an das PersistentVolume gebunden.

Pods verwenden Ansprüche als Volumes. Der Cluster prüft den Anspruch, um das gebundene Volume zu finden, und stellt dieses für den Pod bereit.

Ein weiterer Vorteil der Verwendung von PersistentVolumes und PersistentVolumeClaims ist die Übertragbarkeit. Sie können für verschiedene Cluster und Umgebungen die gleiche Pod-Spezifikation verwenden, da PersistentVolume eine Schnittstelle zum eigentlichen permanenten Speicher sind.

StorageClasses

Volume-Implementierungen wie der CSI-Treiber (Container Storage Interface) für den nichtflüchtigen Speicher von Compute Engine werden über StorageClass-Ressourcen konfiguriert.

GKE erstellt automatisch eine Standard-StorageClass, die den abgestimmten nichtflüchtigen Speichertyp (ext4) verwendet. Die Standard-StorageClass wird verwendet, wenn in einem PersistentVolumeClaim kein StorageClassName angegeben ist. Sie können die bereitgestellte Standard-StorageClass durch eine eigene ersetzen. Eine Anleitung finden Sie unter Standard-StorageClass ändern.

Es besteht die Möglichkeit, benutzerdefinierte StorageClass-Ressourcen zu erstellen, um unterschiedliche Speicherklassen zu beschreiben. Klassen können beispielsweise Dienstqualitätsebenen oder Sicherungsrichtlinien zugeordnet werden. In anderen Speichersystemen werden solche Klassen auch als "Profile" bezeichnet.

Wenn Sie einen Cluster mit Windows-Knotenpools verwenden, müssen Sie eine StorageClass erstellen und einen StorageClassName im PersistentVolumeClaim angeben, da der standardmäßige fstype (ext4) von Windows nicht unterstützt wird. Wenn Sie einen nichtflüchtigen Compute Engine-Speicher nutzen, müssen Sie als Dateispeichertyp NTFS verwenden.

Wenn Sie eine StorageClass definieren, müssen Sie einen Bereitsteller auflisten. In GKE empfehlen wir die Verwendung eines der folgenden Bereitsteller:

PersistentVolumes dynamisch bereitstellen

Meist ist es nicht erforderlich, PersistentVolume-Objekte direkt zu konfigurieren oder nichtflüchtigen Compute Engine-Speicher anzulegen. Sie können stattdessen einen PersistentVolumeClaim erstellen, während von Kubernetes automatisch ein nichtflüchtiger Speicher bereitgestellt wird.

Das folgende Manifest beschreibt eine Anfrage für einen Speicher mit 30 Gibibyte (GiB) an Speicher, der aufgrund seines Zugriffsmodus von jeweils einem Knoten im Lese-/Schreibmodus bereitgestellt werden kann. Außerdem wird ein Pod erstellt, der PersistentVolumeClaim als Volume nutzt.

# pvc-pod-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-demo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi
  storageClassName: standard-rwo
---
kind: Pod
apiVersion: v1
metadata:
  name: pod-demo
spec:
  volumes:
    - name: pvc-demo-vol
      persistentVolumeClaim:
       claimName: pvc-demo
  containers:
    - name: pod-demo
      image: nginx
      resources:
        limits:
          cpu: 10m
          memory: 80Mi
        requests:
          cpu: 10m
          memory: 80Mi
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: pvc-demo-vol

Wenn Sie dieses PersistentVolumeClaim-Objekt mit kubectl apply -f pvc-pod-demo.yaml erstellen, generiert Kubernetes dynamisch ein entsprechendes PersistentVolume-Objekt.

Da die Speicherklasse standard-rwo den Volume-Bindungsmodus WaitForFirstConsumer verwendet, wird das PersistentVolume erst erstellt, wenn ein Pod zur Nutzung des Volumes geplant ist.

Das folgende Beispiel zeigt das erstellte PersistentVolume.

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: pd.csi.storage.gke.io
  finalizers:
  - kubernetes.io/pv-protection
  - external-attacher/pd-csi-storage-gke-io
  name: pvc-c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  uid: d52af557-edf5-4f96-8e89-42a3008209e6
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 30Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: pvc-demo
    namespace: default
    uid: c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  csi:
    driver: pd.csi.storage.gke.io
    csi.storage.k8s.io/fstype: ext4
    volumeAttributes:
      storage.kubernetes.io/csiProvisionerIdentity: 1660085000920-8081-pd.csi.storage.gke.io
    volumeHandle: projects/xxx/zones/us-central1-c/disks/pvc-c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.gke.io/zone
          operator: In
          values:
          - us-central1-c
  persistentVolumeReclaimPolicy: Delete
  storageClassName: standard-rwo
  volumeMode: Filesystem
status:
  phase: Bound

Wenn Sie die Speicherklasse standard-rwo nicht ersetzt haben, wird dieses PersistentVolume in einem neuen, leeren nichtflüchtigen Compute Engine-Speicher abgelegt.

Nichtflüchtigen Speicher löschen

Standardmäßig wird beim Löschen eines PersistentVolumeClaim für dynamisch bereitgestellte Volumes wie den nichtflüchtigen Compute Engine-Speichern sowohl das PersistentVolume-Objekt als auch das tatsächliche Sicherungslaufwerk gelöscht. Dieses Verhalten wird durch die Reaktivierungsrichtlinie in der StorageClass und im PersistentVolume gesteuert, die auf den Standardwert Delete oder Retain festgelegt werden kann. Weitere Informationen finden Sie in der Kubernetes-Dokumentation zur Reaktivierung.

Um Datenverluste beim Löschen von nichtflüchtigen Speichern zu vermeiden oder zu minimieren, empfehlen wir, Sicherung für GKE zu aktivieren und reguläre Sicherungen Ihres GKE-Clusters zu planen. einschließlich der bereitgestellten Arbeitslasten und ihrer Daten.

Nichtflüchtigen Speicher beim Löschen des Clusters verwalten

Wenn ein GKE-Cluster gelöscht wird, behält GKE PersistentVolume-Ressourcen mit der Reaktivierungsrichtlinie Delete oder Retain bei.

Um PersistentVolume-Ressourcen beim Löschen eines Clusters zu entfernen, können Sie den Namespace von PersistentVolumeClaim-Ressourcen manuell löschen. Dies führt zum Löschen von PersistentVolume-Objekten mit der Richtlinie Delete. Alternativ können Sie einzelne PersistentVolumeClaim-Ressourcen löschen. GKE wartet jedoch nicht, bis diese Löschaktivitäten abgeschlossen sind, bevor der Cluster gelöscht wird. Wenn Sie also einen Namespace und dann sofort den Cluster löschen, werden PersistentVolume-Ressourcen mit Delete-Richtlinien möglicherweise nicht gelöscht.

Nach dem Löschen des Clusters können Sie die verbleibenden PersistentVolume-Ressourcen in der Google Cloud Console anzeigen lassen.

Wenn Sie nicht verwendete Ressourcen aufrufen möchten, z. B. nicht verwendete PersistentVolume-Ressourcen, können Sie sich Empfehlungen für inaktive Ressourcen ansehen

Zugriffsmodi

PersistentVolume-Ressourcen unterstützen die folgenden Zugriffsmodi:

  • ReadWriteOnce: Das Volume kann mit Lese-/Schreibzugriff von einem einzelnen Knoten bereitgestellt werden.
  • ReadOnlyMany: Das Volume kann schreibgeschützt von vielen Knoten bereitgestellt werden.
  • ReadWriteMany: Das Volume kann mit Lese-/Schreibzugriff von vielen Knoten bereitgestellt werden. PersistentVolume-Ressourcen, die von nichtflüchtigen Compute Engine-Speichern gesichert werden, unterstützen diesen Zugriffsmodus nicht.

Nichtflüchtige Compute Engine-Speicher als ReadOnlyMany verwenden

ReadWriteOnce ist der häufigste Anwendungsfall für nichtflüchtigen Speicher und der Standardzugriffsmodus der meisten Anwendungen. Nichtflüchtiger Compute Engine-Speicher unterstützt auch den ReadOnlyMany-Modus. Dadurch können mehrere Anwendungen oder mehrere Replikate derselben Anwendung denselben Speicher gleichzeitig nutzen. Sie haben beispielsweise die Möglichkeit, statische Inhalte auf mehreren Replikaten zur Verfügung zu stellen.

Eine Anleitung finden Sie unter Nichtflüchtige Speicher mit mehreren Lesezugriffen verwenden.

Bestehenden nichtflüchtigen Speicher als PersistentVolumes verwenden

Dynamisch bereitgestellte PersistentVolume-Ressourcen sind bei der Erstellung leer. Wenn Sie einen nichtflüchtigen Compute Engine-Speicher haben, der mit Daten gefüllt ist, können Sie diesen in Ihren Cluster einbinden. Erstellen Sie hierfür manuell eine entsprechende PersistentVolume-Ressource. Der nichtflüchtige Speicher muss sich in derselben Zone wie die Clusterknoten befinden.

In diesem Beispiel wird erläutert, wie Sie ein PersistentVolume mit einem vorhandenen nichtflüchtigen Speicher erstellen.

Deployments oder StatefulSets

Sie können in übergeordneten Controllern wie Deployments oder StatefulSets PersistentVolumeClaim bzw. VolumeClaim-Vorlagen verwenden.

Deployments sind für zustandslose Anwendungen vorgesehen. Daher verwenden alle Replikate eines Deployments denselben PersistentVolumeClaim. Da die erstellten Pod-Replikate identisch sind, funktionieren damit nur Volumes im ReadWriteMany-Modus.

Auch von Deployments mit nur einem Replikat, das ein ReadWriteOnce-Volume verwendet, wird abgeraten. Der Grund dafür ist, dass mit der Standard-Deployment-Strategie bei einer Neuerstellung ein zweiter Pod erstellt wird, ohne vorher den ersten Pod zu löschen. Das Deployment kann aufgrund eines Deadlocks fehlschlagen. Der zweite Pod kann dabei nicht gestartet werden, da das ReadWriteOnce-Volume bereits verwendet wird. Der erste Pod wird dann nicht entfernt, da der zweite Pod noch nicht gestartet wurde. Verwenden Sie stattdessen ein StatefulSet mit ReadWriteOnce-Volumes.

StatefulSets sind die empfohlene Bereitstellungsmethode für zustandsorientierte Anwendungen, die pro Replikat ein eindeutiges Volume erfordern. Wenn Sie StatefulSets mit PersistentVolumeClaim-Vorlagen verwenden, können Sie Anwendungen nutzen, die sich durch die jedem Pod-Replikat zugeordneten eindeutigen PersistentVolumeClaims automatisch vertikal skalieren lassen.

Regionale nichtflüchtige Speicher

Regionale nichtflüchtige Speicher sind multizonale Ressourcen, die Daten zwischen zwei Zonen in derselben Region replizieren und ähnlich wie zonale nichtflüchtige Speicher verwendet werden können. Beim Ausfall in einer Zone oder wenn sich Clusterknoten in einer Zone nicht mehr planen lassen, kann Kubernetes Arbeitslasten mithilfe des Volumes per Failover in die andere Zone übertragen. Regionaler nichtflüchtiger Speicher bietet die Möglichkeit, hochverfügbare Lösungen für zustandsorientierte Arbeitslasten in GKE zu erstellen. Sie müssen dafür sorgen, dass die primäre Zone und die Failover-Zone mit ausreichend Ressourcenkapazität zum Ausführen der Arbeitslast konfiguriert sind.

Regionaler nichtflüchtiger Speicher in Form von SSD-Laufwerken kann optional für Anwendungen wie etwa Datenbanken verwendet werden, die eine hohe Verfügbarkeit und Leistung erfordern. Weitere Informationen finden Sie unter Blockspeicher im Leistungsvergleich.

Ebenso wie zonaler nichtflüchtiger Speicher kann auch regionaler nichtflüchtiger Speicher dynamisch nach Bedarf oder vorab manuell vom Clusteradministrator bereitgestellt werden. Informationen zum Hinzufügen regionaler nichtflüchtiger Speicher finden Sie unter Regionalen nichtflüchtigen Speicher bereitstellen.

Zonen in nichtflüchtigen Speichern

Zonale nichtflüchtige Speicher sind zonale Ressourcen und regionale nichtflüchtige Speicher sind multizonale Ressourcen. Wenn Sie dem Cluster nichtflüchtigen Speicher hinzufügen, weist GKE den Speicher einer einzigen Zone zu, sofern keine Zone angegeben ist. GKE wählt die Zone zufällig aus. Wenn nichtflüchtiger Speicher bereitgestellt wurde, werden alle Pods, die auf den Speicher verweisen, für dieselbe Zone wie der nichtflüchtige Speicher geplant. Pods oder Deployments erkennen jedoch die Zone bereits vorhandener nichtflüchtiger Speicher nicht von Natur aus. Damit Pods mit bereits vorhandenen nichtflüchtigen Speichern korrekt geplant werden, verwenden Sie zonale Platzierungsmethoden wie nodeAffinity in Ihrem Pod oder Deployment. Spezifikationen, um auf die entsprechenden Zonen auszurichten.

Volume-Bindungsmodus WaitForFirstConsumer

Wenn Sie einen nichtflüchtigen Speicher in Ihrem Cluster dynamisch bereitstellen, sollten Sie den Modus für die Volume-Bindung WaitForFirstConsumer für Ihre StorageClass festlegen. Mit dieser Einstellung wird Kubernetes angewiesen, einen nichtflüchtigen Speicher in derselben Zone bereitzustellen, in der der Pod geplant ist. Dabei werden Einschränkungen bei der Pod-Planung wie Anti-Affinität und Knotenselektoren berücksichtigt. Durch Anti-Affinität in Zonen können StatefulSet-Pods zusammen mit den entsprechenden Laufwerken auf die Zonen verteilt werden.

Im Folgenden finden Sie eine Beispiel-StorageClass zum Bereitstellen zonaler nichtflüchtiger Speicher, die WaitForFirstConsumer festlegen:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-balanced
  csi.storage.k8s.io/fstype: ext4
volumeBindingMode: WaitForFirstConsumer

Ein Beispiel für die Verwendung regionaler nichtflüchtiger Speicher finden Sie unter Regionalen nichtflüchtigen Speicher bereitstellen.

Nächste Schritte