Kub-kub, metaklasterlar, chuqurchalar, resurslarni taqsimlash

Guruch. 1. Alibaba Cloud-dagi Kubernetes ekotizimlari

2015-yildan beri Kubernetes uchun Alibaba Cloud Container Service (ACK) Alibaba Cloud-dagi eng tez rivojlanayotgan bulut xizmatlaridan biri bo‘lib kelgan. U ko'plab mijozlarga xizmat ko'rsatadi, shuningdek, Alibaba ichki infratuzilmasi va kompaniyaning boshqa bulut xizmatlarini qo'llab-quvvatlaydi.

Dunyo miqyosidagi bulutli provayderlarning shunga o'xshash konteyner xizmatlarida bo'lgani kabi, bizning ustuvor vazifalarimiz ishonchlilik va mavjudlikdir. Shu sababli, o'n minglab Kubernetes klasterlari uchun kengaytiriladigan va global foydalanish mumkin bo'lgan platforma yaratilgan.

Ushbu maqolada biz bulutli infratuzilmada ko'p sonli Kubernetes klasterlarini, shuningdek, asosiy platforma arxitekturasini boshqarish bo'yicha tajribamiz bilan o'rtoqlashamiz.

kirish

Kubernetes bulutdagi turli xil ish yuklari uchun amalda standartga aylandi. Shaklda ko'rsatilganidek. Yuqoridagi 1-raqamga ko'ra, endi tobora ko'proq Alibaba Cloud ilovalari Kubernetes klasterlarida ishlamoqda: davlat va fuqaroligi bo'lmagan ilovalar, shuningdek, ilovalar menejerlari. Kubernetes boshqaruvi har doim infratuzilmani quruvchi va qo'llab-quvvatlovchi muhandislar uchun qiziqarli va jiddiy muhokama mavzusi bo'lib kelgan. Alibaba Cloud kabi bulutli provayderlar haqida gap ketganda, masshtablash masalasi birinchi o'ringa chiqadi. Bunday miqyosda Kubernetes klasterlarini qanday boshqarish mumkin? Biz allaqachon 10 000 tugunli Kubernetes klasterlarini boshqarish bo'yicha eng yaxshi amaliyotlarni ko'rib chiqdik. Albatta, bu qiziqarli masshtablash muammosi. Ammo boshqa o'lchov bor: miqdor klasterlarning o'zlari.

Biz ushbu mavzuni ko'plab ACK foydalanuvchilari bilan muhokama qildik. Ularning aksariyati o'nlab, balki yuzlab kichik yoki o'rta o'lchamli Kubernetes klasterlarini boshqarishni tanlaydi. Buning yaxshi sabablari bor: potentsial zararni cheklash, turli jamoalar uchun klasterlarni ajratish, sinov uchun virtual klasterlarni yaratish. Agar ACK ushbu foydalanish modeli bilan global auditoriyaga xizmat ko'rsatishni maqsad qilgan bo'lsa, u 20 dan ortiq mintaqalarda ko'p sonli klasterlarni ishonchli va samarali boshqarishi kerak.

Guruch. 2. Ko'p sonli Kubernetes klasterlarini boshqarish muammolari

Ushbu miqyosda klasterlarni boshqarishning asosiy muammolari qanday? Rasmda ko'rsatilganidek, to'rtta muammoni hal qilish kerak:

• Geterogenlik

ACK har xil turdagi klasterlarni, jumladan standart, serversiz, Edge, Windows va boshqalarni qo'llab-quvvatlashi kerak. Turli klasterlar turli xil variantlar, komponentlar va xosting modellarini talab qiladi. Ba'zi mijozlar o'z holatlari uchun moslashtirish bo'yicha yordamga muhtoj.

• Har xil klaster o'lchamlari

Klasterlar katta-kichikligi bo‘yicha turlicha bo‘ladi: bir necha ko‘zali bir juft tugundan minglab ko‘zali o‘n minglab tugungacha. Resurs talablari ham juda farq qiladi. Resurslarni noto'g'ri taqsimlash ishlashga ta'sir qilishi yoki hatto muvaffaqiyatsizlikka olib kelishi mumkin.

