ProHoster > Blog > administrasie > 'n Praktiese voorbeeld van die koppeling van Ceph-gebaseerde berging aan 'n Kubernetes-kluster

'n Praktiese voorbeeld van die koppeling van Ceph-gebaseerde berging aan 'n Kubernetes-kluster

Container Storage Interface (CSI) is 'n verenigde koppelvlak tussen Kubernetes en bergingstelsels. Ons het reeds kortliks daaroor gepraat vertel, en vandag gaan ons die kombinasie van CSI en Ceph van nader bekyk: ons sal wys hoe koppel Ceph-berging na die Kubernetes-kluster.
Die artikel verskaf werklike, hoewel effens vereenvoudigde voorbeelde vir gemak van persepsie. Ons oorweeg dit nie om Ceph- en Kubernetes-klusters te installeer en op te stel nie.

Wonder jy hoe dit werk?

'n Praktiese voorbeeld van die koppeling van Ceph-gebaseerde berging aan 'n Kubernetes-kluster

So, jy het 'n Kubernetes-kluster by jou vingers, ontplooi, byvoorbeeld, kubespray. Daar is 'n Ceph-kluster wat naby werk - jy kan dit byvoorbeeld ook hiermee installeer 'n stel speelboeke. Ek hoop dit is nie nodig om te noem dat daar vir produksie tussen hulle 'n netwerk met 'n bandwydte van minstens 10 Gbit/s moet wees nie.

As jy dit alles het, laat ons gaan!

Kom ons gaan eers na een van die Ceph-cluster nodusse en kyk of alles in orde is:

ceph health
ceph -s

Vervolgens sal ons onmiddellik 'n poel vir RBD-skywe skep:

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

Kom ons gaan aan na die Kubernetes-groepering. Daar sal ons eerstens die Ceph CSI-bestuurder vir RBD installeer. Ons sal, soos verwag, deur Helm installeer.
Ons voeg 'n bewaarplek by met 'n grafiek, ons kry 'n stel veranderlikes vir die ceph-csi-rbd grafiek:

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

Nou moet jy die cephrbd.yml-lêer invul. Om dit te doen, vind die groep-ID en IP-adresse van monitors in Ceph uit:

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

Ons voer die verkryde waardes in die cephrbd.yml-lêer in. Terselfdertyd maak ons ​​die skepping van PSP-beleide (Pod Security Policies) moontlik. Opsies in afdelings nodeplugin и voorsiener reeds in die lêer, kan hulle reggestel word soos hieronder getoon:

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

Volgende, al wat vir ons oorbly, is om die grafiek in die Kubernetes-kluster te installeer.

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

Groot, die RBD-bestuurder werk!
Kom ons skep 'n nuwe StorageClass in Kubernetes. Dit verg weer 'n bietjie peuter met Ceph.

Ons skep 'n nuwe gebruiker in Ceph en gee hom regte om na die swembad te skryf Kubus:

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

Kom ons kyk nou dat die toegangsleutel nog daar is:

ceph auth get-key client.rbdkube

Die opdrag sal iets soos hierdie uitvoer:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Kom ons voeg hierdie waarde by Secret in die Kubernetes-groepering – waar ons dit nodig het gebruikerssleutel:

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

En ons skep ons geheim:

kubectl apply -f secret.yaml

Vervolgens benodig ons 'n StorageClass-manifes iets soos hierdie:

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

Moet ingevul word clusterID, wat ons reeds deur die span geleer het ceph fsid, en pas hierdie manifes toe op die Kubernetes-kluster:

kubectl apply -f storageclass.yaml

Om te kyk hoe die trosse saamwerk, kom ons skep die volgende PVC (Persistent Volume Claim):

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

Kom ons kyk dadelik hoe Kubernetes die gevraagde volume in Ceph geskep het:

kubectl get pvc
kubectl get pv

Alles blyk wonderlik te wees! Hoe lyk dit aan die Ceph-kant?
Ons kry 'n lys van volumes in die swembad en bekyk inligting oor ons volume:

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

Kom ons kyk nou hoe die grootte van 'n RBD-volume werk.
Verander die volumegrootte in die pvc.yaml-manifes na 2Gi en pas dit toe:

kubectl apply -f pvc.yaml

Kom ons wag vir die veranderinge om in werking te tree en kyk weer na die volume grootte.

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

kubectl get pv
kubectl get pvc

Ons sien dat die grootte van PVC nie verander het nie. Om uit te vind hoekom, kan jy Kubernetes navraag doen vir 'n YAML-beskrywing van die PVC:

kubectl get pvc rbd-pvc -o yaml

Hier is die probleem:

boodskap: Wag vir gebruiker om 'n peul te (her-)begin om lêerstelselgrootte van volume op nodus te voltooi. tipe: FileSystemResizePending

Dit wil sê, die skyf het gegroei, maar die lêerstelsel daarop het nie.
Om die lêerstelsel te laat groei, moet jy die volume monteer. In ons land word die geskepde PVC/PV tans op geen manier gebruik nie.

Ons kan 'n toetspod skep, byvoorbeeld soos volg:

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

En kom ons kyk nou na PVC:

kubectl get pvc

Die grootte het verander, alles is in orde.

In die eerste deel het ons met die RBD-bloktoestel gewerk (dit staan ​​vir Rados Block Device), maar dit kan nie gedoen word as verskillende mikrodienste gelyktydig met hierdie skyf moet werk nie. CephFS is baie beter geskik om met lêers te werk eerder as skyfbeelde.
Deur die voorbeeld van Ceph- en Kubernetes-klusters te gebruik, sal ons CSI en ander nodige entiteite konfigureer om met CephFS te werk.

Kom ons kry die waardes uit die nuwe Helm-kaart wat ons nodig het:

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

Weereens moet jy die cephfs.yml-lêer invul. Soos voorheen, sal Ceph-opdragte help:

ceph fsid
ceph mon dump

Vul die lêer in met waardes soos hierdie:

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

Neem asseblief kennis dat monitor adresse gespesifiseer word in die eenvoudige vorm adres:poort. Om cephfs op 'n nodus te monteer, word hierdie adresse na die kernmodule oorgedra, wat nog nie weet hoe om met die v2-monitorprotokol te werk nie.
Ons verander die poort vir httpMetrics (Prometheus sal daarheen gaan vir monitering van metrieke) sodat dit nie bots met nginx-proxy, wat deur Kubespray geïnstalleer word nie. Jy het dit dalk nie nodig nie.

Installeer die Helm-kaart in die Kubernetes-groepering:

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

Kom ons gaan na die Ceph-datawinkel om 'n aparte gebruiker daar te skep. Die dokumentasie verklaar dat die CephFS-voorsiener toegangsregte vir groepadministrateur vereis. Maar ons sal 'n aparte gebruiker skep fs met beperkte regte:

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'

En kom ons kyk dadelik na sy toegangsleutel, ons sal dit later nodig hê:

ceph auth get-key client.fs

Kom ons skep aparte Secret en StorageClass.
Niks nuuts nie, ons het dit reeds in die voorbeeld van RBD gesien:

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

Pas die manifes toe:

kubectl apply -f secret.yaml

En nou - 'n aparte bergingsklas:

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

Kom ons vul dit hier in clusterID en van toepassing in Kubernetes:

kubectl apply -f storageclass.yaml

Проверка

Om te kontroleer, soos in die vorige voorbeeld, kom ons skep 'n PVC:

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

En kyk na die teenwoordigheid van PVC/PV:

kubectl get pvc
kubectl get pv

As jy na lêers en gidse in CephFS wil kyk, kan jy hierdie lêerstelsel iewers monteer. Byvoorbeeld soos hieronder getoon.

Kom ons gaan na een van die Ceph cluster nodusse en voer die volgende aksies uit:

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

Natuurlik is die montering van FS op 'n Ceph-knoop soos hierdie slegs geskik vir opleidingsdoeleindes, en dit is wat ons op ons Slurm kursusse. Ek dink nie iemand sal dit in produksie doen nie; daar is 'n hoë risiko om belangrike lêers per ongeluk uit te vee.

En laastens, kom ons kyk hoe dinge werk met die grootte van volumes in die geval van CephFS. Kom ons keer terug na Kubernetes en wysig ons manifes vir PVC - vergroot die grootte daar, byvoorbeeld, na 7Gi.

Kom ons pas die geredigeerde lêer toe:

kubectl apply -f pvc.yaml

Kom ons kyk na die gemonteerde gids om te sien hoe die kwota verander het:

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

Vir hierdie opdrag om te werk, moet jy dalk die pakket op jou stelsel installeer attr.

Die oë is bang, maar die hande wel

Al hierdie towerspreuke en lang YAML-manifeste lyk op die oog af ingewikkeld, maar in die praktyk kry Slurm-studente hulle redelik vinnig onder die knie.
In hierdie artikel het ons nie diep in die oerwoud ingegaan nie – daar is amptelike dokumentasie daarvoor. As jy belangstel in die besonderhede van die opstel van Ceph-berging met 'n Kubernetes-kluster, sal hierdie skakels help:

Algemene beginsels van Kubernetes wat met volumes werk
RBD Dokumentasie
Integrasie van RBD en Kubernetes vanuit 'n Ceph-perspektief
Integreer RBD en Kubernetes vanuit 'n CSI-perspektief
Algemene CephFS-dokumentasie
Die integrasie van CephFS en Kubernetes vanuit 'n CSI-perspektief

Op die Slurm-kursus Kubernetes-basis jy kan 'n bietjie verder gaan en 'n regte toepassing in Kubernetes ontplooi wat CephFS as lêerberging sal gebruik. Deur GET/POS-versoeke sal jy lêers kan oordra na en dit van Ceph ontvang.

En as jy meer belangstel in databerging, teken dan aan vir nuwe kursus oor Ceph. Terwyl die beta-toets aan die gang is, kan die kursus teen 'n afslag verkry word en jy kan die inhoud daarvan beïnvloed.

Skrywer van die artikel: Alexander Shvalov, praktiserende ingenieur South brug, Gesertifiseerde Kubernetes-administrateur, skrywer en ontwikkelaar van Slurm-kursusse.

Bron: will.com