🥇Praktični primjer povezivanja pohrane temeljene na Cephu na Kubernetes klaster

Container Storage Interface (CSI) je objedinjeno sučelje između Kubernetesa i sustava za pohranu. O tome smo već kratko razgovarali rekao, a danas ćemo pobliže pogledati kombinaciju CSI i Ceph: pokazat ćemo kako povežite Ceph pohranu u Kubernetes klaster.
U članku se daju stvarni, iako malo pojednostavljeni primjeri radi lakše percepcije. Ne razmatramo instaliranje i konfiguriranje Ceph i Kubernetes klastera.

Pitate li se kako funkcionira?

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

Ako imate sve ovo, idemo!

Prvo, idemo do jednog od Ceph čvorova klastera i provjerimo je li sve u redu:

ceph health
ceph -s

Zatim ćemo odmah stvoriti skup za RBD diskove:

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

Prijeđimo na Kubernetes klaster. Tamo ćemo prije svega instalirati Ceph CSI drajver za RBD. Instalirat ćemo, očekivano, preko Helma.
Dodamo repozitorij s grafikonom, dobijemo 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 Cephu:

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

Dobivene vrijednosti unosimo u datoteku cephrbd.yml. Istovremeno omogućujemo izradu PSP politika (Pod Security Policies). Mogućnosti u odjeljcima čvorni dodatak и opskrbljivač 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 instalirati grafikon u Kubernetes klaster.

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

Super, RBD driver radi!
Kreirajmo novu StorageClass u Kubernetesu. Ovo opet zahtijeva malo petljanja s Cephom.

Kreiramo novog korisnika u Cephu i dajemo mu prava pisanja u bazen kocka:

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

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

ceph auth get-key client.rbdkube

Naredba će ispisati nešto poput ovoga:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Dodajmo ovu vrijednost Secretu u Kubernetes klasteru - tamo gdje nam je potrebna korisnički ključ:

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

I mi stvaramo našu tajnu:

kubectl apply -f secret.yaml

Zatim nam treba manifest StorageClass nešto poput ovoga:

---
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 ispuniti clusterID, što smo već tim naučili ceph fsid, i primijenite ovaj manifest na Kubernetes klaster:

kubectl apply -f storageclass.yaml

Da provjerimo kako klasteri rade zajedno, stvorimo 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

Pogledajmo odmah kako je Kubernetes stvorio traženi volumen u Cephu:

kubectl get pvc
kubectl get pv

Čini se da je sve super! Kako ovo izgleda na Ceph strani?
Dobivamo popis volumena u skupu i pregledavamo 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 pvc.yaml manifestu na 2Gi i primijenite je:

kubectl apply -f pvc.yaml

Pričekajmo da promjene stupe na snagu i ponovno 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. Kako biste saznali zašto, možete zatražiti od Kubernetesa YAML opis PVC-a:

kubectl get pvc rbd-pvc -o yaml

Evo u čemu je problem:

poruka: Čeka se da korisnik (ponovno) pokrene grupu kako bi završio promjenu veličine volumena na čvoru datotečnog sustava. tip: FileSystemResizePending

Odnosno, disk je narastao, ali datotečni sustav na njemu nije.
Da biste povećali datotečni sustav, morate montirati volumen. Kod nas se stvoreni PVC/PV trenutno ni na koji način ne koristi.

Možemo izraditi 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 se promijenila, sve je u redu.

U prvom dijelu smo radili s RBD blok uređajem (što je skraćenica od Rados Block Device), ali to nije moguće ako različiti mikroservisi moraju raditi s ovim diskom istovremeno. CephFS je puno prikladniji za rad s datotekama nego sa slikama diskova.
Na primjeru klastera Ceph i Kubernetes konfigurirat ćemo CSI i druge potrebne entitete za rad s CephFS-om.

Uzmimo vrijednosti iz novog Helmovog grafikona koji nam je potreban:

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

Opet morate ispuniti datoteku cephfs.yml. Kao i prije, Ceph naredbe pomoći će:

ceph fsid
ceph mon dump

Ispunite datoteku s ovakvim vrijednostima:

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 obliku adresa:port. Za montiranje cephfs na čvoru, te se adrese prenose u modul kernela, koji još ne zna kako raditi s v2 monitor protokolom.
Mijenjamo priključak za httpMetrics (Prometheus će ići tamo za praćenje metrike) tako da ne dolazi u sukob s nginx-proxyjem, koji je instalirao Kubespray. Ovo vam možda 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 pohranu podataka kako bismo tamo stvorili zasebnog korisnika. Dokumentacija navodi da CephFS provider zahtijeva prava pristupa administratora klastera. Ali stvorit ćemo zasebnog korisnika fs s 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 zasebne 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

Ispunimo ga ovdje clusterID i primjenjivo u Kubernetesu:

kubectl apply -f storageclass.yaml

Проверка

Da provjerimo, kao u prethodnom primjeru, stvorimo PVC:

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

I provjerite prisutnost PVC/PV:

kubectl get pvc
kubectl get pv

Ako želite pogledati datoteke i direktorije u CephFS-u, možete montirati ovaj datotečni sustav negdje. Na primjer kao što je prikazano u nastavku.

Idemo na jedan od Ceph čvorova 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 Ceph čvor kao što je ovo prikladno je samo u svrhu obuke, što mi radimo na našem Slurm tečajevi. Mislim da to nitko ne bi radio u produkciji; postoji veliki rizik od slučajnog brisanja važnih datoteka.

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

Primijenimo uređenu datoteku:

kubectl apply -f pvc.yaml

Pogledajmo montirani direktorij da vidimo kako se promijenila kvota:

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

Da bi ova naredba radila, možda ćete morati instalirati paket na svoj sustav attr.

Oči se boje, ali ruke plaše

Sve ove čarolije i dugi YAML manifesti izgledaju komplicirano na površini, ali u praksi, studenti Slurma ih prilično brzo svladaju.
U ovom članku nismo išli duboko u džunglu - za to postoji službena dokumentacija. Ako vas zanimaju pojedinosti o postavljanju Ceph pohrane s Kubernetes klasterom, ove veze će vam pomoći:

Opća načela rada Kubernetesa s volumenima
RBD dokumentacija
Integracija RBD-a i Kubernetesa iz Ceph perspektive
Integracija RBD-a i Kubernetesa iz CSI perspektive
Opća CephFS dokumentacija
Integracija CephFS-a i Kubernetesa iz CSI perspektive

Na tečaju Slurm Kubernetes baza možete otići malo dalje i implementirati pravu aplikaciju u Kubernetesu koja će koristiti CephFS kao pohranu datoteka. Kroz GET/POST zahtjeve moći ćete prenijeti datoteke na Ceph i primiti ih od njih.

A ako vas više zanima pohrana podataka, prijavite se za novi tečaj o Cephu. Dok je beta test u tijeku, tečaj možete dobiti s popustom te možete utjecati na njegov sadržaj.

Autor članka: Alexander Shvalov, inženjer southbridge, certificirani Kubernetes administrator, autor i programer Slurm tečajeva.

Izvor: www.habr.com

Praktičan primjer povezivanja pohrane temeljene na Cephu s klasterom Kubernetes

Проверка

Oči se boje, ali ruke plaše