Një shembull praktik i lidhjes së magazinës së bazuar në Ceph në një klaster Kubernetes

Interface e Ruajtjes së Kontejnerëve (CSI) - është një ndërfaqe e standardizuar e bashkëpunimit midis Kubernetes dhe sistemeve të ruajtjes së të dhënave. Në mënyrë të shkurtër për të, ne tashmë folëm, dhe sot do të shqyrtojmë më në detaje lidhjen CSI dhe Ceph: do të tregojmë se si të lidhni ruajtjen Ceph me klasterin Kubernetes.
Në artikullin e mëposhtëm do të paraqesim shembuj realë, edhe pse pak të thjeshtuar për lehtësi në kuptim. Instalimi dhe konfigurimi i klastereve Ceph dhe Kubernetes nuk do të shqyrtohet.

Ju intereson si funksionon kjo?

Pra, keni në duar një klaster Kubernetes, të vendosur, për shembull, kubespray. Pranë punon një klaster Ceph - mund ta instaloni gjithashtu, për shembull, me këtë grup të playbook-eve. Shpresoj, nuk është e nevojshme të përmendet se për prodhimin, midis tyre duhet të ketë një rrjet me kapacitet jo më të ulët se 10 Gbit/s.

Nëse të gjitha këto i keni, le të fillojmë!

Fillimisht, do të hyjmë në një nga nodet e klasterit Ceph dhe do të kontrollojmë që gjithçka është në rregull:

ceph health
ceph -s

Më pas, këtu do të krijojmë një pool për diskët RBD:

ceph osd pool create kube 32
ceph osd pool application enable kube rbd

Kalojmë në klasterin Kubernetes. Atje, së pari do të instalojmë drejtorin Ceph CSI për RBD. Do ta vendosim siç duhet, përmes Helm.
Shtojmë repositorin me chartin, dhe marrim grupin e variablave të chartit ceph-csi-rbd:

helm repo add ceph-csi https://ceph.github.io/csi-charts
helm inspect values ceph-csi/ceph-csi-rbd > cephrbd.yml

Tani duhet të plotësojmë skedarin cephrbd.yml. Për këtë, le të gjejmë ID-në e klashtarit dhe adresat IP të monitorëve në Ceph:

ceph fsid  # kështu do të mësojmë clusterID
ceph mon dump  # kështu do të shohim adresat IP të monitorëve

Vlerat e marra i shtojmë në skedarin cephrbd.yml. Ndërkohë aktivizojmë krijimin e politikave PSP (Pod Security Policies). Opsionet në seksionet nodeplugin dhe provisioner janë tashmë në skedar, mund të korrigjohen siç tregohen më poshtë:

csiConfig:
  - clusterID: "bcd0d202-fba8-4352-b25d-75c89258d5ab"
    monitors:
      - "v2:172.18.8.5:3300/0,v1:172.18.8.5:6789/0"
      - "v2:172.18.8.6:3300/0,v1:172.18.8.6:6789/0"
      - "v2:172.18.8.7:3300/0,v1:172.18.8.7:6789/0"

nodeplugin:
  podSecurityPolicy:
    enabled: true

provisioner:
  podSecurityPolicy:
    enabled: true

Pastaj, gjithçka që na mbetet është të instalojmë chart-in në klashtarin Kubernetes.

helm upgrade -i ceph-csi-rbd ceph-csi/ceph-csi-rbd -f cephrbd.yml -n ceph-csi-rbd --create-namespace

Shumë mirë, RBD driver-i po punon!
Të krijojmë një StorageClass të re në Kubernetes. Për këtë, do të nevojitet të punojmë pak më shumë me Ceph.

Krijojmë një përdorues të ri në Ceph dhe i japim të drejta për shkrim në depo kube:

ceph auth get-or-create client.rbdkube mon 'profile rbd' osd 'profile rbd pool=kube'

Më tani le të shohim çelësin e aksesit gjithashtu:

ceph auth get-key client.rbdkube

Komanda do të japë diçka të ngjashme me:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Do ta vlerë në Secret në klasterin Kubernetes - atje ku nevojitet userKey:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-rbd-secret
  namespace: ceph-csi-rbd
