Прывітанне, Хабр!
Мы прадстаўляем каманду платформы кампаніі 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, але мы не сталі гарачыцца і правялі невялікае даследаванне на прадмет вернасці выбару. Мы ацэньвалі толькі opensource рашэнні, і ў несумленнай сутычцы безумоўна перамог Kubernetes.
Далей стала пытанне выбару прылады для стварэння кластараў. Мы параўналі самыя папулярныя рашэнні: kops, kubespray, kubeadm.
Для старту kubeadm здаўся нам занадта складаным шляхам, хутчэй, нейкім вынаходнікам веласіпеда , а ў kops бракавала гнуткасці.
І пераможцам выйшаў:
Мы пачалі ставіць эксперыменты на ўласнай віртуалізацыі і AWS, спрабуючы ўзнавіць прыкладнае падабенства нашага папярэдняга патэрна кіравання рэсурсамі, дзе ўсё выкарыстоўваюць адзін і той жа "кластар". І вось у нас з'явіўся першы кластар памерам у 10 невялікіх віртуальных машын, пары з якіх знаходзіцца ў AWS. Мы пачалі спрабаваць міграваць туды каманды, быццам бы ўсё стала "добра", і апавяданне можна было б скончыць, але…
Першыя Праблемы
Ansible - тое, на чым пабудаваны kubespray, гэта не тая прылада які дазваляе вынікаць IaC: пры ўводзе/выснове нод з эксплуатацыі стала штосьці ішло не так, і патрабавалася якое-небудзь умяшанне, а пры выкарыстанні розных АС плэйбук паводзіў сябе па- рознаму. З ростам колькасці каманд і нод у кластары мы сталі заўважаць, што плэйбук выконваўся ўсё даўжэй і даўжэй, у выніку, наш рэкорд 3,5 гадзіны, а ваш? 🙂
І накшталт як kubespray гэта проста Ansible, і ўсё зразумела на першы погляд, але:
У пачатку шляху стаяла задача запускаць магутнасці толькі ў AWS і на віртуалізацыі, але потым, як гэта часта бывае, патрабаванні змяніліся.
У святле гэтага стала зразумела, што наш стары патэрн аб'яднання рэсурсаў у адну сістэму аркестрацыі не падыходзіў - у выпадку, калі кластары моцна выдаленыя і знаходзяцца пад кіраваннем розных правайдэраў.
Далей - больш. Калі ўсе каманды працуюць у межах аднаго кластара, розныя сэрвісы з няправільна ўсталяванымі NodeSelector маглі прыляцець на "чужы" хост іншай каманды і там утылізаваць рэсурсы, а ў выпадку выстаўлення taint - з'яўляліся пастаянныя звароты аб тым, што той ці іншы сэрвіс не працуе, не размяркоўваецца правільна з-за чалавечага фактару. Яшчэ адной праблемай аказаўся разлік кошту, асабліва ўлічваючы праблемы пры размеркаванні сэрвісаў па нодах.
Асобнай гісторыяй ішла выдача правоў супрацоўнікам: кожная каманда хацела быць "на чале" кластара і цалкам ім кіраваць, што магло выклікаць поўны калапс, бо каманды ў асноўным адна ад адной незалежныя.
Як быць?
Улічваючы вышэйапісанае і пажаданні каманд быць больш незалежнымі, мы зрабілі простую выснову: адна каманда - адзін кластар.
Так у нас з'явіўся другі:
А потым і трэці кластар:
Тут мы пачалі думаць: дапусцім, праз год у нашых каманд будзе не адзін кластар? У розных геаграфічных зонах, напрыклад, ці пад кіраваннем розных правайдэраў? А нехта з іх захоча мець магчымасць хутка разгарнуць часовы кластар для якіх-небудзь тэстаў.
Наступіў бы поўны Кубернэтэс! Гэта нейкі MultiKubernetes, атрымліваецца.
Пры гэтым усім нам трэба будзе нейкім чынам падтрымліваць усе гэтыя кластары, мець магчымасць лёгка кіраваць доступам да іх, а таксама ствараць новыя і выводзіць старыя з эксплуатацыі без ручнога ўмяшання.
З моманту пачатку нашага шляху ў свеце Кубернэтэса прайшоў некаторы час, і мы вырашылі зрабіць паўторнае вывучэнне даступных рашэнняў. Аказалася, што на рынку яно ўжо ёсць – 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