🥇Praktický příklad připojení úložiště založeného na Ceph do clusteru Kubernetes

Container Storage Interface (CSI) je jednotný rozhraní pro interakci Kubernetes a systémů pro ukládání dat. Krátce o něm jsme již psali, a dnes podrobněji prozkoumáme vazbu CSI a Ceph: ukážeme, jak připojit úložiště Ceph k clusteru Kubernetes.
V článku jsou uvedeny skutečné, i když poněkud zjednodušené příklady pro lepší pochopení. Instalaci a konfiguraci clusterů Ceph a Kubernetes nebudeme probírat.

Zajímá vás, jak to funguje?

Takže máte k dispozici cluster Kubernetes, například kubespray. Vedle něj běží cluster Ceph – ten můžete také nainstalovat, například tímto balíčkem playbooků. Doufám, že není třeba zdůrazňovat, že pro produkční nasazení by mezi nimi měla být síť s propustností minimálně 10 Gbit/s.

Pokud to všechno máte, jdeme na to!

Nejprve se přihlásíme na jeden z uzlů clusteru Ceph a zkontrolujeme, že je vše v pořádku:

ceph health
ceph -s

Dále vytváříme pool pro RBD disky:

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

Přecházíme do clusteru Kubernetes. Tam nejprve nainstalujeme Ceph CSI driver pro RBD. Instalaci provedeme, jak se patří, přes Helm.
Přidáme repozitář s chartem, získáme sadu proměnných chartu ceph-csi-rbd:

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

Nyní je třeba vyplnit soubor cephrbd.yml. K tomu zjistíme ID clusteru a IP adresy monitorů v Ceph:

ceph fsid  # tím zjistíme clusterID
ceph mon dump  # a tak uvidíme IP adresy monitorů

Získané hodnoty vložíme do souboru cephrbd.yml. Současně zapneme vytvoření politik PSP (Pod Security Policies). Možnosti v sekcích nodeplugin a provisioner už jsou v souboru, můžeme je upravit tak, jak je uvedeno níže:

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

Dále už jen zbývá nainstalovat chart do clusteru Kubernetes.

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

Skvěle, RBD driver funguje!
Vytvoříme v Kubernetes novou StorageClass. K tomu bude zase potřeba trochu pracovat s Ceph.

Vytváříme nového uživatele v Ceph a udělujeme mu práva na zápis do poolu kube:

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

A teď se podíváme na přístupový klíč to vše ve stejném místě:

ceph auth get-key client.rbdkube

Příkaz vydá něco takového:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Uložíme tuto hodnotu do Secret v clusteru Kubernetes – tam, kde je potřeba userKey:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-rbd-secret
  namespace: ceph-csi-rbd
stringData:
  # Hodnoty klíčů odpovídají uživatelskému jménu a jeho klíči, jak je uvedeno v
  # clusteru Ceph. ID uživatele musí mít přístup k poolu,
  # uvedenému ve storage class
  userID: rbdkube
  userKey:

A vytvoříme náš tajný klíč:

kubectl apply -f secret.yaml

Dále potřebujeme zhruba takový manifest StorageClass:

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

   imageFeatures: layering

   # Tyto tajné klíče musí obsahovat údaje pro autorizaci
   # ve vašem poolu.
   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

Je třeba vyplnit clusterID, který jsme již zjistili příkazem ceph fsid, a aplikovat tento manifest v clusteru Kubernetes:

kubectl apply -f storageclass.yaml

Abychom ověřili funkci clusterů ve spojení, vytvoříme následující PVC (Persistent Volume Claim):

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

Hned se podíváme, jak Kubernetes vytvořil v Ceph požadovaný objem:

kubectl get pvc
kubectl get pv

Vypadá to skvěle! Jak to vypadá na straně Ceph?
Získáváme seznam objemů v poolu a prohlížíme si informace o našem objemu:

rbd ls -p kube
rbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653  # zde bude samozřejmě jiný ID objemu, který vydala předchozí příkaz

Teď se podívejme, jak funguje změna velikosti objemu RBD.
Změníme velikost objemu v manifestu pvc.yaml na 2Gi a aplikujeme jej:

kubectl apply -f pvc.yaml

Počkáme, až změny vstoupí v platnost, a znovu se podíváme na velikost objemu.

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

kubectl get pv
kubectl get pvc

Vidíme, že velikost PVC se nezměnila. Chcete-li zjistit důvod, můžete požádat Kubernetes o popis PVC ve formátu YAML:

kubectl get pvc rbd-pvc -o yaml

A tady je problém:

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

To znamená, že disk se zvětšil, ale souborový systém na něm nikoli.
Abychom zvětšili souborový systém, musíme přimontovat objem. Náš vytvořený PVC/PV se momentálně nijak nevyužívá.

Můžeme vytvořit testovací Pod, například takto:

---
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 nyní se podívejme na PVC:

kubectl get pvc

Velikost se změnila, vše je v pořádku.

V první části jsme pracovali s blokovým zařízením RBD (což je zkratka pro Rados Block Device), ale takto to nelze provádět, pokud je třeba, aby s tímto diskem současně pracovaly různé mikroslužby. Pro práci s soubory, a ne s obrazem disku, je mnohem lepší CephFS.
Na příkladu clusterů Ceph a Kubernetes nastavíme CSI a další potřebné entity pro práci s CephFS.

