ProHoster > Блог > Administrado > Praktika ekzemplo de ligado de Ceph-bazita stokado al Kubernetes-areo

Praktika ekzemplo de ligado de Ceph-bazita stokado al Kubernetes-areo

Container Storage Interface (CSI) estas unuigita interfaco inter Kubernetes kaj stokadsistemoj. Pri ĝi ni jam mallonge parolis rakontis, kaj hodiaŭ ni rigardos pli detale la kombinaĵon de CSI kaj Ceph: ni montros kiel konekti Ceph-stokadon al la Kubernetes-areto.
La artikolo disponigas realajn, kvankam iomete simpligitajn ekzemplojn por facileco de percepto. Ni ne konsideras instali kaj agordi Ceph kaj Kubernetes-grupojn.

Ĉu vi scivolas kiel ĝi funkcias?

Praktika ekzemplo de ligado de Ceph-bazita stokado al Kubernetes-areo

Do, vi havas Kubernetes-grupon ĉe viaj fingroj, deplojitan, ekzemple, kubespray. Estas Ceph-grupo funkcianta proksime - vi ankaŭ povas instali ĝin, ekzemple, kun ĉi tio aro da ludlibroj. Mi esperas, ke ne necesas mencii, ke por produktado inter ili devas esti reto kun bendolarĝo de almenaŭ 10 Gbit/s.

Se vi havas ĉion ĉi, ni iru!

Unue, ni iru al unu el la Ceph-grupo-nodoj kaj kontrolu, ke ĉio estas en ordo:

ceph health
ceph -s

Poste, ni tuj kreos naĝejon por RBD-diskoj:

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

Ni transiru al la Kubernetes-areto. Tie, unue, ni instalos la ŝoforon Ceph CSI por RBD. Ni instalos, kiel atendite, per Helm.
Ni aldonas deponejon kun diagramo, ni ricevas aron da variabloj por la diagramo ceph-csi-rbd:

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

Nun vi devas plenigi la dosieron cephrbd.yml. Por fari tion, malkovru la cluster-ID kaj IP-adresojn de monitoroj en Ceph:

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

Ni enigas la akiritajn valorojn en la dosieron cephrbd.yml. Samtempe, ni ebligas la kreadon de PSP-politikoj (Pod Security Policies). Opcioj en sekcioj nodekromaĵo и provizanto jam en la dosiero, ili povas esti korektitaj kiel montrite sube:

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

Poste, ĉio, kio restas por ni, estas instali la diagramon en la Kubernetes-grupo.

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

Bonege, la RBD-ŝoforo funkcias!
Ni kreu novan StorageClass en Kubernetes. Ĉi tio denove postulas iom da marŝado kun Ceph.

Ni kreas novan uzanton en Ceph kaj donas al li rajtojn skribi al la naĝejo kubo:

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

Nun ni vidu, ke la alirŝlosilo ankoraŭ estas tie:

ceph auth get-key client.rbdkube

La komando eligos ion tian:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Ni aldonu ĉi tiun valoron al Sekreto en la Kubernetes-areo - kie ni bezonas ĝin uzantklavo:

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

Kaj ni kreas nian sekreton:

kubectl apply -f secret.yaml

Poste, ni bezonas StorageClass-manifeston ion tian:

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

Necesas plenigi clusterID, kiun ni jam lernis de la teamo ceph fsid, kaj apliki ĉi tiun manifeston al la Kubernetes-grupo:

kubectl apply -f storageclass.yaml

Por kontroli kiel la aretoj funkcias kune, ni kreu la sekvan PVC (Persistenta Volumo-Aserto):

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

Ni tuj vidu kiel Kubernetes kreis la petitan volumon en Ceph:

kubectl get pvc
kubectl get pv

Ĉio ŝajnas esti bonega! Kiel ĉi tio aspektas ĉe la Ceph-flanko?
Ni ricevas liston de volumoj en la naĝejo kaj rigardas informojn pri nia volumo:

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

Nun ni vidu kiel funkcias regrandigo de RBD-volumo.
Ŝanĝu la volumgrandecon en la manifesto pvc.yaml al 2Gi kaj apliku ĝin:

kubectl apply -f pvc.yaml

Ni atendu, ke la ŝanĝoj efektiviĝos kaj denove rigardu la volumgrandecon.

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

kubectl get pv
kubectl get pvc

Ni vidas, ke la grandeco de PVC ne ŝanĝiĝis. Por ekscii kial, vi povas pridemandi Kubernetes pri YAML-priskribo de la PVC:

kubectl get pvc rbd-pvc -o yaml

Jen la problemo:

mesaĝo: Atendante ke uzanto (re-)komencos podon por fini dosiersistemon regrandigi volumon sur nodo. tajpu: FileSystemResizePending

Tio estas, la disko kreskis, sed la dosiersistemo sur ĝi ne.
Por kreskigi la dosiersistemon, vi devas munti la volumon. En nia lando, la kreita PVC/PV estas nuntempe neniel uzata.

Ni povas krei testan Pod, ekzemple jene:

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

Kaj nun ni rigardu PVC:

kubectl get pvc

La grandeco ŝanĝiĝis, ĉio estas en ordo.

