Кампанія "Урус" паспрабавала Kubernetes у розных відах: самастойны дэплоймент на bare metal, у Google Cloud, а затым перанесла сваю платформу ў воблака Mail.ru Cloud Solutions (MCS). Як выбіралі новага хмарнага правайдэра і як удалося міграваць да яго за рэкордныя дзве гадзіны расказвае Ігар Шышкін (), старшы сістэмны адміністратар «Урус».
Чым займаецца «Урус»
Ёсць шмат спосабаў палепшыць якасць гарадскога асяроддзя, і адзін з іх - зрабіць яе экалагічна бяспечнай. Як раз над гэтым працуюць у кампаніі «Урус – разумныя лічбавыя сэрвісы». Тут укараняюць рашэнні, якія дапамагаюць прадпрыемствам кантраляваць важныя экалагічныя паказчыкі і змяншаць негатыўны ўплыў на навакольнае асяроддзе. Датчыкі збіраюць дадзеныя аб складзе паветра, узроўні шуму і іншыя параметры, а затым адпраўляюць іх у адзіную платформу "Урус - Экамон" для аналізу і складання рэкамендацый.
Як уладкованая праца «Урус» знутры
Тыповы кліент «Урус» - кампанія, якая размяшчаецца ў жылой зоне або побач з ёй. Гэта можа быць завод, порт, чыгуначнае дэпо ці любы іншы аб'ект. Калі наш кліент ужо атрымліваў папярэджанне, быў аштрафаваны за забруджванне навакольнага асяроддзя ці сам хоча выдаваць менш шумоў, знізіць колькасць шкодных выкідаў, ён прыходзіць да нас, і мы ўжо прапануем яму гатовае рашэнне па экалагічным маніторынгу.
На графіцы маніторынгу канцэнтрацыі H2S бачныя рэгулярныя начныя выкіды размешчанага побач прадпрыемства
Прылады, якія мы выкарыстоўваем у «Урус», утрымоўваюць у сабе некалькі сэнсараў, якія збіраюць інфармацыю аб утрыманні вызначаных газаў, узроўні шуму і іншыя дадзеныя для адзнакі экалагічнага становішча. Дакладная колькасць сэнсараў заўсёды вызначаецца канкрэтнай задачай.
У залежнасці ад спецыфікі вымярэнняў, прылады з датчыкамі могуць размяшчацца на сценах будынкаў, слупах і ў іншых адвольных месцах. Кожная такая прылада збірае інфармацыю, агрэгуе яе і адпраўляе на шлюз прыёму дадзеных. Тамака мы захоўваем дадзеныя на працяглае захоўванне і предовращаем для наступнага аналізу. Найпросты прыклад таго, што мы атрымліваем на выхадзе пасля аналізу - гэта індэкс якасці паветра, ён жа AQI.
Паралельна на нашай платформе працуе шмат іншых сэрвісаў, але ў асноўным яны носяць абслуговы характар. Напрыклад, сэрвіс натыфікацыі адпраўляе кліентам апавяшчэння, калі нейкі з адсочваных параметраў (дапусцім, змест СО2) перавысіў дапушчальнае значэнне.
Як мы захоўваем дадзеныя. Гісторыя з Kubernetes на bare metal
У праекце экаманіторынгу "Урус" ёсць некалькі сховішчаў дадзеных. У адным мы трымаем "волкія" дадзеныя - тое, што мы атрымалі непасрэдна ад саміх прылад. Гэтае сховішча ўяўляе сабой "магнітную" стужку, як на старых касетах, з гісторыяй усіх паказчыкаў. Другі тып сховішча выкарыстоўваецца для перадапрацаваных дадзеных - дадзеных з прылад, узбагачаных метададзенымі аб сувязях сэнсараў і сведчанні саміх прылад, прыналежнасці да арганізацый, месцам размяшчэння і т. д. Гэтая інфармацыя дазваляе ў дынаміку ацаніць, як змяняўся за вызначаны прамежак часу той ці іншы паказчык . Сховішча "сырых" дадзеных мы выкарыстоўваем у тым ліку як бэкап і для аднаўлення перадапрацаваных дадзеных, калі такая неабходнасць узнікне.
Калі мы некалькі гадоў таму шукалі, як вырашыць праблему з захоўваннем, у нас было два варыянты для выбару платформы: Kubernetes і OpenStack. Але бо апошні выглядае даволі монструозна (проста паглядзіце на яго архітэктуру, каб пераканацца ў гэтым), то мы спыніліся менавіта на Kubernetes'е. Яшчэ адным аргументам у яго карысць стала адносна простае праграмнае кіраванне, магчымасць больш гнутка наразаць нават жалезныя ноды па рэсурсах.
Раўналежна з засваеннем самога Kubernetes мы вывучалі і спосабы захоўвання дадзеных, пакуль мы ўсе нашы сховішчы трымалі ў Kubernetes на сваім жалезе, мы атрымалі выдатную экспертызу. Усё, што ў нас тады было, жыло менавіта на Kubernetes'е: statefull-сховішча, сістэма маніторынгу, СI/CD. Kubernetes стаў для нас all-in-one платформай.
Але нам хацелася працаваць з Kubernetes'ам як з сервісам, а не займацца яго падтрымкай і распрацоўкай. Плюс нам не падабалася тое, у колькі нам абыходзіцца яго змест на bare metal, а распрацоўка патрабавалася нам увесь час! Напрыклад, адной з першых задач стала ўпісаць Ingress-кантролеры Kubernetes у сеткавую інфраструктуру нашай арганізацыі. Гэта грувасткая задача, асабліва калі ўявіць, што на той момант нічога не было гатова для праграмнага кіравання рэсурсамі накшталт DNS-запісаў або вылучэнні IP-адрасоў. Пазней мы пачалі эксперыментаваць з вонкавым сховішчам дадзеных. Да імплементацыі PVC-кантролера так і не дабраліся, але ўжо тады стала зразумела, што гэта вялікі фронт прац, пад які трэба вылучаць асобных адмыслоўцаў.
Пераход на Google Cloud Platform - часовае рашэнне
Мы зразумелі, што так далей працягвацца не можа, і перанеслі нашыя дадзеныя з bare metal на Google Cloud Platform. Насамрэч, тады для расійскай кампаніі было не так шмат цікавых варыянтаў: акрамя Google Cloud Platform аналагічны сэрвіс прапаноўваў толькі Amazon, але мы ўсёткі спыніліся на рашэнні ад Google. Тады яно здалося нам эканамічна схаднейшым, бліжэйшым да Upstream, не кажучы ўжо пра тое, што Google сам па сабе – гэта своеасаблівы PoC Kubernetes у Production.
Першая сур'ёзная праблема з'явілася на гарызонце паралельна з тым, як расла наша кліенцкая база. Калі ў нас з'явілася неабходнасць захоўваць персанальныя дадзеныя, мы апынуліся перад выбарам: ці працуем з Google і парушаем расійскія законы, ці шукаем альтэрнатыву ў РФ. Выбар, у цэлым, быў прадказальны. 🙂
Якім мы бачылі ідэальны хмарны сэрвіс
Да пачатку пошукаў мы ўжо ведалі, што жадаем атрымаць ад будучыні хмарнага правайдэра. Які сэрвіс мы шукалі:
- Хуткі і гнуткі. Такі, каб мы ў любы момант аператыўна маглі дадаць новую наду ці нешта разгарнуць.
- Недарагі. Нас вельмі хвалявала фінансавае пытанне, бо мы былі абмежаваныя ў рэсурсах. Мы ўжо ведалі, што жадаем працаваць з Kubernetes, і зараз стаяла задача мінімізаваць яго кошт, каб павялічыць ці хаця б захаваць эфектыўнасць выкарыстання гэтага рашэння.
- Аўтаматызаваны. Мы планавалі працаваць з сэрвісам праз API, без менеджэраў і тэлефонных званкоў ці сітуацый, калі трэба ўручную паднімаць некалькі дзясяткаў нод у аўральным рэжыме. Так як большасць працэсаў у нас аўтаматызаваны, таго ж мы чакалі ад хмарнага сэрвісу.
- З серверамі ў РФ. Канешне, мы планавалі выконваць расійскае заканадаўства і той самы 152-ФЗ.
У той час правайдэраў Kubernetes па мадэлі aaS у Расіі было мала, пры гэтым, выбіраючы правайдэра, нам было важна не паступіцца нашымі прыярытэтамі. Каманда Mail.ru Cloud Solutions, з якой мы пачалі працаваць і супрацоўнічаем да гэтага часу, падала нам цалкам аўтаматызаваны сэрвіс, з падтрымкай API і зручнай панэллю кіравання, у якой ёсць Horizon – з ім мы маглі хутка падняць адвольную колькасць нод.
Як нам удалося мігрыраваць у MCS за дзве гадзіны
У падобных пераездах многія кампаніі сутыкаюцца з цяжкасцямі і няўдачамі, але ў нашым выпадку іх не было. Нам павезла: бо мы да пачатку міграцыі ўжо працавалі на Kubernetes'е, мы проста паправілі тры файла і запусцілі свае сэрвісы на новай хмарнай платформе, у MCS. Нагадаю, што да таго часу мы канчаткова пайшлі з bare metal і жылі на Google Cloud Platform. Таму сам пераезд заняў не больш за дзве гадзіны, плюс яшчэ крыху часу (каля гадзіны) пайшло на капіраванне дадзеных з нашых прылад. Тады мы ўжо выкарыстоўвалі Spinnaker (мультывоблачны CD-сэрвіс для забеспячэння Continous Delivery). Яго мы таксама аператыўна дадалі ў новы кластар і працягнулі працаваць у звычайным рэжыме.
Дзякуючы аўтаматызацыі працэсаў распрацоўкі і CI/CD Kubernetes'ам у "Урус" займаецца адзін спецыяліст (і гэта я). На нейкім этапе са мной працаваў яшчэ адзін сістэмны адміністратар, але потым аказалася, што ўсю асноўную руціну мы ўжо аўтаматызавалі а з боку нашага асноўнага прадукта задач усё больш і мае сэнс накіраваць рэсурсы на гэта.
Мы атрымалі ад хмарнага правайдэра тое, што чакалі, бо пачалі супрацоўніцтва без ілюзій. Калі і былі нейкія інцыдэнты, то ў асноўным тэхнічныя і такія, якія лёгка растлумачыць адноснай свежасцю сервісу. Галоўнае, што каманда MCS аператыўна ўхіляе недахопы і хутка рэагуе на пытанні ў месэнджарах.
Калі параўноўваць досвед працы з Google Cloud Platform, то ў іх выпадку я нават не ведаў, дзе знаходзіцца кнопка зваротнай сувязі, бо ў ёй проста не было неабходнасці. А калі нейкія праблемы і здараліся, Google сам рассылаў апавяшчэнні ў аднабаковым парадку. Але ў выпадку з MCS вялікім плюсам я лічу тое, што яны знаходзяцца максімальна блізка да расійскіх кліентаў – і тэрытарыяльна, і ментальна.
Як мы бачым працу з аблокамі ў будучыні
Цяпер наша праца цесна завязана на Kubernetes'е, і ён цалкам задавальняе нас з пункту гледжання інфраструктурных задач. Таму мы не плануем кудысьці з яго міграваць, хоць увесь час уводзім новыя практыкі і сэрвісы для спрашчэння руцінных задач і аўтаматызацыі новых, падвышэнні стабільнасці і надзейнасці сэрвісаў… Цяпер запускаем сэрвіс Chaos Monkey (а пэўна мы выкарыстоўваем chaoskube, але канцэпцыі гэта не змяняе : ), які першапачаткова быў створаны ў Netflix. Chaos Monkey робіць адну простую рэч: у адвольны час выдаляе адвольны пад у Kubernetes'е. Гэта трэба, каб наш сэрвіс нармальна жыў з колькасцю інстансаў n–1, так мы прывучаем сябе быць гатовымі да любых непаладак.
Цяпер я бачу выкарыстанне іншых рашэнняў - тых жа хмарных платформаў - як адзіна правільнае для маладых кампаній. Звычайна ў пачатку шляху яны абмежаваныя ў рэсурсах, як кадравых, так і фінансавых, а будаваць і ўтрымліваць уласнае воблака ці дата-цэнтр занадта дорага і працаёмка. Cloud-правайдэры дазваляюць мінімізаваць гэтыя выдаткі, у іх можна хутка атрымаць рэсурсы, неабходныя для працы сэрвісаў тут і зараз, прычым аплачваць гэтыя рэсурсы па факце. Што да кампаніі «Урус», то мы пакуль застанемся дакладныя Kubernetes'у ў воблаку. Але хто ведае, магчыма, нам давядзецца пашырацца геаграфічна, ці ўкараняць рашэнні на базе нейкага спецыфічнага абсталявання. Ці, можа, колькасць спажываных рэсурсаў апраўдае свой Kubernetes на bare-metal, як у старыя добрыя часы. 🙂
Што мы вынеслі з досведу працы з хмарнымі сэрвісамі
Мы пачалі выкарыстоўваць Kubernetes на bare metal, і нават там ен быў па-свойму добры. Але моцныя яго бакі ўдалося раскрыць менавіта ў якасці aaS-кампанента ў воблаку. Калі паставіць мэту і ўсё максімальна аўтаматызаваць, то атрымаецца пазбегнуць vendor lock-in і пераезд паміж хмарнымі правайдэрамі зойме пару гадзін, а нервовыя клеткі застануцца з намі. Іншым кампаніям мы можам параіць: хочаце запусціць свой (хмарны) сэрвіс, маючы абмежаваныя рэсурсы і максімальны velocity для распрацоўкі - пачынайце прама зараз з арэнды хмарных рэсурсаў, а свой дата-цэнтр будуйце пасля таго, як пра вас напіша Forbes.
Крыніца: habr.com