Kubernetes klasterli ishlab chiqarish muhitida Docker konteynerlarini ishga tushirish uchun ajoyib vositadir. Biroq, Kubernetes hal qila olmaydigan muammolar mavjud. Tez-tez ishlab chiqarishni joylashtirish uchun jarayonda to'xtab qolmaslik uchun bizga to'liq avtomatlashtirilgan Moviy/Yashil joylashtirish kerak, bu ham tashqi HTTP so'rovlarini bajarishi va SSL yuklamalarini amalga oshirishi kerak. Bu ha-proksi kabi yuk balansi bilan integratsiyani talab qiladi. Yana bir qiyinchilik - bulutli muhitda ishlaganda Kubernetes klasterining o'zini yarim avtomatik masshtablash, masalan, kechasi klasterni qisman kichraytirish.
Kubernetes-da bunday xususiyatlar qutidan tashqarida bo'lmasa-da, u shunga o'xshash muammolarni hal qilish uchun foydalanishingiz mumkin bo'lgan API taqdim etadi. Ochiq manba asosida yaratilgan Cloud RTI loyihasining bir qismi sifatida Kubernetes klasterini avtomatlashtirilgan Moviy/Yashil joylashtirish va masshtablash vositalari ishlab chiqilgan.
Ushbu maqola, video transkript, ishlab chiqarishda to'xtab qolmasdan, git commit kodini qabul qiladigan ishlab chiqarishga tayyor muhitni yaratish uchun boshqa ochiq manba komponentlari bilan birga Kubernetes-ni qanday sozlashni ko'rsatadi.
Shunday qilib, tashqi dunyodan ilovalaringizga kirish imkoniga ega bo'lganingizdan so'ng, siz avtomatlashtirishni to'liq sozlashni boshlashingiz mumkin, ya'ni uni git commitni bajarishingiz mumkin bo'lgan bosqichga olib keling va bu git commit ishlab chiqarishda tugashiga ishonch hosil qiling. Tabiiyki, ushbu bosqichlarni amalga oshirayotganda, joylashtirishni amalga oshirayotganda, biz to'xtab qolishga duch kelishni xohlamaymiz. Shunday qilib, Kubernetesdagi har qanday avtomatlashtirish API bilan boshlanadi.
Kubernetes qutidan tashqarida samarali foydalanish mumkin bo'lgan vosita emas. Albatta, buni qila olasiz, kubectl va hokazolardan foydalaning, ammo baribir API bu platformadagi eng qiziqarli va foydali narsadir. API-dan funktsiyalar to'plami sifatida foydalanish orqali siz Kubernetes-da qilishni xohlagan deyarli hamma narsaga kirishingiz mumkin. kubectl-ning o'zi ham REST API-dan foydalanadi.
Bu REST, shuning uchun siz ushbu API bilan ishlash uchun istalgan til yoki vositadan foydalanishingiz mumkin, ammo shaxsiy kutubxonalar sizning hayotingizni ancha osonlashtiradi. Mening jamoam ikkita shunday kutubxonani yozdi: biri Java/OSGi uchun va biri Go uchun. Ikkinchisi tez-tez ishlatilmaydi, lekin har qanday holatda ham bu foydali narsalar sizning ixtiyoringizda. Ular qisman litsenziyalangan ochiq manbali loyihadir. Turli tillar uchun bunday kutubxonalar juda ko'p, shuning uchun siz o'zingizga mos keladiganini tanlashingiz mumkin.
Shunday qilib, joylashtirishni avtomatlashtirishni boshlashdan oldin, jarayon hech qanday to'xtab qolmasligiga ishonch hosil qilishingiz kerak. Masalan, bizning jamoamiz odamlar ilovalardan maksimal darajada foydalanayotgan kunning o'rtalarida ishlab chiqarishni joylashtirishni amalga oshiradi, shuning uchun bu jarayonda kechikishlarga yo'l qo'ymaslik kerak. To'xtab qolishning oldini olish uchun ikkita usul qo'llaniladi: ko'k/yashil joylashtirish yoki yangilash. Ikkinchi holda, agar sizda dasturning 2 nusxasi ishlayotgan bo'lsa, ular ketma-ket yangilanadi. Bu usul juda yaxshi ishlaydi, lekin joylashtirish jarayonida bir vaqtning o'zida dasturning turli versiyalari ishlayotgan bo'lsa, mos kelmaydi. Bunday holda, siz backend eski versiyada ishlayotgan vaqtda foydalanuvchi interfeysini yangilashingiz mumkin va dastur ishlashni to'xtatadi. Shuning uchun, dasturlash nuqtai nazaridan, bunday sharoitda ishlash juda qiyin.
Bu bizning ilovalarimizni joylashtirishni avtomatlashtirish uchun ko'k/yashil joylashtirishdan foydalanishni afzal ko'rishimizning sabablaridan biridir. Ushbu usul yordamida siz bir vaqtning o'zida dasturning faqat bitta versiyasi faol bo'lishini ta'minlashingiz kerak.
Moviy/yashil joylashtirish mexanizmi shunday ko'rinadi. Biz ilovalarimiz uchun trafikni ha-proksi orqali qabul qilamiz, bu esa uni bir xil versiyadagi ilovaning ishlaydigan nusxalariga yo'naltiradi.
Yangi o'rnatish amalga oshirilganda, biz yangi komponentlar berilgan va yangi versiyani o'rnatadigan Deployerdan foydalanamiz. Ilovaning yangi versiyasini o'rnatish yangi nusxalar to'plamining "ko'tarilganini" anglatadi, shundan so'ng yangi versiyaning ushbu nusxalari alohida, yangi podda ishga tushiriladi. Biroq, ha-proksi ular haqida hech narsa bilmaydi va hali ularga hech qanday ish yukini yo'naltirmaydi.
Shuning uchun, birinchi navbatda, replikalarning yukga xizmat ko'rsatishga tayyorligini ta'minlash uchun sog'liqni saqlashni tekshirishning yangi versiyalarining ishlashini tekshirishni amalga oshirish kerak.
O'rnatishning barcha komponentlari sog'liqni tekshirishning ba'zi shakllarini qo'llab-quvvatlashi kerak. Bu juda oddiy HTTP qo'ng'irog'ini tekshirish, 200 holatiga ega kodni olganingizda yoki replikalarning ma'lumotlar bazasi va boshqa xizmatlar bilan ulanishini, dinamik muhit ulanishlarining barqarorligini tekshiradigan chuqurroq tekshirish bo'lishi mumkin. , va hamma narsa to'g'ri boshlanadimi yoki yo'qmi. Bu jarayon ancha murakkab bo'lishi mumkin.
Tizim barcha yangilangan replikalar ishlayotganligini tekshirgandan so'ng, Deployer konfiguratsiyani yangilaydi va ha-proksi-ni qayta sozlaydigan to'g'ri konfiguratsiyani o'tkazadi.
Shundan keyingina trafik yangi versiyaning nusxalari bo'lgan podkakka yo'naltiriladi va eski pod yo'qoladi.
Bu mexanizm Kubernetesning o'ziga xos xususiyati emas. Moviy/yashil joylashtirish kontseptsiyasi ancha vaqtdan beri mavjud bo'lib, u doimo yuk balanslagichidan foydalangan. Birinchidan, siz barcha trafikni ilovaning eski versiyasiga yo'naltirasiz va yangilanishdan so'ng uni butunlay yangi versiyaga o'tkazasiz. Ushbu tamoyil nafaqat Kubernetesda qo'llaniladi.
Endi men sizni yangi tarqatish komponenti - Deployer bilan tanishtiraman, u sog'liqni tekshirishni amalga oshiradi, proksi-serverlarni qayta sozlaydi va hokazo. Bu tashqi dunyoga taalluqli bo'lmagan va Kubernetes ichida mavjud bo'lgan tushunchadir. Men sizga ochiq manbali vositalar yordamida o'zingizning Deployer kontseptsiyasini qanday yaratishingiz mumkinligini ko'rsataman.
Shunday qilib, Deployer qiladigan birinchi narsa Kubernetes API yordamida RC replikatsiya kontrollerini yaratishdir. Ushbu API keyingi joylashtirish uchun pods va xizmatlarni yaratadi, ya'ni bizning ilovalarimiz uchun mutlaqo yangi klaster yaratadi. RC replikalar boshlanganiga ishonch hosil qilishi bilanoq, u ularning funksionalligini Sog'liqni saqlash tekshiruvini amalga oshiradi. Buning uchun Deployer GET /health buyrug'idan foydalanadi. U tegishli skanerlash komponentlarini ishga tushiradi va klasterning ishlashini qo'llab-quvvatlovchi barcha elementlarni tekshiradi.
Barcha podkastlar oΚ»z sogΚ»ligΚ»i haqida xabar bergandan soΚ»ng, Deployer yangi konfiguratsiya elementini yaratadi - etcd taqsimlangan xotira, Kubernetes tomonidan ichki foydalaniladi, shu jumladan yuk balansi konfiguratsiyasini saqlash. Biz etcd ga ma'lumotlarni yozamiz va yangi ma'lumotlar uchun confd monitors etcd deb nomlangan kichik vosita.
Agar u dastlabki konfiguratsiyada biron bir o'zgarishlarni aniqlasa, u yangi sozlamalar faylini yaratadi va uni ha-proksi-ga o'tkazadi. Bunday holda, ha-proksi hech qanday ulanishni yo'qotmasdan qayta ishga tushadi va yukni ilovalarimizning yangi versiyasi ishlashiga imkon beruvchi yangi xizmatlarga qaratadi.
Ko'rib turganingizdek, komponentlarning ko'pligiga qaramay, bu erda murakkab narsa yo'q. Siz faqat API va boshqalarga ko'proq e'tibor berishingiz kerak. Men sizga o'zimiz foydalanadigan ochiq manbali tarqatuvchi - Amdatu Kubernetes Deployer haqida aytib bermoqchiman.
Bu Kubernetes o'rnatishni tartibga solish vositasi bo'lib, quyidagi xususiyatlarga ega:
- Moviy/yashil joylashtirish;
- tashqi yuk balansini o'rnatish;
- joylashtirish deskriptorini boshqarish;
- haqiqiy joylashtirishni boshqarish;
- joylashtirish vaqtida sog'liqni saqlash tekshiruvlarining funksionalligini tekshirish;
- atrof-muhit o'zgaruvchilarini podlarga amalga oshirish.
Ushbu Deployer Kubernetes API-ning ustiga qurilgan va tutqichlar va joylashtirishlarni boshqarish uchun REST API-ni, shuningdek, joylashtirish jarayonida jurnallarni oqimlash uchun Websocket API-ni taqdim etadi.
U yuk balanslagich konfiguratsiyasi ma'lumotlarini etcd ga joylashtiradi, shuning uchun siz ha-proksi-dan tashqarida qo'llab-quvvatlash bilan foydalanishingiz shart emas, balki o'zingizning yuk balanslagich konfiguratsiya faylingizdan osongina foydalaning. Amdatu Deployer, xuddi Kubernetesning o'zi kabi Go'da yozilgan va Apache tomonidan litsenziyalangan.
Deployatorning ushbu versiyasidan foydalanishni boshlashdan oldin, men kerakli parametrlarni belgilaydigan quyidagi joylashtirish deskriptoridan foydalanganman.
Ushbu kodning muhim parametrlaridan biri "useHealthCheck" bayrog'ini yoqishdir. Joylashtirish jarayonida aql-idrok tekshiruvi o'tkazilishi kerakligini ko'rsatishimiz kerak. Joylashtirish tasdiqlanishi shart boβlmagan uchinchi tomon konteynerlaridan foydalansa, bu sozlamani oβchirib qoβyish mumkin. Bu identifikator, shuningdek, ha-proksi kerak bo'lgan replikalar sonini va frontend URL manzilini ko'rsatadi. Oxirida "podspec" pod spetsifikatsiyasi bayrog'i joylashgan bo'lib, u port konfiguratsiyasi, tasvir va boshqalar haqida ma'lumot olish uchun Kubernetesni chaqiradi. Bu juda oddiy JSON deskriptoridir.
Ochiq manbali Amdatu loyihasining bir qismi bo'lgan yana bir vosita bu Deploymentctl. U joylashtirishlarni sozlash uchun UIga ega, joylashtirish tarixini saqlaydi va uchinchi tomon foydalanuvchilari va ishlab chiquvchilari tomonidan qayta qo'ng'iroq qilish uchun veb-huklarni o'z ichiga oladi. Siz UI dan foydalana olmaysiz, chunki Amdatu Deployerning o'zi REST API, lekin bu interfeys hech qanday APIni jalb qilmasdan siz uchun joylashtirishni ancha osonlashtirishi mumkin. Deploymentctl Angular 2 yordamida OSGi/Vertx da yozilgan.
Endi men yuqoridagi narsalarni ekranda oldindan yozib olingan yozuvdan foydalanib ko'rsataman, shunda kutishingizga to'g'ri kelmaydi. Biz oddiy Go ilovasini joylashtiramiz. Agar siz ilgari Go-ni sinab ko'rmagan bo'lsangiz, tashvishlanmang, bu juda oddiy dastur, shuning uchun siz buni tushunishingiz kerak.
Bu erda biz faqat /sog'likka javob beradigan HTTP serverini yaratmoqdamiz, shuning uchun bu ilova faqat sog'liqni tekshirishni tekshiradi va boshqa hech narsa yo'q. Agar tekshiruv o'tib ketsa, quyida ko'rsatilgan JSON tuzilishi ishlatiladi. Unda dasturning joylashtiruvchi tomonidan o'rnatiladigan versiyasi, faylning yuqori qismida ko'riladigan xabar va mantiqiy ma'lumotlar turi - bizning ilovamiz ishlayaptimi yoki yo'qmi.
Men oxirgi satr bilan biroz aldadim, chunki faylning yuqori qismiga qat'iy mantiqiy qiymat qo'ydim, bu kelajakda hatto "nosog'lom" dasturni ham o'rnatishga yordam beradi. Buni keyinroq hal qilamiz.
Shunday qilib, keling, boshlaylik. Birinchidan, biz ~ kubectl get pods buyrug'i yordamida har qanday ishlaydigan pods borligini tekshiramiz va frontend URL manzilidan javob yo'qligiga asoslanib, biz hozirda hech qanday joylashtirish amalga oshirilmaganiga ishonch hosil qilamiz.
Keyingi ekranda siz men aytib o'tgan Deploymentctl interfeysini ko'rasiz, unda joylashtirish parametrlari o'rnatiladi: nom maydoni, dastur nomi, tarqatish versiyasi, replikalar soni, oldingi URL, konteyner nomi, rasm, resurs chegaralari, sog'liqni tekshirish uchun port raqami, va boshqalar. . Resurs cheklovlari juda muhim, chunki ular sizga maksimal mumkin bo'lgan texnik vositalardan foydalanishga imkon beradi. Bu yerda siz tarqatish jurnalini ham ko'rishingiz mumkin.
Agar siz hozir ~ kubectl get pods buyrug'ini takrorlasangiz, tizim 20 soniya davomida "muzlatib qo'yishini" ko'rishingiz mumkin, bu vaqt davomida ha-proksi qayta konfiguratsiya qilinadi. Shundan so'ng, podkast ishga tushadi va bizning nusxamiz joylashtirish jurnalida ko'rish mumkin.
Men videodan 20 soniya kutishni kesib tashladim va endi ekranda dasturning birinchi versiyasi o'rnatilganligini ko'rishingiz mumkin. Bularning barchasi faqat UI yordamida amalga oshirildi.
Endi ikkinchi versiyani sinab ko'ramiz. Buning uchun men ilova xabarini "Salom, Kubernetes!" βSalom, Deployer!β da, tizim ushbu rasmni yaratadi va uni Docker registriga joylashtiradi, shundan so'ng biz Deploymentctl oynasida yana βDeployβ tugmasini bosamiz. Bunday holda, joylashtirish jurnali dasturning birinchi versiyasini o'rnatishda bo'lgani kabi avtomatik ravishda ishga tushiriladi.
~ kubectl get pods buyrug'i hozirda dasturning 2 ta versiyasi ishlayotganligini ko'rsatadi, lekin frontend biz hali ham 1-versiyani ishlayotganimizni ko'rsatadi.
Yuk balanslagichi trafikni yangi versiyaga yo'naltirishdan oldin sog'liq tekshiruvi tugashini kutadi. 20 soniyadan so'ng, biz curl-ga o'tamiz va endi bizda ilovaning 2-versiyasi o'rnatilganligini va birinchisi o'chirilganligini ko'ramiz.
Bu "sog'lom" dasturni tarqatish edi. Keling, ilovaning yangi versiyasi uchun Sog'lom parametrini rostdan noto'g'riga o'zgartirsam, ya'ni sog'liq tekshiruvidan o'ta olmagan nosog'lom dasturni o'rnatishga harakat qilsam nima bo'lishini ko'rib chiqamiz. Agar dastur ishlab chiqish bosqichida ba'zi konfiguratsiya xatolariga yo'l qo'yilgan bo'lsa va u ushbu shaklda ishlab chiqarishga yuborilgan bo'lsa, bu sodir bo'lishi mumkin.
Ko'rib turganingizdek, joylashtirish yuqoridagi barcha bosqichlardan o'tadi va ~kubectl get pods ikkala pods ishlayotganligini ko'rsatadi. Ammo oldingi joylashtirishdan farqli o'laroq, jurnal vaqt tugashi holatini ko'rsatadi. Ya'ni, sog'lig'ini tekshirish muvaffaqiyatsiz bo'lganligi sababli, ilovaning yangi versiyasini tarqatib bo'lmaydi. Natijada, tizim ilovaning eski versiyasidan foydalanishga qaytganini va yangi versiya oddiygina o'chirilganligini ko'rasiz.
Buning yaxshi tomoni shundaki, agar sizda bir vaqtning o'zida juda ko'p sonli so'rovlar bo'lsa ham, ular joylashtirish jarayonini amalga oshirishda ishlamay qolish vaqtini sezmaydilar. Agar siz ushbu ilovani iloji boricha ko'proq so'rov yuboradigan Gatling ramkasi yordamida sinab ko'rsangiz, bu so'rovlarning hech biri bekor qilinmaydi. Bu shuni anglatadiki, bizning foydalanuvchilarimiz real vaqtda versiya yangilanishlarini ham sezmaydilar. Agar u muvaffaqiyatsiz bo'lsa, ish eski versiyada davom etadi, agar u muvaffaqiyatli bo'lsa, foydalanuvchilar yangi versiyaga o'tadilar.
Muvaffaqiyatsiz bo'lishi mumkin bo'lgan yagona narsa bor - agar sog'liqni saqlash tekshiruvi muvaffaqiyatli bo'lsa, lekin dastur unga ish yuki qo'llanilishi bilanoq bajarilmasa, ya'ni qulash faqat joylashtirish tugagandan so'ng sodir bo'ladi. Bunday holda, siz eski versiyaga qo'lda qaytishingiz kerak bo'ladi. Shunday qilib, biz Kubernetes-dan unga mo'ljallangan ochiq manbali vositalar bilan qanday foydalanishni ko'rib chiqdik. Agar siz ushbu vositalarni Build/Deploy quvurlaringizga yaratsangiz, joylashtirish jarayoni ancha osonlashadi. Shu bilan birga, o'rnatishni boshlash uchun siz foydalanuvchi interfeysidan foydalanishingiz yoki, masalan, master to'g'ridan-to'g'ri foydalanish orqali ushbu jarayonni to'liq avtomatlashtirishingiz mumkin.
Bizning Build Serverimiz Docker tasvirini yaratadi, uni Docker Hub-ga yoki siz foydalanadigan boshqa registrga surib qo'yadi. Docker Hub veb-hukni qo'llab-quvvatlaydi, shuning uchun biz Deployer orqali yuqorida ko'rsatilgan tarzda masofadan o'rnatishni boshlashimiz mumkin. Shunday qilib, siz ilovangizni potentsial ishlab chiqarishga joylashtirishni to'liq avtomatlashtirishingiz mumkin.
Keling, keyingi mavzuga o'tamiz - Kubernetes klasterini masshtablash. Kubectl buyrug'i masshtablash buyrug'i ekanligini unutmang. Ko'proq yordam bilan biz mavjud klasterimizdagi replikalar sonini osongina ko'paytirishimiz mumkin. Biroq, amalda, biz odatda pods emas, balki tugunlar sonini ko'paytirishni xohlaymiz.
Shu bilan birga, ish vaqtida siz Amazon xizmatlari narxini oshirishingiz kerak bo'lishi mumkin, tunda esa Amazon xizmatlarining narxini pasaytirish uchun siz ishlaydigan ilovalar sonini kamaytirishingiz kerak bo'lishi mumkin. Bu faqat podkastlar sonini o'zgartirish kifoya qiladi degani emas, chunki tugunlardan biri ishlamay qolsa ham, buning uchun Amazonga pul to'lashingiz kerak bo'ladi. Ya'ni, podkalarni masshtablash bilan bir qatorda, ishlatiladigan mashinalar sonini o'lchash kerak bo'ladi.
Bu qiyin bo'lishi mumkin, chunki biz Amazon yoki boshqa bulut xizmatidan foydalanamizmi, Kubernetes foydalanilayotgan mashinalar soni haqida hech narsa bilmaydi. Unda tizimni tugun darajasida o'lchash imkonini beruvchi vosita yo'q.
Shunday qilib, biz tugunlarga ham, podkalarga ham g'amxo'rlik qilishimiz kerak. Biz Kubernetes ishchi tugunlari sonini sozlash uchun AWS API va Scaling guruhi mashinalari yordamida yangi tugunlarni ishga tushirishni osonlikcha kengaytira olamiz. Kubernetes klasteridagi tugunlarni ro'yxatdan o'tkazish uchun bulut-init yoki shunga o'xshash skriptdan ham foydalanishingiz mumkin.
Yangi mashina Scaling guruhida boshlanadi, o'zini tugun sifatida ishga tushiradi, master registrida ro'yxatdan o'tadi va ishlay boshlaydi. Shundan so'ng, olingan tugunlarda foydalanish uchun nusxalar sonini ko'paytirishingiz mumkin. Masshtabni qisqartirish ko'proq harakat talab qiladi, chunki bunday qadam "keraksiz" mashinalarni o'chirib qo'ygandan so'ng allaqachon ishlayotgan ilovalarni yo'q qilishga olib kelmasligiga ishonch hosil qilishingiz kerak. Bunday stsenariyni oldini olish uchun siz tugunlarni "rejalashtirilmagan" holatga o'rnatishingiz kerak. Bu shuni anglatadiki, standart rejalashtiruvchi DaemonSet podslarini rejalashtirishda ushbu tugunlarni e'tiborsiz qoldiradi. Rejalashtiruvchi ushbu serverlardan hech narsani o'chirmaydi, lekin u erda yangi konteynerlarni ham ishga tushirmaydi. Keyingi qadam drenaj tugunini siqib chiqarish, ya'ni ishlaydigan podlarni undan boshqa mashinaga yoki buning uchun etarli quvvatga ega bo'lgan boshqa tugunlarga o'tkazishdir. Ushbu tugunlarda konteyner yo'qligiga ishonch hosil qilganingizdan so'ng, ularni Kubernetesdan olib tashlashingiz mumkin. Shundan so'ng, ular Kubernetes uchun mavjud bo'lishni to'xtatadilar. Keyinchalik, keraksiz tugunlar yoki mashinalarni o'chirish uchun AWS API-dan foydalanishingiz kerak.
Siz AWS API-ga o'xshash boshqa ochiq manbali masshtablash vositasi Amdatu Scalerd-dan foydalanishingiz mumkin. U klasterdagi tugunlarni qo'shish yoki olib tashlash uchun CLI-ni taqdim etadi. Uning qiziqarli xususiyati quyidagi json fayli yordamida rejalashtiruvchini sozlash qobiliyatidir.
Ko'rsatilgan kod tungi davrda klaster sig'imini ikki baravar kamaytiradi. U mavjud nusxalar sonini va Amazon klasterining kerakli hajmini sozlaydi. Ushbu rejalashtiruvchidan foydalanish tunda avtomatik ravishda tugunlar sonini kamaytiradi va ertalab ularni oshiradi, Amazon kabi bulut xizmatidan tugunlardan foydalanish xarajatlarini tejaydi. Bu xususiyat Kubernetes-ga o'rnatilmagan, ammo Scalerd-dan foydalanish ushbu platformani xohlaganingizcha kengaytirish imkonini beradi.
Shuni ta'kidlashni istardimki, ko'pchilik menga: "Hammasi yaxshi va yaxshi, lekin odatda statik bo'lgan mening ma'lumotlar bazasi haqida nima deyish mumkin?" Qanday qilib Kubernetes kabi dinamik muhitda shunga o'xshash narsani ishga tushirishingiz mumkin? Menimcha, siz buni qilmasligingiz kerak, Kubernetesda ma'lumotlar omborini ishga tushirishga urinmasligingiz kerak. Bu texnik jihatdan mumkin va Internetda ushbu mavzu bo'yicha qo'llanmalar mavjud, ammo bu sizning hayotingizni jiddiy ravishda murakkablashtiradi.
Ha, Kubernetes-da doimiy do'konlar tushunchasi mavjud va siz Mongo yoki MySQL kabi ma'lumotlar do'konlarini ishga tushirishga urinib ko'rishingiz mumkin, ammo bu juda ko'p mehnat talab qiladigan ish. Bu ma'lumotlar omborlarining dinamik muhit bilan o'zaro ta'sirini to'liq qo'llab-quvvatlamasligi bilan bog'liq. Ko'pgina ma'lumotlar bazalari muhim konfiguratsiyani talab qiladi, shu jumladan klasterni qo'lda sozlash, avtomatik o'lchovni va boshqa shunga o'xshash narsalarni yoqtirmaydi.
Shuning uchun siz Kubernetesda ma'lumotlar omborini ishga tushirishga urinib, hayotingizni murakkablashtirmasligingiz kerak. Tanish xizmatlardan foydalangan holda o'z ishlarini an'anaviy tarzda tashkil qiling va shunchaki Kubernetesga ulardan foydalanish imkoniyatini bering.
Mavzuni yakunlash uchun men sizni mening jamoam ustida ishlayotgan Kubernetes asosidagi Cloud RTI platformasi bilan tanishtirmoqchiman. U markazlashtirilgan ro'yxatga olish, ilovalar va klaster monitoringi va boshqa ko'plab foydali xususiyatlarni taqdim etadi. Monitoringni namoyish qilish uchun Grafana kabi turli xil ochiq manba vositalaridan foydalanadi.
Nima uchun ha-proksi yuk balanslagichidan Kubernetes bilan foydalanish haqida savol bor edi. Yaxshi savol, chunki hozirda yukni muvozanatlashning 2 darajasi mavjud. Kubernetes xizmatlari hali ham virtual IP manzillarida joylashgan. Siz ularni tashqi xost-mashinalardagi portlar uchun ishlata olmaysiz, chunki Amazon bulutli xostni haddan tashqari yuklasa, manzil o'zgaradi. Shuning uchun biz ha-proksini xizmatlar oldiga joylashtiramiz - trafik Kubernetes bilan muammosiz aloqa qilish uchun yanada statik tuzilmani yaratish.
Yana bir yaxshi savol - ko'k/yashil joylashtirishni amalga oshirayotganda ma'lumotlar bazasi sxemasi o'zgarishiga qanday g'amxo'rlik qilishingiz mumkin? Gap shundaki, Kubernetes-dan foydalanishdan qat'i nazar, ma'lumotlar bazasi sxemasini o'zgartirish qiyin ishdir. Eski va yangi sxemaning mos kelishini ta'minlashingiz kerak, shundan so'ng siz ma'lumotlar bazasini yangilashingiz va keyin ilovalarni o'zingiz yangilashingiz mumkin. Siz ma'lumotlar bazasini almashtirishingiz va keyin ilovalarni yangilashingiz mumkin. Men butunlay yangi ma'lumotlar bazasi klasterini yangi sxema bilan ishga tushirgan odamlarni bilaman, agar sizda Mongo kabi sxemasiz ma'lumotlar bazasi bo'lsa, bu variant, lekin baribir bu oson ish emas. Agar boshqa savollaringiz bo'lmasa, e'tiboringiz uchun rahmat!
Ba'zi reklamalar π
Biz bilan qolganingiz uchun tashakkur. Bizning maqolalarimiz sizga yoqdimi? Ko'proq qiziqarli tarkibni ko'rishni xohlaysizmi? Buyurtma berish yoki do'stlaringizga tavsiya qilish orqali bizni qo'llab-quvvatlang, , Siz uchun biz tomonidan ixtiro qilingan boshlang'ich darajadagi serverlarning noyob analogi: (RAID1 va RAID10, 24 tagacha yadro va 40 Gb gacha DDR4 bilan mavjud).
Amsterdamdagi Equinix Tier IV ma'lumotlar markazida Dell R730xd 2 baravar arzonmi? Faqat shu yerda Gollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! Haqida o'qing
Manba: www.habr.com