Praktiline näide Ceph-põhise salvestuse ühendamisest Kubernetes klastrisse

Container Storage Interface (CSI) on ühtne liides Kubernetes'e ja salvestussüsteemide vahel. Lühidalt oleme sellest juba rääkinud, olen rääkinud, aga täna vaatame lähemalt CSI ja Ceph seost: näitame, kuidas ühendada Ceph salvestus Kubernetes klastriga.
Artiklis on toodud reaalsed, kuigi veidi lihtsustatud näited mugavuse huvides. Ceph ja Kubernetes klastrite installimist ja seadistamist ei käsitleta.

Kas teil on huvi, kuidas see töötab?

Praktiline näide Ceph-põhise salvestuse ühendamisest Kubernetes klastrisse

Nii et teil on olemas Kubernetes klaster, mis on välja arendatud, näiteks kubespray. Kõrval töötab Ceph klaster — selle võib samuti paigaldada, näiteks selle playbookide komplekti. Loodan, et ei pea mainima, et tootmisvõrgu vahel peab olema vähemalt 10 Gbit/s läbilaskevõime.

Kui see kõik on olemas, siis alustame!

Esiteks logime Ceph klastrinoodi ja kontrollime, et kõik on korras:

ceph health
ceph -s

Seejärel loome siinkohal RBD-diskide jaoks basseinid:

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

Liigume Kubernetes klastrisse. Seal paigaldame esmalt Ceph CSI draiveri RBD jaoks. Paigaldame, nagu tavaliselt, läbi Helm.
Lisame repositooriumi chart'iga, saades ceph-csi-rbd chart'i muutujate komplekti:

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

Nüüd peame täitma faili cephrbd.yml. Selleks saame clusterID 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 kirja faili cephrbd.yml. Samuti lülitame sisse PSP (Pod Security Policies) loomise. Võimalused sektsioonides nodeplugin ja provisioner on faili juba olemas, neid saab parandada 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

Edasi peame lihtsalt installima chart'i 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!
Loome Kubernetes'is uue StorageClass'i. Selleks on taas vajalik veidi töötada Ceph'iga.

Loome Ceph'is uue kasutaja ja anname talle kirjutamisõigused basseinile kube:

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

Ja nüüd vaatame juurdepääsu võtme seal samas:

ceph auth get-key client.rbdkube

Käsk väljastab midagi sellist:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Kandideerime selle väärtuse Kubernetes'i klastris salajaseks — sinna, kus see vajalik on userKey:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-rbd-saladus
  namespace: ceph-csi-rbd
stringData:
  # Võtme väärtused vastavad kasutajanimele ja tema võtmele, nagu on märgitud
  # Ceph klastris. Kasutaja ID peab omama juurdepääsu tiigile,
  # mis on määratletud salvestusklassides
  userID: rbdkube
  userKey:

Ja loome meie saladuse:

kubectl apply -f secret.yaml

Edasi vajame umbkaudu sellist StorageClass'i manifeste:

---
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 peaksid sisaldama autoriseerimise andmeid
   # teie tiiki.
   csi.storage.k8s.io/provisioner-secret-name: csi-rbd-saladus
   csi.storage.k8s.io/provisioner-secret-namespace: ceph-csi-rbd
   csi.storage.k8s.io/controller-expand-secret-name: csi-rbd-saladus
   csi.storage.k8s.io/controller-expand-secret-namespace: ceph-csi-rbd
   csi.storage.k8s.io/node-stage-secret-name: csi-rbd-saladus
   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 oleme juba saanud käsuga ceph fsid, ja rakendame selle manifeste Kubernetes'i klastris:

kubectl apply -f storageclass.yaml

Klastrite koostööd 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

Vaata nüüd, kuidas Kubernetes Cephis loodud mahuti välja näeb:

kubectl get pvc
kubectl get pv

Tundub, et kõik on suurepärane! Kuidas see Cephis välja näeb?
Saame loendi mahutitest bassinis ja vaatame meie mahuti kohta teavet:

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

Nüüd vaatame, kuidas RBD mahuti suuruse muutmine töötab.
Muudame mahuti suurust failis pvc.yaml 2Gi peale ja rakendame selle:

kubectl apply -f pvc.yaml

Ootame, kuni muudatused jõustuvad, ja vaatame veel kord mahuti suurust.

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

kubectl get pv
kubectl get pvc

Näeme, et PVC suurus ei ole muutunud. Põhjuse väljaselgitamiseks saab Kuberneteselt küsida PVC kirjeldust YAML formaadis:

kubectl get pvc rbd-pvc -o yaml

Ja siin on probleem:

message: Ootame, et kasutaja (uuesti) käivitaks pod'i, et lõpule viia mahuti failisüsteemi suuruse muutmine sõlmes. type: FileSystemResizePending

See tähendab, et ketas on suurenenud, kuid sellel failisüsteem ei ole.
Failisüsteemi suurendamiseks tuleb mahutit manustada. Meil on loodud PVC/PV, mis praegu ei ole kuidagi kasutuses.

Saame luua proovipodi 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

Nüüd vaatame PVC-d:

kubectl get pvc

Suurus on muutunud, kõik on korras.

