Gyakorlati példa a Ceph-alapú tárolás Kubernetes-fürthöz való csatlakoztatására

A Container Storage Interface (CSI) egy egységes interfész a Kubernetes és a tárolórendszerek között. Röviden már beszéltünk róla mondta, ma pedig közelebbről megvizsgáljuk a CSI és a Ceph kombinációját: megmutatjuk, hogyan csatlakoztassa a Ceph tárolót a Kubernetes klaszterbe.
A cikk valós, bár kissé leegyszerűsített példákkal szolgál a könnyebb felfogás érdekében. Nem gondoljuk a Ceph és Kubernetes fürtök telepítését és konfigurálását.

Kíváncsi vagy, hogyan működik?

Tehát kéznél van egy Kubernetes-fürt, amelyet például kubespray. A közelben működik egy Ceph cluster - pl. ezzel is telepítheted játékkönyvek készlete. Remélem nem kell említeni, hogy a köztük lévő termeléshez legalább 10 Gbit/s sávszélességű hálózatnak kell lennie.

Ha mindez megvan, menjünk!

Először menjünk a Ceph-fürt egyik csomópontjához, és ellenőrizzük, hogy minden rendben van-e:

ceph health
ceph -s

Ezután azonnal létrehozunk egy készletet az RBD lemezekhez:

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

Térjünk át a Kubernetes klaszterre. Ott először telepítjük a Ceph CSI illesztőprogramot az RBD-hez. A várakozásoknak megfelelően a Helmen keresztül telepítjük.
Hozzáadunk egy adattárat egy diagrammal, a ceph-csi-rbd diagramhoz kapunk egy változókészletet:

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öltenie a cephrbd.yml fájlt. Ehhez keresse meg a Ceph-ben lévő monitorok fürtazonosítóját és IP-címét:

ceph fsid  # так мы узнаем clusterID
ceph mon dump  # а так увидим IP-адреса мониторов

A kapott értékeket beírjuk a cephrbd.yml fájlba. Ezzel egyidejűleg lehetővé tesszük a PSP házirendek (Pod Security Policy) létrehozását. Lehetőségek a szakaszokban nodeplugin и gondozó már a fájlban vannak, az alábbiak szerint javíthatók:

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 az van hátra, hogy telepítsük a diagramot a Kubernetes-fürtbe.

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

Remek, az RBD driver működik!
Hozzon létre egy új StorageClass-t a Kubernetesben. Ehhez ismét egy kis trükközésre van szükség Ceph-en.

Létrehozunk egy új felhasználót a Ceph-ben, és jogot adunk neki, hogy írjon a készletbe Kocka:

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

Lássuk, hogy a hozzáférési kulcs még mindig ott van:

ceph auth get-key client.rbdkube

A parancs valami ilyesmit fog kiadni:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Adjuk hozzá ezt az értéket a Secrethez a Kubernetes-fürtben – ahol szükségünk van rá felhasználói kulcs:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-rbd-secret
  namespace: ceph-csi-rbd
stringData:
  # Значения ключей соответствуют имени пользователя и его ключу, как указано в
  # кластере Ceph. ID юзера должен иметь доступ к пулу,
  # указанному в storage class
  userID: rbdkube
  userKey: <user-key>

És létrehozzuk a titkunkat:

kubectl apply -f secret.yaml

Ezután szükségünk van egy StorageClass manifestre, ehhez hasonló:

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

   imageFeatures: layering

   # Эти секреты должны содержать данные для авторизации
   # в ваш пул.
   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, amit már megtanultunk a csapattól ceph fsid, és alkalmazza ezt a jegyzéket a Kubernetes-fürtre:

kubectl apply -f storageclass.yaml

A klaszterek együttműködésének ellenőrzéséhez hozzuk létre a következő PVC-t (Persistent Volume Claim):

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

Azonnal lássuk, hogyan hozta létre Kubernetes a kért kötetet Ceph-ben:

kubectl get pvc
kubectl get pv

Minden nagyszerűnek tűnik! Hogy néz ki ez a Ceph oldalon?
Megkapjuk a készletben lévő kötetek listáját, és megtekintjük a kötetünkkel kapcsolatos információkat:

rbd ls -p kube
rbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653  # тут, конечно же, будет другой ID тома, который выдала предыдущая команда

Most pedig nézzük meg, hogyan működik az RBD-kötet átméretezése.
Módosítsa a kötet méretét a pvc.yaml jegyzékben 2Gi-re, és alkalmazza:

kubectl apply -f pvc.yaml

Várjuk meg a változtatások érvénybe lépését, és nézzük meg újra 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. Hogy megtudja, miért, lekérdezheti a Kubernetes-től a PVC YAML leírását:

kubectl get pvc rbd-pvc -o yaml

Íme a probléma:

üzenet: Várakozás, hogy a felhasználó (újra)indítsa a pod-ot a csomóponton lévő kötet fájlrendszer-átméretezésének befejezéséhez. típus: FileSystemResizePending

Vagyis a lemez nőtt, de a rajta lévő fájlrendszer nem.
A fájlrendszer bővítéséhez csatlakoztatnia kell a kötetet. Hazánkban a létrehozott PVC/PV-t jelenleg semmilyen módon nem használják.

Létrehozhatunk egy tesztpodot, 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

És most nézzük a PVC-t:

kubectl get pvc

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

Az első részben az RBD blokkeszközzel dolgoztunk (ez a Rados Block Device rövidítése), de ezt nem lehet megtenni, ha különböző mikroszolgáltatásoknak egyszerre kell dolgozniuk ezzel a lemezzel. A CephFS sokkal jobban megfelel a fájlokkal való munkavégzéshez, mint a lemezképekhez.
A Ceph- és Kubernetes-fürtök példájával beállítjuk a CSI-t és más szükséges entitásokat a CephFS-szel való együttműködéshez.

