ProHoster > Օրագիր > Վարչակազմը > Ceph-ի վրա հիմնված պահեստը Kubernetes կլաստերին միացնելու գործնական օրինակ

Ceph-ի վրա հիմնված պահեստը Kubernetes կլաստերին միացնելու գործնական օրինակ

Container Storage Interface (CSI) միասնական ինտերֆեյս է Kubernetes-ի և պահեստավորման համակարգերի միջև: Հակիրճ նրա մասին մենք արդեն պատմեց, և այսօր մենք ավելի մանրամասն կանդրադառնանք CSI-ի և Ceph-ի համադրությանը. ցույց կտանք, թե ինչպես լեռ Ceph պահեստ դեպի Կուբերնետես կլաստեր։
Հոդվածը պարունակում է իրական, թեև փոքր-ինչ պարզեցված օրինակներ ընկալման հեշտության համար: Մենք չենք դիտարկում Ceph և Kubernetes կլաստերների տեղադրումն ու կազմաձևումը:

Ձեզ հետաքրքրում է, թե ինչպես է այն աշխատում:

Ceph-ի վրա հիմնված պահեստը Kubernetes կլաստերին միացնելու գործնական օրինակ

Այսպիսով, դուք ձեռքի տակ ունեք Kubernetes կլաստեր, որը տեղակայված է, օրինակ, kubespray. Մոտակայքում աշխատում է Ceph-ի կլաստերը - կարող եք նաև տեղադրել այն, օրինակ, սրա հետ խաղային տետրերի հավաքածու. Հուսով եմ, որ կարիք չկա նշելու, որ արտադրության համար նրանց միջև պետք է լինի առնվազն 10 Գբ/վ թողունակությամբ ցանց։

Եթե ​​ունես այս ամենը, գնանք։

Նախ, եկեք գնանք Ceph կլաստերի հանգույցներից մեկը և ստուգենք, որ ամեն ինչ կարգին է.

ceph health
ceph -s

Հաջորդը, մենք անմիջապես կստեղծենք լողավազան RBD սկավառակների համար.

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

Եկեք գնանք Kubernetes կլաստերին: Այնտեղ, առաջին հերթին, մենք կտեղադրենք 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 ֆայլը: Դա անելու համար մենք պարզում ենք Ceph-ում մոնիտորների կլաստերի ID-ն և IP հասցեները.

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-ում և թույլ տվեք նրան գրել լողավազանին կուբե:

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

Պետք է լրացնել clusterID, որը մենք արդեն տեղեկացել ենք թիմից ceph fsid, և կիրառեք այս մանիֆեստը Kubernetes կլաստերի վրա.

kubectl apply -f storageclass.yaml

Կլաստերների աշխատանքը փաթեթում ստուգելու համար եկեք ստեղծենք հետևյալ PVC-ը (Հաստատուն ծավալի պահանջ).

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

Ամեն ինչ, կարծես, հիանալի է: Իսկ ինչպիսի՞ն է այն Ceph-ի կողմից:
Մենք ստանում ենք լողավազանի հատորների ցանկը և դիտում ենք մեր ծավալի մասին տեղեկությունները.

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

Մենք տեսնում ենք, որ PVC-ի չափը չի փոխվել: Դուք կարող եք Kubernetes-ից խնդրել PVC-ի նկարագրությունը YAML ձևաչափով՝ պարզելու, թե ինչու.

kubectl get pvc rbd-pvc -o yaml

Եվ ահա խնդիրը.

Հաղորդագրություն. Սպասում է, որ օգտատերը (վեր)սկսի պատիճը, որպեսզի ավարտի ֆայլային համակարգի ծավալի չափը հանգույցի վրա: տեսակը՝ FileSystemResizePending

Այսինքն՝ սկավառակն աճել է, իսկ դրա վրա գտնվող ֆայլային համակարգը՝ ոչ։
Ֆայլային համակարգը ընդլայնելու համար անհրաժեշտ է միացնել ձայնը: Մեր դեպքում ստեղծված PVC/PV-ն այժմ ոչ մի կերպ չի օգտագործվում:

Մենք կարող ենք ստեղծել թեստային 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

