• »
  • KUBERNETES »
  • Kubernetes Persistent Volume Claims na NSIS

Kubernetes Persistent Volume Claims na NSIS

W Kubernetes, Persistent Volumes (PV) i Persistent Volume Claims (PVC) to wybrane mechanizmy, które wspólnie służą do zapewnienia trwałości pamięci masowej, poza cyklem życia kontenerów i kapsuł.

Na platformie NSIS, w ramach projektu OpenStack Magnum, taka trwałość jest zaimplementowana przy użyciu sterownika OpenStack Cinder CSI. W tym artykule pokażemy przykład trwałych wolumenów i roszczeń dotyczących trwałych wolumenów. Po zdefiniowaniu roszczenia będzie można go używać w kilku miejscach w aplikacji Kubernetes.

Co będziemy omawiać

  • Weryfikacja obecności sterownika Cinder CSI w klastrze Kubernetes

  • Dynamiczne tworzenie oświadczeń dotyczących woluminów trwałych - za pomocą pliku yaml

  • Przechowywanie danych na woluminie trwałym

  • Usuń kapsułę i utwórz ją ponownie (uzyskując dostęp przez SSH).

  • Sprawdź, czy dane są przechowywane po usunięciu podów

Wymagania wstępne

1 Hosting

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

2 Tworzenie klastrów za pomocą CLI

Artykuł /kubernetes/How-To-Use-Command-Line-Interface-for-Kubernetes-Clusters-On-NSIS-OpenStack-Magnum wprowadzi cię w tworzenie klastrów za pomocą interfejsu wiersza poleceń.

3 Podłącz klienta openstack do chmury

Przygotuj klientów openstack i magnum, wykonując Krok 2 Podłącz 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 Zrozumienie trwałych woluminów i roszczeń dotyczących trwałych woluminów

Jest to oficjalne wprowadzenie do Persistent Volumes i Persistent Volume Claims na głównej stronie Kubernetes.

5 Dalsza lektura na temat OpenStack Cinder CSI

A rather technical introduction to OpenStack Cinder CSI plugin from official Kubernetes repository on GitHub.

W przypadku alternatywnych scenariuszy wymagających wielowęzłowych odczytów/zapisów, 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 trwałości Cinder CSI

Cinder CSI jest wspierany 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 tryby dostępu do trwałej pamięci masowej:

  • readwriteonce (RWO)

  • readonlymany (ROX)

  • readwritemany (RWX)

Implementacja Cinder CSI w chmurze obsługuje typ trwałości 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 na klastrze Kubernetes

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

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

Wtyczka CSI jest wdrożona jako kilka kapsuł działających na węzłach nadrzędnych i roboczych. Możemy wyświetlić szczegóły jednego z tych strąków za pomocą polecenia w następujący sposób:

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

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

Dynamiczne tworzenie oświadczeń o trwałych woluminach

Storage Class is an abstraction that enables dynamic creation of persistent volumes. We can define a storage class once and reuse it later for creating other persistent volume claims of the same type. On cloud we have 2 storage classes created by default on a new cluster. To verify this execute a following kubectl command:

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ć nowe roszczenie Persistent Volume 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 poprzez:

kubectl apply -f dynamic-storage.yaml

możemy sprawdzić, czy roszczenie trwałego woluminu zostało utworzone. Podobnie, pod maską, 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, weryfikując konsolę OpenStack Horizon, widzimy, że został utworzony rzeczywisty wolumen block storage.

../_images/persistent_volume_created.png

Przechowywanie danych na zamontowanym woluminie trwałym

Uruchomimy kapsułę nginx opartą na oficjalnym obrazie, do której zamontujemy nasze roszczenie dotyczące woluminu 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

Uruchomienie tego pliku yaml za pomocą:

kubectl apply -f check.yaml

tworzymy pod, z trwałym wolumenem zamontowanym do folderu /var/www/html. Możemy uzyskać dostęp do poda za pomocą tego polecenia:

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

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

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

Weryfikacja trwałości danych po usunięciu podstacji

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

Zweryfikujmy to poprzez

  • usunięcie kapsuły,

  • odtwarzając go ponownie,

  • dostęp do niego przez SSH i

  • sprawdzenie zawartości folderu /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 trwały, czyli nadal dostępny w zamontowanym folderze.

../_images/file_still_available.png