Эй Хабр!
Биз Exness платформа командасынын өкүлү. Буга чейин биздин кесиптештер жөнүндө макала жазышкан . Бүгүн биз Kubernetes кызматын көчүрүү тажрыйбабыз менен бөлүшкүбүз келет.
Баштоо үчүн, эмне талкууланаарын жакшыраак түшүнүү үчүн сизге бир нече сандарды сунуштайбыз:
- Биздин өнүктүрүү бөлүмүбүз 100+ адамдан турат, анын ичинде өзүн-өзү жетиштүү QA, DevOps жана Scrum процесстери бар 10дон ашык ар кандай командалар. Өнүктүрүү стек - Python, PHP, C++, Java жана Голанг.
- Сыноо жана өндүрүш чөйрөлөрүнүн көлөмү ар бири 2000 контейнерди түзөт. Алар Rancher v1.6 версиясын өздөрүнүн виртуализациясында жана VMware астында иштетип жатышат.
жөнүн көрсөтүү
Алар айткандай, эч нерсе түбөлүккө созулбайт жана Rancher 1.6 версиясын колдоонун аяктаганын бир топ убакыт мурун жарыялаган. Ооба, үч жылдан ашык убакыттын ичинде биз аны кантип даярдоону жана пайда болгон көйгөйлөрдү чечүүнү үйрөндүк, бирок бизде эч качан оңдолбой турган көйгөйлөр барган сайын көп кездешет. Rancher 1.6 ошондой эле укуктарды берүү үчүн оссификацияланган системага ээ, анда сиз дээрлик бардыгын жасай аласыз же эч нерсе кыла аласыз.
Проприетардык виртуалдаштыруу маалыматтарды сактоону жана анын коопсуздугун көбүрөөк көзөмөлдөөнү камсыздаганы менен, компаниянын тынымсыз өсүшүн, долбоорлордун санын жана аларга коюлган талаптарды эске алуу менен кабыл алуу кыйын болгон операциялык чыгымдарды жүктөгөн.
Биз IaC стандарттарына баш ийип, зарыл болсо, кубаттуулукту тез, каалаган географиялык жерде жана сатуучу кулпусу жок алып, андан тез баш тартууну кааладык.
биринчи кадам
Биринчиден, биз командаларга тезирээк өнүгүү циклине ээ болууга жана энергия менен камсыз кылуучу платформа менен өз ара аракеттенүү үчүн операциялык чыгымдарды азайтууга мүмкүндүк берген заманбап технологияларга жана чечимдерге таянгыбыз келди.
Албетте, биздин оюбузга биринчи келген нерсе Кубернетес болду, бирок биз толкунданган жокпуз жана бул туура тандообу деп бир аз изилдөө жүргүздүк. Биз ачык булактуу чечимдерди гана бааладык жана адилетсиз күрөштө Кубернетес шартсыз жеңишке жетти.
Андан кийин кластерлерди түзүү үчүн куралды тандоо маселеси келди. Биз эң популярдуу чечимдерди салыштырдык: kops, kubespray, kubeadm.
Баштасак, кубеадм бизге «велосипедди» ойлоп табуучу сыяктуу өтө татаал жол болуп көрүндү, ал эми копс жетишерлик ийкемдүүлүккө ээ эмес.
Ал эми жеңүүчү болду:
Биз өзүбүздүн виртуалдаштыруу жана AWS менен эксперимент жүргүзүп, мурунку ресурстарды башкаруу үлгүсүнө окшош нерсени кайра түзүүгө аракет кылып көрдүк, анда бардыгы бирдей “кластерди” бөлүшкөн. Эми бизде 10 кичинекей виртуалдык машиналардан турган биринчи кластерибиз бар, алардын бир нечеси AWSде жайгашкан. Биз ал жакка командаларды көчүрүү аракетин баштадык, баары "жакшы" болуп көрүндү жана окуя бүтүшү мүмкүн, бирок...
Биринчи көйгөйлөр
Ansible — kubesprayдин негизинде курулган, бул IaCди ээрчүүгө мүмкүндүк берүүчү курал эмес: түйүндөрдү ишке киргизүү/эксплуатациядан чыгарууда дайыма бир нерсе туура эмес болуп, кандайдыр бир кийлигишүү талап кылынган, ал эми ар кандай ОСти колдонгондо, оюн китеби башкача иш кылган. . Кластердеги командалардын жана түйүндөрдүн саны көбөйгөн сайын, биз оюн китебин толтурууга узагыраак жана узагыраак убакыт талап кылынганын байкай баштадык, натыйжада биздин рекорд 3,5 саатты түздү, сиздикичи? 🙂
Жана бул kubespray жөн эле Ansible окшойт, жана баары бир караганда түшүнүктүү, бирок:
Саякаттын башында, AWSде жана виртуалдаштырууда гана кубаттуулуктарды ишке киргизүү милдети турган, бирок андан кийин, көп учурда, талаптар өзгөрдү.
Ушундан улам, биздин ресурстарды бир оркестрдик тутумга бириктирүүнүн эски үлгүсү ылайыктуу эмес экени белгилүү болду - кластерлер өтө алыс жайгашкан жана ар кандай провайдерлер тарабынан башкарылган учурда.
Дагы дагы. Бардык командалар бир кластердин ичинде иштегенде, туура эмес орнотулган NodeSelectors менен ар кандай кызматтар башка команданын "чет элдик" хостуна учуп, ал жердеги ресурстарды колдонушу мүмкүн, ал эми булгануу орнотулган болсо, тигил же бул кызмат иштебей жатат деген тынымсыз суроо-талаптар келип турду. адам факторуна байланыштуу туура эмес бөлүштүрүлгөн. Дагы бир көйгөй, өзгөчө түйүндөр боюнча кызматтарды бөлүштүрүүдө көйгөйлөрдү эске алуу менен, бааны эсептөө болгон.
Кызматкерлерге укуктарды берүү өзүнчө окуя болду: ар бир команда кластердин “башында” болууну жана аны толугу менен башкарууну каалады, бул толугу менен кыйроого алып келиши мүмкүн, анткени командалар негизинен бири-биринен көз карандысыз.
Эмне кылуу керек?
Жогоруда айтылгандарды жана командалардын өз алдынча болуу каалоолорун эске алып, биз жөнөкөй жыйынтык чыгардык: бир команда – бир кластер.
Ошентип, биз экинчисин алдык:
Анан үчүнчү кластер:
Анан биз ойлоно баштадык: бир жылдан кийин биздин командалар бир эмес, бир нече кластер болот дейли? Ар кандай географиялык аймактарда, мисалы, же ар кандай провайдерлердин көзөмөлүндөбү? Алардын айрымдары кээ бир тесттер үчүн убактылуу кластерди тез арада жайгаштырууну каалашат.
Толук Kubernetes келет! Бул MultiKubernetesтин кандайдыр бир түрү, көрүнүп турат.
Ошол эле учурда, баарыбыз кандайдыр бир жол менен бул кластерлердин баарын сактап, аларга кирүү мүмкүнчүлүгүн оңой башкара алышыбыз керек, ошондой эле жаңыларын түзүп, эскилерин кол менен кийлигишүүсүз жокко чыгарышыбыз керек.
Kubernetes дүйнөсүндөгү саякатыбыз башталгандан бери бир аз убакыт өттү жана биз колдо болгон чечимдерди кайра карап чыгууну чечтик. Бул рынокто мурунтан эле бар экени белгилүү болду - Rancher 2.2.
Биздин изилдөөбүздүн биринчи этабында Rancher Labs 2-версиянын биринчи чыгарылышын жасаган, бирок аны бир нече параметрлери бар тышкы көз карандылыгы жок контейнерди ишке киргизүү же расмий HELM диаграммасын колдонуу менен тез арада көтөрсө болот, бирок бул одоно көрүнгөн. бизге, жана биз бул чечимге таяна аларыбызды билбей калдык, ал иштелип чыгабы же тез эле баш тартабы. UIдеги кластер = чыкылдатуулар парадигмасы да бизге туура келген жок жана биз RKEге байлангыбыз келген жок, анткени бул абдан тар багытталган курал.
Rancher 2.2 версиясы мурунтан эле иштей турган көрүнүшкө ээ болгон жана мурункулары менен бирге көптөгөн тышкы провайдерлер менен интеграция, укуктарды бөлүштүрүүнүн бирдиктүү чекити жана kubeconfig файлдары, kubectl ишке киргизүү сыяктуу бир топ кызыктуу өзгөчөлүктөргө ээ болгон. UIдеги укуктарыңыз менен сүрөт, уяланган аттар мейкиндиктери, башкача айтканда долбоорлор.
Ошондой эле Rancher 2дин айланасында коомчулук түзүлгөн жана аны башкаруу үчүн HashiCorp Terraform деп аталган провайдер түзүлгөн, бул бизге бардыгын чогултууга жардам берди.
Эмне болду
Натыйжада, биз Rancher иштеткен бир кичинекей кластерге ээ болдук, ал бардык башка кластерлерге, ошондой эле ага туташкан көптөгөн кластерлерге жеткиликтүү болуп калды, алардын каалаганына кирүү ldap каталогуна колдонуучуну кошуу сыяктуу эле берилиши мүмкүн. ал кайда жайгашкан жана кайсы провайдердин ресурстарын колдонот.
gitlab-ci жана Terraform колдонуп, булут провайдерлеринде же өзүбүздүн инфраструктурабызда каалаган конфигурациянын кластерин түзүүгө жана аларды Rancher менен туташтырууга мүмкүндүк берген система түзүлдү. Мунун баары IaC стилинде жасалат, мында ар бир кластер репозиторийде сүрөттөлөт жана анын абалы версияланат. Ошол эле учурда, көпчүлүк модулдар тышкы репозиторийлерден туташтырылган, андыктан калган нерсе өзгөрмөлөрдү өткөрүп берүү же инстанциялар үчүн ыңгайлаштырылган конфигурацияңызды сүрөттөп берүү болуп саналат, бул коддун кайталануу пайызын азайтууга жардам берет.
Албетте, биздин саякатыбыз бүтө элек жана алдыда дагы көптөгөн кызыктуу милдеттер турат, мисалы, ар кандай кластерлердин журналдары жана метрикалары менен иштөөнүн бирдиктүү пункту, сервистик тор, мультикластерде жүктөрдү башкаруу үчүн гитоптор жана башка көптөгөн нерселер. Биздин тажрыйба сизге кызыктуу болот деп ишенебиз!
Макаланы платформа инженерлери А.Антипов, А.Гануш жазган.
Source: www.habr.com