Persistente Volumes und persistente Volume-Claims auf einem CODE-DE FRA1-1 Server

In Kubernetes sind Persistent Volumes (PV) und Persistent Volume Claims (PVC) ausgewählte Mechanismen, die Speicherpersistenz über den Lebenszyklus von Containern und Pods hinaus gewährleisten.

Auf der Plattform CODE-DE wird diese Persistenz mit dem OpenStack Cinder CSI-Treiber als Teil des OpenStack Magnum-Projekts implementiert. In diesem Artikel zeigen wir ein Beispiel für persistente Volumes und persistente Volume-Claims. Sobald Sie einen Claim definiert haben, können Sie ihn an mehreren Stellen innerhalb Ihrer Kubernetes-Anwendung verwenden.

Was wir behandeln werden

Überprüfen des Vorhandensein des Cinder CSI-Treibers auf Ihrem Kubernetes-Cluster

Dynamische Erstellung von persistenten Volume-Claims über eine yaml-Datei

Daten auf dem persistenten Volume speichern

Löschen des Pods und erneutes Erstellen (Zugriff über SSH)

Überprüfen, ob die Daten auch nach dem Löschen des Pods noch vorhanden sind.

Voraussetzungen

1 Konto

Sie benötigen ein Konto mit Horizon-Schnittstelle https://cloud.fra1-1.cloudferro.com/auth/login/?next=/.

2 Erstellen von Clustern mit CLI

Der Artikel So verwenden Sie die Befehlszeilenschnittstelle für Kubernetes-Cluster auf CODE-DE OpenStack Magnum führt Sie in die Erstellung von Clustern über eine Befehlszeilenschnittstelle ein.

3 Openstack-Client mit der Cloud verbinden

Bereiten Sie Openstack- und Magnum-Clients vor, indem Sie Schritt 2 OpenStack- und Magnum-Clients mit Horizon Cloud verbinden aus dem Artikel ausführen Installation von OpenStack- und Magnum-Clients für die Befehlszeilenschnittstelle von CODE-DE Horizon.

4 Verständnis von Persistent Volumes und Persistent Volume Claims

Dies ist eine formale Einführung in Persistent Volumes und Persistent Volume Claims auf der Kubernetes site.

5 Weitere Lektüre zu OpenStack Cinder CSI

Eine eher technische Einführung in das OpenStack Cinder CSI Plugin im offiziellem Kubernetes Repository auf GitHub.

Für alternative Szenarien, die Lese-/Schreibvorgänge auf mehreren Knoten erfordern, gibt es alternative Lösungen, die ebenfalls in einen Magnum-Kubernetes-Cluster integriert werden können, z. B. S3-Objektspeicher oder Datenbankpersistenz.

Arten von Cinder CSI Persistence

Cinder CSI wird von Openstack Cinder-Blockspeicher-Volumes unterstützt, die als Speicherressource für den Kubernetes-Cluster erstellt werden.

In Kubernetes gibt es drei Hauptmodi für den Zugriff auf persistenten Speicher:

readwriteonce (RWO)

readonlymany (ROX)

readwritemany (RWX)

Die Cinder CSI Implementierung auf der FRA1-1 Cloud unterstützt den RWO Typ der Persistenz. Das bedeutet, dass ein Persistentes Volume, das über einen Persistent Volume Claim verfügbar ist, für Lese- und Schreibzugriffe von einem einzigen Knoten aus zur Verfügung steht.

Überprüfen Sie den Cinder CSI-Treiber auf Ihrem Kubernetes-Cluster

Der Cinder CSI-Treiber wird auf einem neu erstellten Kubernetes-Cluster vorinstalliert. Um weitere Details anzuzeigen, geben Sie einen der beiden Befehle ein:

kubectl get csidrivers.storage.k8s.io
kubectl describe csidrivers.storage.k8s.io

Das CSI-Plugin wird in Form mehrerer Pods bereitgestellt, die auf Master- und Worker-Knoten laufen. Wir können die Details eines dieser Pods mit folgendem Befehl anzeigen:

