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