🥇Satu contoh praktikal menyambungkan storan berasaskan Ceph kepada gugusan Kubernetes

Antara Muka Penyimpanan Kontena (CSI) ialah antara muka bersatu antara Kubernetes dan sistem storan. Kami telah membincangkannya secara ringkas memberitahu, dan hari ini kita akan melihat dengan lebih dekat gabungan CSI dan Ceph: kita akan tunjukkan caranya sambung storan Ceph kepada gugusan Kubernetes.
Artikel itu menyediakan contoh sebenar, walaupun sedikit dipermudahkan untuk memudahkan persepsi. Kami tidak mempertimbangkan untuk memasang dan mengkonfigurasi kelompok Ceph dan Kubernetes.

Adakah anda tertanya-tanya bagaimana ia berfungsi?

Jadi, anda mempunyai kluster Kubernetes di hujung jari anda, digunakan, sebagai contoh, kubespray. Terdapat kluster Ceph yang berfungsi berdekatan - anda juga boleh memasangnya, sebagai contoh, dengan ini satu set buku permainan. Saya berharap tidak perlu menyebut bahawa untuk pengeluaran antara mereka mesti ada rangkaian dengan lebar jalur sekurang-kurangnya 10 Gbit/s.

Jika anda mempunyai semua ini, mari pergi!

Mula-mula, mari pergi ke salah satu nod kluster Ceph dan periksa sama ada semuanya teratur:

ceph health
ceph -s

Seterusnya, kami akan segera mencipta kumpulan untuk cakera RBD:

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

Mari kita beralih ke kelompok Kubernetes. Di sana, pertama sekali, kami akan memasang pemacu Ceph CSI untuk RBD. Kami akan memasang, seperti yang dijangkakan, melalui Helm.
Kami menambah repositori dengan carta, kami mendapat satu set pembolehubah untuk carta ceph-csi-rbd:

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

Sekarang anda perlu mengisi fail cephrbd.yml. Untuk melakukan ini, ketahui ID kluster dan alamat IP monitor dalam Ceph:

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

Kami memasukkan nilai yang diperoleh ke dalam fail cephrbd.yml. Pada masa yang sama, kami membolehkan penciptaan dasar PSP (Dasar Keselamatan Pod). Pilihan dalam bahagian nodeplugin и pemberi rezeki sudah ada dalam fail, ia boleh diperbetulkan seperti yang ditunjukkan di bawah:

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

Seterusnya, semua yang tinggal untuk kami ialah memasang carta dalam kelompok Kubernetes.

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

Hebat, pemandu RBD berfungsi!
Mari buat StorageClass baharu dalam Kubernetes. Ini sekali lagi memerlukan sedikit bermain-main dengan Ceph.

Kami mencipta pengguna baharu dalam Ceph dan memberinya hak untuk menulis kepada kumpulan kiub:

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

Sekarang mari lihat kunci akses masih ada:

ceph auth get-key client.rbdkube

Perintah akan mengeluarkan sesuatu seperti ini:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Mari tambah nilai ini pada Rahsia dalam kelompok Kubernetes - di mana kita memerlukannya userKey:

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

Dan kami mencipta rahsia kami:

kubectl apply -f secret.yaml

Seterusnya, kami memerlukan manifes StorageClass seperti ini:

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

Perlu diisi clusterID, yang telah kami pelajari oleh pasukan ceph fsid, dan gunakan manifes ini pada gugusan Kubernetes:

kubectl apply -f storageclass.yaml

Untuk menyemak cara kluster berfungsi bersama, mari buat PVC (Tuntutan Volume Berterusan):

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

Mari kita lihat dengan segera cara Kubernetes mencipta volum yang diminta dalam Ceph:

kubectl get pvc
kubectl get pv

Semuanya nampak hebat! Apakah rupa ini di sebelah Ceph?
Kami mendapat senarai volum dalam kumpulan dan melihat maklumat tentang volum kami:

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

Sekarang mari kita lihat cara mengubah saiz volum RBD berfungsi.
Tukar saiz volum dalam manifes pvc.yaml kepada 2Gi dan gunakannya:

kubectl apply -f pvc.yaml

Mari tunggu perubahan itu berkuat kuasa dan lihat saiz kelantangan semula.

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

kubectl get pv
kubectl get pvc

Kami melihat bahawa saiz PVC tidak berubah. Untuk mengetahui sebabnya, anda boleh menanyakan Kubernetes untuk penerangan YAML PVC:

kubectl get pvc rbd-pvc -o yaml

Inilah masalahnya:

mesej: Menunggu pengguna untuk (semula) memulakan pod untuk menyelesaikan saiz semula sistem fail volum pada nod. jenis: FileSystemResizePending

Iaitu, cakera telah berkembang, tetapi sistem fail di atasnya tidak.
Untuk mengembangkan sistem fail, anda perlu melekapkan kelantangan. Di negara kita, PVC/PV yang dicipta pada masa ini tidak digunakan dalam apa jua cara.

Kita boleh membuat Pod ujian, contohnya seperti ini:

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

Dan sekarang mari kita lihat PVC:

kubectl get pvc

Saiz telah berubah, semuanya baik-baik saja.

