Praktiline näide Ceph-põhise salvestuse ühendamisest Kubernetes'i klastri juurde

Container Storage Interface (CSI) on ühtne liides Kubernetes'e ja andmesalvestussüsteemide vahel. Lühidalt oleme juba rääkinud selle toimimisest, rääkinud, ja täna vaatame lähemalt CSI ja Ceph'i seost: näitame, kuidas ühendada Ceph'i salvestust Kubernetes'i klastriga.
Artiklis on esitatud reaalsed, kuigi veidi lihtsustatud näited mugavamaks arusaamiseks. Ceph'i ja Kubernetes'i klastrite paigaldamist ja seadistamist me ei käsitle.

Kas teil on huvi, kuidas see toimib?

Praktiline näide Ceph-põhise salvestuse ühendamisest Kubernetes'i klastri juurde

Oletame, et teil on käepärast Kubernetes'i klaster, mis on seadistatud näiteks kubespray. Kõrval töötab Ceph'i klaster – selle saab samuti paigaldada näiteks selle playbookide kogumi. Loodetavasti ei ole vaja mainida, et tootmisülesannetes peab nende vahel olema võrk, mille ribalaius on vähemalt 10 Gbit/s.

Kui see kõik on teil olemas, siis asume asja kallale!

Esmalt logime sisse ühte Ceph'i klastri sõlme ja kontrollime, et kõik on korras:

ceph health
ceph -s

Seejärel loome kohe RBD-kettaste jaoks basseini:

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

Liigume Kubernetes'i klastrisse. Esmalt paigaldame Ceph CSI draiveri RBD jaoks. Paigaldame selle nagu ikka läbi Helm'i.
Lisame chart'i reposti ning saame ceph-csi-rbd chart'i muutuja komplekti:

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

Nüüd tuleb täita fail cephrbd.yml. Selleks saame teada klastri ID ja Ceph'i monitoride IP-aadressid:

ceph fsid  # nii saame teada clusterID
ceph mon dump  # ja nii näeme monitoride IP-aadresse

Saadud väärtused paneme faili cephrbd.yml. Samuti lülitame sisse PSP (Pod Security Policies) loomise. Valikud jaotistes nodeplugin ja provisioner on juba failis olemas, neid saab muuta nagu allpool näidatud:

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

Seejärel jääb alles vaid paigaldada chart Kubernetes'i klastrisse.

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

Suurepärane, RBD draiver töötab!
Loodame Kubernetes'is uut StorageClass'i. Selleks on jälle vaja natuke tööd Ceph'iga.

Loome Ceph'is uue kasutaja ja anname talle õiguse kirjutada basseini kube:

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

Ja nüüd vaatame pääsukoodi kõik ikka seal:

ceph auth get-key client.rbdkube

Käsk väljastab midagi sellist:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Kandke see väärtus Kubernetes'i klastris Secretisse - sinna, kus see vajalik on userKey:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-rbd-secret
  namespace: ceph-csi-rbd
stringData:
  # Võtme väärtused vastavad kasutajanimele ja tema võti, nagu on määratud
  # Ceph klastris. Kasutaja ID-l peab olema ligipääs basseinile,
  # mis on määratud salvestusklassis
  userID: rbdkube
  userKey:

Ja loome meie salajase võtme:

kubectl apply -f secret.yaml

Edasi vajame umbes sellist StorageClass'i manifesti:

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

   imageFeatures: layering

   # Need saladused peavad sisaldama andmeid autentimiseks
   # teie basseiniga.
   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

Peame täitma clusterID, mille me juba teadsime käsu ceph fsid, ja rakendama selle manifesti Kubernetes'i klastris:

kubectl apply -f storageclass.yaml

Klastrite töö kontrollimiseks loome sellise PVC (Persistent Volume Claim):

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

Vaadakem kohe, kuidas Kubernetes loob Ceph'is taotletud mahtu:

kubectl get pvc
kubectl get pv

Tundub, et kõik on suurepärane! Kuidas see paistab Ceph'i küljest?
Saame nimekirja basseinist ja vaatame meie mahu kohta teavet:

rbd ls -p kube
rbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653  # siin on muidugi teine mahu ID, mille eelmine käsk tagastas

Nüüd vaadakem, kuidas RBD mahu suuruse muutmine töötab.
Muudame mahu suuruse manifestis pvc.yaml 2Gi-ks ja rakendame selle:

kubectl apply -f pvc.yaml

Ootame, kuni muutused jõustuvad, ja vaatame veel kord mahu suurust.

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

kubectl get pv
kubectl get pvc

Näeme, et PVC suurus ei muutunud. Probleemi väljaselgitamiseks võime küsida Kubernetes'e YAML formaadis PVC kirjeldust:

kubectl get pvc rbd-pvc -o yaml

Ja siin on probleem:

message: Ootame kasutajat, et (uuesti) käivitada pod, et lõpetada mahu failisüsteemi suuruse muutmine sõlmel. type: FileSystemResizePending

Ehkki ketas suurenes, ei suurenenud selles failisüsteem.
Failisüsteemi suurendamiseks tuleb maht mountida. Meil on loodud PVC/PV, mida hetkel ei kasutata.

Saame luua katse Pod'i, näiteks nii:

---
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

Ja vaatame PVC-d:

kubectl get pvc

Suurus on muutunud, kõik on korras.

Esimeses osas töötasime RBD (Rados Block Device) plokiseadmestikuga, kuid see ei sobi, kui erinevad mikroteenused peavad sama kettaga samaaegselt töötama. Failide töötlemiseks sobib CephFS oluliselt paremini kui kettapilt.
Seetõttu seadistame Ceph ja Kubernetes klastrite näitel CSI ja muud vajalikud üksused CephFS-i kasutamiseks.

