Persistent Volume Claims w Kubernetes na NSIS Cloud

W Kubernetes woluminy trwałe (PV, Persistent Volumes) i Persistent Volume Claims (PVC) to wybrane mechanizmy, które wspólnie służą do zapewnienia trwałości pamięci masowej niezależne od cyklu życia kontenerów i podów.

Na platformie NSIS, w ramach projektu OpenStack Magnum, takie trwałe woluminy są implementowane przy użyciu sterownika OpenStack Cinder CSI. W tym artykule pokażemy przykład Persistent Volumes i Persistent Volume Claims. Po zdefiniowaniu Persisten Volume Claim będzie można go używać w kilku miejscach w aplikacji Kubernetes.

Co zostanie omówione?

Sprawdzenie obecności sterownika Cinder CSI w klastrze Kubernetes

Dynamiczne tworzenie Persistent Volume Claims za pomocą pliku yaml

Przechowywanie danych na Persistent Volume

Usuwanie poda i tworzenie go ponownie (dostęp przez SSH).

Sprawdzenie, czy dane są zachowane po usunięciu poda

Wymagania wstępne

1 Hosting

Wymagane jest konto hostingowe NSIS z interfejsem Horizon https://horizon.cloudferro.com.

2 Tworzenie klastrów za pomocą CLI

Artykuł Jak korzystać z interfejsu wiersza poleceń dla klastrów Kubernetes w NSIS OpenStack Magnum wprowadzi cię w tworzenie klastrów za pomocą interfejsu wiersza poleceń.

3 Podłączenie klienta openstack do chmury

Przygotuj klienty openstack i magnum, wykonując Krok 2 Podłączanie klientów OpenStack i Magnum do chmury Horizon z artykułu Jak zainstalować klientów OpenStack i Magnum dla interfejsu wiersza poleceń w NSIS Horizon?.

4 Rozumienie Persistent Volumes i Persistent Volume Claims

Oficjalne wprowadzenie do Persistent Volumes i Persistent Volume Claims znajduje się na głównej stronie Kubernetes.

5 Inne źródła wiedzy na temat OpenStack Cinder CSI

Raczej techniczne wprowadzenie do wtyczki OpenStack Cinder CSI z oficjalnego repozytorium Kubernetes na GitHub. https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md.

W przypadku alternatywnych scenariuszy wymagających odczytów/zapisów w wielu węzłach, istnieją alternatywne rozwiązania, które można również zintegrować z klastrem Magnum Kubernetes, na przykład obiektowa pamięć masowa S3 lub trwałość bazy danych.

Rodzaje zapewnienia trwałości Cinder CSI

Cinder CSI jest obsługiwany przez woluminy blokowej pamięci masowej Openstack Cinder, które są tworzone jako zasób pamięci masowej dla klastra Kubernetes.

W Kubernetes istnieją trzy główne sposoby dostępu do trwałej pamięci masowej:

readwriteonce (RWO), do odczytu przez pojedynczy węzeł

readonlymany (ROX), do odczytu przez wiele węzłów

readwritemany (RWX), do odczytu i zapisu przez wiele węzłów

Implementacja Cinder CSI w chmurze obsługuje typ dostępu RWO. Oznacza to, że Persistent Volume dostępny za pośrednictwem Persistent Volume Claim jest dostępny do odczytu i zapisu z pojedynczego węzła.

Sprawdzanie sterownika Cinder CSI w klastrze Kubernetes

Sterownik Cinder CSI jest preinstalowany w nowo utworzonym klastrze Kubernetes. Aby wyświetlić więcej informacji szczegółowych, wpisz jedno z poleceń:

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

Wtyczka CSI jest wdrażana jako kilka podów działających na węzłach głównych i roboczych. Informacje szczegółowe dla jednego z tych podów można wyświetlić za pomocą następującego polecenia:

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

Dane wyjściowe tych poleceń mogą mieć setki wierszy długości, więc zaprezentowanie ich jest poza zakresem tego artykułu.

Dynamiczne tworzenie Persistent Volume Claims

Klasa StorageClass jest abstrakcją, która pozwala na tworzenie trwałych wolumenów. Możemy zdefiniować klasę storage raz i używać jej ponownie podczas tworzenia Persistent Volume Claim tego samego typu. W środowisku chmurowym na nowym klastrze domyślnie tworzone są dwie klasy storage. Aby to zweryfikować, wykonaj poniższą komendę kubectl:

kubectl get sc

Wymienione są 2 klasy pamięci masowej, domyślna dla SSD (cinder-ssd) i druga dla HDD (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

Aby utworzyć nowy Persistent Volume Claim przy użyciu klasy pamięci masowej cinder-ssd, zapisz następujący plik jako dynamic-storage.yaml.

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

Po wykonaniu tego pliku yaml za pomocą polecenia:

kubectl apply -f dynamic-storage.yaml

możemy sprawdzić, czy Persistent Storage Claim został utworzony. Podobnie w tle został również utworzony Persistent Volume. Wyświetl te artefakty za pomocą następujących poleceń:

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

Ponadto, sprawdzając konsolę OpenStack Horizon, widzimy, że został utworzony rzeczywisty wolumen blokowej pamięci masowej.

../_images/persistent_volume_created1.png

Przechowywanie danych na zamontowanym Persistent Volume

Uruchomimy pod nginx oparty na oficjalnym obrazie, do którego zamontujemy nasz volume claim my-pvc.

Zapisz poniższy plik jako 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

Uruchom ten pliku yaml za pomocą polecenia:

kubectl apply -f check.yaml

tworzymy pod z Persistent Volume zamontowanym w katalogu /var/www/html. Dostęp do poda możemy uzyskać za pomocą polecenia:

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

Jako krok weryfikacyjny utwórzmy plik w katalogu, który jest zamontowany w woluminie /var/www/html:

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

Weryfikacja trwałości danych po usunięciu poda

Po wykonaniu poprzednich kroków plik example-file.txt zostanie zapisany na Persistent Volume. Nawet jeśli pod (lub nawet węzeł, na którym ten pod został utworzony) zostanie usunięty, plik powinien zostać zachowany.

Zweryfikujmy to poprzez:

usunięcie podu,

utworzenie go ponownie,

dostęp do niego przez SSH i

sprawdzenie zawartości katalogu /var/www/html:

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

Powinniśmy zobaczyć, że plik example-file.txt jest zachowany, czyli jest nadal dostępny w zamontowanym katalogu.