5 Arten von Kubernetes-Volumes und wie man mit ihnen arbeitet

5 Arten von Kubernetes-Volumes und wie man mit ihnen arbeitet

Was sind Kubernetes-Volumes?

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

Prozesse, die in Containern in einem Pod ausgeführt werden, sehen eine Dateisystemansicht, die aus Folgendem besteht:

• Ein Root-Dateisystem, das dem Inhalt des Container-Images entspricht.
• Auf dem Container bereitgestellte Volumes (sofern definiert). Jedes Volume wird auf einem bestimmten Pfad innerhalb des Container-Dateisystems bereitgestellt.

Volumes werden 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 Volume-Typen in Kubernetes. Die wichtigsten sind flüchtige Volumes, die lokal auf dem Kubernetes-Knoten gespeichert und beim Neustart eines Pods gelöscht werden, und persistente Kubernetes-Volumes (PV), die Daten auch nach dem Herunterfahren eines Pods behalten.

5 Arten von Kubernetes-Volumes

Kubernetes unterstützt verschiedene Volumes, sodass jeder Pod mehrere Volume-Typen gleichzeitig nutzen kann. Ephemere Volumes sind an die Lebensdauer des Pods gebunden, während persistente Volumes über dessen Lebensdauer hinaus bestehen bleiben. Das bedeutet, dass Kubernetes temporäre Volumes vernichtet, sobald der Pod nicht mehr existiert, während die Daten persistenter Volumes erhalten bleiben.

Persistente Volumes

Kubernetes bietet ein Persistent-Volume-Subsystem mit einer API, die die Speicherbereitstellung und -nutzung abstrahiert. Es arbeitet mit zwei API-Ressourcen: PersistentVolume (PV) und PersistentVolumeClaim (PVC).

PersistentVolume (PV)

Ein PV ist eine Speicherressource im Cluster. Administratoren können PVs manuell bereitstellen, und Kubernetes kann StorageClasses verwenden, um PVs dynamisch bereitzustellen. PVs sind wie Volumes Plug-ins, ihr Lebenszyklus ist jedoch unabhängig von den Pods, die das PV verwenden.

Ein PV fungiert als API-Objekt, das die Details der Speicherimplementierung erfasst, einschließlich iSCSI, NFS und Speichersystemen von Cloud-Anbietern. Es funktioniert ähnlich wie ein Knoten, bietet jedoch Speicherressourcen statt Rechenleistung.

PersistentVolumeClaim (PVC)

Ein PVC ist eine Speicheranforderung eines Benutzers. Es funktioniert ähnlich wie ein Pod, verbraucht jedoch PV-Ressourcen anstelle von Knotenressourcen. Ein PVC kann bestimmte Speicherressourcen anfordern und Zugriffsmodi wie ReadWriteOnce, ReadWriteMany und ReadOnlyMany angeben.

PVCs ermöglichen Benutzern die Nutzung abstrakter Speicherressourcen. Benutzer benötigen jedoch typischerweise PVs mit unterschiedlichen Eigenschaften für unterschiedliche Probleme. Aus diesem Grund müssen Clusteradministratoren häufig verschiedene PVs anbieten, die sich nicht nur in Größe und Zugriffsmodi unterscheiden. Dies ist möglich, ohne Benutzer über StorageClass-Ressourcen mit Implementierungsdetails zu konfrontieren.

Vergängliche Volumes (flüchtige Volumes)

Flüchtige Volumes speichern Daten nicht dauerhaft über Neustarts hinweg. Diese Volumes sind an die Lebensdauer des Pods gebunden, d. h. sie werden zusammen mit dem Pod erstellt und gelöscht. Dadurch können Pods gestoppt und neu gestartet werden, ohne dass dies durch die Verfügbarkeit persistenter Volumes eingeschränkt ist.

Temporäre Volumes sind einfach bereitzustellen und zu verwalten. Sie können sie inline in der Pod-Spezifikation angeben. Temporäre Volumes eignen sich ideal für Anwendungen, die keinen dauerhaften Speicher benötigen, wie z. B. Caching-Dienste.

EmptyDir-Volumes

