Klaster OKD (OpenShift) – Zarządzanie volumenami PV

Testowy klaster OKD (OpenShift)

Poniższy wpis bazuje na konfiguracji klastra przeprowadzonej wg. wpisu https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-opis-instalacji/ a w szczególności konfiguracji serwera NFS opisanej na stronie https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-przygotowanie-maszyny-storage-nfs/

Czym jest OpenShift PVC (PersistentVolumeClaim)?

W OpenShift PersistentVolumeClaim (PVC) to żądanie pamięci masowej przez użytkownika lub aplikację. Umożliwia ono dostęp do PersistentVolumes (PV), które zapewniają zasoby pamięci masowej, takie jak NFS, Ceph, AWS EBS itp. PVC abstrakcyjnie zarządzają pamięcią masową, umożliwiając użytkownikom żądanie pamięci masowej bez martwienia się o jej podstawową implementację.

Kluczowe komponenty PVC
PersistentVolume (PV): PersistentVolume to część pamięci masowej udostępniana przez administratora lub dynamicznie tworzona na podstawie klasy pamięci masowej. Reprezentuje rzeczywisty zasób pamięci masowej (np. udział NFS, cel iSCSI lub dysk pamięci masowej w chmurze).

PersistentVolumeClaim (PVC): PVC to żądanie pamięci masowej przez pod. Określa szczegóły, takie jak:

Rozmiar: wymagana ilość pamięci masowej.
Tryb dostępu: sposób dostępu do woluminu (np. ReadWriteOnce, ReadOnlyMany itd.).
Klasa pamięci masowej: określa typ pamięci masowej (np. SSD, HDD lub określone klasy pamięci masowej w chmurze).
StorageClass: określa sposób dynamicznego udostępniania pamięci masowej dla PVC.

Jak działa PVC w OpenShift
Utwórz PVC: programista tworzy PVC, aby zażądać określonej ilości pamięci masowej z określonymi trybami dostępu.

Powiąż z PV: OpenShift automatycznie dopasowuje PVC do odpowiedniego PV na podstawie rozmiaru, trybów dostępu i klasy pamięci masowej. Jeśli zostanie znaleziony pasujący PV, PVC jest z nim powiązany.

Użycie w kontenerach: PVC jest odwoływany w konfiguracji kontenera, a pamięć masowa jest montowana jako wolumin wewnątrz kontenera do użytku przez aplikację.

Tryby dostępu PVC

ReadWriteOnce Może być montowany jako do odczytu i zapisu przez pojedynczy węzeł.
ReadOnlyMany Może być montowany jako tylko do odczytu przez wiele węzłów.
ReadWriteMany Może być montowany jako do odczytu i zapisu przez wiele węzłów (nieobsługiwane przez wszystkie zaplecza pamięci masowej).

Utworzenie rejestru obrazów

Rejestr obrazów zostaje usunięty podczas instalacji. Na platformach, które nie zapewniają współdzielonej pamięci masowej obiektów, operator rejestru obrazów OpenShift uruchamia się jako Usunięty. Umożliwia to programowi openshift-installer ukończenie instalacji na tych typach platform. Po instalacji należy edytować konfigurację operatora rejestru obrazów, aby zmienić stan zarządzania z Usuniętego na Zarządzany. Po zakończeniu tej czynności należy skonfigurować pamięć masową. Więcej informacji można znaleźć tutaj https://docs.openshift.com/container-platform/4.15/registry/configuring_registry_storage/configuring-registry-storage-baremetal.html.

Opis utworzenia volumenu lvm o rozmiarze 100 GB i jego udostępnienie po stronie serwera NFS opisane jest tutaj https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-przygotowanie-maszyny-storage-nfs/#8-konfigurowanie-rejestru-obraz%C3%B3w-dla-klastra-okd-openshift

Przygotowujemy plik definicji nowego PV w pliku /home/bastuser/nfs-pv-registry.yaml bazując na konfiguracji naszego serwera NFS

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv-registry
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /mnt/lv_registry # NFS export path
    server: 192.168.40.20  # NFS server IP
  persistentVolumeReclaimPolicy: Retain  # Reclaim policy (Retain, Recycle, or Delete)

i tworzymy na jego podstawie nowy obiekt typu pv o nazwie nfs-pv-registry

oc apply -f /home/bastuser/nfs-pv-registry.yaml

Weryfikujemy jego powstanie na klastrze

oc get pv

Teraz tworzymy pvc o nazwie nfs-pvc-registry który będzie używany bezpośrednio do przechowywania obrazów OKD (OpenShift)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc-registry
  namespace: openshift-image-registry
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Gi

oc apply -f /home/bastuser/nfs-pvc-registry.yaml

Teraz musimy skonfigurować Image Registry ustawiając ręcznie parametr pvc

oc edit configs.imageregistry.operator.openshift.io

...
spec:
  storage:
    pvc:
      claim: nfs-pvc-registry

lub dużo wygodniej używając oc patch zwracając uwagę na nazwę naszego pvc czyli w tym przypadku nfs-pvc-registry

oc patch configs.imageregistry.operator.openshift.io cluster \
  --type=merge \
  -p '{"spec": {"storage": {"pvc": {"claim": "nfs-pvc-registry"}}}}'

Po wszystkim weryfikujemy czy pody w projekcie openshift-image-registry są poprawnie uruchomione a pvc w tym projekcie ma status Bound

oc get pods -n openshift-image-registry
oc get pvc -n openshift-image-registry

oc get pod -n openshift-image-registry -l docker-registry=default
oc get clusteroperator image-registry

Utworzenie PV i PVC do przechowywania danych podów

Przygotowujemy plik definicji nowego PV w pliku /home/bastuser/pv-05.yaml na podstawie konfiguracji naszego serwera NFS np. z tego opisu https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-przygotowanie-maszyny-storage-nfs/

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pvc-05
spec:
  capacity:
    storage: 10Gi  # Specify the size of the volume
  accessModes:
    - ReadWriteMany # Access mode (can also use ReadWriteMany or ReadOnlyMany)
  nfs:
    path: /mnt/lv_pvc_05  # NFS export path
    server: 192.168.40.20  # NFS server IP
  persistentVolumeReclaimPolicy: Retain  # Reclaim policy (Retain, Recycle, or Delete)

oc create -f /home/bastuser/pv-05.yaml

Weryfikujemy powstanie persistent volume

oc get pv