Kubernetes uchun eng mashhur paket menejeri haqidagi hikoyaning mohiyatini emoji yordamida tasvirlash mumkin:
- quti Helm (bu so'nggi Emoji nashriga eng yaqin narsa);
- qulf - xavfsizlik;
- Kichkina odam - bu muammoning echimi.
Aslida, hamma narsa biroz murakkabroq bo'ladi va hikoya texnik tafsilotlarga to'la Helmni qanday xavfsiz qilish kerak.
- Agar bilmasangiz yoki unutgan bo'lsangiz, Helm nima ekanligini qisqacha aytib bering. U qanday muammolarni hal qiladi va u ekotizimda qayerda joylashgan.
- Keling, Helm arxitekturasini ko'rib chiqaylik. Xavfsizlik va vosita yoki yechimni qanday qilib xavfsizroq qilish haqida hech qanday suhbat komponent arxitekturasini tushunmasdan to'liq emas.
- Keling, Helm komponentlarini muhokama qilaylik.
- Eng dolzarb savol kelajak - Helm 3 ning yangi versiyasi.
Ushbu maqoladagi hamma narsa Helm 2 uchun amal qiladi. Ushbu versiya hozirda ishlab chiqarilmoqda va siz hozir foydalanayotgan versiya bo'lib, u xavfsizlik xavflarini o'z ichiga olgan versiyadir.
Spiker haqida: Aleksandr Xayorov () 10 yildan beri rivojlanib, kontentni yaxshilashga yordam beradi va komissiyaga a'zo bo'ldi . Hozir u Chainstack’da rivojlanish bo‘yicha yetakchi sifatida ishlaydi – bu ishlab chiqish menejeri va yakuniy nashrlarni yetkazib berish uchun mas’ul shaxs o‘rtasidagi gibriddir. Ya'ni, u jang maydonida joylashgan bo'lib, u erda hamma narsa mahsulot yaratishdan tortib, uning ishlashigacha sodir bo'ladi.
Chainstack - bu kichik, faol rivojlanayotgan startap bo'lib, uning vazifasi mijozlarga markazlashmagan ilovalarning infratuzilmasi va murakkabliklarini unutish imkonini berishdir; ishlab chiqish guruhi Singapurda joylashgan. Chainstack-dan kriptovalyutalarni sotish yoki sotib olishni so'ramang, balki korporativ blokcheyn ramkalar haqida gapirishni taklif qiling va ular sizga mamnuniyat bilan javob berishadi.
dubulg'a
Bu Kubernetes uchun paket (diagramma) menejeri. Kubernetes klasteriga ilovalarni olib kirishning eng intuitiv va universal usuli.
Biz, albatta, o'z YAML manifestlarini yaratish va kichik yordamchi dasturlarni yozishdan ko'ra ko'proq tarkibiy va sanoat yondashuvi haqida gapiramiz.
Helm hozirda mavjud va mashhur bo'lgan eng yaxshisidir.
Nega Helm? Avvalo, chunki u CNCF tomonidan qo'llab-quvvatlanadi. Cloud Native yirik tashkilot bo‘lib, Kubernetes, etcd, Fluentd va boshqalar loyihalari uchun bosh kompaniya hisoblanadi.
Yana bir muhim fakt shundaki, Helm juda mashhur loyihadir. 2019 yil yanvar oyida Helm-ni qanday xavfsiz qilish haqida gapira boshlaganimda, loyiha GitHub-da mingta yulduzga ega edi. May oyiga kelib ularning soni 12 mingga yetdi.
Ko'pchilik Helm bilan qiziqadi, shuning uchun siz uni hali ishlatmagan bo'lsangiz ham, uning xavfsizligi haqida bilish sizga foyda keltiradi. Xavfsizlik muhim.
Asosiy Helm jamoasi Microsoft Azure tomonidan qo'llab-quvvatlanadi va shuning uchun boshqalardan farqli o'laroq, juda barqaror loyihadir. Iyul oyi o'rtalarida Helm 3 Alpha 2-ning chiqarilishi loyihada juda ko'p odamlar ishlayotganligini va ular Helm-ni rivojlantirish va yaxshilashga intilish va kuchga ega ekanligini ko'rsatadi.
Helm Kubernetes-da ilovalarni boshqarishning bir nechta asosiy muammolarini hal qiladi.
- Ilova qadoqlash. Hatto WordPress-dagi "Salom, Dunyo" kabi dastur allaqachon bir nechta xizmatlardan iborat va siz ularni bir joyga to'plashni xohlaysiz.
- Ushbu ilovalarni boshqarish bilan birga keladigan murakkablikni boshqarish.
- Ilova o'rnatilgan yoki o'rnatilgandan keyin tugamaydigan hayot aylanishi. U yashashda davom etmoqda, uni yangilash kerak va Helm bunga yordam beradi va buning uchun to'g'ri choralar va siyosatlarni olib borishga harakat qiladi.
Qoplash u aniq tarzda tashkil etilgan: Linux, Windows yoki MacOS uchun oddiy paket menejeri ishiga to'liq mos keladigan metama'lumotlar mavjud. Ya'ni, ombor, turli paketlarga bog'liqliklar, ilovalar uchun meta-ma'lumotlar, sozlamalar, konfiguratsiya xususiyatlari, ma'lumotlarni indekslash va boshqalar. Helm bularning barchasini ilovalar uchun olish va ishlatish imkonini beradi.
Murakkablikni boshqarish. Agar sizda bir xil turdagi ko'plab ilovalar mavjud bo'lsa, u holda parametrlashtirish kerak. Shablonlar shundan kelib chiqadi, lekin shablonlarni yaratishning o'ziga xos usulini o'ylab topmaslik uchun siz Helm taklif qilgan narsadan foydalanishingiz mumkin.
Ilovaning hayot aylanishini boshqarish - menimcha, bu eng qiziqarli va hal qilinmagan savol. Shuning uchun men o'sha kuni Helmga keldim. Biz dasturning hayot aylanishini kuzatishimiz kerak edi va CI/CD va dastur davrlarimizni ushbu paradigmaga o'tkazmoqchi edik.
Helm sizga quyidagilarga imkon beradi:
- joylashtirishni boshqarish, konfiguratsiya va qayta ko'rib chiqish tushunchasini kiritadi;
- orqaga qaytarishni muvaffaqiyatli amalga oshirish;
- turli hodisalar uchun kancalardan foydalaning;
- qo'shimcha ilovalar tekshiruvlarini qo'shing va ularning natijalariga javob bering.
Bundan tashqari Rulda "batareyalar" bor - hayotingizni soddalashtiradigan plaginlar ko'rinishiga kiritilishi mumkin bo'lgan juda ko'p mazali narsalar. Plaginlar mustaqil ravishda yozilishi mumkin, ular juda izolyatsiya qilingan va uyg'un arxitekturani talab qilmaydi. Agar biror narsani amalga oshirmoqchi bo'lsangiz, men uni plagin sifatida qilishni va keyin uni yuqori oqimga qo'shishni tavsiya qilaman.
Helm uchta asosiy tushunchaga asoslanadi:
- Chart Repo — manifestingiz uchun mumkin bo'lgan parametrlar tavsifi va massivi.
- config -ya'ni, qo'llaniladigan qiymatlar (matn, raqamli qiymatlar va boshqalar).
- ozod qilish ikkita yuqori komponentni to'playdi va ular birgalikda Releasega aylanadi. Relizlar versiyalar bo'lishi mumkin, shu bilan uyushgan hayot aylanishiga erishiladi: o'rnatish vaqtida kichik va yangilash, pasaytirish yoki orqaga qaytarish vaqtida katta.
Rul arxitekturasi
Diagramma kontseptual ravishda Helmning yuqori darajadagi arxitekturasini tasvirlaydi.
Sizga eslatib o'tamanki, Helm Kubernetes bilan bog'liq bo'lgan narsadir. Shuning uchun biz Kubernetes klasterisiz (to'rtburchaklar) qilolmaymiz. kube-apiserver komponenti masterda joylashgan. Helmsiz bizda Kubeconfig mavjud. Helm bitta kichik binarni olib keladi, agar shunday deb atash mumkin bo'lsa, Helm CLI yordam dasturi, u kompyuterda, noutbukda, asosiy kompyuterda - har qanday narsada o'rnatiladi.
Lekin bu yetarli emas. Helm-da Tiller deb nomlangan server komponenti mavjud. U Helmning klasterdagi manfaatlarini ifodalaydi; bu boshqa har qanday dastur kabi Kubernetes klasteridagi ilovadir.
Chart Repo ning navbatdagi komponenti - bu diagrammalar mavjud ombor. Rasmiy ombor mavjud va kompaniya yoki loyihaning shaxsiy ombori bo'lishi mumkin.
O'zaro aloqalar
Keling, Helm yordamida dasturni o'rnatmoqchi bo'lganimizda, arxitektura komponentlarining o'zaro ta'sirini ko'rib chiqaylik.
- Biz gaplashamiz
Helm install, omborga kiring (Chart Repo) va Helm diagrammasini oling.
- Helm yordam dasturi (Helm CLI) qaysi klaster bilan bog'lanish kerakligini aniqlash uchun Kubeconfig bilan o'zaro ishlaydi.
- Ushbu ma'lumotni olgandan so'ng, yordamchi dastur bizning klasterimizda joylashgan Tiller-ga ilova sifatida murojaat qiladi.
- Tiller Kubernetes-da amallarni bajarish, ba'zi ob'ektlarni (xizmatlar, pods, replikalar, sirlar va boshqalar) yaratish uchun Kube-apiserverni chaqiradi.
Keyinchalik, butun Helm arxitekturasi ta'sir qilishi mumkin bo'lgan hujum vektorini ko'rish uchun diagrammani murakkablashtiramiz. Va keyin biz uni himoya qilishga harakat qilamiz.
Hujum vektori
Birinchi potentsial zaif nuqta imtiyozli API-foydalanuvchi. Sxemaning bir qismi sifatida bu Helm CLI-ga administrator kirish huquqini qo'lga kiritgan xaker.
Imtiyozsiz API foydalanuvchisi yaqin joyda bo'lsa ham xavf tug'dirishi mumkin. Bunday foydalanuvchi boshqa kontekstga ega bo'ladi, masalan, u Kubeconfig sozlamalarida bitta klaster nom maydonida o'rnatilishi mumkin.
Eng qiziqarli hujum vektori Tiller yaqinidagi klaster ichida joylashgan va unga kira oladigan jarayon bo'lishi mumkin. Bu klasterning tarmoq muhitini ko'radigan veb-server yoki mikroservis bo'lishi mumkin.
Ekzotik, ammo tobora ommalashib borayotgan hujum varianti Chart Repo-ni o'z ichiga oladi. Vijdonsiz muallif tomonidan yaratilgan jadval xavfli manbalarni o'z ichiga olishi mumkin va siz uni ishonch bilan to'ldirasiz. Yoki u siz rasmiy ombordan yuklab olgan diagrammani almashtirishi va, masalan, siyosat shaklida resurs yaratishi va unga kirishni kuchaytirishi mumkin.
Keling, ushbu to'rt tomondan hujumlarni to'xtatishga harakat qilaylik va Helm arxitekturasida qayerda muammolar borligini va qaerda, ehtimol, yo'qligini aniqlaylik.
Keling, diagrammani kattalashtiramiz, ko'proq elementlar qo'shamiz, lekin barcha asosiy komponentlarni saqlab qolamiz.
Helm CLI Chart Repo bilan bog'lanadi, Kubeconfig bilan o'zaro ishlaydi va ish klasterga Tiller komponentiga o'tkaziladi.
Tiller ikkita ob'ekt bilan ifodalanadi:
- Tiller-deploy svc, bu ma'lum bir xizmatni ochib beradi;
- Klasterga kiradigan butun yuk ishlaydigan (bir nusxada bitta nusxadagi diagrammada) tirkagichni joylashtirish.
O'zaro ta'sir qilish uchun turli xil protokollar va sxemalar qo'llaniladi. Xavfsizlik nuqtai nazaridan bizni eng ko'p qiziqtiradi:
- Helm CLI diagramma repoga kirish mexanizmi: qanday protokol, autentifikatsiya bormi va u bilan nima qilish mumkin.
- Helm CLI kubectl yordamida Tiller bilan aloqa o'rnatadigan protokol. Bu klaster ichida o'rnatilgan RPC serveridir.
- Tillerning o'zi klasterda joylashgan va Kube-apiserver bilan o'zaro aloqada bo'lgan mikroservislardan foydalanishi mumkin.
Keling, ushbu sohalarning barchasini tartibda muhokama qilaylik.
RBAC
RBAC yoqilmagan bo'lsa, Helm yoki klaster ichidagi boshqa xizmatlar uchun har qanday xavfsizlik haqida gapirishdan ma'no yo'q.
Ko'rinishidan, bu eng so'nggi tavsiya emas, lekin ishonchim komilki, ko'pchilik RBAC-ni ishlab chiqarishda ham yoqmagan, chunki bu juda ko'p shov-shuv va ko'p narsalarni sozlash kerak. Biroq, men sizni buni qilishga taklif qilaman.
— RBAC uchun veb-sayt advokati. U RBAC-ni o'rnatishga yordam beradigan juda ko'p qiziqarli materiallarni o'z ichiga oladi, nima uchun u yaxshi ekanligini va ishlab chiqarishda u bilan qanday yashashni ko'rsatadi.
Men Tiller va RBAC qanday ishlashini tushuntirishga harakat qilaman. Tiller klaster ichida ma'lum bir xizmat hisobi ostida ishlaydi. Odatda, agar RBAC sozlanmagan bo'lsa, bu superuser bo'ladi. Asosiy konfiguratsiyada Tiller administrator bo'ladi. Shuning uchun Tiller sizning klasteringizga SSH tunnelidir, deb ko'pincha aytiladi. Aslida, bu to'g'ri, shuning uchun yuqoridagi diagrammadagi Standart xizmat hisobi o'rniga alohida ajratilgan xizmat hisobidan foydalanishingiz mumkin.
Helm-ni ishga tushirganingizda va uni birinchi marta serverga o'rnatganingizda, xizmat hisobini foydalanib o'rnatishingiz mumkin --service-account. Bu sizga minimal talab qilinadigan huquqlar to'plamiga ega foydalanuvchidan foydalanish imkonini beradi. To'g'ri, siz bunday "gulchambar" yaratishingiz kerak bo'ladi: Rol va RoleBinding.
Afsuski, Helm buni siz uchun qilmaydi. Siz yoki Kubernetes klasteringiz administratori Helm’dan o‘tish uchun xizmat hisobi uchun Rollar va RolBindings to‘plamini oldindan tayyorlashingiz kerak.
Savol tug'iladi - Rol va ClusterRole o'rtasidagi farq nima? Farqi shundaki, ClusterRole barcha nomlar uchun ishlaydi, oddiy Roles va RoleBindingsdan farqli o'laroq, faqat maxsus nomlar maydoni uchun ishlaydi. Siz butun klaster va barcha nomlar boʻshliqlari uchun siyosatlarni sozlashingiz yoki har bir nom maydoni uchun individual ravishda moslashtirishingiz mumkin.
Shuni ta'kidlash kerakki, RBAC yana bir katta muammoni hal qiladi. Ko'pchilik, afsuski, Helm ko'p ijarachi emasligidan shikoyat qiladi (ko'p ijarachilikni qo'llab-quvvatlamaydi). Agar bir nechta jamoalar klasterni iste'mol qilsa va Helm-dan foydalansa, bu klaster ichida siyosatlarni o'rnatish va ularga kirishni cheklash asosan mumkin emas, chunki Helm ishlaydigan ma'lum bir xizmat hisobi mavjud va u klasterdagi barcha resurslarni uning ostidan yaratadi. , bu ba'zan juda noqulay. Bu to'g'ri - ikkilik faylning o'zi kabi, jarayon kabi, Helm Tiller ko'p ijaraga olish tushunchasiga ega emas.
Biroq, Tillerni klasterda bir necha marta ishlatish imkonini beruvchi ajoyib usul mavjud. Bu bilan hech qanday muammo yo'q, Tiller har qanday nom maydonida ishga tushirilishi mumkin. Shunday qilib, siz RBAC, Kubeconfig-dan kontekst sifatida foydalanishingiz va maxsus Helm-ga kirishni cheklashingiz mumkin.
Bu shunday ko'rinadi.
Masalan, turli jamoalar uchun kontekstga ega ikkita Kubeconfig mavjud (ikkita nom maydoni): ishlab chiqish guruhi va administrator klasteri uchun X Team. Administrator klasteri o'zining keng Tiller-ga ega bo'lib, u Kube-tizim nomlar maydonida joylashgan, mos ravishda rivojlangan xizmat hisobi. Va ishlab chiqish guruhi uchun alohida nom maydoni, ular o'z xizmatlarini maxsus nomlar maydoniga joylashtirishlari mumkin bo'ladi.
Bu amaliy yondashuv, Tiller unchalik kuchga muhtoj emaski, bu sizning byudjetingizga katta ta'sir qiladi. Bu tezkor echimlardan biridir.
Tiller-ni alohida-alohida sozlang va Kubeconfig-ni jamoa, ma'lum bir ishlab chiquvchi yoki atrof-muhit uchun kontekst bilan ta'minlang: Dev, Staging, Production (hamma bir xil klasterda bo'lishi shubhali, ammo buni amalga oshirish mumkin).
Hikoyamizni davom ettirib, keling, RBAC-dan o'tamiz va ConfigMaps haqida gaplashamiz.
ConfigMaps
Helm ConfigMaps-dan ma'lumotlar ombori sifatida foydalanadi. Biz arxitektura haqida gapirganimizda, relizlar, konfiguratsiyalar, orqaga qaytarish va hokazolar haqida ma'lumotlarni saqlaydigan hech qanday ma'lumotlar bazasi yo'q edi. Buning uchun ConfigMaps ishlatiladi.
ConfigMaps bilan bog'liq asosiy muammo ma'lum - ular printsipial jihatdan xavfsiz emas; nozik ma'lumotlarni saqlash mumkin emas. Biz xizmatdan tashqariga chiqmasligi kerak bo'lgan hamma narsa haqida gapiramiz, masalan, parollar. Hozirda Helm uchun eng mahalliy usul ConfigMaps-dan sirlarga o'tishdir.
Bu juda sodda tarzda amalga oshiriladi. Tiller sozlamasini bekor qiling va saqlash sir bo'lishini belgilang. Keyin har bir joylashtirish uchun siz ConfigMap-ni emas, balki sirni olasiz.
Siz sirlarning o'zi g'alati tushuncha va unchalik xavfsiz emasligi haqida bahslashishingiz mumkin. Biroq, buni Kubernetes ishlab chiquvchilari o'zlari qilishlarini tushunish kerak. 1.10 versiyasidan boshlab, ya'ni. Ancha vaqtdan beri, hech bo'lmaganda ommaviy bulutlarda, sirlarni saqlash uchun to'g'ri saqlashni ulash mumkin edi. Jamoa hozirda sirlarga, alohida podslarga yoki boshqa ob'ektlarga kirishni yaxshiroq tarqatish yo'llari ustida ishlamoqda.
Storage Helm-ni sirlarga o'tkazish yaxshiroqdir va ular, o'z navbatida, markaziy tarzda himoyalangan.
Albatta qoladi ma'lumotlarni saqlash chegarasi 1 MB. Helm bu yerda ConfigMaps uchun taqsimlangan saqlash sifatida etcd dan foydalanadi. Va u erda ular bu replikatsiya uchun mos ma'lumotlar bo'lagi deb hisoblashdi va hokazo. Reddit-da bu haqda qiziqarli munozara bor, men dam olish kunlari uchun ushbu kulgili o'qishni yoki ko'chirmani o'qishni tavsiya qilaman. .
Reposlar diagrammasi
Grafiklar ijtimoiy jihatdan eng zaif va "O'rtadagi odam" manbai bo'lishi mumkin, ayniqsa siz birja yechimidan foydalansangiz. Avvalo, biz HTTP orqali ochiladigan omborlar haqida gapiramiz.
Siz Helm Repo-ni HTTPS orqali ochishingiz kerak - bu eng yaxshi variant va arzon.
E'tibor bering grafik imzo mexanizmi. Texnologiya juda oddiy. Bu umumiy va shaxsiy kalitlarga ega oddiy PGP mashinasi GitHub da ishlatadigan narsadir. O'rnating va kerakli kalitlarga ega bo'ling va hamma narsani imzolang, bu haqiqatan ham sizning jadvalingiz ekanligiga ishonch hosil qiling.
Bundan tashqari, Helm mijozi TLS ni qo‘llab-quvvatlaydi (server tomonidagi HTTP ma'nosida emas, balki o'zaro TLS). Muloqot qilish uchun server va mijoz kalitlaridan foydalanishingiz mumkin. Rostini aytsam, men bunday mexanizmdan foydalanmayman, chunki men o'zaro sertifikatlarni yoqtirmayman. Asosan, - Helm 2 uchun Helm Repo-ni sozlashning asosiy vositasi - shuningdek, asosiy autentifikatsiyani qo'llab-quvvatlaydi. Agar u qulayroq va jimroq bo'lsa, siz asosiy autentifikatsiyadan foydalanishingiz mumkin.
Shuningdek, plagin ham mavjud , bu sizga Google Cloud Storage-da Chart Repos-ni joylashtirish imkonini beradi. Bu juda qulay, ajoyib ishlaydi va juda xavfsiz, chunki barcha tasvirlangan mexanizmlar qayta ishlanadi.
Agar siz HTTPS yoki TLS-ni yoqsangiz, mTLS-dan foydalaning va xavflarni yanada kamaytirish uchun asosiy autentifikatsiyani yoqsangiz, Helm CLI va Chart Repo bilan xavfsiz aloqa kanaliga ega bo'lasiz.
gRPC API
Keyingi qadam juda muhim - klasterda joylashgan va bir tomondan server bo'lgan Tillerning xavfsizligini ta'minlash, boshqa tomondan, uning o'zi boshqa komponentlarga kiradi va o'zini kimgadir ko'rsatishga harakat qiladi.
Yuqorida aytib o'tganimdek, Tiller - bu gRPC-ni ochib beradigan xizmat, Helm mijozi unga gRPC orqali keladi. Odatiy bo'lib, albatta, TLS o'chirilgan. Nima uchun bu amalga oshirildi - bu munozarali savol, menimcha, boshida sozlashni soddalashtirganga o'xshaydi.
Ishlab chiqarish va hatto sahnalashtirish uchun men gRPC da TLS ni yoqishni tavsiya qilaman.
Menimcha, diagrammalar uchun mTLS dan farqli o'laroq, bu bu erda mos keladi va juda sodda tarzda amalga oshiriladi - PQI infratuzilmasini yaratish, sertifikat yaratish, Tillerni ishga tushirish, ishga tushirish vaqtida sertifikatni uzatish. Shundan so'ng siz o'zingizni yaratilgan sertifikat va shaxsiy kalit bilan taqdim etgan holda barcha Helm buyruqlarini bajarishingiz mumkin.
Shunday qilib, siz o'zingizni klasterdan tashqaridan Tillerga qilingan barcha so'rovlardan himoya qilasiz.
Shunday qilib, biz Tillerga ulanish kanalini ta'minladik, biz allaqachon RBAC-ni muhokama qildik va Kubernetes apiserverining huquqlarini moslashtirdik, u bilan o'zaro aloqada bo'lishi mumkin bo'lgan domenni qisqartirdik.
Himoyalangan rul
Keling, yakuniy diagrammani ko'rib chiqaylik. Xuddi shu strelkalar bilan bir xil arxitektura.
Endi barcha ulanishlarni xavfsiz yashil rangda chizish mumkin:
- Chart Repo uchun biz TLS yoki mTLS va asosiy autentifikatsiyadan foydalanamiz;
- Tiller uchun mTLS va u TLS bilan gRPC xizmati sifatida taqdim etiladi, biz sertifikatlardan foydalanamiz;
- klaster Role va RoleBinding bilan maxsus xizmat hisobidan foydalanadi.
Biz klasterni sezilarli darajada himoya qildik, ammo kimdir aqlli dedi:
"Faqat bitta mutlaqo xavfsiz echim bo'lishi mumkin - beton qutida joylashgan va askarlar tomonidan qo'riqlanadigan o'chirilgan kompyuter."
Ma'lumotlarni manipulyatsiya qilish va yangi hujum vektorlarini topishning turli usullari mavjud. Biroq, men ushbu tavsiyalar xavfsizlikning asosiy sanoat standartiga erishishiga ishonchim komil.
bonus
Bu qism xavfsizlik bilan bevosita bog'liq emas, balki foydali bo'ladi. Men sizga kam odam biladigan qiziqarli narsalarni ko'rsataman. Misol uchun, diagrammalarni qanday qidirish kerak - rasmiy va norasmiy.
Omborda Endi 300 ga yaqin diagrammalar va ikkita oqim mavjud: barqaror va inkubator. Kim o‘z hissasini qo‘shgan bo‘lsa, inkubatordan otxonaga o‘tish naqadar qiyinligini va otxonadan uchib chiqish qanchalik osonligini juda yaxshi biladi. Biroq, bu Prometey va sizga yoqadigan boshqa narsalar uchun diagrammalarni qidirish uchun eng yaxshi vosita emas, bitta oddiy sababga ko'ra - bu paketlarni qulay tarzda qidirishingiz mumkin bo'lgan portal emas.
Ammo xizmat bor , bu grafiklarni topishni ancha qulay qiladi. Eng muhimi, ko'plab tashqi omborlar va deyarli 800 ta jozibalar mavjud. Bundan tashqari, agar biron sababga ko'ra siz jadvallaringizni barqarorlikka yuborishni xohlamasangiz, omboringizni ulashingiz mumkin.
Hub.helm.sh ni sinab ko'ring va uni birgalikda ishlab chiqaylik. Ushbu xizmat Helm loyihasi ostida va agar siz front-end dasturchi bo'lsangiz va shunchaki tashqi ko'rinishni yaxshilashni istasangiz, hatto uning UI-ga hissa qo'shishingiz mumkin.
Men ham e'tiboringizni qaratmoqchiman Ochiq Service Broker API integratsiyasi. Bu og'ir va tushunarsiz bo'lib tuyuladi, lekin u hamma duch keladigan muammolarni hal qiladi. Oddiy misol bilan tushuntiraman.
Kubernetes klasteri mavjud bo'lib, unda biz klassik dastur - WordPressni ishga tushirmoqchimiz. Umuman olganda, to'liq ishlash uchun ma'lumotlar bazasi kerak. Ko'p turli xil echimlar mavjud, masalan, siz o'zingizning davlat xizmatingizni ishga tushirishingiz mumkin. Bu juda qulay emas, lekin ko'pchilik buni qiladi.
Boshqalar, biz kabi Chainstack, o'z serverlari uchun MySQL yoki PostgreSQL kabi boshqariladigan ma'lumotlar bazalaridan foydalanadilar. Shuning uchun bizning ma'lumotlar bazalarimiz bulutning biron bir joyida joylashgan.
Ammo muammo tug'iladi: biz xizmatimizni ma'lumotlar bazasi bilan bog'lashimiz, ma'lumotlar bazasi lazzatini yaratishimiz, hisob ma'lumotlarini uzatishimiz va qandaydir tarzda uni boshqarishimiz kerak. Bularning barchasi odatda tizim administratori yoki ishlab chiquvchisi tomonidan qo'lda amalga oshiriladi. Va ilovalar kam bo'lsa, hech qanday muammo bo'lmaydi. Ular ko'p bo'lsa, sizga kombayn kerak bo'ladi. Bunday kombayn bor - bu Servis Broker. Bu sizga ommaviy bulutli klaster uchun maxsus plagindan foydalanish va provayderdan Broker orqali resurslarga buyurtma berish imkonini beradi, xuddi API kabi. Buning uchun siz mahalliy Kubernetes vositalaridan foydalanishingiz mumkin.
Bu juda oddiy. Siz, masalan, Azure-da boshqariladigan MySQL-ni asosiy sath bilan so'rashingiz mumkin (buni sozlash mumkin). Azure API yordamida maʼlumotlar bazasi yaratiladi va foydalanishga tayyorlanadi. Bunga aralashishingiz shart emas, plagin buning uchun javobgardir. Masalan, OSBA (Azure plagini) hisob ma'lumotlarini xizmatga qaytaradi va Helm-ga uzatadi. Siz WordPress-dan bulutli MySQL bilan foydalana olasiz, boshqariladigan ma'lumotlar bazalari bilan umuman shug'ullanmaysiz va ichidagi davlat xizmatlari haqida qayg'urmaysiz.
Aytishimiz mumkinki, Helm, bir tomondan, xizmatlarni joylashtirishga imkon beradigan, ikkinchi tomondan, bulutli provayderlarning resurslarini iste'mol qiladigan elim vazifasini bajaradi.
Siz o'zingizning plaginingizni yozishingiz va butun voqeani joyida ishlatishingiz mumkin. Shunda siz shunchaki korporativ Cloud provayderi uchun o'z plaginingizga ega bo'lasiz. Men ushbu yondashuvni sinab ko'rishni tavsiya qilaman, ayniqsa sizda katta miqyos bo'lsa va biron bir xususiyat uchun ishlab chiqish, sahnalashtirish yoki butun infratuzilmani tezda o'rnatmoqchi bo'lsangiz. Bu sizning operatsiyalaringiz yoki DevOps uchun hayotni osonlashtiradi.
Men aytib o'tgan yana bir topilma helm-gcs plagini, bu sizga Helm diagrammalarini saqlash uchun Google-paqirlaridan (obyektni saqlash) foydalanish imkonini beradi.
Uni ishlatishni boshlash uchun sizga faqat to'rtta buyruq kerak bo'ladi:
- plaginni o'rnatish;
- uni boshlash;
- gcp-da joylashgan chelakka yo'lni belgilang;
- diagrammalarni standart usulda nashr etish.
Eng go'zalligi shundaki, avtorizatsiya uchun mahalliy gcp usuli qo'llaniladi. Xizmat qaydnomasidan, ishlab chiquvchi hisob qaydnomasidan, xohlaganingizcha foydalanishingiz mumkin. Bu juda qulay va ishlash uchun hech qanday xarajat qilmaydi. Agar siz men kabi opsless falsafani targ'ib qilsangiz, bu, ayniqsa kichik jamoalar uchun juda qulay bo'ladi.
Shu bilan bir qatorda
Helm - bu xizmatlarni boshqarishning yagona yechimi emas. Bu haqda juda ko'p savollar bor, ehtimol shuning uchun uchinchi versiya juda tez paydo bo'ldi. Albatta, alternativalar mavjud.
Bu maxsus echimlar bo'lishi mumkin, masalan, Ksonnet yoki Metaparticle. Siz o'zingizning klassik infratuzilmani boshqarish vositalaridan (Ansible, Terraform, Chef va boshqalar) men aytib o'tgan maqsadlarda foydalanishingiz mumkin.
Nihoyat, yechim bor , uning mashhurligi ortib bormoqda.
Operator Framework ko'rib chiqilishi kerak bo'lgan eng yaxshi Helm alternatividir.
Bu CNCF va Kubernetes uchun ko'proq mahalliy hisoblanadi, lekin kirish uchun to'siq ancha yuqori, siz ko'proq dasturlashingiz va manifestlarni kamroq tasvirlashingiz kerak.
Draft, Scaffold kabi turli xil qo'shimchalar mavjud. Ular hayotni ancha osonlashtiradi, masalan, ishlab chiquvchilar uchun sinov muhitini o'rnatish uchun Helm-ni yuborish va ishga tushirish siklini soddalashtiradi. Men ularni kuch beruvchilar deb atagan bo'lardim.
Mana hamma narsa qayerda ekanligining vizual jadvali.
X o'qida nima bo'layotganini shaxsiy nazorat qilish darajasi, y o'qida Kubernetesning mahalliyligi darajasi. Helm versiyasi 2 o'rtada bir joyga tushadi. 3-versiyada unchalik katta emas, lekin nazorat va mahalliylik darajasi yaxshilandi. Ksonnet darajasidagi yechimlar hali ham Helm 2 dan ham pastroq. Biroq, bu dunyoda yana nima borligini bilish uchun ularga qarash kerak. Albatta, sizning konfiguratsiya menejeringiz sizning nazoratingiz ostida bo'ladi, lekin u mutlaqo Kubernetesga tegishli emas.
Operator Framework mutlaqo Kubernetesga xosdir va uni yanada nafis va sinchkovlik bilan boshqarishga imkon beradi (lekin kirish darajasi haqida unutmang). Aksincha, bu Helm yordamida juda ko'p sonli ilovalarni qadoqlash uchun ommaviy kombayn emas, balki ixtisoslashtirilgan dastur va uning boshqaruvini yaratish uchun javob beradi.
Kengayuvchilar shunchaki boshqaruvni biroz yaxshilaydi, ish jarayonini to'ldiradi yoki CI/CD quvurlaridagi burchaklarni kesib tashlaydi.
Helmning kelajagi
Yaxshi xabar shundaki, Helm 3 keladi. Helm 3.0.0-alpha.2 ning alfa versiyasi allaqachon chiqarilgan, siz uni sinab ko'rishingiz mumkin. Bu juda barqaror, ammo funksionallik hali ham cheklangan.
Nima uchun sizga Helm 3 kerak? Birinchidan, bu hikoya haqida Tillerning yo'qolishi, komponent sifatida. Bu, siz allaqachon tushunganingizdek, oldinga katta qadamdir, chunki arxitektura xavfsizligi nuqtai nazaridan hamma narsa soddalashtirilgan.
Kubernetes 2 yoki undan ham oldinroq bo'lgan Helm 1.8 yaratilganda, ko'pgina tushunchalar etuk emas edi. Misol uchun, CRD kontseptsiyasi hozirda faol ravishda amalga oshirilmoqda va Helm amalga oshiradi CRD dan foydalaningtuzilmalarni saqlash uchun. Faqat mijozdan foydalanish mumkin bo'ladi va server qismini saqlab qolmaydi. Shunga ko'ra, tuzilmalar va resurslar bilan ishlash uchun mahalliy Kubernetes buyruqlaridan foydalaning. Bu oldinga tashlangan katta qadamdir.
Paydo bo'ladi mahalliy OCI omborlarini qo'llab-quvvatlash (Ochiq konteyner tashabbusi). Bu juda katta tashabbus va Helm birinchi navbatda o'z jadvallarini joylashtirishga qiziqadi. Masalan, Docker Hub ko'plab OCI standartlarini qo'llab-quvvatlaydi. Men taxmin qilmayapman, lekin klassik Docker repozitoriy provayderlari sizga Helm diagrammalarini joylashtirish imkoniyatini berishni boshlaydilar.
Men uchun bahsli hikoya Lua qo'llab-quvvatlash, skriptlarni yozish uchun shablon mexanizmi sifatida. Men Luaning katta muxlisi emasman, lekin bu butunlay ixtiyoriy xususiyat bo'ladi. Men buni 3 marta tekshirdim - Lua-dan foydalanish shart emas. Shuning uchun, Lua-dan foydalanmoqchi bo'lganlar, Go'ni yoqtiradiganlar bizning ulkan lagerimizga qo'shilishadi va buning uchun go-tmpl-dan foydalanadilar.
Nihoyat, men aniq etishmayotgan narsa edi sxemaning paydo bo'lishi va ma'lumotlar turini tekshirish. Endi int yoki string bilan bog'liq muammolar bo'lmaydi, nolni qo'sh tirnoq ichiga o'rash kerak emas. JSONS sxemasi paydo bo'ladi, bu sizga qiymatlar uchun buni aniq tasvirlash imkonini beradi.
Qattiq qayta ishlanadi hodisaga asoslangan model. Bu allaqachon kontseptual tarzda tasvirlangan. Helm 3 filialiga qarang, va siz qancha voqealar, ilgaklar va boshqa narsalar qo'shilganligini ko'rasiz, bu juda soddalashtiradi va boshqa tomondan, joylashtirish jarayonlari va ularga reaktsiyalar ustidan nazoratni qo'shadi.
Helm 3 bizga Helm 2 yoqmagani uchun emas, balki Kubernetes yanada rivojlangani uchun oddiyroq, xavfsizroq va qiziqarliroq bo‘ladi. Shunga ko'ra, Helm Kubernetes ishlanmalaridan foydalanishi va unda Kubernetes uchun ajoyib menejerlarni yaratishi mumkin.
Yana bir yaxshi yangilik shu Aleksandr Xayorov sizga aytadi: Eslatib o‘tamiz, Moskvada ishlab chiqish, sinov va ekspluatatsiya jarayonlari integratsiyasi bo‘yicha konferensiya bo‘lib o‘tadi 30 sentyabr va 1 oktyabr. Siz buni 20 avgustgacha qilishingiz mumkin va yechim bilan tajribangiz haqida bizga xabar bering DevOps yondashuvining vazifalari.
Konferentsiya nazorat punktlari va yangiliklarni quyidagi manzilda kuzatib boring и .
Manba: www.habr.com