ProHoster > Blog > administratë > Një shembull praktik i lidhjes së ruajtjes së bazuar në Ceph me një grup Kubernetes

Një shembull praktik i lidhjes së ruajtjes së bazuar në Ceph me një grup Kubernetes

Ndërfaqja e ruajtjes së kontejnerëve (CSI) është një ndërfaqe e unifikuar midis Kubernetes dhe sistemeve të ruajtjes. Ne kemi folur tashmë për të shkurtimisht tha, dhe sot do të hedhim një vështrim më të afërt në kombinimin e CSI dhe Ceph: ne do të tregojmë se si lidhni ruajtjen e Ceph te grupi Kubernetes.
Artikulli ofron shembuj realë, megjithëse pak të thjeshtuar për lehtësinë e perceptimit. Ne nuk e konsiderojmë instalimin dhe konfigurimin e grupeve Ceph dhe Kubernetes.

A po pyesni veten se si funksionon?

Një shembull praktik i lidhjes së ruajtjes së bazuar në Ceph me një grup Kubernetes

Pra, ju keni një grup Kubernetes në majë të gishtave tuaj, të vendosur, për shembull, kubespray. Ekziston një grup Ceph që punon afër - mund ta instaloni gjithashtu, për shembull, me këtë një grup librash lojërash. Shpresoj të mos jetë nevoja të përmend se për prodhim mes tyre duhet të ketë një rrjet me gjerësi brezi të paktën 10 Gbit/s.

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

Së pari, le të shkojmë në një nga nyjet e grupit Ceph dhe të kontrollojmë nëse gjithçka është në rregull:

ceph health
ceph -s

Më pas, ne do të krijojmë menjëherë një pishinë për disqet RBD:

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

Le të kalojmë te grupi Kubernetes. Atje, para së gjithash, ne do të instalojmë drejtuesin Ceph CSI për RBD. Ne do të instalojmë, siç pritej, përmes Helm.
Shtojmë një depo me një grafik, marrim një grup variablash për grafikun 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ësoni skedarin cephrbd.yml. Për ta bërë këtë, zbuloni ID-në e grupit dhe adresat IP të monitorëve në Ceph:

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

Ne futim vlerat e marra në skedarin cephrbd.yml. Në të njëjtën kohë, ne mundësojmë krijimin e politikave PSP (Pod Security Policies). Opsionet në seksione nodeplugin и ofrues tashmë në skedar, ato mund të korrigjohen siç tregohet 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

Tjetra, gjithçka që na mbetet është të instalojmë grafikun në grupin Kubernetes.

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

E shkëlqyeshme, drejtuesi i RBD funksionon!
Le të krijojmë një StorageClass të ri në Kubernetes. Kjo kërkon përsëri një grindje me Ceph.

Ne krijojmë një përdorues të ri në Ceph dhe i japim atij të drejtën për të shkruar në pishinë Kub:

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

Tani le të shohim se çelësi i hyrjes është ende atje:

ceph auth get-key client.rbdkube

Komanda do të nxjerrë diçka si kjo:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Le ta shtojmë këtë vlerë tek Secret në grupin Kubernetes - aty ku na nevojitet çelësi i përdoruesit:

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

Dhe ne krijojmë sekretin tonë:

kubectl apply -f secret.yaml

Më pas, na duhet një manifest StorageClass diçka si kjo:

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

Duhet të plotësohet ClusterID, të cilën e kemi mësuar tashmë nga ekipi ceph fsid, dhe zbatoni këtë manifest në grupimin Kubernetes:

kubectl apply -f storageclass.yaml

Për të kontrolluar se si grupet funksionojnë së bashku, le të krijojmë PVC-në e mëposhtme (Pretendimi i Vëllimit të Përhershëm):

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 vëllimin e kërkuar në Ceph:

kubectl get pvc
kubectl get pv

Gjithçka duket se është e mrekullueshme! Si duket kjo në anën e Cefit?
Ne marrim një listë të vëllimeve në pishinë dhe shohim informacione rreth vëllimit tonë:

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

Tani le të shohim se si funksionon ndryshimi i madhësisë së një vëllimi RBD.
Ndryshoni madhësinë e volumit në manifestin pvc.yaml në 2Gi dhe aplikojeni:

kubectl apply -f pvc.yaml

Le të presim që ndryshimet të hyjnë në fuqi dhe të shikojmë përsëri madhësinë e volumit.

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

kubectl get pv
kubectl get pvc

Ne shohim se madhësia e PVC nuk ka ndryshuar. Për të zbuluar pse, mund të kërkoni Kubernetes për një përshkrim YAML të PVC:

kubectl get pvc rbd-pvc -o yaml

Këtu është problemi:

mesazhi: Në pritje që përdoruesi të (ri-)nisë një pod për të përfunduar ndryshimin e madhësisë së volumit të sistemit të skedarëve në nyje. lloji: FileSystemResizePending

Kjo do të thotë, disku është rritur, por sistemi i skedarëve në të jo.
Për të rritur sistemin e skedarëve, duhet të montoni volumin. Në vendin tonë, PVC/PV e krijuar aktualisht nuk përdoret në asnjë mënyrë.

Ne mund të krijojmë një Pod testimi, për shembull si ky:

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

Dhe tani le të shohim PVC:

