🥇Yandeks.Cloud | uchun Kubernetesda CSI drayverini ishlab chiqish bo'yicha tajribamiz ProHoster

Flant kompaniyasi Kubernetes uchun ochiq manbali vositalarga o‘z hissasini kengaytirayotganini e’lon qilishdan mamnunmiz. CSI drayverining alfa versiyasi Yandex.Cloud uchun (Container Storage Interface).

Amalga oshirish tafsilotlariga o'tishdan oldin, keling, Yandex allaqachon xizmatga ega bo'lsa, nima uchun bu umuman kerak degan savolga javob beraylik Kubernetes uchun boshqariladigan xizmat.

kirish

Nima uchun bu?

Kompaniyamiz doirasida, Kubernetes-ni ishlab chiqarishda qo'llashning boshidanoq (ya'ni, bir necha yillardan beri) biz o'z asbobimizni (deckhouse) ishlab chiqdik, aytmoqchi, biz yaqinda ochiq manba loyihasi sifatida taqdim etishni rejalashtirmoqdamiz. . Uning yordami bilan biz barcha klasterlarimizni bir xilda sozlaymiz va sozlaymiz va hozirda ularning 100 dan ortig'i turli xil apparat konfiguratsiyalarida va barcha mavjud bulut xizmatlarida mavjud.

Deckhouse-dan foydalanadigan klasterlar ishlash uchun zarur bo'lgan barcha komponentlarga ega: balanslashtirgichlar, qulay diagrammalar, o'lchovlar va ogohlantirishlar bilan monitoring, barcha asboblar paneliga kirish uchun tashqi provayderlar orqali foydalanuvchi autentifikatsiyasi va boshqalar. Boshqariladigan yechimda bunday "nasoslangan" klasterni o'rnatishning ma'nosi yo'q, chunki bu ko'pincha imkonsiz yoki komponentlarning yarmini o'chirish zarurligiga olib keladi.

NB: Bu bizning tajribamiz va bu juda aniq. Biz har kimga tayyor echimlardan foydalanish o'rniga Kubernetes klasterlarini mustaqil ravishda joylashtirishni taklif qilmaymiz. Aytgancha, bizda Kubernetes-ni Yandex-dan boshqarishda haqiqiy tajribamiz yo'q va biz ushbu maqolada ushbu xizmatga hech qanday baho bermaymiz.

Bu nima va kim uchun?

Shunday qilib, biz allaqachon Kubernetes-da saqlashga zamonaviy yondashuv haqida gapirgan edik: CSI qanday ishlaydi? и jamiyat qanday paydo bo'ldi bu yondashuvga.

Hozirgi vaqtda ko'plab yirik bulutli xizmat ko'rsatuvchi provayderlar o'zlarining bulutli disklarini Kubernetesda doimiy hajm sifatida ishlatish uchun drayverlarni ishlab chiqdilar. Agar etkazib beruvchida bunday drayver bo'lmasa, lekin barcha kerakli funktsiyalar API orqali ta'minlangan bo'lsa, u holda drayverni o'zingiz amalga oshirishingizga hech narsa to'sqinlik qilmaydi. Bu Yandex.Cloud bilan sodir bo'ldi.

Rivojlanish uchun asos qilib oldik DigitalOcean buluti uchun CSI drayveri va bir nechta fikrlar GCP uchun haydovchilar, chunki bu bulutlarning API bilan o'zaro aloqasi (Google va Yandex) bir qator o'xshashliklarga ega. Xususan, API va GCP, va y Yandeks ob'ektni qaytarish Operation uzoq davom etgan operatsiyalar holatini kuzatish (masalan, yangi disk yaratish). Yandex.Cloud API bilan ishlash uchun foydalaning Yandex.Cloud Go SDK.

Bajarilgan ishlarning natijasi GitHub-da nashr etilgan va ba'zi sabablarga ko'ra Yandex.Cloud virtual mashinalarida (lekin tayyor boshqariladigan klasterda emas) o'zining Kubernetes o'rnatilishidan foydalanadigan va CSI orqali disklardan foydalanishni (buyurtmani) xohlaydiganlar uchun foydali bo'lishi mumkin.

Реализация

Asosiy xususiyatlar

Hozirgi vaqtda drayver quyidagi funktsiyalarni qo'llab-quvvatlaydi:

Klasterdagi tugunlar topologiyasi bo'yicha klasterning barcha zonalarida disklarni buyurtma qilish;
Oldindan buyurtma qilingan disklarni olib tashlash;
Disklar uchun oflayn o'lchamlarni o'zgartirish (Yandex.Cloud qo'llab-quvvatlamang virtual mashinaga o'rnatilgan disklarni ko'paytirish). Iloji boricha og'riqsiz o'lchamlarni o'zgartirish uchun haydovchini qanday o'zgartirish kerakligi haqida ma'lumot olish uchun pastga qarang.

Kelajakda biz diskdagi suratlarni yaratish va o'chirishni qo'llab-quvvatlashni amalga oshirishni rejalashtirmoqdamiz.

Asosiy qiyinchilik va uni qanday engish kerak

Yandex.Cloud API-da real vaqt rejimida disklarni ko'paytirish qobiliyatining yo'qligi PV (Doimiy hajm) uchun o'lchamini o'zgartirish operatsiyasini murakkablashtiradigan cheklovdir: bu holda, diskdan foydalanadigan dastur paneli to'xtatilishi kerak, va bu ishlamay qolgan ilovalarga olib kelishi mumkin.

Shunga ko'ra CSI spetsifikatsiyalari, agar CSI kontrolleri disklar hajmini faqat "oflayn" o'zgartirishi mumkinligi haqida xabar bersa (VolumeExpansion.OFFLINE), keyin diskni ko'paytirish jarayoni quyidagicha bo'lishi kerak:

Agar plagin faqat mavjud bo'lsa VolumeExpansion.OFFLINE kengaytirish qobiliyati va hajmi hozirda nashr etilgan yoki tugunda mavjud ControllerExpandVolume FAQAT quyidagilardan keyin chaqirilishi kerak:

Plaginda boshqaruvchi mavjud PUBLISH_UNPUBLISH_VOLUME qobiliyat va ControllerUnpublishVolume muvaffaqiyatli chaqirildi.
YOKI YANA

Plaginda kontroller YO'Q PUBLISH_UNPUBLISH_VOLUME qobiliyati, plaginda tugun mavjud STAGE_UNSTAGE_VOLUME qobiliyat va NodeUnstageVolume muvaffaqiyatli yakunlandi.
YOKI YANA

Plaginda kontroller YO'Q PUBLISH_UNPUBLISH_VOLUME qobiliyat, na tugun STAGE_UNSTAGE_VOLUME qobiliyat va NodeUnpublishVolume muvaffaqiyatli yakunlandi.

Bu aslida diskni kengaytirishdan oldin uni virtual mashinadan ajratish kerakligini anglatadi.

Biroq, afsuski amalga oshirish Yan avtomobillar orqali CSI spetsifikatsiyasi ushbu talablarga javob bermaydi:

Yon idishda csi-attacher, o'rnatishlar orasidagi kerakli bo'shliq mavjudligi uchun javobgar bo'lishi kerak, bu funksiya oflayn o'lchamda oddiygina amalga oshirilmaydi. Bu haqda munozara boshlandi shu yerda.
Ushbu kontekstda yonbosh konteyneri nima? CSI plaginining o'zi Kubernetes API bilan o'zaro ta'sir qilmaydi, lekin faqat yonbosh konteynerlari tomonidan yuborilgan gRPC qo'ng'iroqlariga javob beradi. Oxirgi ishlab chiqilmoqda Kubernetes jamoasi tomonidan.

Bizning holatda (CSI plagini), diskni ko'paytirish jarayoni quyidagicha ko'rinadi:

Biz gRPC chaqiruvini qabul qilamiz ControllerExpandVolume;
Biz API-da diskni ko'paytirishga harakat qilmoqdamiz, lekin disk o'rnatilganligi sababli operatsiyani bajarishning mumkin emasligi haqida xatolik qabul qilamiz;
Biz disk identifikatorini xaritada saqlaymiz, unda oshirish operatsiyasi bajarilishi kerak bo'lgan disklar mavjud. Quyida, qisqalik uchun biz ushbu xaritani shunday deb ataymiz volumeResizeRequired;
Diskdan foydalanayotgan podani qo'lda olib tashlang. Kubernetes uni qayta ishga tushiradi. Diskni o'rnatishga vaqti yo'qligi uchun (ControllerPublishVolume) o'rnatishga urinayotganda oshirish operatsiyasini bajarishdan oldin, biz berilgan diskning hali ham ichida ekanligini tekshiramiz volumeResizeRequired va xatoni qaytaring;
CSI drayveri o'lchamini o'zgartirish operatsiyasini qayta bajarishga harakat qiladi. Agar operatsiya muvaffaqiyatli bo'lsa, diskni olib tashlang volumeResizeRequired;
Chunki Disk identifikatori mavjud emas volumeResizeRequired, ControllerPublishVolume muvaffaqiyatli o'tadi, disk o'rnatiladi, pod ishga tushadi.

Hamma narsa etarlicha sodda ko'rinadi, lekin har doimgidek tuzoqlar mavjud. Disklarni kattalashtiradi tashqi reizer, bu operatsiya davomida xatolik yuz berganda navbatdan foydalanadi kutish vaqtining 1000 soniyagacha bo'lgan eksponensial o'sishi bilan:

func DefaultControllerRateLimiter() RateLimiter {
  return NewMaxOfRateLimiter(
  NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),
  // 10 qps, 100 bucket size.  This is only for retry speed and its only the overall factor (not per item)
  &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
  )
}

