Ceph-ზე დაფუძნებული შენახვის კუბერნეტის კლასტერთან დაკავშირების პრაქტიკული მაგალითი

კონტეინერის შენახვის ინტერფეისი (CSI) არის ერთიანი ინტერფეისი Kubernetes-სა და შენახვის სისტემებს შორის. მოკლედ უკვე ვისაუბრეთ განუცხადადა დღეს ჩვენ უფრო დეტალურად განვიხილავთ CSI-სა და Ceph-ის კომბინაციას: ჩვენ ვაჩვენებთ როგორ დააკავშირეთ Ceph საცავი კუბერნეტის კლასტერამდე.
სტატიაში მოცემულია რეალური, თუმცა ოდნავ გამარტივებული მაგალითები აღქმის გასაადვილებლად. ჩვენ არ განვიხილავთ Ceph და Kubernetes კლასტერების დაყენებას და კონფიგურაციას.

გაინტერესებთ როგორ მუშაობს?

ასე რომ, თქვენ გაქვთ Kubernetes კლასტერი თქვენს ხელზე, განლაგებული, მაგალითად, კუბესპრეი. იქვე მუშაობს Ceph კლასტერი - თქვენ ასევე შეგიძლიათ დააინსტალიროთ, მაგალითად, ამით სათამაშო წიგნების ნაკრები. იმედია არ არის საჭირო იმის ხსენება, რომ მათ შორის წარმოებისთვის უნდა არსებობდეს ქსელი მინიმუმ 10 გბიტ/წმ სიჩქარით.

თუ ეს ყველაფერი გაქვს, წავიდეთ!

პირველ რიგში, მოდით გადავიდეთ 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 კლასტერში - სადაც გვჭირდება მომხმარებლის პაროლი:

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

საჭიროა შევსება კლასტერის ID, რაც გუნდმა უკვე ვისწავლეთ ცეფ ფსიდიდა გამოიყენეთ ეს მანიფესტი 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

როგორც ჩანს, ყველაფერი მშვენიერია! რას ჰგავს ეს ცეფის მხარეს?
ჩვენ ვიღებთ აუზში არსებული ტომების ჩამონათვალს და ვუყურებთ ინფორმაციას ჩვენი მოცულობის შესახებ:

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

აი პრობლემა:

შეტყობინება: ელოდება მომხმარებლის (ხელახლა) დაწყებას pod, რათა დაასრულოს ფაილური სისტემის მოცულობის ზომის შეცვლა კვანძზე. ტიპი: 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

გთხოვთ გაითვალისწინოთ, რომ მონიტორის მისამართები მითითებულია მარტივი ფორმით მისამართი:პორტი. კვანძზე cephf-ების დასაყენებლად, ეს მისამართები გადადის ბირთვის მოდულში, რომელმაც ჯერ არ იცის როგორ იმუშაოს 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

შევავსოთ აქ კლასტერის ID და გამოიყენება 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

რასაკვირველია, ცეფის კვანძზე FS-ის დამონტაჟება მხოლოდ სავარჯიშო მიზნებისთვისაა შესაფერისი, რასაც ჩვენ ვაკეთებთ სლუმური კურსები. არა მგონია, ვინმე ამას გააკეთებს წარმოებაში; მნიშვნელოვანი ფაილების შემთხვევით წაშლის მაღალი რისკია.

და ბოლოს, მოდით შევამოწმოთ როგორ მუშაობს ტომების ზომის შეცვლა CephFS-ის შემთხვევაში. მოდით დავუბრუნდეთ Kubernetes-ს და დაარედაქტიროთ ჩვენი მანიფესტი PVC-სთვის - გაზარდეთ ზომა იქ, მაგალითად, 7Gi-მდე.

მოდით გამოვიყენოთ რედაქტირებული ფაილი:

kubectl apply -f pvc.yaml

მოდით შევხედოთ დამონტაჟებულ დირექტორიას, რომ ნახოთ როგორ შეიცვალა კვოტა:

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

იმისათვის, რომ ამ ბრძანებამ იმუშაოს, შეიძლება დაგჭირდეთ პაკეტის დაყენება თქვენს სისტემაში attr.

თვალებს ეშინიათ, მაგრამ ხელებს ეშინიათ

ყველა ეს შელოცვა და გრძელი YAML მანიფესტაციები გარეგნულად რთული ჩანს, მაგრამ პრაქტიკაში, Slurm სტუდენტები მათ საკმაოდ სწრაფად ართმევენ თავს.
ამ სტატიაში ჩვენ არ შევედით ჯუნგლებში ღრმად - ამის ოფიციალური დოკუმენტაცია არსებობს. თუ გაინტერესებთ კუბერნეტის კლასტერთან Ceph შენახვის დაყენების დეტალები, ეს ბმულები დაგეხმარებათ:

კუბერნეტების ტომებთან მუშაობის ზოგადი პრინციპები
RBD დოკუმენტაცია
RBD-ისა და Kubernetes-ის ინტეგრირება ცეფის პერსპექტივიდან
RBD-ისა და Kubernetes-ის ინტეგრირება CSI პერსპექტივიდან
ზოგადი CephFS დოკუმენტაცია
CephFS-ისა და Kubernetes-ის ინტეგრირება CSI პერსპექტივიდან

Slurm კურსზე კუბერნეტის ბაზა შეგიძლიათ ცოტა წინ წახვიდეთ და განათავსოთ რეალური აპლიკაცია Kubernetes-ში, რომელიც გამოიყენებს CephFS-ს ფაილების შესანახად. GET/POST მოთხოვნის საშუალებით თქვენ შეძლებთ ფაილების გადატანას და მათ მიღებას Ceph-ისგან.

და თუ უფრო მეტად გაინტერესებთ მონაცემთა შენახვა, მაშინ დარეგისტრირდით ახალი კურსი Ceph. სანამ ბეტა ტესტი გრძელდება, კურსის მიღება შესაძლებელია ფასდაკლებით და შეგიძლიათ გავლენა მოახდინოთ მის შინაარსზე.

სტატიის ავტორი: ალექსანდრე შვალოვი, პრაქტიკოსი ინჟინერი Southbridge, Kubernetes-ის სერტიფიცირებული ადმინისტრატორი, Slurm კურსების ავტორი და შემქმნელი.

წყარო: www.habr.com