5 Arten von Kubernetes Volumes und wie man mit ihnen arbeitet

Was sind Kubernetes Volumes?

Ein Kubernetes-Volume ist ein Verzeichnis mit Daten, auf das Container in einem Kubernetes-Pod zugreifen können. Der Speicherort des Verzeichnisses, das Speichermedium, das es unterstützt, und sein Inhalt hängen vom spezifischen Volume-Typ ab, der verwendet wird.

Prozesse, die in Containern in einem Pod ausgeführt werden, sehen eine Dateisystem-Ansicht, die sich aus Folgendem zusammensetzt:

• Ein Root-Dateisystem, das mit dem Inhalt des Container-Images übereinstimmt.
• Auf dem Container gemountete Volumes (sofern definiert). Jedes Volume wird auf einem bestimmten Pfad innerhalb des Container-Dateisystems gemountet.

Volumes sind im Feld .spec.containers[*].volumeMounts der Pod-Vorlage definiert. Für jeden Pod und jedes Container-Image innerhalb des Pods müssen Sie angeben, welche Volumes gemountet werden und auf welchen Pfaden (die Pfade können für jeden Container unterschiedlich sein).

Es gibt verschiedene Arten von Volumes in Kubernetes. Die wichtigsten sind kurzlebige Volumes, die lokal auf dem Kubernetes-Node gespeichert sind und beim Neustart eines Pods gelöscht werden, sowie Kubernetes Persistent Volumes (PV), bei denen die Daten auch nach dem Herunterfahren eines Pods erhalten bleiben.

In diesem Artikel:

• Arten von Kubernetes Volumes
  • Persistente Volumes
  • Ephemere Volumes
  • EmptyDir-Volumes
  • Kubernetes hostPath-Volumes
  • Kubernetes Volumes ConfigMap
• Plugins zum Speichern von Kubernetes Volumes
  • NFS
  • CSI
• Was sind Kubernetes volumeMounts?
• Erstellen eines Kubernetes-Volumes durch Bereitstellen von Pods
• Kubernetes Volume Management mit NetApp Cloud Volumes ONTAP

5 Arten von Kubernetes Volumes

Kubernetes unterstützt verschiedene Volumes, sodass jeder Pod mehrere Volume-Typen gleichzeitig verwenden kann. Kurzlebige Volumes sind an die Lebensdauer des Pods gebunden, während persistente Volumes über die Lebensdauer des Pods hinaus bestehen bleiben können. Das bedeutet, dass Kubernetes kurzlebige Volumes zerstört, sobald ihr Pod nicht mehr existiert, während die Daten der persistenten Volumes erhalten bleiben.

Persistente Volumes

Kubernetes stellt ein PersistentVolume-Subsystem mit einer API bereit, die die Storage-Provisionierung und -Nutzung abstrahiert. Es funktioniert mit zwei API-Ressourcen—PersistentVolume (PV) und PersistentVolumeClaim (PVC).

PersistentVolume (PV)
Eine PV ist eine Storage-Ressource, die sich im Cluster befindet. Administratoren können PVs manuell bereitstellen, und Kubernetes kann Storage-Klassen verwenden, um PVs dynamisch bereitzustellen. Wie Volumes sind PVs Plug-ins, aber ihr Lebenszyklus ist unabhängig von jedem Pod, der das PV verwendet.

Ein PV fungiert als API-Objekt, das die Details der Storage-Implementierung erfasst, einschließlich iSCSI, NFS und Cloud-Provider-Storage-Systemen. Es funktioniert ähnlich wie ein Node, bietet jedoch Storage-Ressourcen anstelle von Computing.

PersistentVolumeClaim (PVC)
Eine PVC ist eine Speicheranfrage, die von einem Benutzer gestellt wird. Sie funktioniert ähnlich wie ein Pod, verbraucht jedoch PV-Ressourcen anstelle von Node-Ressourcen. Eine PVC kann bestimmte Speicherressourcen anfordern und dabei Größenzugriffsmodi wie ReadWriteOnce, ReadWriteMany und ReadOnlyMany angeben.