kubectl get pvc

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

Në pjesën e parë, ne kemi punuar me pajisjen e bllokut RBD (ai qëndron për Rados Block Device), por kjo nuk mund të bëhet nëse mikroshërbime të ndryshme duhet të punojnë me këtë disk njëkohësisht. CephFS është shumë më i përshtatshëm për të punuar me skedarë sesa me imazhe të diskut.
Duke përdorur shembullin e grupeve Ceph dhe Kubernetes, ne do të konfigurojmë CSI dhe entitete të tjera të nevojshme për të punuar me CephFS.

Le të marrim vlerat nga grafiku i ri Helm që na nevojitet:

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

Përsëri duhet të plotësoni skedarin cephfs.yml. Si më parë, komandat e Ceph do të ndihmojnë:

ceph fsid
ceph mon dump

Plotësoni skedarin me vlera si kjo:

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

Ju lutemi vini re se adresat e monitorit janë të specifikuara në formularin e thjeshtë adresa:port. Për të montuar cephfs në një nyje, këto adresa transferohen në modulin e kernelit, i cili ende nuk di të punojë me protokollin e monitorit v2.
Ne ndryshojmë portin për httpMetrics (Prometheus do të shkojë atje për metrikat e monitorimit) në mënyrë që të mos bie ndesh me nginx-proxy, i cili është i instaluar nga Kubespray. Ju mund të mos keni nevojë për këtë.

Instaloni grafikun Helm në grupin Kubernetes:

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

Le të shkojmë në dyqanin e të dhënave Ceph për të krijuar një përdorues të veçantë atje. Dokumentacioni thotë se ofruesi i CephFS kërkon të drejtat e aksesit të administratorit të grupit. Por ne do të krijojmë një përdorues të veçantë fs me të drejta 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 le të shohim menjëherë çelësin e tij të hyrjes, do të na duhet më vonë:

ceph auth get-key client.fs

Le të krijojmë Secret dhe StorageClass të veçantë.
Asgjë e re, ne e kemi parë tashmë këtë në shembullin e RBD:

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

Zbatimi i manifestit:

kubectl apply -f secret.yaml

Dhe tani - një StorageClass më vete:

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

Le ta plotësojmë këtu ClusterID dhe i zbatueshëm në Kubernetes:

kubectl apply -f storageclass.yaml

Проверка

Për të kontrolluar, si në shembullin e mëparshëm, le të krijojmë një PVC:

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

Dhe kontrolloni praninë e PVC/PV:

kubectl get pvc
kubectl get pv

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

Le të shkojmë në një nga nyjet e grupit Ceph dhe të kryejmë veprimet e mëposhtme:

# Точка монтирования
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, montimi i FS në një nyje Ceph si kjo është i përshtatshëm vetëm për qëllime trajnimi, gjë që bëjmë në Kurse slurm. Unë nuk mendoj se dikush do ta bënte këtë në prodhim; ekziston një rrezik i lartë i fshirjes aksidentale të skedarëve të rëndësishëm.

Dhe së fundi, le të kontrollojmë se si funksionojnë gjërat me ndryshimin e madhësisë së vëllimeve në rastin e CephFS. Le të kthehemi te Kubernetes dhe të modifikojmë manifestin tonë për PVC - rrisni madhësinë atje, për shembull, në 7Gi.

Le të aplikojmë skedarin e redaktuar:

kubectl apply -f pvc.yaml

Le të shohim drejtorinë e montuar për të parë se si ka ndryshuar kuota:

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

Që kjo komandë të funksionojë, mund t'ju duhet të instaloni paketën në sistemin tuaj attr.

Sytë kanë frikë, por duart kanë

Të gjitha këto magji dhe manifestime të gjata YAML duken të ndërlikuara në sipërfaqe, por në praktikë, studentët Slurm i kuptojnë shumë shpejt.
Në këtë artikull ne nuk hymë thellë në xhungël - ka dokumentacion zyrtar për këtë. Nëse jeni të interesuar për detajet e konfigurimit të ruajtjes së Ceph me një grup Kubernetes, këto lidhje do t'ju ndihmojnë:

Parimet e përgjithshme të punës së Kubernetes me vëllime
Dokumentacioni RBD
Integrimi i RBD dhe Kubernetes nga perspektiva e Ceph
Integrimi i RBD dhe Kubernetes nga një perspektivë CSI
Dokumentacioni i Përgjithshëm CephFS
Integrimi i CephFS dhe Kubernetes nga një këndvështrim CSI

Në kursin Slurm Baza e Kubernetes mund të shkoni pak më tej dhe të vendosni një aplikacion të vërtetë në Kubernetes që do të përdorë CephFS si ruajtje skedarësh. Nëpërmjet kërkesave GET/POST do të mund të transferoni skedarë dhe t'i merrni ato nga Ceph.

Dhe nëse jeni më të interesuar për ruajtjen e të dhënave, atëherë regjistrohuni kurs i ri mbi Ceph. Ndërsa testi beta është në vazhdim, kursi mund të merret me një zbritje dhe ju mund të ndikoni në përmbajtjen e tij.

Autori i artikullit: Alexander Shvalov, inxhinier praktik Southbridge, Administrator i certifikuar i Kubernetes, autor dhe zhvillues i kurseve Slurm.

Burimi: www.habr.com