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
- Weitere Informationen zu StatefulSets, die empfohlene Bereitstellungsmethode für zustandsorientierte Anwendungen
- Zustandsorientierte Anwendung bereitstellen
- Nichtflüchtige Speicher in einem Cluster verwenden
- Nichtflüchtige Speicher mit mehreren Lesezugriffen verwenden
- Nichtflüchtigen SSD-Speicher verwenden
- Regionalen nichtflüchtigen Speicher bereitstellen