Kubernetes klasterida ma'lumotlarni saqlash

Kubernetes klasterida ishlaydigan ilovalar uchun ma'lumotlarni saqlashni sozlashning bir necha yo'li mavjud. Ulardan ba'zilari allaqachon eskirgan, boshqalari esa yaqinda paydo bo'lgan. Ushbu maqolada biz saqlash tizimlarini ulashning uchta varianti kontseptsiyasini ko'rib chiqamiz, shu jumladan eng so'nggisi - Konteynerni saqlash interfeysi orqali ulanish.

Kubernetes klasterida ma'lumotlarni saqlash

1-usul: pod manifestida PV ni belgilang

Kubernetes klasteridagi podani tavsiflovchi odatiy manifest:

Kubernetes klasterida ma'lumotlarni saqlash

Manifestning qaysi jild ulanganligi va qayerda ekanligini tavsiflovchi qismlari rang bilan ajratilgan.

bo'lim O'rnatish hajmi o'rnatish nuqtalarini (mountPath) ko'rsating - doimiy hajm konteyner ichidagi qaysi katalogga o'rnatiladi, shuningdek jildning nomi.

bo'lim x podda ishlatiladigan barcha jildlarni sanab o'tadi. Har bir jildning nomini, shuningdek turini (bizning holatda: awsElasticBlockStore) va ulanish parametrlarini belgilang. Manifestda qaysi parametrlar ko'rsatilganligi tovush turiga bog'liq.

Xuddi shu hajm bir vaqtning o'zida bir nechta pod konteynerlariga o'rnatilishi mumkin. Shunday qilib, turli xil dastur jarayonlari bir xil ma'lumotlarga kirishlari mumkin.

Ushbu ulanish usuli eng boshida, Kubernetes endigina go'daklik davrida ixtiro qilingan va bugungi kunda bu usul eskirgan.

Uni ishlatishda bir nechta muammolar mavjud:

  1. barcha jildlar qo'lda yaratilishi kerak; Kubernetes biz uchun hech narsa yarata olmaydi;
  2. har bir jild uchun kirish parametrlari noyobdir va ular hajmdan foydalanadigan barcha podslarning manifestlarida ko'rsatilishi kerak;
  3. saqlash tizimini o'zgartirish uchun (masalan, AWS-dan Google Cloud-ga o'tish), barcha manifestlarda o'rnatilgan hajmlarning sozlamalari va turini o'zgartirishingiz kerak.

Bularning barchasi juda noqulay, shuning uchun aslida bu usul faqat ba'zi maxsus hajm turlarini ulash uchun ishlatiladi: configMap, secret, emptyDir, hostPath:

  • configMap va secret - bu konteynerdagi Kubernetes manifestlaridan fayllar bilan jild yaratish imkonini beruvchi xizmat hajmlari.

  • emptyDir - bu vaqtinchalik hajm bo'lib, faqat podning ishlash muddati uchun yaratilgan. Sinov yoki vaqtinchalik ma'lumotlarni saqlash uchun foydalanish uchun qulay. Pod o'chirilganda, emptyDir hajmi ham o'chiriladi va barcha ma'lumotlar yo'qoladi.

  • hostPath - har qanday katalogni, shu jumladan /etc/kubernetes ilovasi bilan konteyner ichida dastur ishlayotgan serverning mahalliy diskiga o'rnatish imkonini beradi. Bu xavfli xususiyat, shuning uchun xavfsizlik siyosati odatda bunday turdagi hajmlardan foydalanishni taqiqlaydi. Aks holda, tajovuzkor ilovasi HTC Kubernetes katalogini o‘z konteyneriga o‘rnatishi va barcha klaster sertifikatlarini o‘g‘irlashi mumkin bo‘ladi. Odatda, hostPath jildlaridan faqat kube tizimi nom maydonida ishlaydigan tizim ilovalari tomonidan foydalanishga ruxsat beriladi.

Kubernetes qutidan tashqarida ishlaydigan saqlash tizimlari hujjatlarda keltirilgan.

Usul 2. SC/PVC/PV o'choqlariga ulanish

Muqobil ulanish usuli - bu Storage klassi, PersistentVolumeClaim, PersistentVolume tushunchasi.