Ein emptyDir-Volume wird erstellt, wenn Kubernetes einem Knoten einen Pod zuweist. Die Lebensdauer dieses Volumes ist an den Lebenszyklus eines Pods auf diesem bestimmten Knoten gebunden. 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 Knoten entfernt wird, abstürzt oder ausfällt.

Nach dem Erstellen eines emptyDir-Volumes können Sie den Volumetypnamen als Feld in der Pod-Manifestdatei deklarieren. Er wird im Abschnitt Volume-Eigenschaften mit leeren geschweiften Klammern {} als Wert angezeigt. emptyDir-Volumes eignen sich hauptsächlich zur temporären Datenspeicherung. Sie können sie beispielsweise für temporären Speicherplatz verwenden, z. B. für eine datenträgerbasierte Zusammenführung.

Sie können emptyDir-Volumes auf dem Medium speichern, das dem Knoten zugrunde liegt (z. B. Netzwerkspeicher oder SSD). Alternativ können Sie memory im Feld emptyDir.medium angeben. Kubernetes mountet dann ein RAM-gestütztes Dateisystem (tmpfs). Beachten Sie, dass Kubernetes tmpfs beim Neustart des Knotens löscht.

Kubernetes-Hostpfad-Volumes

Ein HostPath-Volume mountet ein Verzeichnis oder eine Datei aus dem Dateisystem des Hostknotens in Ihren Pod.

Wichtige Anwendungsfälle für HostPath-Volumes:

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

Sicherheit von HostPath-Volumes

HostPath-Volumes bergen zahlreiche Sicherheitsrisiken. Vermeiden Sie deren Verwendung, wann immer möglich. Wenn Sie ein HostPath-Volume verwenden müssen, beschränken Sie es auf das erforderliche Verzeichnis oder die erforderliche Datei und mounten Sie es schreibgeschützt.

Wichtige Sicherheitsrisiken:

• Offengelegte Anmeldeinformationen: HostPaths können privilegierte Systemanmeldeinformationen oder privilegierte APIs offenlegen. Bedrohungsakteure können dies nutzen, um andere Teile des Clusters anzugreifen oder aus dem Container auszubrechen.
• Root-Berechtigungen: Alle auf den zugrunde liegenden Hosts erstellten Verzeichnisse und Dateien sind nur für Root-Benutzer schreibbar. 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.

Mit einer AdmissionPolicy können Sie den HostPath-Zugriff auf bestimmte Verzeichnisse beschränken. Die Richtlinie ist jedoch nur wirksam, wenn Sie für VolumeMounts die Verwendung schreibgeschützter Mounts fordern.

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. Beim Verweisen auf eine ConfigMap müssen Sie den Namen der ConfigMap im Volume angeben. Mit Kubernetes können Sie den Pfad für einen bestimmten Eintrag in der ConfigMap anpassen.

Plugins zum Speichern von Kubernetes-Volumes

Kubernetes bietet mehrere Speicher-Plugins, die Zugriff auf in einem Kubernetes-Cluster bereitgestellte Speichergeräte ermöglichen. Diese werden mithilfe des StorageClass-Objekts implementiert.

Zu den wichtigsten Plugins, die derzeit von Kubernetes unterstützt werden, gehören GCEPersistentDisk, AWSElasticBlockStore, AzureDisk, Glusterfs, NFS und iSCSI.

Lassen Sie uns zwei bemerkenswerte Speicher-Plugins genauer betrachten.

NFS

Network File System (NFS) ist ein Standardprotokoll zum Einbinden von Speichergeräten als lokale Laufwerke. Mit Kubernetes können Sie ein NFS-Volume als lokales Laufwerk in einem Container einbinden. 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:

• Flüchtige NFS-Volumes: können an vorhandenen NFS-Speicher angehängt werden.
• PersistentVolumes mit NFS: ermöglicht das Einrichten verwalteter Ressourcen auf einem Cluster, auf die über NFS zugegriffen wird.

CSI

