Eslatma. tarjima.: GitLab-da Kubernetesni qabul qilish kompaniyaning o'sishiga hissa qo'shadigan ikkita asosiy omildan biri hisoblanadi. Biroq, yaqin vaqtgacha GitLab.com onlayn-xizmati infratuzilmasi virtual mashinalarda qurilgan va atigi bir yil oldin uning K8-ga ko'chishi boshlangan, bu hali ham tugallanmagan. Biz GitLab SRE muhandisining bu qanday sodir bo'lishi va loyihada ishtirok etayotgan muhandislar qanday xulosalar chiqarishi haqidagi yaqinda chop etilgan maqolasining tarjimasini taqdim etishdan mamnunmiz.
Taxminan bir yil davomida bizning infratuzilma bo'limimiz GitLab.com saytida ishlaydigan barcha xizmatlarni Kubernetesga ko'chirmoqda. Shu vaqt ichida biz nafaqat xizmatlarni Kubernetesga ko'chirish, balki o'tish davrida gibrid joylashtirishni boshqarish bilan bog'liq muammolarga duch keldik. Biz olgan qimmatli saboqlar ushbu maqolada muhokama qilinadi.
GitLab.com ning boshidanoq uning serverlari virtual mashinalarda bulutda ishlagan. Ushbu virtual mashinalar Chef tomonidan boshqariladi va bizning yordamida o'rnatiladi . agar dastur yangilanishi kerak bo'lsa, CI quvur liniyasidan foydalangan holda serverlar parkini muvofiqlashtirilgan, ketma-ket yangilashdan iborat. Bu usul - sekin va bir oz bo'lsa ham - GitLab.com oflayn foydalanuvchilar bilan bir xil o'rnatish va sozlash amaliyotlaridan foydalanishini ta'minlaydi (o'zini o'zi boshqaradigan) Buning uchun Linux paketlarimizdan foydalangan holda GitLab o'rnatish.
Biz ushbu usuldan foydalanamiz, chunki GitLab nusxalarini o'rnatish va sozlashda jamiyatning oddiy a'zolari boshdan kechiradigan barcha qayg'u va quvonchlarni boshdan kechirish juda muhim. Ushbu yondashuv bir muncha vaqt yaxshi ishladi, lekin GitLab-dagi loyihalar soni 10 milliondan oshganida, biz endi u bizning masshtablash va joylashtirish ehtiyojlarimizga javob bermasligini angladik.
Kubernetes va bulutli GitLab ga birinchi qadamlar
Loyiha 2017 yilda yaratilgan GitLab-ni bulutli joylashtirishga tayyorlash va foydalanuvchilarga GitLab-ni Kubernetes klasterlariga o'rnatish imkonini berish. O‘shanda biz GitLab-ni Kubernetes-ga ko‘chirish SaaS platformasining miqyosliligini oshirishini, joylashtirishni soddalashtirishini va hisoblash resurslari samaradorligini oshirishini bilardik. Shu bilan birga, bizning ilovamizning ko'pgina funktsiyalari o'rnatilgan NFS bo'limlariga bog'liq edi, bu virtual mashinalardan o'tishni sekinlashtirdi.
Bulut va Kubernetesga intilish bizning muhandislarimizga bosqichma-bosqich o'tishni rejalashtirish imkonini berdi, bunda biz yangi xususiyatlarni ishlab chiqishda davom etgan holda ilovaning tarmoq xotirasiga bog'liqligidan voz kechdik. 2019 yilning yozida migratsiyani rejalashtirishni boshlaganimizdan beri ushbu cheklovlarning aksariyati hal qilindi va GitLab.com saytini Kubernetesga ko'chirish jarayoni hozirda davom etmoqda!
Kubernetesdagi GitLab.com xususiyatlari
GitLab.com uchun biz barcha ilovalar trafigini boshqaradigan yagona mintaqaviy GKE klasteridan foydalanamiz. Migratsiya (allaqachon qiyin) murakkabligini minimallashtirish uchun biz mahalliy saqlash yoki NFSga tayanmaydigan xizmatlarga e'tibor qaratamiz. GitLab.com asosan monolit Rails kod bazasidan foydalanadi va biz ish yuki xususiyatlariga asoslanib, trafikni o'zlarining tugun hovuzlarida ajratilgan turli so'nggi nuqtalarga yo'naltiramiz.
Frontend holatida bu turlar veb, API, Git SSH/HTTPS va Registry so'rovlariga bo'linadi. Backend holatida biz navbatdagi ishlarni har xil xususiyatlarga qarab ajratamiz , bu bizga turli xil ish yuklari uchun Xizmat darajasidagi maqsadlarni (SLOs) o'rnatishga imkon beradi.
Ushbu GitLab.com xizmatlarining barchasi o'zgartirilmagan GitLab Helm diagrammasi yordamida tuzilgan. Konfiguratsiya pastki diagrammalarda amalga oshiriladi, biz xizmatlarni bosqichma-bosqich klasterga o'tkazganimizda, ularni tanlab yoqish mumkin. Redis, Postgres, GitLab Pages va Gitaly kabi baʼzi davlat xizmatlarimizni migratsiyaga qoʻshmaslikka qaror qilgan boʻlsak ham, Kubernetes-dan foydalanish bizga hozirda Chef boshqarayotgan VMlar sonini tubdan kamaytirish imkonini beradi.
Kubernetes konfiguratsiyasining ko'rinishi va boshqaruvi
Barcha sozlamalar GitLab tomonidan boshqariladi. Buning uchun Terraform va Helm-ga asoslangan uchta konfiguratsiya loyihasi qo'llaniladi. Iloji bo'lsa, biz GitLab-ni ishga tushirish uchun GitLab-dan foydalanishga harakat qilamiz, ammo operatsion vazifalar uchun bizda alohida GitLab o'rnatilishi mavjud. Bu GitLab.com tarqatish va yangilanishlarni amalga oshirishda GitLab.com mavjudligiga bog'liq emasligingizni ta'minlash uchun kerak.
Kubernetes klasteri uchun quvurlarimiz alohida GitLab o'rnatilishida ishlayotgan bo'lsa-da, quyidagi manzillarda ochiq bo'lgan kod omborlarining ko'zgulari mavjud:
- — GitLab Helm diagrammasi uchun GitLab.com konfiguratsiya ramkasi;
- - GitLab ilovasi bilan bevosita bog'lanmagan xizmatlar uchun konfiguratsiyalarni o'z ichiga oladi. Bular ro'yxatga olish va klaster monitoringi uchun konfiguratsiyalar, shuningdek, PlantUML kabi o'rnatilgan vositalarni o'z ichiga oladi;
- — Kubernetes va eski VM infratuzilmasi uchun terraform konfiguratsiyasi. Bu erda siz klasterni ishga tushirish uchun zarur bo'lgan barcha resurslarni, jumladan, klasterning o'zi, tugunlar hovuzlari, xizmat hisoblari va IP manzil zahiralarini sozlaysiz.
O'zgartirishlar kiritilganda ommaviy ko'rinish ko'rsatiladi. klasterga o'zgartirish kiritishdan oldin SRE tahlil qiladigan batafsil farqga havola bilan.
SRE uchun havola ishlab chiqarish uchun ishlatiladigan va kirish cheklangan GitLab o'rnatilishida batafsil farqga olib keladi. Bu ishchilar va hamjamiyatga operatsion loyihaga (faqat SRElar uchun ochiq) kirish huquqiga ega bo'lmagan holda taklif qilingan konfiguratsiya o'zgarishlarini ko'rish imkonini beradi. Kod uchun ommaviy GitLab nusxasini CI quvurlari uchun shaxsiy nusxa bilan birlashtirib, biz konfiguratsiya yangilanishlari uchun GitLab.com dan mustaqillikni ta'minlagan holda yagona ish jarayonini saqlaymiz.
Migratsiya paytida biz nimani bilib oldik
Ko'chib o'tish paytida biz Kubernetesda yangi migratsiya va joylashtirishlarga qo'llanadigan tajriba orttirildi.
1. Mavjud zonalar orasidagi transport tufayli xarajatlarning oshishi
GitLab.com saytidagi Git omborlari floti uchun kunlik chiqish statistikasi (kuniga bayt)
Google o'z tarmog'ini hududlarga ajratadi. Ular, o'z navbatida, qulaylik zonalariga (AZ) bo'linadi. Git xostingi katta hajmdagi ma'lumotlar bilan bog'liq, shuning uchun biz uchun tarmoqdan chiqishni nazorat qilish muhim. Ichki trafik uchun chiqish faqat bir xil mavjudlik zonasida qolsa, bepul bo'ladi. Ushbu yozuvni yozish paytida biz odatdagi ish kunida taxminan 100 TB ma'lumotlarga xizmat qilamiz (va bu faqat Git omborlari uchun). Bizning eski VM-ga asoslangan topologiyamizdagi bir xil virtual mashinalarda joylashgan xizmatlar endi turli Kubernetes podslarida ishlaydi. Bu shuni anglatadiki, ilgari VM uchun mahalliy bo'lgan ba'zi trafik potentsial mavjudlik zonalaridan tashqariga chiqishi mumkin.
Mintaqaviy GKE klasterlari ortiqcha uchun bir nechta mavjudlik zonalarini qamrab olish imkonini beradi. Biz imkoniyatni ko'rib chiqyapmiz katta hajmdagi trafikni yaratadigan xizmatlar uchun. Bu klaster darajasidagi ortiqchalikni saqlab, chiqish xarajatlarini kamaytiradi.
2. Limitlar, resurs so'rovlari va masshtablash
registry.gitlab.com saytida ishlab chiqarish trafigini qayta ishlovchi replikalar soni. Trafik cho'qqisiga UTC ~15:00 da tushadi.
Migratsiya hikoyamiz 2019-yil avgust oyida, birinchi xizmatimiz GitLab konteyner registrini Kubernetes-ga ko‘chirganimizda boshlangan. Bu juda muhim, yuqori trafikli xizmat birinchi migratsiya uchun yaxshi tanlov bo‘ldi, chunki u bir nechta tashqi bog‘liqliklarga ega fuqaroligi bo‘lmagan ilovadir. Biz duch kelgan birinchi muammo tugunlarda xotira yo'qligi sababli ko'p sonli ko'chirilgan podalar edi. Shu sababli biz so'rovlar va cheklovlarni o'zgartirishga majbur bo'ldik.
Aniqlanishicha, vaqt o'tishi bilan xotira iste'moli ortib borayotgan dasturda so'rovlar uchun past qiymatlar (har bir pod uchun zaxira xotirasi) va "saxiy" foydalanishning qattiq chegarasi to'yinganlikka olib keldi. (to'yinganlik) tugunlar va ko'chirishning yuqori darajasi. Bu muammo bilan shug'ullanish uchun, bu edi . Bu tugunlardagi bosimni olib tashladi va podkalarning tugunga ortiqcha bosim o'tkazmaydigan hayot aylanishini ta'minladi. Endi biz saxiy (va deyarli bir xil) so'rov va chegara qiymatlari bilan migratsiyani boshlaymiz va kerak bo'lganda ularni moslashtiramiz.
3. Ko‘rsatkichlar va jurnallar
Infratuzilma bo'limi kechikish, xatolik darajasi va o'rnatilgan bilan to'yinganlikka e'tibor qaratadi (SLO) bilan bog'langan .
O'tgan yil davomida infratuzilma bo'limidagi muhim voqealardan biri bu SLOlarni monitoring qilish va ular bilan ishlashni yaxshilash bo'ldi. SLOlar bizga migratsiya paytida diqqat bilan kuzatib boradigan individual xizmatlar uchun maqsadlarni belgilashga imkon berdi. Biroq, kuzatuv qobiliyati yaxshilangan bo'lsa ham, ko'rsatkichlar va ogohlantirishlar yordamida muammolarni darhol ko'rish har doim ham mumkin emas. Masalan, kechikish va xatolik stavkalariga e'tibor qaratish orqali biz migratsiyadan o'tayotgan xizmatdan foydalanishning barcha holatlarini to'liq qamrab olmaymiz.
Bu muammo ba'zi ish yuklarini klasterga o'tkazgandan so'ng deyarli darhol aniqlandi. Bu, ayniqsa, so'rovlar soni kam bo'lgan, lekin konfiguratsiyaga juda aniq bog'liqliklarga ega bo'lgan funktsiyalarni tekshirishimiz kerak bo'lganda keskinlashdi. Migratsiyadan olingan asosiy saboqlardan biri monitoring qilishda nafaqat ko'rsatkichlarni, balki jurnallar va "uzun dum" ni ham hisobga olish zarurati edi. (bu haqida diagrammada - taxminan. tarjima.) xatolar. Endi har bir migratsiya uchun biz jurnal so'rovlarining batafsil ro'yxatini kiritamiz (so'rovlar jurnali) va agar muammolar yuzaga kelsa, bir smenadan ikkinchisiga o'tkazilishi mumkin bo'lgan aniq orqaga qaytarish protseduralarini rejalashtiring.
Eski VM infratuzilmasi va Kubernetesga asoslangan yangi infratuzilmada bir xil so'rovlarga parallel ravishda xizmat ko'rsatish o'ziga xos qiyinchilik tug'dirdi. Lift-va-shift migratsiyasidan farqli o'laroq (ilovalarni yangi infratuzilmaga "xuddi shunday" tez o'tkazish; batafsil ma'lumotni o'qish mumkin, masalan, - taxminan. tarjima.), "eski" VMlar va Kubernetes ustida parallel ishlash monitoring vositalarining ikkala muhitga mos kelishini va o'lchovlarni bir ko'rinishda birlashtira olishini talab qiladi. O'tish davrida izchil kuzatuvchanlikka erishish uchun bir xil asboblar paneli va jurnal so'rovlaridan foydalanishimiz muhim.
4. Trafikni yangi klasterga o'tkazish
GitLab.com uchun serverlarning bir qismi bag'ishlangan . Kanareyka Parki bizning ichki loyihalarimizga xizmat qiladi va bundan tashqari . Lekin u birinchi navbatda infratuzilma va dasturga kiritilgan o'zgarishlarni sinab ko'rish uchun mo'ljallangan. Birinchi migratsiya xizmati cheklangan miqdordagi ichki trafikni qabul qilish bilan boshlandi va biz ushbu usuldan barcha trafikni klasterga yuborishdan oldin SLOlar bajarilishini ta'minlash uchun foydalanishda davom etamiz.
Migratsiya holatida, bu ichki loyihalarga so'rovlar avval Kubernetes-ga yuborilishini anglatadi va keyin biz HAProxy orqali backend uchun og'irlikni o'zgartirib, qolgan trafikni asta-sekin klasterga o'tkazamiz. VM dan Kubernetes ga o'tish paytida, eski va yangi infratuzilma o'rtasida trafikni qayta yo'naltirishning oson usuliga ega bo'lish va shunga mos ravishda eski infratuzilmani migratsiyadan keyingi dastlabki bir necha kun ichida qaytarib olishga tayyor bo'lish juda foydali ekanligi ayon bo'ldi.
5. Po‘choqlarning zahira sig‘imlari va ulardan foydalanish
Deyarli darhol quyidagi muammo aniqlandi: Ro'yxatga olish xizmati uchun pods tez ishga tushdi, lekin Sidekiq uchun pods ishga tushirildi. . Sidekiq podslarini ishga tushirishning uzoq davom etishi biz ish yuklarini Kubernetesga ko‘chirishni boshlaganimizda muammo bo‘lib qoldi, ular uchun ishlarni tez qayta ishlash va tezlik bilan kengaytirish kerak edi.
Bunday holda, saboq shundan iborat ediki, Kubernetesning Horizontal Pod Autoscaler (HPA) traffikning o'sishini yaxshi boshqar ekan, ish yuklarining xususiyatlarini hisobga olish va podkastlarga zaxira sig'imlarni ajratish muhim (ayniqsa, talab notekis taqsimlanganda). Bizning holatlarimizda, ish o'rinlarining to'satdan o'sishi sodir bo'ldi, bu tez masshtabga olib keldi, bu esa tugunlar hovuzini o'lchashga ulgurmasdan oldin CPU resurslarining to'yinganligiga olib keldi.
Klasterdan imkon qadar ko'proq siqib chiqarish vasvasasi har doim bo'ladi, lekin dastlab ishlash bilan bog'liq muammolarga duch kelganimizdan so'ng, biz endi saxovatli pod byudjetidan boshlaymiz va SLOlarni diqqat bilan kuzatib, uni keyinroq qisqartiramiz. Sidekiq xizmati uchun podslarni ishga tushirish sezilarli darajada tezlashdi va endi o'rtacha 40 soniya davom etadi. GitLab.com saytida ham, rasmiy GitLab Helm diagrammasi bilan ishlaydigan o‘z-o‘zini boshqaradigan o‘rnatish foydalanuvchilarimizda ham g‘olib bo‘ldi.
xulosa
Har bir xizmatni ko‘chirib o‘tkazganimizdan so‘ng biz Kubernetes-dan ishlab chiqarishda foydalanishning afzalliklaridan xursand bo‘ldik: ilovalarni tezroq va xavfsizroq joylashtirish, masshtablash va resurslarni yanada samarali taqsimlash. Bundan tashqari, migratsiyaning afzalliklari GitLab.com xizmatidan tashqarida. Rasmiy Helm chartidagi har bir yaxshilanish o'z foydalanuvchilariga foyda keltiradi.
Umid qilamanki, sizga bizning Kubernetes migratsiya sarguzashtlari haqidagi hikoya yoqdi. Biz barcha yangi xizmatlarni klasterga ko'chirishda davom etamiz. Qo'shimcha ma'lumotni quyidagi nashrlarda topish mumkin:
- «";
- «";
- .
Tarjimondan PS
Shuningdek, bizning blogimizda o'qing:
- «";
- «";
- «";
- «".
Manba: www.habr.com