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.

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 auch 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 Über Google Kubernetes Engine-Cluster auf Dateifreigaben zugreifen.

Eine weitere Speicheroption ist der Cloud Volumes-Dienst. Dieses Produkt ist ein vollständig verwalteter, cloudbasierter Datenspeicherdienst, der erweiterte Datenverwaltungsfunktionen und eine hochgradig skalierbare Leistung bietet. Beispiele finden Sie unter Cloud Volumes-Dienst für Google Cloud.

Im Gegensatz zu Volumes wird der Lebenszyklus von PersistentVolume 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 gcePersistentDisk 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 30-GiB-Speicher, der aufgrund seines Zugriffsmodus von jeweils einem Knoten im Lese-/Schreibmodus bereitgestellt werden kann:

# pvc-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-demo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi

Wenn Sie dieses PersistentVolumeClaim-Objekt mit kubectl apply -f pvc-demo.yaml erstellen, generiert Kubernetes dynamisch ein entsprechendes PersistentVolume-Objekt. Das folgende Beispiel zeigt das erstellte PersistentVolume.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pvc-cd3fd5e9-695a-11ea-a3da-42010a800003
  uid: ced478c1-695a-11ea-a3da-42010a800003
  annotations:
    kubernetes.io/createdby: gce-pd-dynamic-provisioner
    pv.kubernetes.io/bound-by-controller: "yes"
    pv.kubernetes.io/provisioned-by: kubernetes.io/gce-pd
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 30Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: pvc-demo
    uid: cd3fd5e9-695a-11ea-a3da-42010a800003
  gcePersistentDisk:
    fsType: ext4
    pdName: gke-cluster-1-pvc-cd3fd5e9-695a-11ea-a3da-42010a800003
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.kubernetes.io/zone
          operator: In
          values:
          - us-central1-c
        - key: topology.kubernetes.io/region
          operator: In
          values:
          - us-central1
  persistentVolumeReclaimPolicy: Delete
  storageClassName: standard
  volumeMode: Filesystem
status:
  phase: Bound

Wenn Sie die GKE-Standardspeicherklasse beibehalten haben, wird dieses PersistentVolume in einem neuen, leeren nichtflüchtigen Compute Engine-Speicher abgelegt. Damit Sie diesen Speicher in einem Pod nutzen können, müssen Sie den Anspruch als Volume verwenden. Wenn Sie einen Anspruch löschen, werden auch das entsprechende PersistentVolume-Objekt und der bereitgestellte nichtflüchtige Compute Engine-Speicher gelöscht.

Wenn Sie verhindern möchten, dass dynamisch bereitgestellte, nichtflüchtige Speicher gelöscht werden, setzen Sie die Rückforderungsrichtlinie der PersistentVolume-Ressource oder ihrer StorageClass-Ressource auf Retain. Für den nichtflüchtigen Speicher fallen dadurch weiterhin Gebühren an, auch wenn er nicht von einem PersistentVolumeClaim genutzt wird. Beispiele zum Ändern der Rückforderungsrichtlinie finden Sie unter Rückforderungsrichtlinie eines PersistentVolume ändern und StorageClass-Ressource.

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

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: kubernetes.io/gce-pd
parameters:
  type: pd-balanced
  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