Практичен пример за поврзување складирање базирано на Ceph со кластерот Kubernetes

Интерфејсот за складирање на контејнери (CSI) е унифициран интерфејс помеѓу Kubernetes и системите за складирање. Веќе накратко разговаравме за тоа кажа, а денес ќе ја разгледаме подетално комбинацијата на CSI и Ceph: ќе покажеме како поврзете складирање Ceph до кластерот Кубернетес.
Написот дава вистински, иако малку поедноставени примери за полесно перцепција. Не размислуваме да инсталираме и конфигурираме кластери Ceph и Kubernetes.

Дали се прашувате како функционира?

Значи, имате кластер Kubernetes на дофат на раката, распореден, на пример, кубеспреј. Во близина работи кластерот Ceph - исто така можете да го инсталирате, на пример, со ова збир на книги за игри. Се надевам дека нема потреба да се споменува дека за производство меѓу нив мора да има мрежа со пропусен опсег од најмалку 10 Gbit/s.

Ако го имате сето ова, ајде да одиме!

Прво, да одиме до еден од јазлите на кластерот Ceph и да провериме дали сè е во ред:

ceph health
ceph -s

Следно, веднаш ќе создадеме базен за RBD-дискови:

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

Ајде да продолжиме кон кластерот Кубернетес. Таму, пред сè, ќе го инсталираме драјверот Ceph CSI за RBD. Ќе инсталираме, очекувано, преку Helm.
Додаваме складиште со графикон, добиваме збир на променливи за табелата ceph-csi-rbd:

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

Сега треба да ја пополните датотеката cephrbd.yml. За да го направите ова, дознајте ги ID на кластерот и IP адресите на мониторите во Ceph:

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

Добиените вредности ги внесуваме во датотеката cephrbd.yml. Во исто време, овозможуваме креирање на политики за PSP (Pod Security Policies). Опции во делови јазол приклучок и обезбедувач веќе во датотеката, тие можат да се коригираат како што е прикажано подолу:

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

Следно, сè што ни останува е да ја инсталираме табелата во кластерот Kubernetes.

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

Одлично, возачот на RBD работи!
Ајде да создадеме нова StorageClass во Kubernetes. Ова повторно бара малку чепкање со Кеф.

Создаваме нов корисник во Ceph и му даваме права да пишува на базенот кубе:

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

Сега да видиме дека клучот за пристап е сè уште таму:

ceph auth get-key client.rbdkube

Командата ќе излезе вака:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Ајде да ја додадеме оваа вредност на Secret во кластерот Kubernetes - онаму каде што ни е потребно userKey:

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

И ние ја создаваме нашата тајна:

kubectl apply -f secret.yaml

Следно, ни треба StorageClass манифест нешто вака:

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

Треба да се пополни кластерИД, што веќе го научивме од тимот цеф фсид, и применете го овој манифест на кластерот Kubernetes:

kubectl apply -f storageclass.yaml

За да провериме како кластерите работат заедно, ајде да го создадеме следниов ПВЦ (Постојано барање за волумен):

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

Ајде веднаш да видиме како Kubernetes го создал бараниот волумен во Ceph:

kubectl get pvc
kubectl get pv

Се чини дека сè е одлично! Како изгледа ова на страната на Кеф?
Добиваме список на томови во базенот и прегледуваме информации за нашиот волумен:

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

Сега да видиме како функционира промената на големината на волуменот на RBD.
Променете ја големината на јачината на звукот во манифестот pvc.yaml во 2Gi и применете ја:

kubectl apply -f pvc.yaml

Да почекаме промените да стапат на сила и повторно да ја разгледаме големината на јачината на звукот.

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

kubectl get pv
kubectl get pvc

Гледаме дека големината на ПВЦ не е променета. За да дознаете зошто, можете да побарате од Kubernetes опис на YAML на PVC:

kubectl get pvc rbd-pvc -o yaml

Еве го проблемот:

порака: Се чека корисникот да (повторно) стартува подлога за да ја заврши промената на големината на јачината на датотечниот систем на јазолот. тип: FileSystemResizePending

Тоа е, дискот порасна, но датотечниот систем на него не.
За да го зголемите датотечниот систем, треба да ја монтирате јачината на звукот. Кај нас создадениот ПВЦ/ПВ моментално не се користи на кој било начин.

Можеме да создадеме тест Pod, на пример вака:

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

И сега да го погледнеме ПВЦ:

kubectl get pvc

Големината е променета, сè е во ред.

