Praktični primjer povezivanja pohrane zasnovane na Ceph-u na Kubernetes klaster

Interfejs za skladištenje kontejnera (CSI) je ujedinjeni interfejs između Kubernetesa i sistema skladištenja. Već smo ukratko pričali o tome rekao je, a danas ćemo detaljnije pogledati kombinaciju CSI i Ceph: pokazat ćemo kako povežite Ceph skladište u Kubernetes klaster.
Članak daje stvarne, iako malo pojednostavljene primjere radi lakše percepcije. Ne razmatramo instaliranje i konfigurisanje Ceph i Kubernetes klastera.

Pitate se kako to funkcionira?

Praktični primjer povezivanja pohrane zasnovane na Ceph-u na Kubernetes klaster

Dakle, imate Kubernetes klaster na dohvat ruke, raspoređen, na primjer, kubespray. U blizini radi Ceph klaster - možete ga i instalirati, na primjer, s ovim set igraonica. Nadam se da nema potrebe spominjati da za proizvodnju između njih mora postojati mreža sa propusnošću od najmanje 10 Gbit/s.

Ako imate sve ovo, idemo!

Prvo, idemo na jedan od čvorova Ceph klastera i provjerimo da li je sve u redu:

ceph health
ceph -s

Zatim ćemo odmah kreirati bazen za RBD diskove:

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

Pređimo na Kubernetes klaster. Tamo ćemo prije svega instalirati Ceph CSI drajver za RBD. Instalirati ćemo, kako se očekuje, preko Helma.
Dodamo spremište sa grafikonom, dobijamo skup varijabli za ceph-csi-rbd grafikon:

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

Sada trebate popuniti datoteku cephrbd.yml. Da biste to učinili, saznajte ID klastera i IP adrese monitora u Ceph-u:

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

Dobijene vrijednosti unosimo u datoteku cephrbd.yml. Istovremeno omogućavamo kreiranje PSP politika (Pod Security Policies). Opcije u odjeljcima nodeplugin и dobavljač već u datoteci, mogu se ispraviti kao što je prikazano u nastavku:

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

Zatim, sve što nam preostaje je da instaliramo grafikon u Kubernetes klaster.

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

Odlično, RBD drajver radi!
Kreirajmo novu StorageClass u Kubernetesu. Ovo opet zahtijeva malo petljanja sa Cephom.

Kreiramo novog korisnika u Ceph-u i dajemo mu prava da piše u bazen Kocka:

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

Sada da vidimo da je pristupni ključ još uvijek tu:

ceph auth get-key client.rbdkube

Naredba će ispisati nešto ovako:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Dodajmo ovu vrijednost Secretu u Kubernetes klaster - tamo gdje nam je potrebna userKey:

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

I stvaramo našu tajnu:

kubectl apply -f secret.yaml

Zatim, trebamo StorageClass manifest otprilike ovako:

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

Potrebno je popuniti clusterID, što smo već naučili od strane tima ceph fsid, i primijeniti ovaj manifest na Kubernetes klaster:

kubectl apply -f storageclass.yaml

Da provjerimo kako klasteri rade zajedno, napravimo sljedeći PVC (Persistent Volume Claim):

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

Hajde odmah da vidimo kako je Kubernetes kreirao traženi volumen u Ceph-u:

kubectl get pvc
kubectl get pv

Čini se da je sve super! Kako ovo izgleda na Ceph strani?
Dobijamo listu volumena u bazenu i vidimo informacije o našem volumenu:

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

Sada da vidimo kako funkcionira promjena veličine RBD volumena.
Promijenite veličinu volumena u manifestu pvc.yaml u 2Gi i primijenite ga:

kubectl apply -f pvc.yaml

Sačekajmo da promjene stupe na snagu i ponovo pogledajmo veličinu volumena.

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

kubectl get pv
kubectl get pvc

Vidimo da se veličina PVC-a nije promijenila. Da saznate zašto, možete pitati Kubernetes za YAML opis PVC-a:

kubectl get pvc rbd-pvc -o yaml

Evo problema:

poruka: Čeka se da korisnik (ponovno) pokrene pod da završi promjenu veličine volumena na čvoru. tip: FileSystemResizePending

To jest, disk je porastao, ali sistem datoteka na njemu nije.
Da biste povećali sistem datoteka, morate montirati volumen. U našoj zemlji stvoreni PVC/PV se trenutno ne koristi ni na koji način.

Možemo kreirati test Pod, na primjer ovako:

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

A sada pogledajmo PVC:

kubectl get pvc

Veličina je promijenjena, sve je u redu.