Pada bahagian pertama, kami bekerja dengan peranti blok RBD (ia bermaksud Rados Block Device), tetapi ini tidak boleh dilakukan jika perkhidmatan mikro yang berbeza perlu berfungsi dengan cakera ini secara serentak. CephFS adalah lebih sesuai untuk bekerja dengan fail berbanding imej cakera.
Menggunakan contoh kelompok Ceph dan Kubernetes, kami akan mengkonfigurasi CSI dan entiti lain yang diperlukan untuk bekerja dengan CephFS.

Mari dapatkan nilai daripada carta Helm baharu yang kami perlukan:

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

Sekali lagi anda perlu mengisi fail cephfs.yml. Seperti sebelum ini, arahan Ceph akan membantu:

ceph fsid
ceph mon dump

Isi fail dengan nilai seperti ini:

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

Sila ambil perhatian bahawa alamat monitor dinyatakan dalam borang mudah address:port. Untuk melekapkan cephfs pada nod, alamat ini dipindahkan ke modul kernel, yang belum tahu cara berfungsi dengan protokol monitor v2.
Kami menukar port untuk httpMetrics (Prometheus akan pergi ke sana untuk memantau metrik) supaya ia tidak bercanggah dengan nginx-proxy, yang dipasang oleh Kubespray. Anda mungkin tidak memerlukan ini.

Pasang carta Helm dalam kelompok Kubernetes:

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

Mari pergi ke stor data Ceph untuk membuat pengguna berasingan di sana. Dokumentasi menyatakan bahawa penyedia CephFS memerlukan hak akses pentadbir kluster. Tetapi kami akan membuat pengguna yang berasingan fs dengan hak terhad:

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'

Dan mari kita segera melihat kunci aksesnya, kita akan memerlukannya kemudian:

ceph auth get-key client.fs

Mari buat Secret dan StorageClass yang berasingan.
Tiada yang baru, kami telah melihat ini dalam contoh RBD:

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

Menggunakan manifes:

kubectl apply -f secret.yaml

Dan sekarang - StorageClass yang berasingan:

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

Jom isi di sini clusterID dan terpakai dalam Kubernetes:

kubectl apply -f storageclass.yaml

Проверка

Untuk menyemak, seperti dalam contoh sebelumnya, mari buat PVC:

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

Dan semak kehadiran PVC/PV:

kubectl get pvc
kubectl get pv

Jika anda ingin melihat fail dan direktori dalam CephFS, anda boleh memasang sistem fail ini di suatu tempat. Contohnya seperti yang ditunjukkan di bawah.

Mari pergi ke salah satu nod kluster Ceph dan lakukan tindakan berikut:

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

Sudah tentu, pemasangan FS pada nod Ceph seperti ini hanya sesuai untuk tujuan latihan, iaitu apa yang kami lakukan pada Kursus Slurm. Saya tidak fikir sesiapa akan melakukan ini dalam pengeluaran; terdapat risiko tinggi untuk memadam fail penting secara tidak sengaja.

Dan akhirnya, mari kita semak cara perkara berfungsi dengan mengubah saiz volum dalam kes CephFS. Mari kembali ke Kubernetes dan edit manifes kami untuk PVC - tingkatkan saiz di sana, sebagai contoh, kepada 7Gi.

Mari gunakan fail yang diedit:

kubectl apply -f pvc.yaml

Mari lihat direktori yang dipasang untuk melihat cara kuota telah berubah:

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

Untuk arahan ini berfungsi, anda mungkin perlu memasang pakej pada sistem anda attr.

Mata takut, tetapi tangan takut

Semua mantera dan manifes YAML yang panjang ini kelihatan rumit di permukaan, tetapi dalam praktiknya, pelajar Slurm memahaminya dengan cepat.
Dalam artikel ini kami tidak pergi jauh ke dalam hutan - terdapat dokumentasi rasmi untuk itu. Jika anda berminat dengan butiran menyediakan storan Ceph dengan kluster Kubernetes, pautan ini akan membantu:

Prinsip umum Kubernetes bekerja dengan jilid
Dokumentasi RBD
Mengintegrasikan RBD dan Kubernetes dari perspektif Ceph
Mengintegrasikan RBD dan Kubernetes dari perspektif CSI
Dokumentasi Am CephFS
Mengintegrasikan CephFS dan Kubernetes dari perspektif CSI

Pada kursus Slurm Pangkalan Kubernetes anda boleh pergi lebih jauh dan menggunakan aplikasi sebenar dalam Kubernetes yang akan menggunakan CephFS sebagai storan fail. Melalui permintaan GET/POST anda akan dapat memindahkan fail ke dan menerimanya daripada Ceph.

Dan jika anda lebih berminat dengan storan data, maka daftarlah kursus baru tentang Ceph. Semasa ujian beta sedang berjalan, kursus ini boleh diperolehi pada harga diskaun dan anda boleh mempengaruhi kandungannya.

Pengarang artikel: Alexander Shvalov, jurutera yang berlatih Southbridge, Pentadbir Kubernetes Bertauliah, pengarang dan pembangun kursus Slurm.

Sumber: www.habr.com

Contoh praktikal untuk menyambungkan storan berasaskan Ceph kepada gugusan Kubernetes

Проверка

Mata takut, tetapi tangan takut