Saqlash klassi ma'lumotlarni saqlash tizimiga ulanish parametrlarini saqlaydi.

Doimiy Volume da'vosi ilovaga kerak bo'lgan talablarni tavsiflaydi.
Doimiy hajm kirish parametrlari va ovoz balandligi holatini saqlaydi.

G'oyaning mohiyati: pod manifestida ular PersistentVolumeClaim tipidagi hajmni ko'rsatadi va claimName parametrida ushbu ob'ekt nomini ko'rsatadi.

Kubernetes klasterida ma'lumotlarni saqlash

PersistentVolumeClaim manifesti ilova talab qiladigan ma'lumotlar hajmiga qo'yiladigan talablarni tavsiflaydi. Shu jumladan:

  • disk hajmi;
  • kirish usuli: ReadWriteOnce yoki ReadWriteMany;
  • Saqlash sinfiga havola - biz qaysi ma'lumotlarni saqlash tizimida hajmni yaratmoqchimiz.

Saqlash klassi manifestida saqlash tizimiga ulanish turi va parametrlari saqlanadi. Kubelet ularning tuguniga ovoz balandligini o'rnatish uchun kerak.

PersistentVolume manifestlari ma'lum hajm uchun (tom identifikatori, yo'l va boshqalar) Saqlash sinfi va kirish parametrlarini ko'rsatadi.

PVX yaratishda Kubernetes qaysi hajm hajmi va qaysi saqlash sinfi talab qilinishini ko'rib chiqadi va bepul PersistentVolume ni tanlaydi.

Agar bunday PV mavjud bo'lmasa, Kubernetes maxsus dasturni ishga tushirishi mumkin - Provayder (uning nomi Storage sinfida ko'rsatilgan). Ushbu dastur saqlash tizimiga ulanadi, kerakli hajmdagi hajmni yaratadi, identifikatorni oladi va PersistentVolumeClaim bilan bog'langan Kubernetes klasterida PersistentVolume manifestini yaratadi.

Bu barcha abstraktsiyalar to'plami ilova qaysi saqlash tizimi bilan ishlayotganligi haqidagi ma'lumotlarni dastur manifest darajasidan ma'muriyat darajasiga olib tashlash imkonini beradi.

Ma'lumotlarni saqlash tizimiga ulanish uchun barcha parametrlar Storage sinfida joylashgan bo'lib, ular uchun klaster ma'murlari javobgardir. AWS-dan Google Cloud-ga o'tishda qilishingiz kerak bo'lgan yagona narsa dastur manifestlarida Storage sinfi nomini PVX ga o'zgartirishdir. Ma'lumotlarni saqlash uchun Persistans hajmi Provisioner dasturi yordamida avtomatik ravishda klasterda yaratiladi.

3-usul: Konteynerni saqlash interfeysi

Turli xil saqlash tizimlari bilan o'zaro aloqada bo'lgan barcha kodlar Kubernetes yadrosining bir qismidir. Xatolarni tuzatish yoki yangi funksiyalarning chiqarilishi yangi versiyalar bilan bog'liq; kod Kubernetesning barcha qo'llab-quvvatlanadigan versiyalari uchun o'zgartirilishi kerak. Bularning barchasini saqlab qolish va yangi funksiyalarni qo'shish qiyin.

Muammoni hal qilish uchun Cloud Foundry, Kubernetes, Mesos va Docker ishlab chiqaruvchilari Konteynerlarni saqlash interfeysini (CSI) yaratdilar - bu konteynerlarni boshqarish tizimining o'zaro ta'sirini tavsiflovchi oddiy birlashtirilgan interfeys va ma'lum bir qurilma bilan ishlaydigan maxsus drayver (CSI Driver). saqlash tizimi. Saqlash tizimlari bilan o'zaro ishlash uchun barcha kodlar Kubernetes yadrosidan alohida tizimga ko'chirildi.

Konteynerni saqlash interfeysi hujjatlari.

Odatda, CSI Driver ikkita komponentdan iborat: Node Plugin va Controller plaginlari.

Node Plugin har bir tugunda ishlaydi va hajmlarni o'rnatish va ular ustida operatsiyalarni bajarish uchun javobgardir. Controller plagini saqlash tizimi bilan o'zaro ta'sir qiladi: hajmlarni yaratadi yoki o'chiradi, kirish huquqlarini tayinlaydi va hokazo.