PVCs ermöglichen es Benutzern, abstrakte Speicherressourcen zu nutzen, aber Benutzer benötigen in der Regel PVs mit unterschiedlichen Eigenschaften für verschiedene Probleme. Deshalb müssen Cluster-Administratoren oft verschiedene PVs anbieten, die sich in mehr als nur Größe und Zugriffsmodi unterscheiden. Sie können dies tun, ohne die Benutzer mit Implementierungsdetails durch StorageClass-Ressourcen zu konfrontieren.

Verwandte Inhalte: Lesen Sie unseren Leitfaden zu Kubernetes PVC

Ephemere Volumes

Kurzlebige Volumes speichern Daten nicht persistent über Neustarts hinweg. Diese Volumes sind an die Lebensdauer des Pods gebunden, was bedeutet, dass sie zusammen mit dem Pod erstellt und gelöscht werden. Es ermöglicht das Stoppen und Neustarten von Pods, ohne sie auf die Verfügbarkeit eines persistenten Volumes zu beschränken.

Kurzlebige Volumes sind einfach zu implementieren und zu verwalten. Sie können sie inline in der Pod-Spezifikation angeben. Kurzlebige Volumes sind ideal für Anwendungen, die keinen persistenten Storage benötigen, wie Caching-Services.

EmptyDir-Volumes

Ein emptyDir Volume wird erstellt, wenn Kubernetes einem Pod einen Node zuweist. Die Lebensdauer dieses Volumes ist an den Lebenszyklus eines Pods gebunden, der auf diesem bestimmten Node existiert. Ein emptyDir Volume wird neu erstellt, wenn Container neu gestartet werden oder abstürzen. Die Daten in diesem Volume werden jedoch gelöscht und gehen verloren, wenn der Pod vom Node entfernt wird, abstürzt oder beendet wird.

Nachdem Sie ein emptyDir Volume erstellt haben, können Sie den Volume-Typnamen als Feld in der Pod-Manifestdatei deklarieren. Es wird im Abschnitt der Volume-Eigenschaft mit leeren geschweiften Klammern{} als Wert angezeigt. EmptyDir Volumes eignen sich hauptsächlich für die temporäre Datenspeicherung. Zum Beispiel können Sie es für Scratch-Speicher verwenden, wie bei einem datenträgerbasierten Merge.

Sie können emptyDir-Volumes auf dem Medium speichern, das den Node unterstützt. Sie können beispielsweise Netzwerkspeicher oder SSD verwenden. Alternativ können Sie "memory" im Feld emptyDir.medium festlegen und Kubernetes mountet ein RAM-gestütztes Dateisystem (tmpfs). Beachten Sie, dass Kubernetes tmpfs beim Neustart des Nodes löscht.

Kubernetes hostPath-Volumes

Ein hostPath-Volume bindet ein Verzeichnis oder eine Datei aus dem Dateisystem des Host-Nodes in Ihren Pod ein.

Hier sind die wichtigsten Anwendungsfälle für hostPath Volumes:

• Verwenden Sie ein /var/lib/dockerhostPath—um einen Container auszuführen, der Zugriff auf Docker-Interna benötigt.
• Verwenden Sie ein /sys hostPath—um cAdvisor in einem Container auszuführen.
• Erlauben Sie einem Pod, einen hostPath—anzugeben, um zu definieren, ob ein bestimmter hostPath vorhanden sein soll, bevor der Pod ausgeführt wird, und ob er erstellt werden soll.
• Geben Sie einen Typ für ein hostPath-Volume an—Sie können dies zusätzlich zur erforderlichen Pfadeigenschaft einrichten.

HostPath Volumes Sicherheit
HostPath Volumes bergen viele Sicherheitsrisiken. Vermeiden Sie die Verwendung dieser Volumes wann immer möglich. Wenn Sie ein HostPath Volume verwenden müssen, sollten Sie es nur auf das erforderliche Verzeichnis oder die erforderliche Datei beschränken und es als ReadOnly einbinden.

Hier sind die wichtigsten Sicherheitsrisiken:

• Offengelegte Anmeldedaten—HostPaths können privilegierte Systemanmeldeinformationen oder privilegierte APIs offenlegen. Bedrohungsakteure können es nutzen, um andere Teile des Clusters anzugreifen oder einen Container-Escape durchzuführen.
• Root-Rechte—alle auf den zugrunde liegenden Hosts erstellten Verzeichnisse oder Dateien sind nur von Root beschreibbar. Wenn Sie auf ein hostPath Volume schreiben möchten, müssen Sie die Dateiberechtigungen auf dem Host ändern oder den Prozess als Root in einem privilegierten Container ausführen.

Sie können die AdmissionPolicy verwenden, um den HostPath-Zugriff auf bestimmte Verzeichnisse einzuschränken. Die Richtlinie ist jedoch nur wirksam, wenn Sie volumeMounts dazu verpflichten, readOnly-Mounts zu verwenden.

Kubernetes Volumes ConfigMap

Eine ConfigMap ermöglicht das Einfügen von Konfigurationsdaten in Pods. In einer ConfigMap gespeicherte Daten können in einem configMap-Volume-Typ referenziert und dann von containerisierten Anwendungen genutzt werden, die in einem Pod ausgeführt werden. Sie müssen den Namen der ConfigMap im Volume angeben, wenn Sie auf eine ConfigMap verweisen. Kubernetes ermöglicht es Ihnen, den Pfad für einen bestimmten Eintrag in der ConfigMap anzupassen.

Plugins zum Speichern von Kubernetes Volumes

Kubernetes bietet mehrere Storage-Plug-ins, die den Zugriff auf Storage-Geräte ermöglichen, die in einem Kubernetes-Cluster bereitgestellt werden. Diese werden mithilfe des StorageClass-Objekts implementiert.

Einige der wichtigsten Plug-ins, die derzeit von Kubernetes unterstützt werden, sind GCEPersistentDisk, AWSElasticBlockStore, AzureDisk, Glusterfs, NFS und iSCSI. Weitere Informationen zu diesen Plug-ins finden Sie in der StorageClass-Dokumentation.

Lassen Sie uns zwei bemerkenswerte Storage-Plugins genauer betrachten.

NFS

Network File System (NFS) ist ein Standardprotokoll zum Mounten von Storage-Geräten als lokale Laufwerke. Kubernetes ermöglicht es Ihnen, ein NFS-Volume als lokales Laufwerk in einem Container einzubinden. Da Legacy-Code häufig über NFS auf Daten zugreift, ist dieses Plugin sehr nützlich für die Migration von Legacy-Workloads zu Kubernetes.

Es gibt zwei Möglichkeiten, über NFS und Kubernetes auf Daten zuzugreifen:

• Kurzlebige NFS-Volumes—können an bestehende NFS-Storage angeschlossen werden.
• PersistentVolumes mit NFS— ermöglicht die Einrichtung verwalteter Ressourcen in einem Cluster, auf die über NFS zugegriffen werden kann.

CSI

Das Container Storage Interface (CSI) ist eine Standardschnittstelle, die es Container-Orchestratoren ermöglicht, Storage-Systeme für die von ihnen verwalteten Container bereitzustellen. CSI ermöglicht es Storage-Anbietern, Plugins zu erstellen, die „out of tree“ sind, was bedeutet, dass sie nicht in das Kubernetes-Code-Repository eingecheckt werden müssen und nicht mit Kubernetes ausgeliefert werden.

Es gibt viele Out-of-Tree-Plugins, die auf CSI basieren und direkt von Speicheranbietern angeboten werden. Die Einführung von CSI hat es für Speichertechnologien viel einfacher gemacht, Kubernetes zu unterstützen.

Verwandte Inhalte: Lesen Sie unseren Leitfaden zur Container Storage Interface

Was sind Kubernetes volumeMounts?

Es sind zwei Schritte erforderlich, um ein Volume zu erstellen und es für einen Pod zugänglich zu machen:

• Deklarieren in der Eigenschaft spec:volumes der Pod-Vorlage und dann das Bereitstellen des Pods auf einigen Knoten
• Einbinden des Volumes in einen bestimmten Container mithilfe der Eigenschaft spec:containers::volumeMounts

Diese Schritte gehen Hand in Hand. Wenn Sie ein Volume erstellen, müssen Sie es auch in einen Container mounten, und Sie dürfen ein Volume nicht mounten, ohne es in der Pod-Vorlage zu deklarieren.