• Turli versiyalar

Kubernetes juda tez rivojlanmoqda. Yangi versiyalar bir necha oyda chiqariladi. Mijozlar har doim yangi xususiyatlarni sinab ko'rishga tayyor. Shunday qilib, ular sinov yukini Kubernetesning yangi versiyalariga, ishlab chiqarish yukini esa barqaror versiyalarga qo'ymoqchi. Ushbu talabni qondirish uchun ACK doimiy versiyalarini saqlab turgan holda Kubernetesning yangi versiyalarini mijozlarga yetkazib turishi kerak.

• Xavfsizlik muvofiqligi

Klasterlar turli hududlarda tarqalgan. Shunday qilib, ular turli xil xavfsizlik talablariga va rasmiy qoidalarga rioya qilishlari kerak. Misol uchun, Evropadagi klaster GDPRga mos kelishi kerak, Xitoydagi moliyaviy bulut esa qo'shimcha himoya qatlamlariga ega bo'lishi kerak. Ushbu talablar majburiydir va ularni e'tiborsiz qoldirish mumkin emas, chunki bu bulut platformasi mijozlari uchun katta xavf tug'diradi.

ACK platformasi yuqoridagi muammolarni hal qilish uchun mo'ljallangan. Hozirda u butun dunyo bo'ylab 10 mingdan ortiq Kubernetes klasterlarini ishonchli va barqaror boshqaradi. Keling, bunga qanday erishilganini, jumladan, bir nechta asosiy dizayn/arxitektura tamoyillari orqali erishilganini ko'rib chiqaylik.

dizayn

Kub ustidagi kub va chuqurchalar

Markazlashtirilgan ierarxiyadan farqli o'laroq, hujayraga asoslangan arxitektura odatda platformani bitta ma'lumot markazidan tashqariga kengaytirish yoki falokatni tiklash ko'lamini kengaytirish uchun ishlatiladi.

Alibaba bulutidagi har bir mintaqa bir nechta zonalardan (AZ) iborat va odatda ma'lum bir ma'lumot markaziga mos keladi. Katta mintaqada (masalan, Xuanchjou) ko'pincha ACK bilan ishlaydigan minglab Kubernetes mijozlar klasterlari mavjud.

ACK ushbu Kubernetes klasterlarini Kubernetes-ning o'zidan foydalanib boshqaradi, ya'ni bizda Kubernetes klasterlari mijozini boshqarish uchun ishlaydigan Kubernetes metaklaster mavjud. Ushbu arxitektura "kube-on-kube" (KoK) deb ham ataladi. KoK arxitekturasi mijozlar klasterlarini boshqarishni soddalashtiradi, chunki klasterni joylashtirish oddiy va deterministikdir. Eng muhimi, biz mahalliy Kubernetes xususiyatlaridan qayta foydalanishimiz mumkin. Masalan, API serverlarini joylashtirish orqali boshqarish, bir nechta etcdlarni boshqarish uchun etcd operatoridan foydalanish. Bunday rekursiya har doim alohida zavq keltiradi.

Mijozlar soniga qarab bir nechta Kubernetes metaklasterlari bitta hududda joylashtirilgan. Biz bu metaklasterlarni hujayralar deb ataymiz. Butun zonaning ishdan chiqishidan himoya qilish uchun ACK bir hududda ko‘p faol joylashtirishni qo‘llab-quvvatlaydi: metaklaster Kubernetes mijoz klasterining asosiy komponentlarini bir nechta zonalar bo‘ylab tarqatadi va ularni bir vaqtning o‘zida, ya’ni ko‘p faol rejimda ishga tushiradi. Magistrning ishonchliligi va samaradorligini ta'minlash uchun ACK komponentlarni joylashtirishni optimallashtiradi va API serveri va boshqalar bir-biriga yaqin bo'lishini ta'minlaydi.

Ushbu model sizga Kubernetes-ni samarali, moslashuvchan va ishonchli boshqarish imkonini beradi.

Metaklaster resurslarini rejalashtirish

