🥇Gyakorlati példa Ceph alapú tároló csatlakoztatására egy Kubernetes klaszterben

A Konténer Tárolási Felület (CSI) egy egységes interfész a Kubernetes és a tárolórendszerek közötti interakcióhoz. Röviden róla már beszéltünk, de ma részletesebben megvizsgáljuk a CSI és a Ceph összekapcsolását: megmutatjuk, hogyan kötjük össze a Ceph tárolót a Kubernetes klaszterrel.
A cikkben valós példák szerepelnek, amelyek bár kissé leegyszerűsítettek az olvashatóság kedvéért. A Ceph és a Kubernetes klaszterek telepítése és konfigurálása nem képezi a téma részét.

Érdekli, hogyan működik?

Tehát Önnek van egy Kubernetes klaszter a kezében, például telepítve a kubespray. Mellett működik egy Ceph klaszter — ezt is telepítheti például ezzel a playbook készlettel. Remélem, nem kell megemlíteni, hogy a termelési környezetben közöttük legalább 10 Gbit/s sebességű hálózatnak kell lennie.

Ha mindez megvan, kezdjünk neki!

Először lépjünk be a Ceph klaszter egyik node-jába, és ellenőrizzük, hogy minden rendben van:

ceph health
ceph -s

Ezt követően létrehozunk egy medencét az RBD lemezek számára:

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

Lépjünk a Kubernetes klaszterre. Itt először telepítjük a Ceph CSI meghajtót az RBD-hez. Telepíteni fogjuk, ahogy azt a Helm megkívánja.
Hozzáadjuk a chart repót, és megkapjuk a ceph-csi-rbd chart változóit:

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

Most ki kell töltenünk a cephrbd.yml fájlt. Ehhez megtudjuk a klaszter azonosítóját és a Ceph monitorok IP-címét:

ceph fsid  # így tudjuk meg a clusterID-t
ceph mon dump  # és így látjuk a monitorok IP-címeit

A kapott értékeket beírjuk a cephrbd.yml fájlba. Eközben engedélyezzük a PSP (Pod Security Policies) létrehozását. Az opciók a nodeplugin és provisioner már léteznek a fájlban, ezeket az alábbiak szerint módosíthatjuk:

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

Ezután már csak annyit kell tennünk, hogy telepítjük a chart-ot a Kubernetes klaszterre.

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

Remek, az RBD meghajtó működik!
Hozzunk létre egy új StorageClass-t a Kubernetes-ben. Ehhez ismét szükség lesz egy kis munkára a Ceph-vel.

Új felhasználót hozunk létre a Ceph-ben, és jogosultságokat adunk neki a kube medencébe való íráshoz kube:

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

Most nézzük meg a hozzáférési kulcsot, ugyanott:

ceph auth get-key client.rbdkube

A parancs körülbelül ilyesmit ad vissza:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Ezt az értéket beírjuk a Kubernetes klaszter titkosított tárolójába — oda, ahol szükséges userKey:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-rbd-secret
  namespace: ceph-csi-rbd
stringData:
  # A kulcsok értékei megfelelnek a felhasználónévnek és a titkos kulcsának, ahogy azt
  # a Ceph klaszterben megadták. A felhasználó ID-jának hozzáféréssel kell rendelkeznie a megadott
  # tároló osztályhoz tartozó medencéhez.
  userID: rbdkube
  userKey:

És létrehozzuk a titkunkat:

kubectl apply -f secret.yaml

Ezután szükségünk van egy ilyen StorageClass megvalósításra:

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

   imageFeatures: layering

   # Ezeknek a titkoknak tartalmazniuk kell az azonosításhoz szükséges adatokat
   # az ön medencéjéhez.
   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

Ki kell tölteni clusterID, amelyet már tudunk a parancs segítségével ceph fsid, és alkalmazni ezt a megvalósítást a Kubernetes klaszterben:

kubectl apply -f storageclass.yaml

A klaszterek közötti működés ellenőrzéséhez hozzunk létre egy ilyen PVC-t (Persistent Volume Claim):

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