Եվ հիմա եկեք նայենք PVC-ին.

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

Նկատի ունեցեք, որ մոնիտորի հասցեները նշված են պարզ ձևի հասցե:port: Հոսթի վրա cephfs տեղադրելու համար այս հասցեները փոխանցվում են միջուկի մոդուլին, որը դեռ չգիտի, թե ինչպես աշխատել մոնիտորինգի արձանագրության v2-ի հետ:
Մենք փոխում ենք պորտը httpMetrics-ի համար (Prometheus-ը կգնա այնտեղ՝ մոնիտորինգի չափումների համար), որպեսզի այն չհակասի 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

Լրացրե՛ք այստեղ clusterID և կիրառելի է Kubernetes-ում.

kubectl apply -f storageclass.yaml

Проверка

Ստուգելու համար, ինչպես նախորդ օրինակում, եկեք ստեղծենք PVC.

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

Եվ ստուգեք PVC/PV.

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

Իհարկե, Ceph հանգույցի վրա նման FS տեղադրումը հարմար է միայն ուսումնական նպատակների համար, ինչը մենք անում ենք մեր Անբարենպաստ դասընթացներ. Չեմ կարծում, որ որևէ մեկը դա անի արտադրության մեջ, կարևոր ֆայլերը պատահաբար վերագրանցելու մեծ ռիսկ կա:

Եվ վերջապես, եկեք ստուգենք, թե ինչպես են գործերը աշխատում ծավալի չափափոխման դեպքում CephFS-ի դեպքում: Մենք վերադառնում ենք Kubernetes և խմբագրում ենք մեր մանիֆեստը PVC-ի համար. մենք այնտեղ չափը մեծացնում ենք, օրինակ, մինչև 7Gi:

Կիրառել խմբագրված ֆայլը.

kubectl apply -f pvc.yaml

Տեսնենք, թե ինչպես է փոխվել քվոտան տեղադրված գրացուցակում.

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

Որպեսզի այս հրամանն աշխատի, գուցե անհրաժեշտ լինի տեղադրել փաթեթը attr.

Աչքերը վախենում են, բայց ձեռքերը վախենում են

Արտաքնապես, այս բոլոր կախարդանքները և երկարատև YAML դրսևորումները բարդ են թվում, բայց գործնականում Slurm-ի ուսանողները բավականին արագ են վերաբերվում դրանց:
Այս հոդվածում մենք չենք խորացել վայրի բնության մեջ, դրա համար պաշտոնական փաստաթղթեր կան: Եթե ​​ձեզ հետաքրքրում է Kubernetes կլաստերի միջոցով Ceph պահեստը կարգավորելու մանրամասները, այս հղումները կօգնեն.

Kubernetes-ի ընդհանուր սկզբունքները հատորներով
RBD Փաստաթղթեր
RBD-ի և Kubernetes-ի ինտեգրումը Ceph-ի տեսանկյունից
RBD-ի և Kubernetes-ի ինտեգրումը CSI-ի տեսանկյունից
Ընդհանուր CephFS Փաստաթղթեր
CephFS-ի և Kubernetes-ի ինտեգրումը CSI-ի տեսանկյունից

Դասընթացի վրա Slurm Կուբերնետես բազա Դուք կարող եք մի քայլ առաջ գնալ և իրական հավելված տեղադրել Kubernetes-ում, որը կօգտագործի CephFS-ը որպես ֆայլերի պահեստ: GET/POST հարցումների միջոցով դուք կկարողանաք ֆայլեր փոխանցել և ստանալ դրանք Ceph-ից:

Եվ եթե դուք ավելի շատ հետաքրքրված եք տվյալների պահպանման հարցում, ապա գրանցվեք նոր Ceph դասընթաց. Մինչ բետա թեստն աշխատում է, դասընթացը կարելի է ձեռք բերել զեղչով և ազդել դրա բովանդակության վրա:

Հոդվածի հեղինակ՝ Ալեքսանդր Շվալով, պրակտիկ ինժեներ Սաութբրիջ, հավաստագրված Kubernetes ադմինիստրատոր, Slurm դասընթացների հեղինակ և մշակող:

Source: www.habr.com