Hier ist ein Beispiel, das sowohl das Erstellen als auch das Mounten eines Volumes in einer Pod-Template-YAML-Konfiguration zeigt:

spec: containers: —name: my-app image: nginx volumeMounts: —name: my-volume mountPath: /app/config volumes: —name: my-volume 

In diesem Code:

• volumes (unten) erstellt ein Volume mit dem Namen my-volume und hängt es an das Pod an
• volumeMounts definiert, wie das Volume gemountet wird, einschließlich des Dateipfads, über den das Volume von innerhalb des Containers verfügbar ist
• Es ist wichtig, dass an beiden Stellen—der Volume-Deklaration und der volumeMounts property—derselbe Volumename verwendet wird.

Erstellen eines Kubernetes-Volumes durch Bereitstellen von Pods

Um ein Kubernetes-Volume zu erstellen, implementieren Sie einen oder mehrere Pods, die das Volume deklarieren. Eine gängige Methode hierfür ist ein Deployment-Objekt. Hier ist ein Beispiel für ein Deployment-Manifest, das Folgendes bewirkt:

• Stellt drei Pods bereit, jeweils mit einem NGINX-Container
• Deklariert ein emptyDir Volume
• Bindet das Volume auf jedem der drei Container im Root-Verzeichnis ein

apiVersion: apps/v1 kind: Deployment metadata: name: pods-with-volumes spec: replicas: 3 selector: matchLabels: app: demo template: metadata: labels: app: demo spec: containers: —name: my-container image: nginx:1.14.2 volumeMounts: —mountPath: / name: my-volume volumes: —name: my-volume emptyDir: {} 

Beachten Sie, dass der Name dieser Deployment in pods-with-volumes definiert ist – so wird darauf in der Kubernetes-Umgebung verwiesen.

Wie wir im vorherigen Abschnitt gesehen haben, führt dieses Bereitstellungsobjekt die beiden Aktionen aus, die zum Erstellen eines Volumes erforderlich sind:

• Die Eigenschaft spec:template:volumes deklariert das Volume.
• Die Eigenschaft spec:containers::volumeMounts bindet das Volume in die Container ein.

Nehmen wir an, diese YAML-Datei wird unter dem Namen my-deployment.yaml gespeichert. Sie können das Deployment in Ihrem Kubernetes-Cluster mit diesem Befehl erstellen:

kubectl apply -f my-deployment.yaml

Um zu überprüfen, ob die Bereitstellung mit den erwarteten Volumes ordnungsgemäß läuft, führen Sie diesen Befehl aus:

kubectl describe pods pods-with-volumes

Wenn alles ordnungsgemäß funktioniert hat, zeigt die Ausgabe, dass jeder Pod einen Container mit dem Namen my-container mit dem angeforderten Bereitstellungspunkt hat:

Mounts: / von my-volume (rw)

Die Ausgabe zeigt auch das Volume, das unter jedem Pod ausgeführt wird:

Volumes: my-volume: Type: EmptyDir (ein temporäres Verzeichnis, das die Lebensdauer eines Pods teilt)

Kubernetes Volume Management mit NetApp Cloud Volumes ONTAP

NetApp Cloud Volumes ONTAP, die führende Storage-Management-Lösung der Enterprise-Klasse, bietet sichere, bewährte Storage-Management-Services auf AWS, Azure und Google Cloud. Die Kapazität von Cloud Volumes ONTAP kann bis in den Petabyte-Bereich skaliert werden und unterstützt verschiedene Anwendungsfälle wie Fileservices, Datenbanken, DevOps oder andere Enterprise-Workloads mit einer Vielzahl von Funktionen, darunter Hochverfügbarkeit, Datenschutz, Storage-Effizienz, Kubernetes-Integration und mehr.

Insbesondere unterstützt Cloud Volumes ONTAP die Bereitstellung und Verwaltung von Kubernetes Persistent Volumes für die Anforderungen containerisierter Workloads.

Erfahren Sie mehr darüber, wie Cloud Volumes ONTAP dazu beiträgt, die Herausforderungen containerisierter Anwendungen in diesen Kubernetes Workloads mit Cloud Volumes ONTAP Case Studies zu bewältigen.