Hey Xabr!
Biz Exness platformasi jamoasi vakilimiz. Ilgari hamkasblarimiz allaqachon maqola yozgan edi . Bugun biz Kubernetes-ga xizmatlarni ko'chirish tajribamiz bilan o'rtoqlashmoqchimiz.
Boshlash uchun nima muhokama qilinishini yaxshiroq tushunish uchun sizga bir nechta raqamlarni taklif qilamiz:
- Rivojlanish bo'limi 100 dan ortiq kishidan iborat bo'lib, ular o'z-o'zini ta'minlaydigan QA, DevOps va Scrum jarayonlariga ega 10 dan ortiq turli jamoalarni o'z ichiga oladi. Rivojlanish steklari - Python, PHP, C++, Java va Golang.
- Sinov va ishlab chiqarish muhitining o'lchami har birida 2000 ta konteynerdan iborat. Ular o'zlarining virtualizatsiyasida va VMware ostida Rancher v1.6 ni ishga tushirishmoqda.
Motivatsiya
Ular aytganidek, hech narsa abadiy davom etmaydi va Rancher ancha oldin 1.6 versiyasini qo'llab-quvvatlash tugashini e'lon qildi. Ha, uch yildan ko'proq vaqt davomida biz uni qanday tayyorlashni va paydo bo'lgan muammolarni hal qilishni o'rgandik, lekin ko'pincha biz hech qachon tuzatib bo'lmaydigan muammolarga duch kelamiz. Rancher 1.6 shuningdek, huquqlarni berish uchun ossifikatsiyalangan tizimga ega, bu erda siz deyarli hamma narsani qila olasiz yoki hech narsa qila olmaysiz.
Xususiy virtualizatsiya ma'lumotlarni saqlash va uning xavfsizligi ustidan ko'proq nazoratni ta'minlagan bo'lsa-da, kompaniyaning doimiy o'sishi, loyihalar soni va ularga qo'yiladigan talablarni hisobga olgan holda qabul qilish qiyin bo'lgan operatsion xarajatlarni yukladi.
Biz IaC standartlariga rioya qilishni va agar kerak bo'lsa, istalgan geografik joylashuvda va sotuvchi blokirovkasisiz quvvatni tezda qo'lga kiritishni va undan tezda voz kechishni xohladik.
birinchi qadamlar
Avvalo, biz jamoalarga tezroq rivojlanish tsikliga ega bo'lish va quvvatni ta'minlaydigan platforma bilan o'zaro ishlash uchun operatsion xarajatlarni minimallashtirish imkonini beradigan zamonaviy texnologiyalar va echimlarga tayanmoqchi edik.
Albatta, bizning boshimizga kelgan birinchi narsa Kubernetes edi, lekin biz hayajonlanmadik va bu to'g'ri tanlovmi yoki yo'qligini bilish uchun ozgina tadqiqot qildik. Biz faqat ochiq manba echimlarini baholadik va adolatsiz jangda Kubernetes so'zsiz g'alaba qozondi.
Keyinchalik klasterlarni yaratish uchun vositani tanlash masalasi keldi. Biz eng mashhur echimlarni solishtirdik: kops, kubespray, kubeadm.
Boshlash uchun kubeadm bizga "velosiped" ixtirochisiga o'xshab juda murakkab yo'l bo'lib tuyuldi va koplarning moslashuvchanligi etarli emas edi.
Va g'olib:
Biz o'z virtualizatsiyamiz va AWS bilan tajriba o'tkazishni boshladik, hamma bir xil "klaster" ga ega bo'lgan avvalgi resurslarni boshqarish naqshimizga o'xshash narsani qayta yaratishga harakat qildik. Va endi bizda 10 ta kichik virtual mashinadan iborat birinchi klasterimiz bor, ulardan ikkitasi AWSda joylashgan. Biz u erga jamoalarni ko'chirishga harakat qila boshladik, hamma narsa "yaxshi" bo'lib tuyuldi va hikoya tugashi mumkin edi, lekin ...
Birinchi muammolar
Ansible - kubespray asosida qurilgan, bu sizga IaC-ga rioya qilish imkonini beruvchi vosita emas: tugunlarni ishga tushirish/o'chirishda doimo nimadir noto'g'ri ketdi va qandaydir aralashuv talab qilindi va turli operatsion tizimlardan foydalanganda o'yin kitobi boshqacha harakat qildi. . Klasterdagi jamoalar va tugunlar soni oshgani sayin, biz o'yin kitobini to'ldirish uchun ko'proq va uzoq davom etayotganini seza boshladik va natijada bizning rekordimiz 3,5 soatni tashkil etdi, siznikichi? π
Va kubespray shunchaki Ansible kabi ko'rinadi va birinchi qarashda hamma narsa aniq, lekin:
Sayohatning boshida vazifa faqat AWS va virtualizatsiyada imkoniyatlarni ishga tushirish edi, ammo keyin tez-tez bo'lganidek, talablar o'zgardi.
Shu nuqtai nazardan, bizning resurslarni bitta orkestrlash tizimiga birlashtirishning eski namunasi mos emasligi aniq bo'ldi - klasterlar juda uzoqda joylashgan va turli provayderlar tomonidan boshqariladigan holatda.
Yana ko'proq. Barcha jamoalar bitta klasterda ishlaganda, noto'g'ri o'rnatilgan NodeSelectors bilan turli xizmatlar boshqa jamoaning "xorijiy" xostiga uchib, u yerdagi resurslardan foydalanishi mumkin edi va agar ifloslanish o'rnatilgan bo'lsa, u yoki bu xizmat ishlamayotganligi haqida doimiy so'rovlar bo'lib turardi. inson omili tufayli to'g'ri taqsimlanmagan. Yana bir muammo, ayniqsa, xizmatlarni tugunlar bo'ylab tarqatishdagi muammolarni hisobga olgan holda, xarajatlarni hisoblash edi.
Xodimlarga huquqlarning berilishi alohida voqea edi: har bir jamoa klasterning "boshida" bo'lishni va uni to'liq boshqarishni xohladi, bu butunlay qulashi mumkin edi, chunki jamoalar asosan bir-biridan mustaqil.
Qanday qilib bo'lish kerak?
Yuqoridagilarni va jamoalarning yanada mustaqil bo'lish istagini inobatga olib, biz oddiy xulosaga keldik: bitta jamoa - bitta klaster.
Shunday qilib, biz ikkinchisini oldik:
Va keyin uchinchi klaster:
Keyin biz o'ylay boshladik: deylik, bir yildan keyin jamoalarimizda bir nechta klaster bo'ladimi? Turli geografik hududlarda, masalan, yoki turli provayderlar nazorati ostidami? Va ulardan ba'zilari ba'zi testlar uchun vaqtinchalik klasterni tezda joylashtirishni xohlashadi.
To'liq Kubernetes keladi! Bu qandaydir MultiKubernetes, ma'lum bo'ldi.
Shu bilan birga, barchamiz qandaydir tarzda ushbu klasterlarning barchasini saqlab qolishimiz, ularga kirishni oson boshqarishimiz, shuningdek, qo'l aralashuvisiz yangilarini yaratishimiz va eskilarini bekor qilishimiz kerak.
Kubernetes dunyosiga sayohatimiz boshlanganidan beri biroz vaqt o'tdi va biz mavjud echimlarni qayta ko'rib chiqishga qaror qildik. Ma'lum bo'lishicha, u allaqachon bozorda mavjud - Rancher 2.2.
Tadqiqotimizning birinchi bosqichida Rancher Labs allaqachon 2-versiyaning birinchi versiyasini chiqargan edi, ammo uni tashqi bog'liqliksiz konteynerni bir nechta parametrlar bilan ishga tushirish yoki rasmiy HELM diagrammasi yordamida juda tez ko'tarish mumkin bo'lsa-da, bu juda qo'pol tuyuldi. bizga, va biz bu qarorga tayanishimiz mumkinligini bilmasdik, u ishlab chiqiladimi yoki tezda tark etiladi. UI-dagi klaster = bosish paradigmasi ham bizga mos kelmadi va biz RKE bilan bog'lanishni xohlamadik, chunki bu juda tor yo'naltirilgan vositadir.
Rancher 2.2 versiyasi allaqachon ko'proq ishlaydigan ko'rinishga ega edi va avvalgilari bilan bir qatorda ko'plab tashqi provayderlar bilan integratsiya, huquqlarni tarqatishning yagona nuqtasi va kubeconfig fayllari, kubectl-ni ishga tushirish kabi bir qator qiziqarli xususiyatlarga ega edi. UIdagi huquqlaringiz bilan tasvir, o'rnatilgan nomlar maydoni, aka loyihalar.
Rancher 2 atrofida allaqachon hamjamiyat shakllangan edi va uni boshqarish uchun HashiCorp Terraform nomli provayder yaratildi, bu bizga hamma narsani birlashtirishga yordam berdi.
Nima bo'ldi
Natijada, biz Rancher bilan ishlaydigan, boshqa barcha klasterlar va unga ulangan ko'plab klasterlar uchun ochiq bo'lgan bitta kichik klasterga ega bo'ldik. qayerda joylashganligi va qaysi provayderning resurslaridan foydalanishi.
Gitlab-ci va Terraform-dan foydalanib, bulutli provayderlarda yoki o'z infratuzilmamizda istalgan konfiguratsiya klasterini yaratish va ularni Rancher-ga ulash imkonini beruvchi tizim yaratildi. Bularning barchasi IaC uslubida amalga oshiriladi, bu erda har bir klaster ombor tomonidan tavsiflanadi va uning holati versiyalanadi. Shu bilan birga, aksariyat modullar tashqi omborlardan ulanadi, shunda qolgan narsa o'zgaruvchilarni o'tkazish yoki misollar uchun sizning shaxsiy konfiguratsiyangizni tavsiflashdir, bu esa kod takrorlanish foizini kamaytirishga yordam beradi.
Albatta, bizning sayohatimiz hali tugamaydi va oldinda har qanday klasterlarning jurnallari va ko'rsatkichlari bilan ishlashning yagona nuqtasi, xizmat ko'rsatish tarmog'i, multiklasterda yuklarni boshqarish uchun gitoplar va boshqalar kabi ko'plab qiziqarli vazifalar turibdi. Umid qilamizki, bizning tajribamiz siz uchun qiziqarli bo'ladi!
Maqola A. Antipov, A. Ganush, platforma muhandislari tomonidan yozilgan.
Manba: www.habr.com