Yuqorida aytib o'tganimizdek, har bir mintaqadagi metaklasterlar soni mijozlar soniga bog'liq. Lekin qaysi nuqtada yangi metaklaster qo'shish kerak? Bu resurslarni rejalashtirishning odatiy muammosi. Qoida tariqasida, mavjud metaklasterlar barcha resurslarini tugatgandan so'ng, yangisini yaratish odatiy holdir.

Masalan, tarmoq resurslarini olaylik. KoK arxitekturasida mijoz klasterlaridagi Kubernetes komponentlari metaklasterda pods sifatida joylashtirilgan. Biz foydalanamiz Terway (3-rasm) konteyner tarmoqlarini boshqarish uchun Alibaba Cloud tomonidan ishlab chiqilgan yuqori samarali plagindir. U xavfsizlik siyosatlarining boy to‘plamini taqdim etadi va Alibaba bulutli elastik tarmoq interfeysi (ENI) orqali mijozlarning virtual shaxsiy bulutlariga (VPC) ulanish imkonini beradi. Tarmoq resurslarini metaklasterdagi tugunlar, podlar va xizmatlar bo'ylab samarali taqsimlash uchun biz virtual xususiy bulutlar metaklasterida ulardan foydalanishni diqqat bilan kuzatishimiz kerak. Tarmoq resurslari tugagach, yangi hujayra yaratiladi.

Har bir metaklasterda mijozlar klasterlarining maqbul sonini aniqlash uchun biz xarajatlarimizni, zichlik talablarini, resurslar kvotasi, ishonchlilik talablari va statistikani ham hisobga olamiz. Ushbu ma'lumotlarning barchasi asosida yangi metaklaster yaratish qarori qabul qilinadi. E'tibor bering, kichik klasterlar kelajakda sezilarli darajada kengayishi mumkin, shuning uchun klasterlar soni o'zgarmagan taqdirda ham resurslar iste'moli ortadi. Odatda har bir klaster o'sishi uchun etarli bo'sh joy qoldiramiz.

Guruch. 3. Terway tarmog'i arxitekturasi

Mijoz klasterlari bo'ylab masshtablash ustasi komponentlari

Sehrgar komponentlari turli xil resurs ehtiyojlariga ega. Ular klasterdagi tugunlar va podslar soniga, APIServer bilan o'zaro aloqada bo'lgan nostandart kontrollerlar/operatorlar soniga bog'liq.

ACK-da har bir Kubernetes mijoz klasteri hajmi va ish vaqti talablari bilan farqlanadi. Sehrgar komponentlarini joylashtirish uchun universal konfiguratsiya mavjud emas. Agar biz xato qilib katta mijoz uchun past resurs chegarasini o'rnatgan bo'lsak, unda uning klasteri yukni bardosh bera olmaydi. Agar siz barcha klasterlar uchun konservativ tarzda yuqori chegara qo'ysangiz, resurslar behuda ketadi.

Ishonchlilik va narx o'rtasidagi nozik kelishuvni topish uchun ACK tip tizimidan foydalanadi. Ya'ni, biz klasterlarning uchta turini aniqlaymiz: kichik, o'rta va katta. Har bir tur alohida resurslarni taqsimlash profiliga ega. Turi sehrgar komponentlarining yuki, tugunlar soni va boshqa omillar asosida aniqlanadi. Klaster turi vaqt o'tishi bilan o'zgarishi mumkin. ACK ushbu omillarni doimiy ravishda kuzatib boradi va shunga mos ravishda yuqoriga/pastga yozishi mumkin. Klaster turi o'zgartirilgandan so'ng, resurslarni taqsimlash foydalanuvchining minimal aralashuvi bilan avtomatik ravishda yangilanadi.

Biz ushbu tizimni yanada aniqroq masshtablash va turni yanada aniqroq yangilash bilan takomillashtirish ustida ishlayapmiz, shunda bu o‘zgarishlar yanada muammosiz sodir bo‘ladi va iqtisodiy ma’noga ega bo‘ladi.

Guruch. 4. Intellektual ko'p bosqichli turdagi almashtirish