Hozircha eski drayverlar Kubernetes yadrosida qolmoqda, ammo ulardan foydalanish tavsiya etilmaydi va har kimga CSI drayverini ular ishlaydigan tizim uchun maxsus o'rnatish tavsiya etiladi.

Yangilik Storage klassi orqali ma'lumotlarni saqlashni o'rnatishga odatlanganlarni qo'rqitishi mumkin, ammo aslida hech qanday dahshatli narsa yuz bermadi. Dasturchilar uchun aslida hech narsa o'zgarmaydi - ular faqat Storage klassi nomi bilan ishlagan va shunday qilishda davom etadi. Administratorlar uchun rul chartini o'rnatish qo'shildi va sozlamalar tuzilishi o'zgartirildi. Agar ilgari sozlamalar to'g'ridan-to'g'ri Storage sinfiga kiritilgan bo'lsa, endi ular avval rul jadvalida, keyin esa Storage sinfida o'rnatilishi kerak. Agar qarasangiz, hech qanday yomon narsa bo'lmagan.

Keling, CSI drayveridan foydalangan holda Ceph saqlash tizimlariga ulanishga o'tish orqali olishingiz mumkin bo'lgan imtiyozlarni ko'rib chiqish uchun misol keltiraylik.

Ceph bilan ishlashda CSI plagini o'rnatilgan drayverlarga qaraganda saqlash tizimlari bilan ishlash uchun ko'proq imkoniyatlarni taqdim etadi.

  1. Dinamik disk yaratish. Odatda RBD disklari faqat RWO rejimida ishlatiladi, lekin CSI for Ceph ularni RWX rejimida ishlatishga imkon beradi. Turli tugunlardagi bir nechta pods bir xil RDB diskini o'z tugunlariga o'rnatishi va ular bilan parallel ravishda ishlashi mumkin. Rostini aytsam, hamma narsa unchalik yorqin emas - bu disk faqat blokli qurilma sifatida ulanishi mumkin, ya'ni siz dasturni u bilan bir nechta kirish rejimida ishlashga moslashingiz kerak bo'ladi.
  2. Snapshotlar yaratish. Kubernetes klasterida siz suratni yaratish talabi bilan manifest yaratishingiz mumkin. CSI plagini uni ko'radi va diskdan suratga oladi. Unga asoslanib, siz PersistentVolume-ning zaxira nusxasini yoki nusxasini yaratishingiz mumkin.
  3. Disk hajmini oshirish Kubernetes klasteridagi saqlash va PersistentVolume haqida.
  4. Kvotalar. Kubernetes-ga o'rnatilgan CephFS drayverlari kvotalarni qo'llab-quvvatlamaydi, ammo so'nggi Ceph Nautilus bilan yangi CSI plaginlari CephFS bo'limlarida kvotalarni yoqishi mumkin.
  5. Ko'rsatkichlar. CSI plagini Prometeyga qaysi hajmlar ulanganligi, qanday aloqalar sodir bo'layotgani va hokazolar haqida turli ko'rsatkichlarni taqdim etishi mumkin.
  6. Topologiyadan xabardor. Manifestlarda klaster geografik jihatdan qanday taqsimlanganligini ko'rsatish va Amsterdamda joylashgan saqlash tizimini Londonda ishlaydigan podslarga ulashdan qochish imkonini beradi.

Cephni CSI orqali Kubernetes klasteriga qanday ulash mumkin, qarang Slurm kechki maktab ma'ruzasining amaliy qismida. Siz ham obuna bo'lishingiz mumkin Ceph video kurs, 15 oktyabrda ishga tushadi.

Maqola muallifi: Sergey Bondarev, Southbridge me'mori, sertifikatlangan Kubernetes administratori, kubesprayni ishlab chiquvchilardan biri.

Bir oz Post Scriptum reklama uchun emas, balki foyda uchun...

PS Sergey Bondarev ikkita intensiv kursni olib boradi: yangilangan Kubernetes bazasi 28-30 sentyabr va yuqori Kubernetes Mega 14–16 oktyabr.

Kubernetes klasterida ma'lumotlarni saqlash

Manba: www.habr.com

a Izoh qo'shish