Еј Хабр!
Ние го претставуваме тимот на платформата Exness. Претходно, нашите колеги веќе напишаа статија за . Денес сакаме да го споделиме нашето искуство за мигрирање услуги во Кубернетес.
За почеток, ви нудиме неколку бројки за подобро разбирање на она што ќе се дискутира:
- Нашиот оддел за развој се состои од 100+ луѓе, вклучувајќи повеќе од 10 различни тимови со самодоволни процеси за QA, DevOps и Scrum. Стак за развој - Python, PHP, C++, Java и Golang.
- Големината на околините за тестирање и производство е околу 2000 контејнери секоја од нив. Тие работат на Rancher v1.6 на сопствена виртуелизација и под VMware.
Мотивација
Како што велат, ништо не трае вечно, а Rancher одамна најави крај на поддршката за верзијата 1.6. Да, за повеќе од три години научивме како да го подготвиме и да ги решаваме проблемите што се појавуваат, но се почесто се соочуваме со проблеми кои никогаш нема да се поправат. Ранчер 1.6, исто така, има осифициран систем за издавање права, каде што можете или да направите речиси сè или ништо.
Иако комерцијалната виртуелизација обезбеди поголема контрола врз складирањето податоци и нивната безбедност, таа наметна оперативни трошоци кои беа тешко да се прифатат со оглед на постојаниот раст на компанијата, бројот на проекти и барањата за нив.
Сакавме да ги следиме стандардите на IaC и, доколку е потребно, да добиеме капацитет брзо, на која било географска локација и без заклучување на продавачот, а исто така да можеме брзо да го напуштиме.
Првите чекори
Пред сè, сакавме да се потпреме на современи технологии и решенија кои ќе им овозможат на тимовите да имаат побрз циклус на развој и да ги минимизираат оперативните трошоци за интеракција со платформата што обезбедува енергија.
Се разбира, првото нешто што ни падна на ум беше Кубернетес, но не се возбудивме и направивме мало истражување за да видиме дали тоа е вистинскиот избор. Ги оценувавме само решенијата со отворен код и во нефер битка, Кубернетес безусловно победи.
Следуваше прашањето за избор на алатка за создавање кластери. Ги споредивме најпопуларните решенија: kops, kubespray, kubeadm.
За почеток, kubeadm ни се чинеше дека е премногу комплицирана патека, напротив како еден вид изумител на „велосипед“, а копсот немаше доволно флексибилност.
А победникот беше:
Почнавме да експериментираме со нашата сопствена виртуелизација и AWS, обидувајќи се да создадеме нешто приближно слично на нашата претходна шема за управување со ресурси, каде што сите го делат истиот „кластер“. И сега го имаме нашиот прв кластер од 10 мали виртуелни машини, од кои неколку се наоѓаат во AWS. Почнавме да се обидуваме да мигрираме тимови таму, се чинеше дека сè е „добро“, и приказната можеше да се заврши, но ...
Први проблеми
Ansible е она на што е изградено kubespray, тоа не е алатка која ви овозможува да го следите IaC: при пуштање во работа/демонтирање на јазли, нешто постојано тргна наопаку и беше потребна некаква интервенција, а при користење на различни ОС, книгата за игри се однесуваше поинаку различни начини. Како што растеше бројот на тимови и јазли во кластерот, почнавме да забележуваме дека книгата за играње трае подолго и подолго за да се заврши, и како резултат на тоа, нашиот рекорд беше 3,5 часа, што е со вашиот? 🙂
И се чини дека kubespray е само Ansible, и сè е јасно на прв поглед, но:
На почетокот на патувањето, задачата беше да се лансираат капацитети само во AWS и на виртуелизација, но потоа, како што често се случува, барањата се променија.
Со оглед на ова, стана јасно дека нашата стара шема на комбинирање ресурси во еден систем за оркестрација не е соодветна - во случај кога кластерите се многу оддалечени и се управувани од различни провајдери.
Понатаму повеќе. Кога сите тимови работат во ист кластер, разни услуги со неправилно инсталирани NodeSelectors би можеле да летаат до „странскиот“ домаќин на друг тим и да користат ресурси таму, а доколку се постави дамка, имало постојани барања дека една или друга услуга не работи. неправилно распределен поради човечки фактор. Друг проблем беше пресметувањето на трошоците, особено со оглед на проблемите во дистрибуцијата на услугите низ јазлите.
Посебна приказна беше издавањето права на вработените: секој тим сакаше да биде „на чело“ на кластерот и целосно да управува со него, што може да предизвика целосен колапс, бидејќи тимовите во основа се независни еден од друг.
Што да сторите?
Имајќи го предвид горенаведеното и желбите на тимовите да бидат понезависни, донесовме едноставен заклучок: еден тим - еден кластер.
Значи, добивме втор:
И потоа третиот кластер:
Потоа почнавме да размислуваме: да речеме дека за една година нашите тимови ќе имаат повеќе од еден кластер? Во различни географски области, на пример, или под контрола на различни провајдери? И некои од нив ќе сакаат да можат брзо да распоредат привремен кластер за некои тестови.
Полни Кубернети би дошле! Ова е некој вид MultiKubernetes, се испоставува.
Во исто време, сите ќе треба некако да ги одржуваме сите овие кластери, да можеме лесно да управуваме со пристапот до нив, како и да создаваме нови и да ги деактивираме старите без рачна интервенција.
Помина извесно време од почетокот на нашето патување во светот на Кубернетес и решивме да ги преиспитаме достапните решенија. Се испостави дека веќе постои на пазарот - Ранчер 2.2.
Во првата фаза од нашето истражување, Rancher Labs веќе го имаше направено првото издание на верзијата 2, но иако можеше да се подигне многу брзо со лансирање контејнер без надворешни зависности со неколку параметри или со користење на официјалната табела HELM, се чинеше грубо до нас, и не знаевме дали можеме да се потпреме на оваа одлука дали ќе биде развиена или брзо напуштена. Парадигмата кластер = кликови во самиот кориснички интерфејс исто така не ни одговараше и не сакавме да се врземе за RKE, бидејќи тоа е прилично тесно фокусирана алатка.
Верзијата Rancher 2.2 веќе имаше пофункционален изглед и, заедно со претходните, имаше куп интересни функции надвор од кутијата, како што се интеграција со многу надворешни провајдери, единствена точка на дистрибуција на права и датотеки kubeconfig, лансирање на kubectl слика со вашите права во интерфејсот, вгнездени именски простори ака проекти.
Имаше, исто така, заедница веќе формирана околу Ранчер 2 и беше создаден провајдер наречен HashiCorp Terraform за да управува со него, што ни помогна да составиме сè заедно.
Што се случи
Како резултат на тоа, завршивме со еден мал кластер кој работи Rancher, достапен за сите други кластери, како и многу кластери поврзани со него, пристап до кој било може да се дозволи исто како и додавање корисник во директориумот ldap, без оглед на каде се наоѓа и ресурсите на кој провајдер ги користи.
Користејќи ги gitlab-ci и Terraform, создаден е систем кој ви овозможува да креирате кластер од која било конфигурација во облак-провајдерите или нашата сопствена инфраструктура и да ги поврзете со Rancher. Сето ова е направено во IaC стил, каде што секој кластер е опишан со складиште, а неговата состојба е верзирана. Во исто време, повеќето модули се поврзани од надворешни складишта, така што останува само да се пренесат променливи или да се опише вашата прилагодена конфигурација за примери, што помага да се намали процентот на повторување на кодот.
Се разбира, нашето патување е далеку од завршено и претстојат уште многу интересни задачи, како што е една точка на работа со дневници и метрика на кои било кластери, сервисна мрежа, gitops за управување со товари во мултикластер и многу повеќе. Се надеваме дека нашето искуство ќе ви биде интересно!
Статијата е напишана од A. Antipov, A. Ganush, Platform Engineers.
Извор: www.habr.com