Mijoz klasterlarining miqyosda evolyutsiyasi

Oldingi bo'limlar ko'p sonli Kubernetes klasterlarini boshqarishning ba'zi jihatlarini qamrab oldi. Biroq, hal qilinishi kerak bo'lgan yana bir muammo bor: klasterlar evolyutsiyasi.

Kubernetes bulutli dunyoning "Linux" dir. U doimiy ravishda yangilanadi va modulli bo'ladi. Biz doimiy ravishda mijozlarimizga yangi versiyalarni etkazib berishimiz, zaifliklarni tuzatishimiz va mavjud klasterlarni yangilashimiz, shuningdek, ko'plab tegishli komponentlarni (CSI, CNI, Device Plugin, Scheduler Plugin va boshqalar) boshqarishimiz kerak.

Misol tariqasida Kubernetes komponentlarini boshqarishni olaylik. Boshlash uchun biz ushbu bog'langan komponentlarni ro'yxatga olish va boshqarish uchun markazlashtirilgan tizimni ishlab chiqdik.

Guruch. 5. Moslashuvchan va ulanadigan komponentlar

Oldinga o'tishdan oldin, yangilanish muvaffaqiyatli bo'lganiga ishonch hosil qilishingiz kerak. Buning uchun biz komponentlarning funksionalligini tekshirish tizimini ishlab chiqdik. Tekshirish yangilanishdan oldin va keyin amalga oshiriladi.

Guruch. 6. Klaster komponentlarini dastlabki tekshirish

Ushbu komponentlarni tez va ishonchli yangilash uchun uzluksiz joylashtirish tizimi qisman oshirish (kulrang rang), pauzalar va boshqa funktsiyalarni qo'llab-quvvatlaydi. Standart Kubernetes kontrollerlari ushbu foydalanish holatiga mos kelmaydi. Shuning uchun, klaster komponentlarini boshqarish uchun biz plagin va yordamchi boshqaruv modulini (yonboshli boshqaruv) o'z ichiga olgan maxsus kontrollerlar to'plamini ishlab chiqdik.

Masalan, BroadcastJob boshqaruvchisi har bir ishchi mashinasidagi komponentlarni yangilash yoki har bir mashinadagi tugunlarni tekshirish uchun mo'ljallangan. Broadcast ishi DaemonSet kabi klasterdagi har bir tugunda podkastni boshqaradi. Biroq, DaemonSet har doim podkastni uzoq vaqt ishlaydi, BroadcastJob esa uni buzadi. Broadcast kontrolleri, shuningdek, yangi qo'shilgan tugunlarda podlarni ishga tushiradi va tugunlarni kerakli komponentlar bilan ishga tushiradi. 2019 yil iyun oyida biz OpenKruise avtomatlashtirish dvigatelining manba kodini ochdik, biz undan kompaniya ichida foydalanamiz.

Guruch. 7. OpenKurise barcha tugunlarda Broadcast vazifasini bajarilishini tashkil qiladi

Mijozlarga to'g'ri klaster konfiguratsiyasini tanlashda yordam berish uchun biz oldindan belgilangan profillar to'plamini taqdim etamiz, jumladan Serversiz, Edge, Windows va Yalang'och metall profillar. Landshaft kengayishi va mijozlarimizning ehtiyojlari o'sib borishi bilan biz zerikarli sozlash jarayonini soddalashtirish uchun ko'proq profillarni qo'shamiz.

Guruch. 8. Turli stsenariylar uchun kengaytirilgan va moslashuvchan klaster profillari

Ma'lumotlar markazlarida global kuzatuvchanlik

Quyidagi rasmda ko'rsatilganidek. 9, Alibaba Cloud Container bulutli xizmati dunyoning yigirmata mintaqasida joylashtirilgan. Ushbu miqyosni hisobga olgan holda, ACKning asosiy maqsadlaridan biri, agar mijoz klasteri muammoga duch kelsa, biz vaziyatga tezda javob bera olishimiz uchun ishlaydigan klasterlar holatini osongina kuzatishdir. Boshqacha qilib aytganda, siz barcha hududlardagi mijozlar klasterlaridan real vaqt rejimida statistik ma’lumotlarni samarali va xavfsiz to‘plash va natijalarni vizual tarzda taqdim etish imkonini beradigan yechimni topishingiz kerak.