Bu vaqti-vaqti bilan diskni kengaytirish operatsiyasining 15+ daqiqaga uzaytirilishiga olib kelishi mumkin va shuning uchun tegishli podkast mavjud bo'lmaydi.

Potentsial ishlamay qolish vaqtini kamaytirishga juda oson va og'riqsiz imkon beradigan yagona variant bu bizning tashqi resizer versiyamizdan maksimal kutish vaqti chegarasidan foydalanish edi. 5 soniyada:

workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)

Biz munozarani zudlik bilan boshlash va tashqi resizerni tuzatishni zarur deb hisoblamadik, chunki disklarning oflayn o'lchamini o'zgartirish tez orada barcha bulut provayderlarida yo'q bo'lib ketadigan orqaga qaytishdir.

Uni ishlatishni qanday boshlash kerak?

Drayv Kubernetes 1.15 va undan yuqori versiyalarida qo'llab-quvvatlanadi. Haydovchi ishlashi uchun quyidagi talablar bajarilishi kerak:

Bayroq --allow-privileged qiymatga sozlang true API server va kubelet uchun;
Kiritilgan --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true API server va kubelet uchun;
Tog'ning tarqalishi (tog'ning tarqalishi) klasterda yoqilgan bo'lishi kerak. Docker-dan foydalanilganda, demon umumiy ulanishlarga ruxsat berish uchun sozlanishi kerak.

O'rnatishning o'zi uchun barcha kerakli qadamlar README da tasvirlangan. O'rnatish manifestlardan Kubernetesda ob'ektlar yaratishni o'z ichiga oladi.

Haydovchi ishlashi uchun sizga quyidagilar kerak bo'ladi:

Manifestda katalog identifikatorini belgilang (folder-id) Yandex.Cloud (hujjatlarga qarang);
Yandex.Cloud API bilan ishlash uchun CSI drayveri xizmat hisobidan foydalanadi. Manifestda Secret o'tkazilishi kerak vakolatli kalitlar xizmat hisobidan. Hujjatlarda tasvirlangan, xizmat qaydnomasini qanday yaratish va kalitlarni olish.

Umuman - harakat qilib ko'ring, va biz fikr-mulohazalarni qabul qilishdan xursand bo'lamiz va yangi masalalarhar qanday muammoga duch kelsangiz!

Qo'shimcha yordam

Natijada shuni ta'kidlashni istardikki, biz ushbu CSI drayverini Go'da qiziqarli ilovalar yozish istagidan emas, balki kompaniya ichidagi favqulodda ehtiyoj tufayli amalga oshirdik. O'zimizni amalga oshirishni davom ettirish biz uchun amaliy ko'rinmaydi, shuning uchun agar Yandex qiziqish bildirsa va haydovchini qo'llab-quvvatlashni davom ettirishga qaror qilsa, biz ularga omborni o'tkazishdan mamnun bo'lamiz.

Bundan tashqari, Yandex o'zining boshqariladigan Kubernetes klasterida Ochiq manbada chiqarilishi mumkin bo'lgan CSI drayverini o'z dasturiga ega. Shuningdek, biz ushbu ishlab chiqish variantini qulay deb bilamiz - jamoa uchinchi tomon kompaniyasidan emas, balki xizmat ko'rsatuvchi provayderning tasdiqlangan drayveridan foydalanishi mumkin.