Хеј Хабр!
Представљамо тим Екнесс платформе. Раније су наше колеге већ писале чланак о . Данас желимо да поделимо наше искуство миграције услуга на Кубернетес.
За почетак, нудимо вам неколико бројева за боље разумевање о чему ће бити речи:
- Наше одељење за развој састоји се од 100+ људи, укључујући више од 10 различитих тимова са самодовољним КА, ДевОпс и Сцрум процесима. Развојни стог - Питхон, ПХП, Ц++, Јава и Голанг.
- Величина тестног и производног окружења је око 2000 контејнера сваки. Они користе Ранцхер в1.6 на сопственој виртуелизацији и под ВМваре-ом.
Мотивација
Како кажу, ништа не траје вечно, а Ранчер је доста давно најавио престанак подршке за верзију 1.6. Да, за више од три године научили смо како да то припремимо и решимо проблеме који се појављују, али све чешће се сусрећемо са проблемима који никада неће бити исправљени. Ранчер 1.6 такође има окоштали систем за издавање права, где можете или скоро све или ништа.
Иако је власничка виртуелизација обезбедила већу контролу над складиштењем података и њиховом безбедношћу, наметнула је оперативне трошкове које је било тешко прихватити с обзиром на константан раст компаније, број пројеката и захтеве за њима.
Желели смо да пратимо ИаЦ стандарде и, ако је потребно, брзо добијемо капацитет, на било којој географској локацији и без закључавања добављача, а такође и да будемо у могућности да га брзо напустимо.
Први кораци
Пре свега, желели смо да се ослонимо на модерне технологије и решења која би омогућила тимовима да имају бржи развојни циклус и минимизирају оперативне трошкове за интеракцију са платформом која обезбеђује снагу.
Наравно, прво што нам је пало на памет био је Кубернетес, али нисмо се узбуђивали и мало смо истражили да видимо да ли је то прави избор. Оцењивали смо само решења отвореног кода и у неправедној борби Кубернетес је безусловно победио.
Следеће је било питање избора алата за креирање кластера. Упоредили смо најпопуларнија решења: копс, кубеспраи, кубеадм.
За почетак, кубеадм нам се чинио превише компликованим путем, пре као нека врста проналазача „бицикла“, а копс није имао довољно флексибилности.
А победник је био:
Почели смо да експериментишемо са сопственом виртуелизацијом и АВС-ом, покушавајући да поново створимо нешто отприлике слично нашем претходном обрасцу управљања ресурсима, где су сви делили исти „кластер“. И сада имамо наш први кластер од 10 малих виртуелних машина, од којих се неколико налази у АВС-у. Почели смо да мигрирамо тимове тамо, све је било „добро“, и прича је могла да се заврши, али...
Први проблеми
Ансибле је оно на чему је изграђен кубеспраи, то није алатка која вам омогућава да пратите ИаЦ: приликом пуштања у рад/декомисије чворова, нешто је стално шло по злу и била је потребна нека врста интервенције, а када се користе различити ОС, приручник се понашао другачије. . Како је број тимова и чворова у кластеру растао, почели смо да примећујемо да је потребно све дуже и дуже да се заврши, и као резултат тога, наш рекорд је био 3,5 сата, а ваш? 🙂
И изгледа да је кубеспраи само Ансибле, и све је јасно на први поглед, али:
На почетку пута, задатак је био да се капацитети покрену само у АВС-у и на виртуелизацији, али су се онда, као што се често дешава, захтеви променили.
У светлу овога, постало је јасно да наш стари образац комбиновања ресурса у један систем оркестрације није прикладан – у случају када су кластери веома удаљени и којима управљају различити провајдери.
У наставку. Када сви тимови раде у оквиру истог кластера, разни сервиси са погрешно инсталираним НодеСелецторима могли би да одлете до „страног” домаћина другог тима и тамо користе ресурсе, а ако је постављена мрља, постојали су стални захтеви да један или други сервис не ради, није правилно распоређено због људског фактора. Други проблем је био израчунавање трошкова, посебно имајући у виду проблеме у дистрибуцији услуга између чворова.
Посебна прича је била издавање права запосленима: сваки тим је желео да буде „на челу” кластера и да у потпуности управља њиме, што би могло да изазове потпуни колапс, пошто су тимови у основи независни једни од других.
Шта да радим?
Узимајући у обзир наведено и жеље тимова да буду независнији, донели смо једноставан закључак: један тим – један кластер.
Дакле, добили смо другу:
И онда трећи кластер:
Онда смо почели да размишљамо: рецимо да ће за годину дана наши тимови имати више од једног кластера? У различитим географским областима, на пример, или под контролом различитих провајдера? А неки од њих ће желети да буду у могућности да брзо примене привремени кластер за неке тестове.
Дошао би пун Кубернетес! Испоставило се да је ово нека врста МултиКубернетеса.
Истовремено, сви ћемо морати некако да одржавамо све ове кластере, да будемо у могућности да лако управљамо приступом њима, као и да креирамо нове и поништимо старе без ручне интервенције.
Прошло је неко време од почетка нашег путовања у свет Кубернетеса и одлучили смо да преиспитамо доступна решења. Испоставило се да већ постоји на тржишту - Ранчер 2.2.
У првој фази нашег истраживања, Ранцхер Лабс је већ направио прво издање верзије 2, али иако је могло да се подигне веома брзо покретањем контејнера без спољних зависности са неколико параметара или коришћењем званичног ХЕЛМ Цхарт-а, изгледало је грубо нама, и нисмо знали да ли можемо да се ослонимо на ову одлуку да ли ће се она развити или брзо напустити. Парадигма кластер = кликови у самом корисничком интерфејсу такође нам није одговарала, а нисмо желели да се везујемо за РКЕ, пошто је то прилично уско фокусиран алат.
Верзија Ранцхер 2.2 је већ имала функционалнији изглед и, заједно са претходним, имала је гомилу занимљивих функција ван кутије, као што су интеграција са многим спољним провајдерима, јединствена тачка дистрибуције права и кубецонфиг фајлова, покретање кубецтл-а слика са вашим правима у корисничком интерфејсу, угнежђени простори имена звани пројекти.
Такође је постојала заједница која је већ формирана око Ранчера 2, а креиран је провајдер под називом ХасхиЦорп Терраформ да њиме управља, што нам је помогло да све спојимо.
Шта се десило
Као резултат тога, добили смо један мали кластер који покреће Ранцхер, доступан свим другим кластерима, као и многим кластерима повезаним са њим, приступ било ком од којих се може одобрити једноставно као додавањем корисника у лдап директоријум, без обзира на где се налази и које ресурсе провајдера користи.
Користећи гитлаб-ци и Терраформ, креиран је систем који вам омогућава да креирате кластер било које конфигурације у цлоуд провајдерима или нашој сопственој инфраструктури и повежете их са Ранцхер-ом. Све ово се ради у ИаЦ стилу, где је сваки кластер описан репозиторијумом, а његово стање је верзионисано. Истовремено, већина модула је повезана из спољних спремишта, тако да остаје само да проследите променљиве или опишете вашу прилагођену конфигурацију за примере, што помаже да се смањи проценат понављања кода.
Наравно, наш пут је далеко од краја и пред нама је још много занимљивих задатака, као што је једна тачка рада са евиденцијама и метрикама било ког кластера, сервисна мрежа, гитопови за управљање оптерећењима у мултикластеру и још много тога. Надамо се да ће вам наше искуство бити занимљиво!
Чланак су написали А. Антипов, А. Гануш, инжењери платформе.
Извор: ввв.хабр.цом