Во првиот дел, работевме со блок-уредот RBD (тој е кратенка за Rados Block Device), но тоа не може да се направи ако различни микросервиси треба да работат со овој диск истовремено. CephFS е многу подобро прилагоден за работа со датотеки наместо со слики од диск.
Користејќи го примерот на кластерите Ceph и Kubernetes, ќе ги конфигурираме CSI и другите неопходни ентитети да работат со CephFS.

Ајде да ги добиеме вредностите од новата шема на Helm што ни треба:

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

Повторно треба да ја пополните датотеката cephfs.yml. Како и досега, командите на Ceph ќе помогнат:

ceph fsid
ceph mon dump

Пополнете ја датотеката со вредности како ова:

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

Ве молиме имајте предвид дека адресите на мониторот се наведени во едноставната форма адреса:порт. За монтирање на cephfs на јазол, овие адреси се пренесуваат во модулот на јадрото, кој сè уште не знае како да работи со протоколот за монитор v2.
Ја менуваме портата за httpMetrics (Прометеј ќе оди таму за следење метрика) за да не е во конфликт со nginx-proxy, кој е инсталиран од Kubespray. Можеби нема да ви треба ова.

Инсталирајте ја табелата на Helm во кластерот Kubernetes:

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

Ајде да одиме во продавницата за податоци Ceph за да создадеме посебен корисник таму. Документацијата наведува дека давателот на CephFS бара права за пристап на администратор на кластерот. Но, ние ќе создадеме посебен корисник fs со ограничени права:

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'

И веднаш да го погледнеме неговиот клуч за пристап, ќе ни треба подоцна:

ceph auth get-key client.fs

Ајде да создадеме посебна Secret и StorageClass.
Ништо ново, ова веќе го видовме во примерот на RBD:

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

Примена на манифестот:

kubectl apply -f secret.yaml

И сега - посебна 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

Ајде да го пополниме овде кластерИД и се применува во Kubernetes:

kubectl apply -f storageclass.yaml

Проверка

За да провериме, како и во претходниот пример, ајде да создадеме ПВЦ:

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

И проверете го присуството на ПВЦ/ПВ:

kubectl get pvc
kubectl get pv

Ако сакате да ги погледнете датотеките и директориумите во CephFS, можете да го монтирате овој датотечен систем некаде. На пример како што е прикажано подолу.

Ајде да одиме на еден од јазлите на кластерот Ceph и да ги извршиме следните дејства:

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

Се разбира, монтирањето FS на Ceph јазол како овој е погодно само за цели на обука, што е она што го правиме на нашата Курсеви за слабеење. Мислам дека никој не би го направил ова во производството; постои голем ризик од случајно бришење важни датотеки.

И, конечно, да провериме како функционираат работите со промена на големината на волумените во случајот со CephFS. Ајде да се вратиме на Kubernetes и да го уредиме нашиот манифест за PVC - зголемете ја големината таму, на пример, на 7Gi.

Ајде да ја примениме изменетата датотека:

kubectl apply -f pvc.yaml

Ајде да го погледнеме монтираниот директориум за да видиме како се смени квотата:

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

За оваа команда да работи, можеби ќе треба да го инсталирате пакетот на вашиот систем attr.

Очите се плашат, но рацете се плашат

Сите овие магии и долгите YAML манифестации изгледаат комплицирани на површината, но во пракса, студентите на Slurm ги добиваат прилично брзо.
Во оваа статија не навлеговме длабоко во џунглата - постои официјална документација за тоа. Ако сте заинтересирани за деталите за поставување на складиштето Ceph со кластерот Kubernetes, овие врски ќе ви помогнат:

Општи принципи на Kubernetes работа со томови
RBD документација
Интегрирање на RBD и Kubernetes од перспектива на Ceph
Интегрирање на RBD и Kubernetes од перспектива на CSI
Општа CephFS документација
Интегрирање на CephFS и Kubernetes од перспектива на CSI

На курсот Slurm База Кубернетес можете да одите малку подалеку и да распоредите вистинска апликација во Kubernetes која ќе користи CephFS како складирање на датотеки. Преку барањата GET/POST ќе можете да префрлате датотеки и да ги примате од Ceph.

И ако сте повеќе заинтересирани за складирање податоци, тогаш пријавете се за нов курс за Ceph. Додека трае бета тестот, курсот може да се добие со попуст и можете да влијаете на неговата содржина.

Автор на статијата: Александар Швалов, инженер-практик Саутбриџ, Сертифициран Kubernetes администратор, автор и развивач на курсеви за Slurm.

Извор: www.habr.com