Klaster OKD (OpenShift) – Zarz膮dzanie volumenami PV

IT Admin > Konteneryzacja > OpenShift > 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

Nale偶y teraz w艂膮czy膰 registry oraz default route

# Najpierw sprawd藕, czy nadal masz Removed
oc get configs.imageregistry.operator.openshift.io cluster -o jsonpath='{.spec.managementState}{"\n"}'
Removed

W艂膮cz Image Registry (Managed) i zostaw PVC kt贸re ju偶 masz nfs-pvc-registry

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

W艂膮cz automatyczne wystawienie Route (defaultRoute)

oc patch configs.imageregistry.operator.openshift.io cluster --type=merge -p '{
  "spec": { "defaultRoute": true }
}'

Sprawd藕 Route

oc get route -n openshift-image-registry

Test logowania do registry z bastiona

REG_HOST=$(oc get route -n openshift-image-registry -o jsonpath='{.items[0].spec.host}{"\n"}')
echo $REG_HOST
sudo dnf -y install podman
podman login -u $(oc whoami) -p $(oc whoami -t) $REG_HOS

Doinstalowanie CA klastra do systemowego trust store bastiona

podman login -u $(oc whoami) -p $(oc whoami -t) $REG_HOS

# w razie bldow 
#Error: authenticating creds for "default-route-openshift-image-registry.apps.testcluster.okdlab.local": pinging container registry default-route-openshift-image-registry.apps.testcluster.okdlab.local: Get "https://default-route-openshift-image-registry.apps.testcluster.okdlab.local/v2/": tls: failed to verify certificate: x509: certificate signed by unknown authority

# Wyci膮gnij cert 艂a艅cucha z registry route
echo | openssl s_client -showcerts -connect ${REG_HOST}:443 -servername ${REG_HOST} 2>/dev/null \
  | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/ {print}' > /tmp/registry-route.crt

# Dodaj do trust store (Fedora/RHEL/CentOS)
sudo cp /tmp/registry-route.crt /etc/pki/ca-trust/source/anchors/registry-route.crt
sudo update-ca-trust

# sprobuj ponownie
podman login -u $(oc whoami) -p $(oc whoami -t) $REG_HOST
Login Succeeded!

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
Konteneryzacja, OpenShift
Tags , ,