Das Container Storage Interface (CSI) ist eine Standardschnittstelle, die es Container-Orchestratoren ermöglicht, Speichersysteme für von ihnen verwaltete Container verfügbar zu machen. CSI ermöglicht Speicheranbietern die Erstellung von Plug-ins, die „out of tree“ sind. Das 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 auf Basis von CSI, die direkt von Speicheranbietern angeboten werden. Mit der Einführung von CSI ist die Unterstützung von Kubernetes durch Speichertechnologien deutlich einfacher geworden.

Was sind Kubernetes-VolumeMounts?

Das Erstellen eines Volumes und das Zugänglichmachen für einen Pod umfasst zwei Schritte:

1. Deklarieren Sie es in der Eigenschaft spec.volumes der Pod-Vorlage und stellen Sie den Pod dann auf einigen Knoten bereit.
2. Einbinden des Volumes in einen bestimmten Container mithilfe der Spezifikation spec.containers[].volumeMounts.

Diese Schritte gehen Hand in Hand. Wenn Sie ein Volume erstellen, müssen Sie es auch in einen Container einbinden. Sie können ein Volume nicht einbinden, ohne es in der Pod-Vorlage zu deklarieren.

Beispiel, das sowohl die Erstellung als auch die Bereitstellung eines Volumes in einer YAML-Konfiguration einer Pod-Vorlage 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 den Pod an.
• volumeMounts definiert, wie das Volume gemountet wird, einschließlich des Dateipfads, über den das Volume innerhalb des Containers verfügbar ist.
• Es ist wichtig, dass an beiden Stellen derselbe Volumename verwendet wird, in der Volume-deklaration und in der Eigenschaft volumeMounts.

Erstellen eines Kubernetes-Volumes durch Bereitstellen von Pods

Um ein Kubernetes-Volume zu erstellen, stellen Sie einen oder mehrere Pods bereit, die das Volume deklarieren. Ein gängiger Weg hierfür ist die Verwendung eines Deployment-Objekts.

Hier ist ein Beispiel für ein Deployment-Manifest, das Folgendes bewirkt:

• Stellt drei Pods bereit, jeder mit einem NGINX-Container.
• Deklariert ein emptyDir-Volume.
• Mountet das Volume auf jedem der drei Container im Stammverzeichnis.

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: {}

Der Name dieser Bereitstellung ist pods-with-volumes. So wird in der Kubernetes-Umgebung darauf verwiesen.

Wie im vorherigen Abschnitt gesehen, führt dieses Deployment-Objekt die beiden zum Erstellen eines Volumes erforderlichen Aktionen aus:

• Die Eigenschaft spec.template.spec.volumes deklariert das Volume.
• Die Eigenschaft spec.template.spec.containers[].volumeMounts mountet das Volume in die Container.

Nehmen wir an, diese YAML-Datei ist 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äß ausgeführt wird, führen Sie diesen Befehl aus:

kubectl describe pods pods-with-volumes

Wenn alles richtig funktioniert hat, zeigt die Ausgabe für jeden Pod einen Container mit dem Namen my-container und dem angeforderten Einhängepunkt:

Mounts: / from my-volume (rw)

Die Ausgabe zeigt auch das unter jedem Pod laufende Volume:

Volumes:   my-volume:     Type:    EmptyDir (a temporary directory that shares a pod's lifetime)

Kubernetes Volume Management mit NetApp Cloud Volumes ONTAP

NetApp Cloud Volumes ONTAP, die führende Speicherverwaltungslösung für Unternehmen, bietet sichere und bewährte Speicherverwaltungsdienste auf AWS, Azure und Google Cloud. Die Kapazität von Cloud Volumes ONTAP ist bis in den Petabyte-Bereich skalierbar und unterstützt verschiedene Anwendungsfälle wie Dateidienste, Datenbanken, DevOps oder andere Unternehmens-Workloads mit einem leistungsstarken Funktionsumfang, darunter Hochverfügbarkeit, Datenschutz, Speichereffizienz, Kubernetes-Integration und mehr.

Insbesondere Cloud Volumes ONTAP unterstützt die Bereitstellungs- und Verwaltungsanforderungen von Kubernetes Persistent Volumes für containerisierte Workloads.