kubectl describe pod csi-cinder-controllerplugin-0 -n kube-system

Die Ausgabe dieser Befehle kann Hunderte von Zeilen lang sein, so dass wir darauf verzichten, sie hier zu zeigen.

Persistente Volume-Claims dynamisch erstellen

Eine Speicherklasse (storage class) ist eine Abstraktion, die die dynamische Erstellung von persistenten Datenträgern ermöglicht. Wir können eine Speicherklasse einmal definieren und sie später für die Erstellung anderer persistenter Volume Claims desselben Typs wiederverwenden. In der CLoud FRA1-1 sind standardmäßig 2 Speicherklassen in einem neuen Cluster angelegt. Um dies zu überprüfen, führen Sie den folgenden kubectl-Befehl aus:

kubectl get sc

Die 2 Speicherklassen sind aufgelistet, die Standardklasse für SSD-Speicher (cinder-ssd), und die zweite für HDD-Speicher (cinder-hdd):

(openstack_cli) eouser@LAPTOP-63SMP31T:~$ kubectl get sc
NAME                   PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
cinder-hdd             cinder.csi.openstack.org   Delete          Immediate           true                   4d17h
cinder-ssd (default)   cinder.csi.openstack.org   Delete          Immediate           true                   4d17h

Um einen neuen Persistent-Volume-Claim mit der Speicherklasse cinder-ssd zu erstellen, speichern Sie die folgende Datei als dynamic-storage.yaml.

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

Danach führen Sie diesen Befehl aus:

kubectl apply -f dynamic-storage.yaml

Wir können prüfen, ob der Claim für das persistente Volume erstellt wurde. Ebenso wurde im Hintergrund das Persistente Volume erstellt. Zeigen Sie diese Artefakte mit den folgenden Befehlen an:

kubectl get pv
kubectl get pvc

(openstack_cli) eouser@LAPTOP-63SMP31T:~$ kubectl get pvc
NAME     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
my-pvc   Bound    pvc-0299b433-6b9c-48cb-8106-05cffae73612   1Gi        RWO            cinder-ssd     12s

In der OpenStack Horizon-Konsole können wir sehen, dass tatsächlich ein Volume Block Storage erstellt wurde.

Speichern von Daten auf dem gemounteten persistenten Volume

Wir werden einen nginx-Pod ausführen, der auf einem offiziellen Image basiert, in das wir unseren my-pvc-Volume-Claim einhängen.

Speichern Sie die folgenden Zeilen als check.yaml.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: check
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: check
  volumes:
    - name: check
      persistentVolumeClaim:
        claimName: my-pvc

Ausführen dieser yaml-Datei mit:

kubectl apply -f check.yaml

Wir haben einen Pod erstellt, dessen persistentes Volume in den Ordner /var/www/html gemountet wurde. Wir können mit diesem Befehl auf den Pod zugreifen:

kubectl exec --tty --stdin mypod -- "/bin/bash"

Zur Überprüfung erstellen wir eine Datei in dem Ordner, der in das Volume /var/www/html eingebunden ist:

touch /var/www/html/example-file.txt

Überprüfen, ob die Daten nach dem Löschen des Pods noch vorhanden sind

Nach Ausführung der vorangegangenen Schritte wird die example-file.txt auf dem persistenten Volume gespeichert. Selbst wenn der Pod (oder sogar der Knoten, auf dem dieser Pod erstellt wurde) gelöscht würde, sollte diese Datei erhalten bleiben.

Überprüfen wir dies, indem wir

den Pod löschen,

ihn wieder neu erstellen,

auf ihn über SSH zugreifen und

den Inhalt des Ordners /var/www/html überprüfen:

kubectl delete pod mypod
kubectl apply -f check.yaml
kubectl exec --tty --stdin mypod -- "/bin/bash"
cd /var/www/html
ls -l

Es sollte zu sehen sein, dass die Datei example-file.txt persistent ist, d.h. immer noch im gemounteten Ordner vorhanden ist.