URUS kompaniyasi Kubernetes-ni turli shakllarda sinab ko'rdi: yalang'och metallda, Google Cloud-da mustaqil joylashtirish va keyin o'z platformasini Mail.ru Cloud Solutions (MCS) bulutiga o'tkazdi. Igor Shishkin ular qanday qilib yangi bulut provayderini tanlaganliklari va unga ikki soat ichida rekord darajada o'tishga muvaffaq bo'lganliklarini aytib beradi (), URUS kompaniyasining katta tizim administratori.
URUS nima qiladi?
Shahar atrof-muhit sifatini yaxshilashning ko'plab usullari mavjud bo'lib, ulardan biri uni ekologik toza qilishdir. URUS - Smart Digital Services kompaniyasi aynan shu narsa ustida ishlamoqda. Bu erda ular korxonalarga muhim ekologik ko'rsatkichlarni kuzatish va ularning atrof-muhitga salbiy ta'sirini kamaytirishga yordam beradigan echimlarni amalga oshiradilar. Sensorlar havo tarkibi, shovqin darajasi va boshqa parametrlar bo‘yicha ma’lumotlarni to‘playdi, so‘ngra ularni tahlil qilish va tavsiyalar berish uchun yagona URUS-Ekomon platformasiga yuboradi.
URUS ichkaridan qanday ishlaydi
URUSning odatiy mijozi - bu turar-joy hududida yoki uning yaqinida joylashgan kompaniya. Bu zavod, port, temir yo'l deposi yoki boshqa ob'ekt bo'lishi mumkin. Agar mijozimiz allaqachon ogohlantirish olgan bo'lsa, atrof-muhitni ifloslantirgani uchun jarimaga tortilgan yoki kamroq shovqin qilishni, zararli chiqindilar miqdorini kamaytirishni xohlasa, u bizga keladi va biz unga atrof-muhit monitoringi uchun tayyor echimni taklif qilamiz.
H2S kontsentratsiyasi monitoringi grafigi yaqin atrofdagi zavoddan muntazam tungi chiqindilarni ko'rsatadi
URUS da biz foydalanadigan qurilmalarda atrof-muhit holatini baholash uchun ma'lum gazlar tarkibi, shovqin darajasi va boshqa ma'lumotlar haqida ma'lumot to'playdigan bir nechta sensorlar mavjud. Datchiklarning aniq soni har doim aniq vazifa bilan belgilanadi.
O'lchovlarning o'ziga xos xususiyatlariga qarab, datchikli qurilmalar binolarning devorlariga, qutblarga va boshqa o'zboshimchalik bilan joylashtirilishi mumkin. Har bir bunday qurilma ma'lumotlarni to'playdi, uni jamlaydi va ma'lumotlarni qabul qiluvchi shlyuzga yuboradi. U erda biz ma'lumotlarni uzoq muddatli saqlash uchun saqlaymiz va keyingi tahlil uchun oldindan qayta ishlaymiz. Tahlil natijasida olingan narsalarning eng oddiy misoli AQI deb ham ataladigan havo sifati indeksidir.
Bunga parallel ravishda bizning platformamizda boshqa ko'plab xizmatlar ishlaydi, lekin ular asosan xizmat ko'rsatish xususiyatiga ega. Misol uchun, agar kuzatilayotgan parametrlardan biri (masalan, CO2 tarkibi) ruxsat etilgan qiymatdan oshib ketgan bo'lsa, bildirishnoma xizmati mijozlarga bildirishnomalarni yuboradi.
Biz ma'lumotlarni qanday saqlaymiz. Yalang'och metallda Kubernetesning hikoyasi
URUS atrof-muhit monitoringi loyihasi bir nechta ma'lumotlar omboriga ega. Birida biz "xom" ma'lumotlarni saqlaymiz - biz to'g'ridan-to'g'ri qurilmalarning o'zidan olgan narsamiz. Ushbu saqlash "magnit" lenta bo'lib, eski kasetlarda bo'lgani kabi, barcha ko'rsatkichlar tarixiga ega. Ikkinchi turdagi saqlash oldindan qayta ishlangan ma'lumotlar uchun ishlatiladi - sensorlar o'rtasidagi ulanishlar va qurilmalarning o'qishlari, tashkilotlarga aloqadorligi, joylashuvi va boshqalar haqidagi metama'lumotlar bilan boyitilgan qurilmalar ma'lumotlari. ma'lum bir vaqt ichida o'zgardi. Biz "xom" ma'lumotlar omboridan boshqa narsalar qatori zaxira sifatida va agar zarurat tug'ilsa, qayta ishlangan ma'lumotlarni qayta tiklash uchun foydalanamiz.
Bir necha yil oldin biz saqlash muammosini hal qilmoqchi bo'lganimizda, ikkita platforma tanlovi bor edi: Kubernetes va OpenStack. Ammo ikkinchisi juda dahshatli ko'rinadiganligi sababli (bunga ishonch hosil qilish uchun uning arxitekturasiga qarang), biz Kubernetesga joylashdik. Uning foydasiga yana bir dalil nisbatan oddiy dasturiy ta'minotni boshqarish, resurslarga ko'ra hatto apparat tugunlarini ham moslashuvchan tarzda kesish qobiliyati edi.
Kubernetes-ning o'zini o'zlashtirish bilan bir qatorda, biz ma'lumotlarni saqlash usullarini ham o'rgandik, Kubernetes-dagi barcha saqlashimizni o'z uskunamizda saqlagan holda, biz mukammal tajribaga ega bo'ldik. Biz Kubernetesda yashagan hamma narsa: to'liq saqlash, monitoring tizimi, CI/CD. Kubernetes biz uchun yaxlit platformaga aylandi.
Ammo biz Kubernetes bilan xizmat sifatida ishlashni va uni qo'llab-quvvatlash va rivojlantirish bilan shug'ullanmaslikni xohladik. Bundan tashqari, biz uni yalang'och metallda saqlash qanchalik qimmatga tushganini yoqtirmadik va biz doimo rivojlanishga muhtoj edik! Masalan, birinchi vazifalardan biri Kubernetes Ingress kontrollerlarini tashkilotimizning tarmoq infratuzilmasiga integratsiya qilish edi. Bu juda og'ir vazifa, ayniqsa o'sha paytda DNS yozuvlari yoki IP manzillarini taqsimlash kabi dasturiy resurslarni boshqarish uchun hech narsa tayyor emasligini hisobga olsak. Keyinchalik biz tashqi ma'lumotlarni saqlash bilan tajriba o'tkaza boshladik. Biz hech qachon PVX kontrollerni joriy qilish bilan shug'ullanmadik, lekin shunga qaramay, bu maxsus mutaxassislarni talab qiladigan katta ish sohasi ekanligi ayon bo'ldi.
Google Cloud Platform-ga o'tish vaqtinchalik yechimdir
Biz buni davom ettira olmasligini tushundik va maʼlumotlarimizni yalangʻoch metalldan Google Cloud Platform-ga oʻtkazdik. Darhaqiqat, o'sha paytda rus kompaniyasi uchun juda ko'p qiziqarli variantlar mavjud emas edi: Google Cloud Platform-dan tashqari, faqat Amazon shunga o'xshash xizmatni taklif qildi, ammo biz hali ham Google-dan yechim topdik. Keyin biz uchun iqtisodiy jihatdan foydaliroq, Upstreamga yaqinroq bo'lib tuyuldi, Google-ning o'zi ishlab chiqarishda PoC Kubernetes turi ekanligini hisobga olmaganda.
Mijozlar bazamiz o'sishi bilan birinchi katta muammo ufqda paydo bo'ldi. Shaxsiy ma'lumotlarni saqlash zarurati tug'ilganda, biz tanlovga duch keldik: biz Google bilan ishlaymiz va Rossiya qonunlarini buzamiz yoki biz Rossiya Federatsiyasida muqobilni qidiramiz. Umuman olganda, tanlovni oldindan aytish mumkin edi. 🙂
Biz ideal bulut xizmatini qanday ko'rdik
Qidiruv boshlanishida biz kelajakdagi bulut provayderidan nimani olishni xohlayotganimizni allaqachon bilardik. Biz qanday xizmatni qidirdik:
- Tez va moslashuvchan. Shunday qilib, biz istalgan vaqtda tezda yangi tugun qo'shishimiz yoki biror narsani joylashtirishimiz mumkin.
- Arzon. Bizni moliyaviy masala juda xavotirga soldi, chunki resurslarimiz cheklangan edi. Biz Kubernetes bilan ishlashni xohlayotganimizni allaqachon bilardik va endi vazifa ushbu yechimdan foydalanish samaradorligini oshirish yoki hech bo'lmaganda saqlab qolish uchun uning narxini minimallashtirish edi.
- avtomatlashtirilgan. Biz menejerlarsiz va telefon qo'ng'iroqlarisiz yoki favqulodda rejimda bir necha o'nlab tugunlarni qo'lda ko'tarishimiz kerak bo'lgan vaziyatlarsiz API orqali xizmat bilan ishlashni rejalashtirdik. Ko'pgina jarayonlarimiz avtomatlashtirilganligi sababli, biz bulut xizmatidan ham xuddi shunday kutgan edik.
- Rossiya Federatsiyasidagi serverlar bilan. Albatta, biz Rossiya qonunchiligiga va xuddi shu 152-FZga rioya qilishni rejalashtirdik.
O'sha paytda Rossiyada Kubernetes aaS provayderlari kam edi va provayderni tanlashda biz uchun ustuvorliklarimizni buzmaslik muhim edi. Biz ish boshlagan va hozir ham hamkorlik qilayotgan Mail.ru Cloud Solutions jamoasi bizga to‘liq avtomatlashtirilgan xizmatni, API qo‘llab-quvvatlashini va Horizonni o‘z ichiga olgan qulay boshqaruv panelini taqdim etdi - bu bilan biz tezda o‘zboshimchalik bilan tugunlarni ko‘tarishimiz mumkin edi.
Qanday qilib biz MCS-ga ikki soat ichida o'tishga muvaffaq bo'ldik
Bunday harakatlarda ko'plab kompaniyalar qiyinchiliklarga va muvaffaqiyatsizlikka duch kelishadi, ammo bizning holatlarimizda ular yo'q edi. Bizga omad kulib boqdi: migratsiya boshlanishidan oldin Kubernetes ustida ishlaganimiz sababli, biz shunchaki uchta faylni tuzatdik va MCS yangi bulut platformasida xizmatlarimizni ishga tushirdik. Sizga eslatib o'tamanki, o'sha vaqtga qadar biz yalang'och metallni qoldirib, Google Cloud Platformida yashadik. Shuning uchun, harakatning o'zi ikki soatdan ko'proq vaqtni oldi, shuningdek, bizning qurilmalarimizdan ma'lumotlarni nusxalash uchun biroz ko'proq vaqt (taxminan bir soat) sarflandi. O'sha paytda biz allaqachon Spinnaker (uzluksiz yetkazib berish uchun ko'p bulutli CD xizmati) dan foydalanardik. Biz uni tezda yangi klasterga qo'shdik va odatdagidek ishlashni davom ettirdik.
Rivojlanish jarayonlari va CI/CDni avtomatlashtirish tufayli URUSdagi Kubernetes bir mutaxassis tomonidan boshqariladi (va bu men). Ba'zi bosqichlarda men bilan boshqa tizim ma'muri ishladi, ammo keyin ma'lum bo'ldiki, biz barcha asosiy tartibni avtomatlashtirdik va bizning asosiy mahsulotimizda tobora ko'proq vazifalar bor edi va resurslarni bunga yo'naltirish mantiqiy edi.
Biz bulut provayderidan kutgan narsamizni oldik, chunki biz xayollarsiz hamkorlikni boshladik. Agar biron bir voqea sodir bo'lgan bo'lsa, ular asosan texnik va xizmatning nisbiy yangiligi bilan oson tushuntirilishi mumkin edi. Asosiysi, MCS jamoasi kamchiliklarni tezda bartaraf etadi va messenjerlardagi savollarga tezkor javob beradi.
Agar men o'z tajribamni Google Cloud Platform bilan solishtiradigan bo'lsam, ularda men fikr-mulohaza tugmasi qayerda ekanligini ham bilmasdim, chunki bunga ehtiyoj yo'q edi. Va agar biron bir muammo yuzaga kelsa, Google o'zi bir tomonlama ravishda bildirishnomalarni yuboradi. Ammo MCS misolida, menimcha, katta afzallik shundaki, ular rossiyalik mijozlarga - geografik va ruhiy jihatdan imkon qadar yaqin.
Kelajakda bulutlar bilan ishlashni qanday ko'ramiz
Endi bizning ishimiz Kubernetes bilan chambarchas bog'liq va u bizga infratuzilma vazifalari nuqtai nazaridan to'liq mos keladi. Shu sababli, biz undan hech qayerga ko‘chib o‘tishni rejalashtirmayapmiz, garchi biz muntazam vazifalarni soddalashtirish va yangilarini avtomatlashtirish, xizmatlarning barqarorligi va ishonchliligini oshirish uchun doimiy ravishda yangi amaliyot va xizmatlarni joriy etayotgan bo‘lsak ham... Biz hozir Chaos Monkey xizmatini ishga tushirmoqdamiz (xususan, , biz chaoskube-dan foydalanamiz, lekin bu kontseptsiyani o'zgartirmaydi: ), dastlab Netflix tomonidan yaratilgan. Chaos Monkey bitta oddiy narsani qiladi: u tasodifiy Kubernetes podini tasodifiy vaqtda o'chiradi. Bu bizning xizmatimiz n–1 misollar soni bilan normal yashashi uchun zarur, shuning uchun biz o'zimizni har qanday muammolarga tayyor bo'lishga o'rgatamiz.
Endi men uchinchi tomon yechimlaridan foydalanishni - bir xil bulutli platformalarni - yosh kompaniyalar uchun yagona to'g'ri narsa deb bilaman. Odatda, sayohatning boshida ular insoniy va moliyaviy resurslarda cheklangan va o'zlarining bulut yoki ma'lumotlar markazini qurish va saqlash juda qimmat va mehnat talab qiladi. Bulutli provayderlar sizga ushbu xarajatlarni minimallashtirishga imkon beradi, siz ulardan xizmatlarning ishlashi uchun zarur bo'lgan resurslarni shu erda va hozir olishingiz va undan keyin ushbu resurslar uchun to'lashingiz mumkin. URUS kompaniyasiga kelsak, biz hozircha bulutdagi Kubernetesga sodiq qolamiz. Ammo kim biladi, biz geografik jihatdan kengaytirishimiz yoki ba'zi maxsus jihozlarga asoslangan echimlarni amalga oshirishimiz kerak bo'lishi mumkin. Yoki, ehtimol, iste'mol qilingan resurslar miqdori eski kunlardagi kabi, yalang'och metallda o'z Kubernetlarini oqlaydi. 🙂
Bulutli xizmatlar bilan ishlashdan nimani o'rgandik
Biz Kubernetesni yalang'och metallda ishlatishni boshladik va hatto u erda ham o'ziga xos tarzda yaxshi edi. Ammo uning kuchli tomonlari bulutdagi aaS komponenti sifatida aniq namoyon bo'ldi. Agar siz o'z oldingizga maqsad qo'ysangiz va hamma narsani iloji boricha avtomatlashtirsangiz, sotuvchilarni blokirovka qilishdan qochishingiz mumkin va bulutli provayderlar o'rtasida harakatlanish bir necha soat davom etadi va asab hujayralari biz bilan qoladi. Biz boshqa kompaniyalarga maslahat berishimiz mumkin: agar siz cheklangan resurslarga va rivojlanish uchun maksimal tezlikka ega boʻlgan oʻz (bulut) xizmatingizni ishga tushirmoqchi boʻlsangiz, hoziroq bulutli resurslarni ijaraga olishdan boshlang va Forbes siz haqingizda yozganidan keyin maʼlumotlar markazingizni yarating.
Manba: www.habr.com