Eine einfache Anleitung zur Implementierung von persistentem Speicher in Kubernetes

Persistenter Speicher in Kubernetes löst ein einfaches Problem: Ihr Container kann verschwinden, aber Ihre Datenbankdateien, Uploads oder Warteschlangendaten dürfen das nicht. Zustandslose Pods können jederzeit ersetzt werden. Zustandsbehaftete Apps benötigen Speicher, der Pod-Neustarts, Neuplanungen und Knotenwartung überlebt.

Dieser Leitfaden erklärt PersistentVolumes (PVs), PersistentVolumeClaims (PVCs), Zugriffsmodi und StorageClasses mit praktischen YAML-Beispielen, die Sie für eine reale Arbeitslast anpassen können.

Grundlegendes zu PersistentVolumes (PVs) und PersistentVolumeClaims (PVCs)

Bevor Sie Speicher in einen Pod einbinden, sollten Sie wissen, welches Objekt welche Aufgabe übernimmt:

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

Diese Trennung ermöglicht es Plattformteams, Speicherdetails zu verwalten, während Anwendungsteams die benötigte Kapazität und das Zugriffsmuster anfordern können.

Schlüsselkonzepte: Zugriffsmodi und StorageClasses

Zwei Einstellungen steuern das meiste PVC-Verhalten: wie das Volume gemountet werden kann und welches Speicher-Backend es erstellen soll.

Zugriffsmodi

Zugriffsmodi definieren, wie ein Volume an einen Pod angebunden werden kann. Die verfügbaren Zugriffsmodi sind:

• ReadWriteOnce (RWO): Das Volume kann als Lese-/Schreibzugriff von einem einzelnen Knoten gemountet werden.
• ReadOnlyMany (ROX): Das Volume kann von vielen Knoten schreibgeschützt gemountet werden.
• ReadWriteMany (RWX): Das Volume kann von vielen Knoten als Lese-/Schreibzugriff gemountet werden.
• ReadWriteOncePod (RWOP): Das Volume kann als Lese-/Schreibzugriff von einem einzelnen Pod gemountet werden. Dies ist nützlich, wenn Sie ein strengeres Single-Writer-Verhalten benötigen und Ihr CSI-Treiber dies unterstützt.

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

StorageClasses

Eine StorageClass bietet Administratoren eine Möglichkeit, die "Klassen" des von ihnen angebotenen Speichers zu beschreiben. Verschiedene Klassen können auf Qualitätsstufen, Backup-Richtlinien oder beliebige Richtlinien abbilden, die von den Cluster-Administratoren festgelegt werden. Eine StorageClass hat einen Provisioner, der Speicher bereitstellt, und eine Reihe von Parametern für den Provisioner. Wenn ein PVC ohne ein bestimmtes PV erstellt wird und eine StorageClass anfordert, stellt Kubernetes dynamisch ein PV unter Verwendung der angegebenen StorageClass bereit.

Implementierung von persistentem Speicher Schritt für Schritt

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

Schritt 1: Definieren Sie einen PersistentVolumeClaim (PVC)

Zuerst müssen Sie einen PVC erstellen, der Ihre Speicheranforderungen angibt. Dieser PVC fungiert als Speicheranforderung für Ihre 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 gemountet werden kann.
• resources.requests.storage: 1Gi: Wir fordern 1 Gigabyte Speicher an.

Anwenden des PVC:

Speichern Sie den obigen Inhalt in einer Datei mit dem Namen 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 ist, wenn ein geeignetes PV verfügbar ist oder dynamisch bereitgestellt wurde.

Schritt 2: Erstellen Sie einen Pod, der den PVC verwendet

Lassen Sie uns nun einen Pod erstellen, der den von unserem PVC angeforderten Speicher nutzt. Wir werden das vom PVC bereitgestellte Volume in ein bestimmtes Verzeichnis in unserem Container einbinden.

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 mit dem Namen 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 gemountet werden soll (mountPath: /usr/share/nginx/html).

Anwenden des Pods:

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

kubectl apply -f pod-with-pv.yaml

Jetzt hat Ihr nginx-Container Zugriff auf den persistenten Speicher, der durch my-pvc am Pfad /usr/share/nginx/html definiert ist. Alle Daten, die in diesem Pfad innerhalb des Containers geschrieben werden, bleiben erhalten, selbst wenn der Pod gelöscht und neu erstellt wird, solange der PVC und das zugrunde liegende PV erhalten bleiben.

Dynamische Bereitstellung mit StorageClasses

Das manuelle 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 gedeckt werden kann. Dies wird durch StorageClasses erreicht.

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

kubectl get storageclass

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

Beispiel pvc-dynamic.yaml:

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

Wenn Sie diesen PVC anwenden, sucht Kubernetes nach einer StorageClass mit dem Namen standard (oder einem anderen von Ihnen angegebenen Namen) und weist dessen Provisioner an, ein neues PV mit 5Gi zu erstellen und an diesen PVC zu binden.

Tipps und Best Practices

• Wählen Sie den richtigen Zugriffsmodus: Überlegen Sie sorgfältig, welchen Zugriffsmodus Ihre Anwendung benötigt. ReadWriteOnce ist üblich für Einzelreplikat-Datenbanken, während ReadWriteMany für gemeinsam genutzte Dateisysteme erforderlich ist, die von mehreren Pods verwendet werden.
• Verstehen Sie die Speicherleistung: Verschiedene Speicheranbieter und StorageClasses bieten unterschiedliche Leistungsmerkmale (IOPS, Durchsatz). Wählen Sie eine StorageClass, die die Leistungsanforderungen Ihrer Anwendung erfüllt.
• 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-Wiederverwendungsrichtlinie: PVs haben eine persistentVolumeReclaimPolicy, üblicherweise Delete oder Retain. Dynamisch bereitgestellte Volumes verwenden oft die von ihrer StorageClass definierte Wiederverwendungsrichtlinie. Die alte Recycle-Richtlinie ist veraltet und sollte nicht für neue Setups verwendet werden.
• Namespace-Überlegungen: PVCs sind namespaced. Stellen Sie sicher, dass sich Ihr Pod und PVC im selben Namespace befinden, damit die Bindung erfolgen kann.

Fazit

Persistenter Speicher in Kubernetes beginnt mit einem PVC, einem Pod-Mount und einer StorageClass, die zu Ihrer Arbeitslast passt. Für eine Einzelreplikat-Datenbank beginnen Sie mit einem ReadWriteOnce-Claim, überprüfen Sie, ob es Bound erreicht, binden Sie es in den Container ein und machen Sie Backups von Anfang an zu einem Teil des Designs.