En la unua parto, ni laboris kun la RBD-bloka aparato (ĝi signifas Rados Block Device), sed ĉi tio ne povas esti farita se malsamaj mikroservoj bezonas labori kun ĉi tiu disko samtempe. CephFS multe pli taŭgas por labori kun dosieroj prefere ol diskbildoj.
Uzante la ekzemplon de Ceph kaj Kubernetes-aretoj, ni agordos CSI kaj aliajn necesajn entojn por labori kun CephFS.

Ni ricevu la valorojn de la nova Helm-diagramo, kiun ni bezonas:

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

Denove vi devas plenigi la cephfs.yml dosieron. Kiel antaŭe, Ceph-komandoj helpos:

ceph fsid
ceph mon dump

Plenigu la dosieron per valoroj kiel ĉi tio:

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

Bonvolu noti, ke monitoraj adresoj estas specifitaj en la simpla formo adreso:porto. Por munti cephfs sur nodo, ĉi tiuj adresoj estas transdonitaj al la kernomodulo, kiu ankoraŭ ne scias kiel labori kun la v2 monitora protokolo.
Ni ŝanĝas la havenon por httpMetrics (Prometheus iros tien por monitorado de metrikoj) por ke ĝi ne konfliktu kun nginx-proxy, kiu estas instalita de Kubespray. Vi eble ne bezonas ĉi tion.

Instalu la Helm-diagramon en la Kubernetes-areto:

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

Ni iru al la datumvendejo Ceph por krei tie apartan uzanton. La dokumentaro deklaras, ke la provizanto de CephFS postulas alirrajtojn de administranto de cluster. Sed ni kreos apartan uzanton fs kun limigitaj rajtoj:

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'

Kaj ni tuj rigardu lian alirŝlosilon, ni bezonos ĝin poste:

ceph auth get-key client.fs

Ni kreu apartajn Secret kaj StorageClass.
Nenio nova, ni jam vidis ĉi tion en la ekzemplo de RBD:

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

Aplikante la manifeston:

kubectl apply -f secret.yaml

Kaj nun - aparta Stokadoklaso:

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

Ni plenigu ĝin ĉi tie clusterID kaj aplikebla en Kubernetes:

kubectl apply -f storageclass.yaml

inspektado

Por kontroli, kiel en la antaŭa ekzemplo, ni kreu PVC:

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

Kaj kontrolu la ĉeeston de PVC/PV:

kubectl get pvc
kubectl get pv

Se vi volas rigardi dosierojn kaj dosierujojn en CephFS, vi povas munti ĉi tiun dosiersistemon ie. Ekzemple kiel montrite sube.

Ni iru al unu el la Ceph-grupo-nodoj kaj faru la jenajn agojn:

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

Kompreneble, munti FS sur Ceph-nodo tiel taŭgas nur por trejnado, kion ni faras sur nia. Slurm-kursoj. Mi pensas, ke neniu farus tion en produktado; estas alta risko hazarde forviŝi gravajn dosierojn.

Kaj finfine, ni kontrolu kiel aferoj funkcias kun regrandigo de volumoj en la kazo de CephFS. Ni revenu al Kubernetes kaj redaktu nian manifeston por PVC - pliigu la grandecon tie, ekzemple, al 7Gi.

Ni apliku la redaktitan dosieron:

kubectl apply -f pvc.yaml

Ni rigardu la muntitan dosierujon por vidi kiel la kvoto ŝanĝiĝis:

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

Por ke ĉi tiu komando funkciu, vi eble bezonos instali la pakaĵon en via sistemo attr.

La okuloj timas, sed la manoj

Ĉiuj ĉi tiuj sorĉoj kaj longaj YAML-manifestoj ŝajnas komplikaj sur la surfaco, sed praktike, Slurm-studentoj ekkomprenas ilin sufiĉe rapide.
En ĉi tiu artikolo ni ne eniris profunde en la ĝangalon - ekzistas oficiala dokumentaro por tio. Se vi interesiĝas pri la detaloj pri agordo de Ceph-stokado kun Kubernetes-grupo, ĉi tiuj ligiloj helpos:

Ĝeneralaj principoj de Kubernetes laboranta kun volumoj
RBD Dokumentado
Integrante RBD kaj Kubernetes de Ceph-perspektivo
Integrante RBD kaj Kubernetes de CSI-perspektivo
Ĝenerala CephFS-dokumentado
Integrante CephFS kaj Kubernetes de CSI-perspektivo

Sur la Slurm-kurso Kubernetes Bazo vi povas iri iom plu kaj disfaldi veran aplikaĵon en Kubernetes, kiu uzos CephFS kiel dosierstokado. Per GET/POST petoj vi povos transdoni dosierojn al kaj ricevi ilin de Ceph.

Kaj se vi pli interesiĝas pri konservado de datumoj, tiam aliĝu nova kurso pri Ceph. Dum la beta-testo daŭras, la kurso povas esti akirita kun rabato kaj vi povas influi ĝian enhavon.

Aŭtoro de la artikolo: Aleksandr Ŝvalov, praktikanta inĝeniero Southbridge, Atestita Kubernetes Administranto, verkinto kaj ellaboranto de Slurm-kursoj.

fonto: www.habr.com