Nézzük meg, hogyan hozta létre Kubernetes a Ceph-ben a kért kötetet:

kubectl get pvc
kubectl get pv

Úgy tűnik, minden rendben van! Hogyan néz ki ez a Ceph oldalán?
Kérjük, azonosítsuk a köteteket a medencében, és nézzük meg a kötetünkről szóló információkat:

rbd ls -p kube
rbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653  # itt természetesen más kötet ID lesz, amelyet az előző parancs adott

Most nézzük meg, hogyan működik a RBD kötet méretének módosítása.
Módosítjuk a kötet méretét a pvc.yaml megvalósításban 2Gi-ra, és alkalmazzuk:

kubectl apply -f pvc.yaml

Várjunk egy kicsit, amíg a módosítások érvénybe lépnek, és még egyszer nézzük meg a kötet méretét.

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

kubectl get pv
kubectl get pvc

Látjuk, hogy a PVC mérete nem változott. Az ok megismeréséhez kérhetjük a Kubernetes-től a PVC YAML formátumban való leírását:

kubectl get pvc rbd-pvc -o yaml

Itt van a probléma:

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

Tehát a lemez megnőtt, de a rajta lévő fájlrendszer nem.
A fájlrendszer megnöveléséhez csatolni kell a kötetet. A már létrehozott PVC/PV jelenleg nem használatos.

Létrehozhatunk egy teszt Pod-ot, például így:

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

Most nézzük meg a PVC-t:

kubectl get pvc

A méret megváltozott, minden rendben van.

Az első részben egy RBD (Rados Block Device) blokktároló eszközzel dolgoztunk, de ezt nem lehet így csinálni, ha különböző mikroszolgáltatásoknak egyidejűleg kell hozzáférniük ehhez a lemezhez. Fájlokkal való munkához sokkal jobban illik a CephFS.
A Ceph és Kubernetes klaszterek alapján beállítjuk a CSI-t és a CephFS használatához szükséges egyéb entitásokat.

Megkapjuk a szükséges új Helm-diagram értékeket:

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

Újra ki kell tölteni a cephfs.yml fájlt. Ahogyan korábban is, a Ceph parancsok segítenek:

ceph fsid
ceph mon dump

A fájl értékeivel körülbelül így töltjük ki:

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

Vedd észre, hogy a monitorok címei egyszerű formában address:port szerepelnek. A cephfs csatolásához a csomóponton ezeket a címeket a kernel modulhoz adjuk át, amely még nem tudja kezelni a v2 monitor protokollt.
A httpMetrics portját (ahova a Prometheus megy a monitorozási metrikákért) megváltoztatjuk, hogy ne ütközzön a kubespray által telepített nginx-proxyval. Lehet, hogy neked erre nem lesz szükséged.

Helm-diagram telepítése a Kubernetes klaszterre:

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

Átmegyünk a Ceph adatbázis tárolójába, hogy ott létrehozzunk egy külön felhasználót. A dokumentáció szerint a CephFS províziózónak szüksége van a klaszter adminisztrátori jogaira. De létrehozunk egy külön felhasználót fs korlátozott jogokkal:

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'

És azonnal megnézzük a hozzáférési kulcsát, ez később jól jön:

ceph auth get-key client.fs

Létrehozunk külön Secret-et és StorageClass-t.
Semmi újat, ezt már láttuk az RBD példáján:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-cephfs-secret
  namespace: ceph-csi-cephfs
stringData:
  # Szükséges a dinamikusan létrehozott kötetekhez
  adminID: fs
  adminKey:

Alkalmazzuk a manifesztet:

kubectl apply -f secret.yaml

