Ein einfacher Leitfaden zur Implementierung persistenten Speichers in Kubernetes

Ein einfacher Leitfaden zur Implementierung von persistentem Speicher in Kubernetes

In der Welt der Container-Orchestrierung glänzt Kubernetes bei der Verwaltung von zustandslosen Anwendungen – solchen, die Daten zwischen Neustarts oder Skalierungsereignissen nicht beibehalten müssen. Viele moderne Anwendungen, wie Datenbanken, Message Queues und Key-Value-Speicher, sind jedoch von Natur aus zustandsbehaftet. Diese Anwendungen benötigen eine zuverlässige Möglichkeit, Daten persistent zu speichern und darauf zuzugreifen, auch wenn die sie ausführenden Pods neu geplant oder ersetzt werden. Hier kommt der persistente Speicher von Kubernetes ins Spiel.

Diese Anleitung wird die Konzepte von PersistentVolumes (PVs) und PersistentVolumeClaims (PVCs) entmystifizieren, die die Kernkomponenten für die Verwaltung von persistentem Speicher in Kubernetes sind. Wir werden durch praktische YAML-Beispiele führen, wie Speicher für Ihre Pods definiert, angefordert und gebunden werden, damit Sie zustandsbehaftete Anwendungen sicher auf Ihrem Kubernetes-Cluster bereitstellen können.

Verständnis von PersistentVolumes (PVs) und PersistentVolumeClaims (PVCs)

Bevor wir uns mit der Implementierung befassen, ist es wichtig, die Rollen von PVs und PVCs zu verstehen:

• PersistentVolume (PV): Ein PV ist ein Speicherbereich im Cluster, der von einem Administrator bereitgestellt oder dynamisch mithilfe von StorageClasses bereitgestellt wurde. PVs sind Clusterressourcen, ähnlich wie Nodes. Sie haben einen Lebenszyklus, der unabhängig von jedem einzelnen Pod ist, der den PV verwendet. PVs abstrahieren die Details der zugrunde liegenden Speicherimplementierung (z. B. NFS, iSCSI, Block Storage von Cloud-Anbietern).
• PersistentVolumeClaim (PVC): Ein PVC ist eine Speicheranforderung eines Benutzers. Er verbraucht Speicherressourcen, die im Cluster als PVs verfügbar sind. PVCs ähneln Pods insofern, als sie Rechenressourcen verbrauchen und auf einen Namespace beschränkt sind. Ein PVC gibt die gewünschte Speicherkapazität, Zugriffsmodi und optional eine StorageClass an.

Diese Trennung von Zuständigkeiten ermöglicht es Clusteradministratoren, Speicherressourcen unabhängig bereitzustellen und zu verwalten, während Anwendungsentwickler Speicher anfordern können, ohne die zugrunde liegenden Implementierungsdetails kennen zu müssen.

Schlüsselkonzepte: Zugriffsmodi und StorageClasses

Zwei wichtige Konzepte, die bei der Arbeit mit PVs und PVCs zu beachten sind, sind Zugriffsmodi und StorageClasses:

Zugriffsmodi

Zugriffsmodi definieren, wie ein Volume in einem Pod eingehängt werden kann. Die verfügbaren Zugriffsmodi sind:

• ReadWriteOnce (RWO): Das Volume kann als Lese-/Schreibzugriff von einem einzigen Knoten eingehängt werden.
• ReadOnlyMany (ROX): Das Volume kann von vielen Knoten als schreibgeschützter Zugriff eingehängt werden.
• ReadWriteMany (RWX): Das Volume kann von vielen Knoten als Lese-/Schreibzugriff eingehängt werden.

Es ist wichtig zu beachten, dass die tatsächliche Unterstützung für diese Modi vom zugrunde liegenden Speicheranbieter abhängt.

StorageClasses

Eine StorageClass bietet Administratoren eine Möglichkeit, die "Klassen" von Speicher zu beschreiben, die sie anbieten. Unterschiedliche Klassen können auf Quality-of-Service-Level, Backup-Richtlinien oder beliebige Richtlinien abgebildet werden, die von den Clusteradministratoren festgelegt werden. Eine StorageClass hat einen Provisioner, der den Speicher bereitstellt, und eine Reihe von Parametern für den Provisioner. Wenn ein PVC ohne einen spezifischen PV erstellt wird und eine StorageClass anfordert, wird Kubernetes dynamisch ein PV unter Verwendung der angegebenen StorageClass bereitstellen.

Implementierung von persistentem Speicher: Schritt für Schritt

Lassen Sie uns ein gängiges Szenario durchgehen: Anfordern und Verwenden von persistentem Speicher für einen Pod.

Schritt 1: Definieren eines PersistentVolumeClaim (PVC)

Zuerst müssen Sie einen PVC erstellen, der Ihre Speicheranforderungen spezifiziert. Dieser PVC fungiert als Anforderung für Speicher von Ihrer Anwendung.

Beispiel pvc.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

In diesem Beispiel:

• name: my-pvc: Dies ist der Name unseres PVC.
• accessModes: - ReadWriteOnce: Wir fordern Speicher an, der von einem einzelnen Knoten mit Lese-/Schreibzugriff eingehängt werden kann.
• resources.requests.storage: 1Gi: Wir fordern 1 Gigabyte Speicher an.

Anwenden des PVC:

Speichern Sie den obigen Inhalt in einer Datei namens pvc.yaml und wenden Sie ihn auf Ihren Cluster an:

kubectl apply -f pvc.yaml

Nach dem Anwenden können Sie den Status des PVC überprüfen:

kubectl get pvc my-pvc

Sie sollten eine Ausgabe sehen, die angibt, dass der PVC Bound (gebunden) ist, wenn ein geeigneter PV verfügbar ist oder dynamisch bereitgestellt wurde.

Schritt 2: Erstellen eines Pods, der den PVC verwendet

Nun erstellen wir einen Pod, der den von unserem PVC angeforderten Speicher nutzt. Wir werden das von dem PVC bereitgestellte Volume in ein bestimmtes Verzeichnis innerhalb unseres Containers einhängen.

Beispiel pod-with-pv.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: my-stateful-pod
spec:
  containers:
    - name: my-container
      image: nginx
      ports:
        - containerPort: 80
      volumeMounts:
        - name: my-persistent-storage
          mountPath: /usr/share/nginx/html
  volumes:
    - name: my-persistent-storage
      persistentVolumeClaim:
        claimName: my-pvc

In diesem Beispiel:

• volumes: Wir definieren ein Volume namens my-persistent-storage.
• persistentVolumeClaim.claimName: my-pvc: Dies verknüpft unser Volume mit dem zuvor erstellten PVC.
• volumeMounts: Innerhalb der Containerdefinition geben wir an, wo dieses Volume eingehängt werden soll (mountPath: /usr/share/nginx/html).

Anwenden des Pods:

Speichern Sie den obigen Inhalt in einer Datei namens pod-with-pv.yaml und wenden Sie ihn an:

kubectl apply -f pod-with-pv.yaml

Nun hat Ihr nginx-Container Zugriff auf den persistenten Speicher, der von my-pvc definiert wurde, unter dem Pfad /usr/share/nginx/html. Alle Daten, die in diesen Pfad innerhalb des Containers geschrieben werden, bleiben erhalten, auch wenn der Pod gelöscht und neu erstellt wird, solange der PVC und sein zugrunde liegender PV bestehen bleiben.

Dynamische Bereitstellung mit StorageClasses

Manuelles Erstellen von PVs kann umständlich sein. Kubernetes bietet dynamische Bereitstellung, bei der PVs automatisch erstellt werden, wenn ein PVC Speicher anfordert, der nicht durch vorhandene PVs erfüllt werden kann. Dies geschieht mithilfe von StorageClasses.

Die meisten Cloud-Anbieter (AWS, GCP, Azure) bieten vorkonfigurierte StorageClasses. Sie können diese mit folgendem Befehl einsehen:

kubectl get storageclass

Um die dynamische Bereitstellung zu nutzen, fügen Sie einfach ein Feld storageClassName zu Ihrer PVC-Definition hinzu:

Beispiel pvc-dynamic.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-dynamic-pvc
spec:
  storageClassName: standard # Ersetzen Sie 'standard' durch einen tatsächlichen Namen einer StorageClass
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Wenn Sie diesen PVC anwenden, sucht Kubernetes nach einer StorageClass namens standard (oder einem anderen von Ihnen angegebenen Namen) und weist deren Provisioner an, einen neuen PV mit 5Gi zu erstellen und ihn an diesen PVC zu binden.

Tipps und Best Practices

• Wählen Sie den richtigen Zugriffsmodus: Überlegen Sie sorgfältig, welcher Zugriffsmodus von Ihrer Anwendung benötigt wird. ReadWriteOnce ist üblich für Datenbanken mit einzelner Replikation, während ReadWriteMany für gemeinsam genutzte Dateisysteme, die von mehreren Pods verwendet werden, erforderlich ist.
• Speicherleistung verstehen: Unterschiedliche Speicheranbieter und StorageClasses bieten unterschiedliche Leistungsmerkmale (IOPS, Durchsatz). Wählen Sie eine StorageClass, die den Leistungsanforderungen Ihrer Anwendung entspricht.
• Backup-Strategie: Persistenter Speicher bedeutet nicht automatisch Backup. Implementieren Sie eine robuste Backup-Strategie für Ihre persistenten Volumes, insbesondere für kritische Daten.
• PV Reclaim Policy: PVs haben eine reclaimPolicy, die Delete (Standard), Retain oder Recycle (veraltet) sein kann. Retain ist nützlich, um sicherzustellen, dass keine Daten verloren gehen, wenn ein PV gelöscht wird, der zugrunde liegende Speicher aber noch existiert.
• Namespace-Überlegungen: PVCs sind auf Namespaces beschränkt. Stellen Sie sicher, dass sich Ihr Pod und Ihr PVC im selben Namespace befinden, damit die Bindung stattfinden kann.

Fazit

Die Implementierung von persistentem Speicher ist eine grundlegende Voraussetzung für den Betrieb zustandsbehafteter Anwendungen in Kubernetes. Durch das Verständnis und die Nutzung von PersistentVolumes und PersistentVolumeClaims sowie der Flexibilität von StorageClasses können Sie die Daten Ihrer Anwendung zuverlässig verwalten. Diese Anleitung hat das grundlegende Wissen und praktische Beispiele geliefert, um Ihnen den Einstieg zu erleichtern und Ihnen die Bereitstellung anspruchsvollerer und widerstandsfähigerer zustandsbehafteter Workloads auf Kubernetes zu ermöglichen.