Získáme hodnoty z potřebného nového Helm chartu:

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

Znovu je třeba vyplnit soubor cephfs.yml. Jako dříve nám pomohou příkazy Ceph:

ceph fsid
ceph mon dump

Vyplňujeme soubor s hodnotami přibližně takto:

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

Všimněte si, že adresy monitorů jsou uvedeny v jednoduché formě address:port. Pro připojení cephfs na uzlu se tyto adresy předávají jádrovému modulu, který ještě neumí pracovat s protokolem monitorů v2.
Port pro httpMetrics (kam bude Prometheus posílat metriky pro monitoring) měníme, aby nedošlo k konfliktu s nginx-proxy, který se instaluje pomocí Kubespray. Možná to nebudete potřebovat.

Nainstalujeme Helm chart do clusteru Kubernetes:

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

Přejdeme do úložiště dat Ceph, abychom zde vytvořili samostatného uživatele. V dokumentaci je uvedeno, že provizoru CephFS jsou potřeba administrátorská práva pro cluster. Ale vytvoříme samostatného uživatele fs s omezenými právy:

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'

A hned se podíváme na jeho přístupový klíč, který budeme potřebovat dále:

ceph auth get-key client.fs

Vytvoříme samostatné Secret a StorageClass.
Nic nového, už jsme to viděli na příkladu RBD:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-cephfs-secret
  namespace: ceph-csi-cephfs
stringData:
  # Je nutné pro dynamicky vytvářené svazky
  adminID: fs
  adminKey:

Používáme manifest:

kubectl apply -f secret.yaml

A nyní – samostatný StorageClass:

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

  # Název souborového systému CephFS, ve kterém bude vytvořen objem
  fsName: cephfs

  # (volitelné) Pool Ceph, ve kterém budou uložena data objemu
  # pool: cephfs_data

  # (volitelné) Volby připojení Ceph-fuse oddělené čárkami
  # například:
  # fuseMountOptions: debug

  # (volitelné) Volby připojení CephFS pro jádro oddělené čárkami
  # Viz man mount.ceph pro seznam těchto voleb. Například:
  # kernelMountOptions: readdir_max_bytes=1048576,norbytes

  # Tajné klíče musí obsahovat oprávnění pro admina a/nebo uživatele 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

  # (volitelné) Ovladač může používat buď ceph-fuse (fuse), 
  # nebo ceph kernelclient (kernel).
  # Pokud není uvedeno, bude použit výchozí způsob připojení objemů, 
  # což je určeno hledáním ceph-fuse a mount.ceph
  # mounter: kernel
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
  - debug

Vyplníme to tady clusterID a aplikujeme v Kubernetes:

kubectl apply -f storageclass.yaml

Kontrola

Pro kontrolu, jak bylo uvedeno v předchozím příkladu, vytvoříme PVC:

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

A zkontrolujeme existenci PVC/PV:

kubectl get pvc
kubectl get pv

Pokud chcete vidět soubory a adresáře v CephFS, můžete tento souborový systém připojit někde jinde. Například, jak je ukázáno níže.

Půjdeme na jeden z uzlů klastru Ceph a provedeme následující kroky:

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

Samozřejmě, takové připojení FS na uzlu Ceph je vhodné výhradně pro výukové účely, což děláme na našich kurzech Slurm. Nemyslím si, že by to někdo dělal v produkčním prostředí, je velké riziko omylem přepsat důležité soubory.

A nakonec se podívejme, jak je to v případě CephFS se změnou velikosti objemu. Vracíme se do Kubernetes a upravíme náš manifest pro PVC — zvětšíme tam velikost, například na 7Gi.

Aplikujeme upravený soubor:

kubectl apply -f pvc.yaml

Podíváme se na připojený adresář, jak se změnilo kvóty:

getfattr -n ceph.quota.max_bytes

K provedení tohoto příkazu budete možná muset do systému nainstalovat balíček attr.

Oči se bojí, ale ruce dělají

Na první pohled se všechny tyto magie a dlouhé manifesty YAML zdají složité, ale v praxi si se nimi studenti Slérmu docela rychle poradí.
V tomto článku se nezabýváme podrobnostmi – na to je oficiální dokumentace. Pokud vás zajímají detaily nastavení úložiště Ceph v kombinaci s Kubernetes, pomohou tyto odkazy:

Obecné principy fungování Kubernetes s objemy
Dokumentace k RBD
Integrace RBD a Kubernetes z pohledu Ceph
Integrace RBD a Kubernetes z pohledu CSI
Obecná dokumentace k CephFS
Integrace CephFS a Kubernetes z pohledu CSI

Na kurzu Slérm Základy Kubernetes můžete zajít ještě o kousek dál a nasadit v Kubernetes skutečnou aplikaci, která bude používat CephFS jako úložiště pro soubory. Pomocí GET/POST dotazů budete moci přenášet soubory a získávat je z Ceph.

A pokud vás více zajímá uchovávání dat, přihlaste se na nový kurz o Ceph. Během beta testování lze kurz získat se slevou a ovlivnit jeho obsah.

Autor článku: Alexander Shvalov, praktikující inženýr Southbridge, Certified Kubernetes Administrator, autor a vývojář kurzů Slérm.

Zdroj: habr.com

Praktický příklad připojení úložiště na bázi Ceph do klastru Kubernetes

Kontrola

Oči se bojí, ale ruce dělají