Esimeses osas töötasime RBD plokiseadmestikuga (mis tähendab Rados Block Device), kuid see ei sobi, kui erinevad mikroteenused peavad samaaegselt selle kettaga töötama. Failidega, mitte ketta pildiga, sobib palju paremini CephFS.
Seadistame CSI ja teised vajalikud üksused CephFS-i tööks Ceph ja Kubernetes klastrite näitel.

Saame vajalikud väärtused uuest Helm-graafikust:

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

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

ceph fsid
ceph mon dump

Täidame väärtustega faili 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

Pöörake tähelepanu, et monitoride aadressid on esitatud lihtsa kujuga address:port. CephFS-i mountimiseks sõlmes edastatakse need aadressid tuumamoodulile, mis ei oska veel kasutada monitori protokolli v2.
Muudame httpMetrics'i porti (kuhu Prometheus kogub andmeid jälgimiseks), et vältida konflikti nginx-proxy'ga, mis installitakse Kubespray'ga. Teile ei pruugi see vajalik olla.

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

Liigume Ceph andmemälusse, et seal luua eraldi kasutaja. Dokumentatsioonis on märgitud, et CephFS-i provisioneerijatel on vaja klastrihalduse õigus. 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 tuleb meile hiljem kasuks:

ceph auth get-key client.fs

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

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-cephfs-secret
  namespace: ceph-csi-cephfs
stringData:
  # Vajalik dünaamiliselt loodud mahtude 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 failissüsteemi nimi, kus maht luuakse
  fsName: cephfs

  # (valikuline) Ceph puu, kus mahu andmed salvestatakse
  # pool: cephfs_data

  # (valikuline) Ceph-fuse jaoks eraldatud komadega paigaldusvalikud
  # näiteks:
  # fuseMountOptions: debug

  # (valikuline) CephFS tuuma paigaldusvalikud
  # Vaata man mount.ceph, et näha nende valikute loendit. Näiteks:
  # kernelMountOptions: readdir_max_bytes=1048576,norbytes

  # Saladused peavad sisaldama administraatori ja/või Ceph'i kasutaja juurdepääse.
  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) Juht edastab võib kasutada kas ceph-fuse (fuse)
  # või ceph kernelclient (kernel).
  # Kui ei ole määratud, kasutatakse vaikimisi mahtude paigaldamist,
  # mis määratakse ceph-fuse ja mount.ceph otsimise kaudu
  # mounter: kernel
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
  - debug

Täidame selle siia clusterID ja rakendame Kuberneteses:

kubectl apply -f storageclass.yaml

Kontrollimine

Kuna kontrollime, kuidas nagu eelmisel juhul, 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 vaadata faile ja kaustu CephFS-is, saate selle failisüsteemi kuhugi mountida. Näiteks, nagu allpool näidatud.

Läheme ühte Ceph-klastri sõlmest ja teeme järgmised 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

Loomulikult sobib selline FS mountimine Ceph-i sõlmes ainult õppe eesmärkidel, millega me tegeleme meie Slõrm kursustel.Ei usu, et keegi selle tootmises teeks, sest on suur risk kogemata kustutada olulisi faile.

Ja lõpuks vaatame, kuidas on CephFS-i puhul suuruse muutmisega. Naaseme Kubernetesesse ja redigeerime oma PVC manifeste — suurendame seal suurust näiteks kuni 7Gi.

Rakendame redigeeritud faili:

kubectl apply -f pvc.yaml

Vaadake mountitud kataloogis, kuidas on kvota muutunud:

getfattr -n ceph.quota.max_bytes

Selle käsu tööks võite vajada süsteemis paketti attr.

Silmad kardavad, aga käed teevad

Esialgu võivad kõik need manused ja pikad YAML manifestid tunduda keerulised, kuid praktikas saavad Slërmi õpilased nendega üsna kiiresti hakkama.
Selles artiklis me ei süvene süvitsi – selleks on ametlik dokumentatsioon. Kui teid huvitavad Ceph’i salvestusäri seadistamise üksikasjad koos Kubernetes klastriga, siis aitavad järgmised lingid:

Kubernetes'i ja mahutite üldpõhimõtted
RBD dokumentatsioon
RBD ja Kubernetes'i integreerimine Ceph'i vaatenurgast
RBD ja Kubernetes'i integreerimine CSI vaatenurgast
CephFS üldine dokumentatsioon
CephFS ja Kubernetes'i integreerimine CSI vaatenurgast

Slërm kursusel Kubernetes Baas võite minna veelgi kaugemale ja käivitada Kubernetes'is tõeline rakendus, mis kasutab CephFS-i failide salvestamiseks. GET/POST päringute kaudu saate faile edastada ja neid Ceph'ist hankida.

Kui teid huvitab rohkem andmete salvestamine, siis registreeruge uuele Ceph kursusele. Seni kui käib beetatestimine, saab kursust soodushinnaga ja mõjutada selle sisu.

Artikli autor: Aleksandr Shvalov, praktiseeriv insener Southbridge, Certified Kubernetes Administrator, Slërm kursuste autor ja arendaja.

Allikas: habr.com

Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid 🔥 Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster