ProHoster > Blogs > Administrācija > Praktisks piemērs Ceph bāzes krātuves savienošanai ar Kubernetes klasteru

Praktisks piemērs Ceph bāzes krātuves savienošanai ar Kubernetes klasteru

Container Storage Interface (CSI) ir vienota saskarne starp Kubernetes un uzglabāšanas sistēmām. Mēs jau par to īsi runājām stāstīja, un šodien mēs tuvāk apskatīsim CSI un Ceph kombināciju: mēs parādīsim, kā pievienojiet Ceph krātuvi uz Kubernetes klasteru.
Rakstā sniegti reāli, lai arī nedaudz vienkāršoti piemēri uztveres atvieglošanai. Mēs neapsveram Ceph un Kubernetes klasteru instalēšanu un konfigurēšanu.

Vai jūs interesē, kā tas darbojas?

Praktisks piemērs Ceph bāzes krātuves savienošanai ar Kubernetes klasteru

Tātad jums ir pieejams Kubernetes klasteris, kas ir izvietots, piemēram, kubespray. Netālu darbojas Ceph klasteris - to var arī instalēt, piemēram, ar šo rotaļu grāmatu komplekts. Ceru, ka nevajag minēt, ka ražošanai starp tām ir jābūt tīklam ar joslas platumu vismaz 10 Gbit/s.

Ja tev tas viss ir, dodamies!

Vispirms dosimies uz vienu no Ceph klastera mezgliem un pārbaudīsim, vai viss ir kārtībā:

ceph health
ceph -s

Tālāk mēs nekavējoties izveidosim baseinu RBD diskiem:

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

Pāriesim pie Kubernetes klastera. Tur, pirmkārt, mēs instalēsim Ceph CSI draiveri RBD. Mēs instalēsim, kā paredzēts, izmantojot Helm.
Mēs pievienojam repozitoriju ar diagrammu, mēs iegūstam mainīgo kopu diagrammai ceph-csi-rbd:

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

Tagad jums jāaizpilda fails cephrbd.yml. Lai to izdarītu, noskaidrojiet Ceph monitoru klastera ID un IP adreses:

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

Iegūtās vērtības ievadām failā cephrbd.yml. Tajā pašā laikā mēs ļaujam izveidot PSP politikas (Pod drošības politikas). Iespējas sadaļās mezglu spraudnis и nodrošinātājs jau failā, tos var labot, kā parādīts zemāk:

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

Tālāk mums atliek tikai instalēt diagrammu Kubernetes klasterī.

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

Lieliski, RBD draiveris darbojas!
Izveidosim jaunu StorageClass pakalpojumā Kubernetes. Tas atkal prasa mazliet piestrādāt ar Ceph.

Mēs izveidojam jaunu lietotāju Ceph un piešķiram viņam tiesības rakstīt pūlā Kubs:

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

Tagad apskatīsim, vai piekļuves atslēga joprojām atrodas:

ceph auth get-key client.rbdkube

Komanda izvadīs kaut ko līdzīgu:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Pievienosim šo vērtību noslēpumam Kubernetes klasterī — tur, kur mums tas ir nepieciešams lietotāja atslēga:

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

Un mēs radām savu noslēpumu:

kubectl apply -f secret.yaml

Tālāk mums ir nepieciešams StorageClass manifests, kas līdzīgs šim:

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

Jāaizpilda klastera ID, ko komanda jau ir iemācījusies ceph fsid, un lietojiet šo manifestu Kubernetes klasterim:

kubectl apply -f storageclass.yaml

Lai pārbaudītu, kā kopas darbojas kopā, izveidosim šādu PVC (persistent Volume Claim):

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

Tūlīt redzēsim, kā Kubernetes izveidoja pieprasīto sējumu Ceph:

kubectl get pvc
kubectl get pv

Šķiet, ka viss ir lieliski! Kā tas izskatās Kefa pusē?
Mēs iegūstam baseinā esošo sējumu sarakstu un apskatām informāciju par mūsu sējumu:

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

Tagad redzēsim, kā darbojas RBD apjoma maiņa.
Mainiet apjoma lielumu pvc.yaml manifestā uz 2Gi un lietojiet to:

kubectl apply -f pvc.yaml

Pagaidīsim, kad izmaiņas stāsies spēkā, un vēlreiz paskatīsimies uz skaļuma lielumu.

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

kubectl get pv
kubectl get pvc

Mēs redzam, ka PVC izmērs nav mainījies. Lai uzzinātu, kāpēc, varat vaicāt Kubernetes, lai iegūtu PVC YAML aprakstu:

kubectl get pvc rbd-pvc -o yaml

Lūk, problēma:

ziņojums: gaida, līdz lietotājs (atkārtoti) sāks podziņu, lai pabeigtu failu sistēmas apjoma maiņu mezglā. tips: FileSystemResizePending

Tas ir, disks ir pieaudzis, bet tajā esošā failu sistēma nav.
Lai paplašinātu failu sistēmu, jāpievieno sējums. Mūsu valstī izveidotais PVC/PV šobrīd netiek izmantots nekādā veidā.

Mēs varam izveidot testa Pod, piemēram, šādi:

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

Un tagad apskatīsim PVC:

kubectl get pvc

Izmērs mainījies, viss kārtībā.

Pirmajā daļā strādājām ar RBD blokierīci (tas apzīmē Rados Block Device), taču to nevar izdarīt, ja ar šo disku vienlaicīgi jāstrādā dažādiem mikropakalpojumiem. CephFS ir daudz labāk piemērots darbam ar failiem, nevis diska attēliem.
Izmantojot Ceph un Kubernetes klasteru piemēru, mēs konfigurēsim CSI un citas nepieciešamās entītijas darbam ar CephFS.

Iegūsim mums nepieciešamās vērtības no jaunās Helm diagrammas:

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

Atkal ir jāaizpilda fails cephfs.yml. Tāpat kā iepriekš, Ceph komandas palīdzēs:

ceph fsid
ceph mon dump

Aizpildiet failu ar šādām vērtībām:

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

Lūdzu, ņemiet vērā, ka monitoru adreses ir norādītas vienkāršā formā adrese:ports. Lai mezglā uzstādītu cephfs, šīs adreses tiek pārsūtītas uz kodola moduli, kas vēl nezina, kā strādāt ar v2 monitora protokolu.
Mēs mainām httpMetrics portu (Prometheus dosies tur, lai uzraudzītu metriku), lai tas nebūtu pretrunā ar nginx-proxy, ko uzstāda Kubespray. Jums tas var nebūt vajadzīgs.

Instalējiet Helm diagrammu Kubernetes klasterī:

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

Dosimies uz Ceph datu veikalu, lai tur izveidotu atsevišķu lietotāju. Dokumentācijā teikts, ka CephFS nodrošinātājam ir nepieciešamas klastera administratora piekļuves tiesības. Bet mēs izveidosim atsevišķu lietotāju fs ar ierobežotām tiesībām:

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'

Un nekavējoties apskatīsim viņa piekļuves atslēgu, mums tas būs vajadzīgs vēlāk:

ceph auth get-key client.fs

Izveidosim atsevišķu Secret un StorageClass.
Nekas jauns, mēs to jau esam redzējuši RBD piemērā:

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

Manifesta piemērošana:

kubectl apply -f secret.yaml

Un tagad - atsevišķa 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

Aizpildīsim to šeit klastera ID un piemērojams Kubernetes:

kubectl apply -f storageclass.yaml

Проверка

Lai pārbaudītu, tāpat kā iepriekšējā piemērā, izveidosim PVC:

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

Un pārbaudiet PVC/PV klātbūtni:

kubectl get pvc
kubectl get pv

Ja vēlaties apskatīt CephFS failus un direktorijus, varat kaut kur uzstādīt šo failu sistēmu. Piemēram, kā parādīts zemāk.

Dosimies uz vienu no Ceph klastera mezgliem un veiksim šādas darbības:

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

Protams, FS uzstādīšana uz Ceph mezgla, piemēram, šī, ir piemērota tikai apmācības nolūkiem, ko mēs darām savā Slurm kursi. Es nedomāju, ka kāds to darītu ražošanā; pastāv liels risks nejauši izdzēst svarīgus failus.

Un visbeidzot, pārbaudīsim, kā CephFS gadījumā notiek apjoma maiņa. Atgriezīsimies pie Kubernetes un rediģēsim savu PVC manifestu — palieliniet tur izmēru, piemēram, līdz 7Gi.

Pielietosim rediģēto failu:

kubectl apply -f pvc.yaml

Apskatīsim pievienoto direktoriju, lai redzētu, kā ir mainījusies kvota:

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

Lai šī komanda darbotos, iespējams, būs jāinstalē pakotne savā sistēmā piesaistīt.

Acis baidās, bet rokas baidās

Visas šīs burvestības un garie YAML manifesti ārēji šķiet sarežģīti, taču praksē Slurm studenti tos apgūst diezgan ātri.
Šajā rakstā mēs neiedziļinājāmies džungļos - tam ir oficiāla dokumentācija. Ja jūs interesē sīkāka informācija par Ceph krātuves iestatīšanu ar Kubernetes klasteru, šīs saites palīdzēs:

Kubernetes darba ar apjomiem vispārīgie principi
UBA dokumentācija
UBA un Kubernetes integrēšana no Ceph viedokļa
UBA un Kubernetes integrēšana no CSI viedokļa
Vispārējā CephFS dokumentācija
CephFS un Kubernetes integrēšana no CSI viedokļa

Par Slurm kursu Kubernetes bāze varat iet nedaudz tālāk un Kubernetes izvietot reālu lietojumprogrammu, kas izmantos CephFS kā failu krātuvi. Izmantojot GET/POST pieprasījumus, jūs varēsiet pārsūtīt failus uz Ceph un saņemt tos no tā.

Un, ja jūs vairāk interesē datu glabāšana, tad pierakstieties jauns kurss par Ceph. Kamēr notiek beta tests, kursu var iegūt ar atlaidi un ietekmēt tā saturu.

Raksta autors: Aleksandrs Švalovs, praktizējošais inženieris Southbridge, Sertificēts Kubernetes administrators, Slurm kursu autors un izstrādātājs.

Avots: www.habr.com