Most pedig – egy külön StorageClass:

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

  # A CephFS fájlrendszer neve, amelyben a kötet létrejön
  fsName: cephfs

  # (opcionális) A Ceph tároló, ahol a kötet adatai tárolódnak
  # pool: cephfs_data

  # (opcionális) Vesszővel elválasztott Ceph-fuse csatolási opciók
  # például:
  # fuseMountOptions: debug

  # (opcionális) Vesszővel elválasztott CephFS csatolási opciók a kernelhez
  # Lásd a man mount.ceph a lehetőségek listájához. Például:
  # kernelMountOptions: readdir_max_bytes=1048576,norbytes

  # A titkoknak tartalmazniuk kell a Ceph adminisztrátor és/vagy felhasználói hozzáféréseit.
  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

  # (opcionális) A meghajtó használhat ceph-fuse-t (fuse) 
  # vagy ceph kernelclient-et (kernel).
  # Ha nincs megadva, az alapértelmezett kötetcsatolás lesz használva,
  # ezt a ceph-fuse és mount.ceph keresésével határozzák meg.
  # mounter: kernel
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
  - debug

Töltsük ki itt clusterID és alkalmazzuk a Kubernetesben:

kubectl apply -f storageclass.yaml

Ellenőrzés

A példához hasonlóan ellenőrizzük, hozzunk létre egy PVC-t:

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

És ellenőrizzük a PVC/PV meglétét:

kubectl get pvc
kubectl get pv

Ha meg szeretnéd nézni a fájlokat és mappákat a CephFS-ben, csatolhatod ezt a fájlrendszert valahová. Például, ahogy az alább látható.

Látogassunk el a Ceph klaszter egyik csomópontjára, és végezzük el az alábbi lépéseket:

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

Természetesen, ez a fajta fájlrendszer-csatolás a Ceph csomóponton kizárólag tanulási célokra alkalmas, ahogy mi is foglalkozunk a Slurm kurzusainkkal. Nem gondolom, hogy bárki ezt a produkcióban tenni fogja, nagy a kockázata, hogy véletlenül felülírja a fontos fájlokat.

Végül nézzük meg, hogyan állnak a kötetméretek módosítási lehetőségei CephFS esetén. Visszatérünk a Kuberneteshez, és szerkesztjük a PVC mifest, növeljük a méretet például 7Gi-ra.

Alkalmazzuk a szerkesztett fájlt:

kubectl apply -f pvc.yaml

Nézzük meg a csatolt mappában, hogyan változott a kvóta:

getfattr -n ceph.quota.max_bytes

Ehhez a parancshoz lehet, hogy telepítened kell a rendszerbe a csomagot attr.

A szemek félnek, de a kezek dolgoznak

Bár ezek a varázslatok és hosszú YAML manifestei bonyolultnak tűnnek, a Slurm diákjai meglehetősen gyorsan megértik őket a gyakorlatban.
Ebben a cikkben nem mélyedtünk el a részletekbe — erre ott a hivatalos dokumentáció. Ha a Ceph tároló Kubernetes klaszterrel való beállításának részletei érdeklik, ezek a linkek segítenek:

A Kubernetes általános működési elvei a kötetekkel
Dokumentáció RBD-hez
RBD és Kubernetes integrációja a Ceph szempontjából
RBD és Kubernetes integrációja a CSI szempontjából
Általános dokumentáció a CephFS-ről
CephFS és Kubernetes integrációja a CSI szempontjából

A Slurm tanfolyamon Kubernetes Alapok továbbléphet, és egy valós alkalmazást indíthat a Kubernetes alatt, amely CephFS-t használ fájlok tárolására. GET/POST lekérdezésekkel fájlokat küldhet és kaphat a Ceph-ből.

Ha inkább az adatmegőrzés érdekli, akkor iratkozzon fel a új Ceph tanfolyamra. Amíg a bétateszt zajlik, a tanfolyam kedvezménnyel érhető el, és hatással lehet a tartalmára.

A cikk szerzője: Alexander Shvalov, gyakorló mérnök Southbridge, Certified Kubernetes Administrator, a Slurm tanfolyamok szerzője és fejlesztője.

Forrás: habr.com

Gyakorlati példája a Ceph-alapú tároló Kubernetes klaszterhez való csatlakozásának.

Ellenőrzés

A szemek félnek, de a kezek dolgoznak