Guruch. 9. Alibaba Cloud Container xizmatini yigirmata mintaqada global joylashtirish

Ko'pgina Kubernetes monitoring tizimlari singari biz Prometeyni asosiy vositamiz sifatida ishlatamiz. Har bir metaklaster uchun Prometey agentlari quyidagi ko'rsatkichlarni to'playdi:

• Xost resurslari (CPU, xotira, disk va boshqalar) va tarmoq o'tkazish qobiliyati kabi OT ko'rsatkichlari.
• Kube-apiserver, kube-nazoratchi-menejer va kube-rejalashtiruvchi kabi metaklaster va mijozlar klasterini boshqarish tizimi uchun ko'rsatkichlar.
• Kubernetes-state-metrics va cadvisordan ko'rsatkichlar.
• disk yozish vaqti, ma'lumotlar bazasi hajmi, tugunlar orasidagi havolalarning o'tkazuvchanligi va boshqalar kabi ko'rsatkichlar.

Global statistika odatda ko'p qatlamli yig'ish modeli yordamida yig'iladi. Har bir metaklasterdan monitoring ma'lumotlari birinchi navbatda har bir mintaqada jamlanadi va keyin umumiy rasmni ko'rsatadigan markaziy serverga yuboriladi. Hamma narsa federatsiya mexanizmi orqali ishlaydi. Har bir maʼlumot markazidagi Prometey serveri ushbu maʼlumotlar markazidan koʻrsatkichlarni toʻplaydi va markaziy Prometey serveri monitoring maʼlumotlarini yigʻish uchun masʼuldir. AlertManager markaziy Prometeyga ulanadi va kerak bo'lganda DingTalk, elektron pochta, SMS va boshqalar orqali ogohlantirishlar yuboradi. Vizualizatsiya - Grafana yordamida.

10-rasmda monitoring tizimini uch darajaga bo'lish mumkin:

• Chegara darajasi

Markazdan eng uzoqda joylashgan qatlam. Prometheus Edge Server har bir metaklasterda ishlaydi va bir xil tarmoq domenidagi meta va mijoz klasterlaridan ko'rsatkichlarni to'playdi.

• Kaskad darajasi

Prometey kaskad qatlamining vazifasi bir nechta mintaqalardan monitoring ma'lumotlarini yig'ishdir. Ushbu serverlar Xitoy, Osiyo, Yevropa va Amerika kabi yirik geografik birliklar darajasida ishlaydi. Klasterlar o'sishi bilan mintaqani bo'lish mumkin, keyin har bir yangi yirik mintaqada kaskad darajasidagi Prometey serveri paydo bo'ladi. Ushbu strategiya yordamida siz kerak bo'lganda muammosiz o'lchov qilishingiz mumkin.

• Markaziy daraja

Markaziy Prometey serveri barcha kaskad serverlariga ulanadi va yakuniy ma'lumotlarni yig'ishni amalga oshiradi. Ishonchliligi uchun ikkita markaziy Prometey nusxasi bir xil kaskad serverlariga ulangan turli zonalarda ko'tarildi.

Guruch. 10. Prometey federatsiyasi mexanizmiga asoslangan global ko'p darajali monitoring arxitekturasi

Xulosa

Kubernetes-ga asoslangan bulutli echimlar sanoatimizni o'zgartirishda davom etmoqda. Alibaba Cloud konteyner xizmati xavfsiz, ishonchli va yuqori unumdor hostingni ta'minlaydi - bu Kubernetes bulutli hostingning eng yaxshilaridan biridir. Alibaba Cloud jamoasi Open Source va ochiq manba hamjamiyatining tamoyillariga qattiq ishonadi. Biz, albatta, bulutli texnologiyalarni boshqarish va boshqarish sohasidagi bilimlarimizni baham ko'rishda davom etamiz.

Manba: www.habr.com