U prvom dijelu smo radili sa RBD blok uređajem (to je skraćenica od Rados Block Device), ali to se ne može učiniti ako sa ovim diskom istovremeno treba da rade različite mikroservise. CephFS je mnogo prikladniji za rad sa datotekama nego slikama diska.
Koristeći primjer Ceph i Kubernetes klastera, konfigurisaćemo CSI i druge neophodne entitete za rad sa CephFS.

Uzmimo vrijednosti iz novog Helm grafikona koji su nam potrebni:

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

Opet morate popuniti cephfs.yml datoteku. Kao i ranije, Ceph naredbe će pomoći:

ceph fsid
ceph mon dump

Popunite datoteku vrijednostima poput ove:

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

Imajte na umu da su adrese monitora navedene u jednostavnom obrascu adresa:port. Za montiranje cephf-ova na čvor, ove adrese se prosljeđuju modulu kernela, koji još ne zna kako da radi sa v2 protokolom monitora.
Mijenjamo port za httpMetrics (Prometheus će ići tamo radi praćenja metrike) tako da ne bude u sukobu sa nginx-proxy, koji je instalirao Kubespray. Možda vam ovo neće trebati.

Instalirajte Helm grafikon u Kubernetes klaster:

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

Idemo u Ceph skladište podataka da tamo kreiramo zasebnog korisnika. U dokumentaciji se navodi da CephFS provider zahtijeva administratorska prava pristupa klasteru. Ali mi ćemo kreirati posebnog korisnika fs sa ograničenim pravima:

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'

I pogledajmo odmah njegov pristupni ključ, trebat će nam kasnije:

ceph auth get-key client.fs

Kreirajmo odvojene Secret i StorageClass.
Ništa novo, to smo već vidjeli na primjeru RBD-a:

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

Primjena manifesta:

kubectl apply -f secret.yaml

A sada - zasebna 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

Hajde da ga popunimo ovde clusterID i primjenjivo u Kubernetesu:

kubectl apply -f storageclass.yaml

inspekcija

Za provjeru, kao u prethodnom primjeru, napravimo PVC:

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

I provjerite prisustvo PVC/PV:

kubectl get pvc
kubectl get pv

Ako želite da pogledate datoteke i direktorijume u CephFS-u, možete negdje montirati ovaj sistem datoteka. Na primjer kao što je prikazano ispod.

Idemo na jedan od čvorova Ceph klastera i izvršimo sljedeće radnje:

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

Naravno, montiranje FS-a na ovakav Ceph čvor je pogodno samo za potrebe obuke, što mi radimo na našem Slurm kursevi. Mislim da to niko ne bi radio u produkciji; postoji veliki rizik od slučajnog brisanja važnih datoteka.

I na kraju, hajde da provjerimo kako stvari funkcioniraju sa promjenom veličine volumena u slučaju CephFS-a. Vratimo se na Kubernetes i uredimo naš manifest za PVC - povećajte veličinu tamo, na primjer, na 7Gi.

Primijenimo uređeni fajl:

kubectl apply -f pvc.yaml

Pogledajmo montirani direktorij da vidimo kako se kvota promijenila:

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

Da bi ova komanda radila, možda ćete morati da instalirate paket na vaš sistem attr.

Oči se boje, ali ruke se boje

Sve ove čarolije i dugi YAML manifesti naizgled izgledaju komplikovano, ali u praksi, učenici Slurma ih vrlo brzo svladaju.
U ovom članku nismo išli duboko u džunglu - za to postoji službena dokumentacija. Ako vas zanimaju detalji o postavljanju Ceph pohrane s Kubernetes klasterom, ove veze će vam pomoći:

Opšti principi rada Kubernetesa sa tomovima
RBD dokumentacija
Integracija RBD-a i Kubernetesa iz Ceph perspektive
Integracija RBD-a i Kubernetesa iz CSI perspektive
Opšta CephFS dokumentacija
Integracija CephFS-a i Kubernetesa iz CSI perspektive

Na kursu Slurm Kubernetes Base možete otići malo dalje i postaviti pravu aplikaciju u Kubernetes koja će koristiti CephFS kao skladište datoteka. Putem GET/POST zahtjeva moći ćete prenijeti datoteke u Ceph i primiti ih od njih.

A ako vas više zanima pohrana podataka, prijavite se novi kurs o Cephu. Dok je beta test u toku, kurs se može nabaviti uz popust i možete uticati na njegov sadržaj.

Autor članka: Alexander Shvalov, praktičar Southbridge, certificirani Kubernetes administrator, autor i programer Slurm kurseva.

izvor: www.habr.com