Nézzük a szükséges értékeket az új Helm diagramból:

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

Ismét ki kell töltenie a cephfs.yml fájlt. Mint korábban, a Ceph parancsok segítenek:

ceph fsid
ceph mon dump

Töltse ki a fájlt a következő értékekkel:

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

Kérjük, vegye figyelembe, hogy a monitorok címei egyszerű cím:port formában vannak megadva. A cephfs csomóponthoz való csatlakoztatásához ezeket a címeket át kell adni a kernelmodulnak, amely még nem tudja, hogyan kell együttműködni a v2 monitor protokollal.
Megváltoztatjuk a httpMetrics portját (a Prometheus oda megy a metrikák figyeléséhez), hogy ne ütközzen a Kubespray által telepített nginx-proxyval. Lehet, hogy erre nincs szüksége.

Telepítse a Helm diagramot a Kubernetes-fürtben:

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

Menjünk a Ceph adattárba, hogy ott külön felhasználót hozzunk létre. A dokumentáció szerint a CephFS-szolgáltatóhoz fürtrendszergazdai hozzáférési jogok szükségesek. 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 nézzük meg a hozzáférési kulcsát, később szükségünk lesz rá:

ceph auth get-key client.fs

Hozzon létre külön Secret és StorageClass osztályt.
Semmi újdonság, ezt már láttuk az RBD példájában:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-cephfs-secret
  namespace: ceph-csi-cephfs
stringData:
  # Необходимо для динамически создаваемых томов
  adminID: fs
  adminKey: <вывод предыдущей команды>

A jegyzék alkalmazása:

kubectl apply -f secret.yaml

És most - egy külön StorageClass:

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

  # Имя файловой системы CephFS, в которой будет создан том
  fsName: cephfs

  # (необязательно) Пул Ceph, в котором будут храниться данные тома
  # pool: cephfs_data

  # (необязательно) Разделенные запятыми опции монтирования для Ceph-fuse
  # например:
  # fuseMountOptions: debug

  # (необязательно) Разделенные запятыми опции монтирования CephFS для ядра
  # См. man mount.ceph чтобы узнать список этих опций. Например:
  # kernelMountOptions: readdir_max_bytes=1048576,norbytes

  # Секреты должны содержать доступы для админа и/или юзера 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

  # (необязательно) Драйвер может использовать либо ceph-fuse (fuse), 
  # либо ceph kernelclient (kernel).
  # Если не указано, будет использоваться монтирование томов по умолчанию,
  # это определяется поиском ceph-fuse и mount.ceph
  # mounter: kernel
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
  - debug

Töltsük ki itt clusterID és Kubernetesben alkalmazható:

kubectl apply -f storageclass.yaml

Проверка

Az ellenőrzéshez, mint az előző példában, 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őrizze a PVC/PV jelenlétét:

kubectl get pvc
kubectl get pv

Ha a CephFS-ben szeretne fájlokat és könyvtárakat nézni, akkor ezt a fájlrendszert felcsatolhatja valahova. Például az alábbiak szerint.

Menjünk a Ceph-fürt egyik csomópontjához, és hajtsuk végre a következő műveleteket:

# Точка монтирования
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 az FS felszerelése egy ilyen Ceph csomópontra csak edzési célokra alkalmas, amit mi csinálunk Slurm tanfolyamok. Nem hiszem, hogy ezt bárki megtenné az éles környezetben; nagy a kockázata annak, hogy véletlenül törölni fognak fontos fájlokat.

Végül pedig nézzük meg, hogyan működnek a dolgok a kötetek átméretezésével a CephFS esetében. Térjünk vissza a Kuberneteshez, és szerkesszük a PVC jegyzékünket – növeljük ott a méretet például 7Gi-re.

Alkalmazzuk a szerkesztett fájlt:

kubectl apply -f pvc.yaml

Nézzük meg a csatolt könyvtárat, és nézzük meg, hogyan változott a kvóta:

getfattr -n ceph.quota.max_bytes <каталог-с-данными>

A parancs működéséhez telepítenie kell a csomagot a rendszerére attr.

A szemek félnek, de a kezek csinálják

Mindezek a varázslatok és a hosszú YAML manifesztációk a felszínen bonyolultnak tűnnek, de a gyakorlatban a Slurm-hallgatók elég gyorsan rászoknak rájuk.
Ebben a cikkben nem mentünk a dzsungel mélyére – erre van hivatalos dokumentáció. Ha érdeklik a Ceph tároló Kubernetes-fürttel történő beállításának részletei, ezek a hivatkozások segítenek:

A Kubernetes kötetekkel való munka általános elvei
RBD dokumentáció
Az RBD és a Kubernetes integrálása Ceph szemszögéből
Az RBD és a Kubernetes integrálása CSI szemszögből
Általános CephFS dokumentáció
A CephFS és a Kubernetes integrálása CSI szemszögből

A Slurm pályán Kubernetes bázis egy kicsit tovább léphet, és telepíthet egy valódi alkalmazást a Kubernetesben, amely a CephFS-t használja fájltárolóként. A GET/POST kéréseken keresztül fájlokat vihet át a Ceph-ra és fogadhat tőle.

Ha pedig jobban érdekel az adattárolás, akkor iratkozzon fel új tanfolyam Ceph. Amíg a bétateszt folyamatban van, a tanfolyamot kedvezményesen lehet beszerezni, és befolyásolni lehet annak tartalmát.

A cikk szerzője: Alexander Shvalov, gyakorló mérnök Southbridge, Okleveles Kubernetes Adminisztrátor, Slurm tanfolyamok szerzője és fejlesztője.

Forrás: will.com