Здравейте, Хабр!
Представяме ви екипа на платформата на компания 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 и на виртуализация, но после, както често се случва, изискванията се промениха.
В светлината на това стана ясно, че нашият стар модел за обединяване на ресурсите в една система за оркестрация не беше подходящ — в случаи, когато кластерите са силно отдалечени и се управляват от различни доставчици.
По-нататък — още. Когато всички екипи работят в рамките на един кластър, различни услуги с неправилно установени NodeSelector могат да се окажат на "чужд" хост на друг екип и да изразходват ресурси, а при установяване на taint — възникваха постоянни оплаквания, че тази или онази услуга не работи, не се разпределя правилно заради човешкия фактор. Друга проблематика беше изчисляването на разходите, особено предвид проблемите при разпределението на услугите по нодове.
Отделна история беше предоставянето на права на служителите: всеки екип искаше да бъде "на върха" на кластера и напълно да го управлява, което можеше да доведе до пълен колапс, тъй като екипите основно са независими един от друг.
Какво да правим?
Като взехме предвид горепосоченото и желанието на екипите да бъдат по-независими, направихме прост извод: един екип — един кластер.
Така ни се появи втори:
А след това и трети кластер:
Тук започнахме да мислим: да допуснем, че след година нашите екипи ще имат не един клъстер? В различни географски зони, например, или под управлението на различни доставчици? Някой от тях би искал да има възможността бързо да разгръща временно клъстер за тестове.
Това би било пълен Kubernetes! Получава се некакъв MultiKubernetes.
В същото време, всички ние по някакъв начин трябва да поддържаме всички тези клъстери, да имаме възможността лесно да управляваме достъпа до тях, а също така да създаваме нови и да деактивираме стари без ръчно намесване.
От началото на нашия път в света на Kubernetes е минало известно време, и решихме да направим повторно проучване на наличните решения. Оказа се, че на пазара вече е налично — Rancher 2.2.
На първия етап от нашите изследвания Rancher Labs вече бяха направили първия релийз на версия 2, но макар че можеше да бъде много бързо стартирана, стартирайки контейнер без външни зависимости с няколко параметра или използвайки официалния HELM Chart, тя ни се стори недоразвита и не знаехме дали можем да разчитаме на това решение, дали ще бъде развивано или бързо ще бъде забравено. Самата парадигма клъстер = кликвания в UI също не ни подхождаше, и не искахме да се обвързваме с RKE, тъй като това е достатъчно узкоспециализиран инструмент.
Версията Rancher 2.2 вече имаше по-работещ вид и в комбинация с предишната притежаваше множество интересни възможности от кутията, като интеграция с много външни доставчици, единна точка за разширение на права и kubeconfig файлове, стартиране на образа kubectl с твоите права в UI, вложени неймспейси, известни още като проекти.
Също така около Rancher 2 вече се бе формирало общество и бе създаден доставчик HashiCorp Terraform за управление на него, който ни помогна да съберем всичко на едно място.
Какво постигнахме
В крайна сметка получихме един малък клъстер, в който е стартиран Rancher, достъпен за всички останали клъстери, както и много свързани с него клъстери, достъп до който може да бъде предоставен толкова лесно, колкото да добавиш потребител в ldap каталог, независимо от това къде се намира и какви ресурси на доставчика използва.
С помощта на gitlab-ci и Terraform беше създадена система, която позволява изграждането на кластер с всякаква конфигурация в облачни доставчици или в собствената ни инфраструктура и свързването им с Rancher. Всичко това е реализирано в стил IaC, където всеки кластер е описан в репозитория, а неговото състояние е версионирано. В същото време повечето модули се свързват от външни репозитории, така че остава само да се предадат променливи или да се опише собствена персонализирана конфигурация за инстанции, което помага да се намали процентът на повторяемост на кода.
Разбира се, нашето пътуване далеч не е свършило и напред ни чакат още много интересни задачи, като единна точка за работа с логовете и метриките на всякакви клъстери, service mesh, gitops за управление на натоварванията в мултикластер и много други. Надяваме се, че нашият опит ще е интересен за вас!
Статията е написана от А. Антипов, А. Гануш, Platform Engineers.
Източник: habr.com