stringData:
  # Vlerat e çelësave janë në përputhje me emrin e përdoruesit dhe çelësin e tij, siç është përcaktuar në
  # klasterin Ceph. ID e përdoruesit duhet të ketë qasje në rezervuarin,
  # të treguar në klasën e ruajtjes
  userID: rbdkube
  userKey:

Dhe krijojmë sekretin tonë:

kubectl apply -f secret.yaml

Pastaj na nevojitet një manifest i tillë StorageClass:

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: csi-rbd-sc
provisioner: rbd.csi.ceph.com
parameters:
   clusterID: 
   pool: kube

   imageFeatures: layering

   # Këto sekrete duhet të përmbajnë të dhëna për autorizim
   # në rezervuarin tuaj.
   csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret
   csi.storage.k8s.io/provisioner-secret-namespace: ceph-csi-rbd
   csi.storage.k8s.io/controller-expand-secret-name: csi-rbd-secret
   csi.storage.k8s.io/controller-expand-secret-namespace: ceph-csi-rbd
   csi.storage.k8s.io/node-stage-secret-name: csi-rbd-secret
   csi.storage.k8s.io/node-stage-secret-namespace: ceph-csi-rbd

   csi.storage.k8s.io/fstype: ext4

reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
  - discard

Duhet të plotësojmë clusterID, i cili e kemi mësuar tashmë me komandën ceph fsid, dhe apliko këtë manifest në klasterin Kubernetes:

kubectl apply -f storageclass.yaml

Për të verifikuar funksionimin e klastereve në bashkëpunim, do të krijojmë një PVC (Kërkesë për Volume të Përhershëm) të tillë:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rbd-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-rbd-sc

Le të shohim menjëherë se si Kubernetes krijoi volumën e kërkuar në Ceph:

kubectl get pvc
kubectl get pv

Duket se gjithçka është në rregull! Por si duket kjo në anën e Ceph?
Marrim listën e volumeve në rezervuari dhe shohim informacionin për volumën tonë:

rbd ls -p kube
rbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653  # këtu, sigurisht, do të ketë një ID tjetër për volum, që u dha nga komanda e mëparshme

Tani le të shohim se si funksionon ndryshimi i madhësisë së volumit RBD.
Ndryshojmë madhësinë e volumit në manifestin pvc.yaml në 2Gi dhe e aplikojmë:

kubectl apply -f pvc.yaml

Të presim derisa ndryshimet të hyjnë në fuqi dhe t'i hedhim një sy përsëri madhësisë së volumit.

rbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653

kubectl get pv
kubectl get pvc

Vërejmë se madhësia e PVC nuk është ndryshuar. Për të kuptuar arsyen, mund të kërkojmë nga Kubernetes përshkrimin e PVC në formatin YAML:

kubectl get pvc rbd-pvc -o yaml

Dhe ja problemi:

message: Waiting for user to (re-)start a pod to finish file system resize of volume on node. type: FileSystemResizePending

Pra, disku u rrit, por sistemi i skedave mbi të — jo.
Për të zgjeruar sistemin e skedave, duhet të montoni volumet. Aktualisht, PVC/PV i krijuar nuk përdoret asnjëherë.

Mund të krijojmë një Pod testues, p.sh. kështu:

---
apiVersion: v1
kind: Pod
metadata:
  name: csi-rbd-demo-pod
spec:
  containers:
    - name: web-server
      image: nginx:1.17.6
      volumeMounts:
        - name: mypvc
          mountPath: /data
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        claimName: rbd-pvc
        readOnly: false

Tani le të shikojmë PVC:

kubectl get pvc

Madhësia ka ndryshuar, gjithçka është në rregull.

Në pjesën e parë punuam me një pajisje blloku RBD (ky është emërtimi – Rados Block Device), por nuk është e mundur ta bësh këtë nëse kërkohet përdorimi i njëkohshëm të këtij disku nga mikroshërbime të ndryshme. Për punë me skedarë, e jo me imazhin e disku, CephFS është shumë më i përshtatshëm.
Në shembullin e klashtave Ceph dhe Kubernetes do të konfigurimim CSI dhe entitetet e tjera të nevojshme për të punuar me CephFS.