Saame vajalikud väärtused meie uue Helm-chart'i jaoks:

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

Peame uuesti täitma faili cephfs.yml. Nagu varem, aitavad Ceph'i käsud:

ceph fsid
ceph mon dump

Täidame faili väärtustega umbes nii:

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

Pange tähele, et monitooringu aadresse esitatakse lihtsas vormis aadress:port. CephFS-i mountimiseks sõlmes edastatakse need aadressid tuumamoodulile, mis ei oska veel töötada v2 monitooringu protokolliga.
Muutame httpMetrics'i porti (sinna saadab Prometheus jälgimiseks mõõdikud), et vältida konflikti nginx-proxyga, mille installeerib Kubespray. Teie jaoks see võib-olla vajalik ei ole.

Paigaldame Helm-chart'i Kubernetes klastrisse:

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

Läheme Ceph andmetehoidu, et luua seal eraldi kasutaja. Dokumentatsioonis on öeldud, et CephFS-i provisjonimiseks on vaja klastrihalduri õigusi. Kuid loome eraldi kasutaja fs piiratud õigustega:

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'

Ja vaatame kohe tema juurdepääsuvõtit, see on meile edaspidi kasulik:

ceph auth get-key client.fs

Loome eraldi Secret ja StorageClass.
Midagi uut, oleme seda juba näinud RBD näitel:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-cephfs-secret
  namespace: ceph-csi-cephfs
stringData:
  # Vajalik dünaamiliselt loodud mahutite jaoks
  adminID: fs
  adminKey:

Rakendame manifesti:

kubectl apply -f secret.yaml

Ja nüüd - eraldi StorageClass:

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

  # CephFS faili süsteemi nimi, milles maht luuakse
  fsName: cephfs

  # (valikuline) Ceph bassein, kus volüümide andmed hoiustatakse
  # pool: cephfs_data

  # (valikuline) Comma eraldatud Ceph-fuse mountimise valikud
  # näiteks:
  # fuseMountOptions: debug

  # (valikuline) Comma eraldatud CephFS mountimise valikud kernelile
  # Vaata man mount.ceph nende valikute loendi jaoks. Näiteks:
  # kernelMountOptions: readdir_max_bytes=1048576,norbytes

  # Salajastes peavad olema administraatori ja/või Ceph kasutaja juurdepääsud.
  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

  # (valikuline) Draiver võib kasutada kas ceph-fuse (fuse) või
  # ceph kernelclient (kernel).
  # Kui ei ole määratud, kasutatakse vaikimisi mahtude mountimist,
  # seda määrab ceph-fuse ja mount.ceph otsing
  # mounter: kernel
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
  - debug

Täidame siia clusterID ja rakendame Kubernetesis:

kubectl apply -f storageclass.yaml

Kontrollimine

Kontrollimiseks, nagu eelmises näites, loome PVC:

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

Ja kontrollime PVC/PV olemasolu:

kubectl get pvc
kubectl get pv

Kui soovite näha faile ja katalooge CephFS-is, saate selle faili süsteemi kuhugi monteerida. Näiteks nagu allpool näidatud.

Läheme ühele Ceph klastrite nodest ja teeme sellised toimingud:

# Точка монтирования
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

Muidugi, selline FS montaaž Ceph nodul sobib ainult õppe eesmärkidel, millega me tegeleme meie Slurm kursustel. Ei usu, et keegi seda tootmises teeks, suur oht on olulisi faile kogemata üle kirjutada.

Ja viimasena kontrollime, kuidas on CephFS-i mahutite muutmisega. Tagasi Kubernetesisse ja redigeerime meie PVC manifesti - suurendame seal suurust, näiteks 7Gi-ks.

Rakendame redigeeritud faili:

kubectl apply -f pvc.yaml

Vaata monteeritud kataloogis, kuidas kvoot on muutunud:

getfattr -n ceph.quota.max_bytes

Selle käsu tööks võib olla vajalik installida süsteemi pakett attr.

Silmad kardavad, aga käed teevad

Esialgu näivad kõik need loitsud ja pikad YAML manifeste keerulised, kuid praktikas saavad Slørmi üliõpilased nendega üsna kiiresti hakkama.
Selles artiklis me ei süvenenud sügavale — selleks on ametlik dokumentatsioon. Kui teid huvitavad Cephi salvestusruumi seadistamise üksikasjad koos Kubernetes'i klastriga, aitavad need lingid:

Kubernetes'i ja mahtude üldpõhimõtted
RBD dokumentatsioon
RBD ja Kubernetes'i integreerimine Cephi vaatenurgast
RBD ja Kubernetes'i integreerimine CSI vaatenurgast
CephFS ülddokumendid
CephFS ja Kubernetes'i integreerimine CSI vaatenurgast

Slørmi kursusel Kubernetes Põhi saate minna veelgi kaugemale ja käivitada Kubernetes'is reaalne rakendus, mis kasutab CephFS-i failide salvestamiseks. GET/POST päringute kaudu saate faili edastada ja neid Ceph'st saada.

Kui teid rohkem huvitab andmete salvestamine, siis registreeruge uus kursus Cephi kohta. Seni, kuni beta-testimine on käimas, on kursus saadaval soodushinnaga ja saate mõjutada selle sisu.

Artikli autor: Aleksandr Švalov, praktikantinsener Southbridge, Certified Kubernetes Administrator, Slørmi kursuste autor ja arendaja.

Allikas: habr.com

Osta usaldusväärne hostimine veebilehtede jaoks DDoS-i kaitsega, VPS VDS serverid 🔥 Osta usaldusväärne hostimine veebilehtede jaoks DDoS-i kaitsega, VPS VDS serverid | ProHoster