Do të marrim vlerat nga Helm-charta që na nevojitet:

helm inspect values ceph-csi/ceph-csi-cephfs > cephfs.yml

Sërish duhet të plotësojmë skedarin cephfs.yml. Si më parë, komandat Ceph do të na ndihmojnë:

ceph fsid
ceph mon dump

Plotësojmë skedarin me vlera pak a shumë kështu:

csiConfig:
  - clusterID: "bcd0d202-fba8-4352-b25d-75c89258d5ab"
    monitors:
      - "172.18.8.5:6789"
      - "172.18.8.6:6789"
      - "172.18.8.7:6789"

nodeplugin:
  httpMetrics:
    enabled: true
    containerPort: 8091
  podSecurityPolicy:
    enabled: true

provisioner:
  replicaCount: 1
  podSecurityPolicy:
    enabled: true

Vini re se adresat e monitorëve janë të dhënë në një format të thjeshtë address:port. Për të montuar cephfs në nod, këto adresa dërgohen në modul të bërthamës, i cili ende nuk di të punojë me protokolin e monitorëve v2.
Ne e ndryshojmë portin për httpMetrics (ku Prometheus do të shkojë për metrikat e monitorimit) që të mos ketë konflikte me nginx-proxy, i cili instalohet nga Kubespray. Kjo mund të mos jetë e nevojshme për ju.

Po instalojmë Helm-chart në klasterin Kubernetes:

helm upgrade -i ceph-csi-cephfs ceph-csi/ceph-csi-cephfs -f cephfs.yml -n ceph-csi-cephfs --create-namespace

Tani kalojmë tek depoja e të dhënave Ceph për të krijuar një përdorues të veçantë. Në dokumentacion thuhet se provizionuesi CephFS ka nevojë për të drejta administratori në klaster. Por ne do të krijojmë një përdorues të veçantë fs me dëshmi të kufizuara:

ceph auth get-or-create client.fs mon 'allow r' mgr 'allow rw' mds 'allow rws' osd 'allow rw pool=cephfs_data, allow rw pool=cephfs_metadata'

Dhe menjëherë do të shohim çelësin e tij të qasjes, do të na nevojitet më vonë:

ceph auth get-key client.fs

Do të krijojmë Secret të veçantë dhe StorageClass.
Nuk ka asgjë të re, ne këtë e kemi parë më parë në shembullin RBD:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-cephfs-secret
  namespace: ceph-csi-cephfs
stringData:
  # E nevojshme për volumin që krijohet dinamikisht
  adminID: fs
  adminKey:

Aplikojmë manifestin:

kubectl apply -f secret.yaml

Tani – një StorageClass të veçantë:

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-cephfs-sc
provisioner: cephfs.csi.ceph.com
parameters:
  clusterID: 

  # Emri i sistemit të skedarëve CephFS, në të cilin do të krijohet vëllimi
  fsName: cephfs

  # (opsionale) Pishina Ceph ku do të ruhen të dhënat e vëllimit
  # pool: cephfs_data

  # (opsionale) Opsione të montažhimit të ndara me presje për Ceph-fuse
  # për shembull:
  # fuseMountOptions: debug

  # (opsionale) Opsione të montažhimit CephFS për kernel të ndara me presje
  # Shihni man mount.ceph për të mësuar rreth këtyre opsioneve. Për shembull:
  # kernelMountOptions: readdir_max_bytes=1048576,norbytes

  # Sekretet duhet të përmbajnë qasje për administratorin dhe/ose përdoruesin Ceph.
  csi.storage.k8s.io/provisioner-secret-name: csi-cephfs-secret
  csi.storage.k8s.io/provisioner-secret-namespace: ceph-csi-cephfs
  csi.storage.k8s.io/controller-expand-secret-name: csi-cephfs-secret
  csi.storage.k8s.io/controller-expand-secret-namespace: ceph-csi-cephfs
  csi.storage.k8s.io/node-stage-secret-name: csi-cephfs-secret
  csi.storage.k8s.io/node-stage-secret-namespace: ceph-csi-cephfs

  # (opsionale) Driveri mund të përdorë ose ceph-fuse (fuse), 
  # ose ceph kernelclient (kernel).
  # Nëse nuk përcaktohet, do të përdoret montažhimi i vëllimeve nga parazgjedhja,
  # kjo përcaktohet nga kërkimi i ceph-fuse dhe mount.ceph
  # mounter: kernel
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
  - debug

Do ta mbushim këtu clusterID dhe do ta aplikojmë në Kubernetes:

kubectl apply -f storageclass.yaml

Kontroll

Për kontroll, siç bëmë në shembullin e kaluar, do të krijojmë PVC:

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-cephfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  storageClassName: csi-cephfs-sc

Dhe do të kontrollojmë praninë e PVC/PV:

kubectl get pvc
kubectl get pv

Nëse dëshironi të shihni skedarët dhe katalogët në CephFS, mund ta montoni këtë sistem skedari diku. Për shembull, siç tregohet më poshtë.

Shkoni në një nga nodet e klasterit Ceph dhe kryeni këto veprime:

# Точка монтирования
mkdir -p /mnt/cephfs

# Создаём файл с ключом администратора
ceph auth get-key client.admin >/etc/ceph/secret.key

# Добавляем запись в /etc/fstab
# !! Изменяем ip адрес на адрес нашего узла
echo "172.18.8.6:6789:/ /mnt/cephfs ceph name=admin,secretfile=/etc/ceph/secret.key,noatime,_netdev    0       2" >> /etc/fstab

mount /mnt/cephfs

Sigurisht, një montim i tillë FS në noden Ceph është i përshtatshëm vetëm për qëllime mësimore, dhe kjo është ajo që ne po bëjmë në kurset tona Sllërm.Nuk mendoj se ndokush do ta bëjë këtë në prodhim, ka një rrezik të madh për të përmbysur skedarë të rëndësishëm.

Dhe në fund, le të kontrollojmë si qëndrojnë gjërat me ndërrimin e madhësisë së volumit në rastin e CephFS. Kthehemi në Kubernetes dhe redaktojmë manifestin tonë për PVC - do ta rrisim atje madhësinë, për shembull, në 7Gi.

Do ta aplikojmë skedarin e redaktuar:

kubectl apply -f pvc.yaml

Le të shohim në katalogun e montuar si ka ndryshuar kuota:

getfattr -n ceph.quota.max_bytes

Për të funksionuar këtë komandë, ndoshta do t'ju nevojitet të instaloni paketën në sistemin tuaj attr.

Syri friksohet, por duar bëjnë

Pamja e këtyre magjive dhe manifestëve të gjatë YAML duket e komplikuar, por në praktikë studentët e Slyërm e menaxhojnë ato mjaft shpejt.
Në këtë artikull ne nuk thellohemi në detaje — ka dokumentacionin zyrtar për këtë. Nëse jeni të interesuar për detajet e konfigurimit të depozitës Ceph së bashku me klasterin Kubernetes, këto lidhje do t' ju ndihmojnë:

Parimet e përgjithshme të punës së Kubernetes me volume
Dokumentacioni për RBD
Integrimi i RBD dhe Kubernetes nga perspektiva e Ceph
Integrimi i RBD dhe Kubernetes nga perspektiva e CSI
Dokumentacioni i përgjithshëm për CephFS
Integrimi i CephFS dhe Kubernetes nga perspektiva e CSI

Në kursin Slyërm Baza Kubernetes mund të shkoni edhe më tej dhe të zhvilloni një aplikacion real në Kubernetes, i cili do të përdorë CephFS si depo për skedarët. Nëpërmjet kërkesave GET/POST do të jeni në gjendje të transferoni skedarë dhe t'i merrni ata nga Ceph.

Dhe nëse ju intereson më shumë ruajtja e të dhënave, regjistrohuni në kursin e ri për Ceph. Gjatë testimit beta, kursi mund të merret me zbritje dhe të ndikoni në përmbajtjen e tij.

Autori i artikullit: Alexander Shvalov, inxhinier praktikues Southbridge, Administrator i Certifikuar Kubernetes, autor dhe zhvillues i kurseve Slyërm.

Burimi: habr.com