Како да мигрирате во облакот за два часа благодарение на Kubernetes и автоматизацијата

Компанијата URUS го испроба Kubernetes во различни форми: независно распоредување на гол метал, во Google Cloud, а потоа ја префрли својата платформа во облакот Mail.ru Cloud Solutions (MCS). Игор Шишкин раскажува како избрале нов провајдер на облак и како успеале да мигрираат во него за рекордни два часа (t3ran), виш системски администратор во УРУС.

Што прави УРУС?

Постојат многу начини да се подобри квалитетот на урбаната средина, а еден од нив е да се направи еколошки. Токму на ова работи компанијата URUS - Smart Digital Services. Овде тие имплементираат решенија кои им помагаат на претпријатијата да ги следат важните еколошки индикатори и да го намалат нивното негативно влијание врз животната средина. Сензорите собираат податоци за составот на воздухот, нивото на бучава и други параметри, а потоа ги испраќаат до унифицираната платформа URUS-Ekomon за анализа и давање препораки.

Како функционира УРУС одвнатре

Типичен клиент на URUS е компанија лоцирана во или во близина на станбена област. Ова може да биде фабрика, пристаниште, железничко складиште или кој било друг објект. Доколку нашиот клиент веќе добил предупредување, е казнет за загадување на животната средина или сака да прави помала бучава, да ја намали количината на штетни емисии, тој доаѓа кај нас, а ние веќе му нудиме готово решение за мониторинг на животната средина.

Графикот за следење на концентрацијата на H2S покажува редовни ноќни емисии од блиската постројка

Уредите што ги користиме во URUS содржат неколку сензори кои собираат информации за содржината на одредени гасови, нивоата на бучава и други податоци за да ја проценат еколошката состојба. Точниот број на сензори секогаш се одредува според конкретната задача.

Во зависност од спецификите на мерењата, уредите со сензори можат да се лоцираат на ѕидовите на зградите, столбовите и други произволни места. Секој таков уред собира информации, ги собира и ги испраќа до портата за примање податоци. Таму ги зачувуваме податоците за долгорочно складирање и претходно ги обработуваме за последователна анализа. Наједноставниот пример за тоа што го добиваме како резултат на анализата е индексот за квалитет на воздухот, познат и како AQI.

Паралелно, на нашата платформа работат многу други услуги, но тие се главно од услужна природа. На пример, услугата за известување испраќа известувања до клиентите доколку некој од набљудуваните параметри (на пример, содржина на CO2) ја надминува дозволената вредност.

Како складираме податоци. Приказната за Kubernetes на гол метал

Проектот URUS за мониторинг на животната средина има неколку складишта на податоци. Во еден од нив чуваме „необработени“ податоци - она ​​што го добивме директно од самите уреди. Ова складирање е „магнетна“ лента, како на старите касети, со историја на сите индикатори. Вториот тип складирање се користи за претходно обработени податоци - податоци од уреди, збогатени со метаподатоци за врските помеѓу сензорите и читањата на самите уреди, поврзаност со организации, локации итн. Оваа информација ви овозможува динамично да процените како има одреден индикатор се менува во одреден временски период. Ние го користиме складирањето на „суровини“ податоци, меѓу другото, како резервна копија и за враќање на претходно обработените податоци, доколку се појави таква потреба.

Кога баравме да го решиме нашиот проблем со складирањето пред неколку години, имавме два избора на платформа: Kubernetes и OpenStack. Но, бидејќи второто изгледа прилично монструозно (само погледнете ја неговата архитектура за да се уверите во ова), се населивме на Кубернетес. Друг аргумент во негова корист беше релативно едноставната софтверска контрола, можноста за пофлексибилно намалување дури и хардверски јазли според ресурсите.

Паралелно со совладувањето на самиот Kubernetes, проучувавме и начини за складирање податоци, додека целото складирање во Kubernetes го чувавме на сопствен хардвер, добивме одлична експертиза. Сè што тогаш живеевме на Kubernetes: целосно складирање, систем за следење, CI/CD. Kubernetes стана се-во-едно платформа за нас.

Но, сакавме да работиме со Kubernetes како услуга, а не да се вклучиме во неговата поддршка и развој. Плус, не ни се допадна колку не чинеше да го одржуваме на гол метал и ни требаше постојано развивање! На пример, една од првите задачи беше да се интегрираат контролорите на Kubernetes Ingress во мрежната инфраструктура на нашата организација. Ова е незгодна задача, особено ако се земе предвид дека во тоа време ништо не беше подготвено за програмско управување со ресурсите, како што се записите DNS или распределбата на IP адреси. Подоцна почнавме да експериментираме со надворешно складирање на податоци. Никогаш не успеавме да го имплементираме ПВЦ контролерот, но дури и тогаш стана јасно дека ова е голема област на работа која бара посветени специјалисти.

Префрлувањето на Google Cloud Platform е привремено решение

Сфативме дека ова не може да продолжи и ги преместивме нашите податоци од гол метал на Google Cloud Platform. Всушност, во тоа време немаше многу интересни опции за руска компанија: покрај Google Cloud Platform, само Amazon понуди слична услуга, но ние сепак се решивме на решението од Google. Тогаш ни се чинеше економски поисплатливо, поблиску до Upstream, а да не зборуваме за фактот дека самиот Google е еден вид PoC Kubernetes во продукција.

Првиот голем проблем се појави на хоризонтот како што растеше нашата база на клиенти. Кога имавме потреба да складираме лични податоци, бевме соочени со избор: или работиме со Google и ги прекршуваме руските закони или бараме алтернатива во Руската Федерација. Изборот, во целина, беше предвидлив. 🙂

Како ја видовме идеалната услуга за облак

До почетокот на пребарувањето, веќе знаевме што сакаме да добиеме од идниот обезбедувач на облак. Каква услуга баравме:

• Брзо и флексибилно. Така што можеме брзо да додадеме нов јазол или да распоредиме нешто во секое време.
• Ефтин. Бевме многу загрижени за финансиското прашање, бидејќи бевме ограничени во ресурси. Веќе знаевме дека сакаме да работиме со Kubernetes, а сега задачата беше да се минимизираат трошоците за да се зголеми или барем да се одржи ефикасноста на користењето на ова решение.
• Автоматизирано. Планиравме да работиме со услугата преку API, без менаџери и телефонски повици или ситуации кога треба рачно да подигнеме неколку десетици јазли во итен режим. Бидејќи повеќето од нашите процеси се автоматизирани, истото го очекувавме и од услугата облак.
• Со сервери во Руската Федерација. Се разбира, планиравме да се усогласиме со руското законодавство и истиот 152-ФЗ.

Во тоа време, имаше малку провајдери на Kubernetes aaS во Русија, а при изборот на провајдер, ни беше важно да не ги компромитираме нашите приоритети. Тимот на Mail.ru Cloud Solutions, со кој почнавме да работиме и сè уште соработуваме, ни обезбеди целосно автоматизирана услуга, со поддршка за API и удобен контролен панел кој го вклучува Horizon - со него брзо би можеле да подигнеме произволен број на јазли.

Како успеавме да мигрираме во МЦС за два часа

Во ваквите потези многу компании се соочуваат со тешкотии и падови, но во нашиот случај немаше такви. Имавме среќа: бидејќи веќе работевме на Kubernetes пред да започне миграцијата, едноставно коригиравме три датотеки и ги лансиравме нашите услуги на новата облак платформа, MCS. Дозволете ми да ве потсетам дека дотогаш конечно го оставивме голиот метал и живеевме на Google Cloud Platform. Затоа, самиот потег траеше не повеќе од два часа, плус малку повеќе време (околу еден час) беше потрошено за копирање податоци од нашите уреди. Тогаш веќе користевме Spinnaker (сервис за ЦД со повеќе облаци за да обезбедиме континуирана испорака). Исто така, брзо го додадовме во новиот кластер и продолживме да работиме како и обично.

Благодарение на автоматизацијата на развојните процеси и CI/CD, со Kubernetes во URUS управува еден специјалист (а тоа сум јас). Во одредена фаза, друг системски администратор работеше со мене, но потоа се покажа дека веќе ја автоматизиравме целата главна рутина и имаше сè повеќе задачи од страна на нашиот главен производ и имаше смисла да ги насочиме ресурсите кон ова.

Го добивме она што го очекувавме од облак провајдерот, бидејќи започнавме соработка без илузии. Доколку имало некакви инциденти, тие биле претежно технички и оние кои лесно може да се објаснат со релативната свежина на услугата. Главната работа е што тимот на MCS брзо ги елиминира недостатоците и брзо одговара на прашањата во гласниците.

Ако го споредам моето искуство со Google Cloud Platform, во нивниот случај не ни знаев каде е копчето за повратни информации, бидејќи едноставно немаше потреба од тоа. И ако навистина се јавиле некакви проблеми, самиот Google испраќал известувања еднострано. Но, во случајот со MCS, мислам дека големата предност е што тие се што е можно поблиску до руските клиенти - и географски и ментално.

Како гледаме да работиме со облаци во иднина

Сега нашата работа е тесно поврзана со Кубернетес и целосно ни одговара од гледна точка на инфраструктурните задачи. Затоа, не планираме никаде да мигрираме од него, иако постојано воведуваме нови практики и услуги за поедноставување на рутинските задачи и автоматизирање нови, зголемување на стабилноста и доверливоста на услугите... Сега ја лансираме услугата Chaos Monkey (конкретно , користиме chaoskube, но ова не го менува концептот: ), кој првично беше создаден од Netflix. Chaos Monkey прави една едноставна работа: брише случаен Kubernetes pod во случајно време. Ова е неопходно за нашата услуга да живее нормално со бројот на примероци n–1, па затоа се тренираме да бидеме подготвени за какви било проблеми.

Сега ја гледам употребата на решенија од трети страни - истите облак платформи - како единствената вистинска работа за младите компании. Обично, на почетокот на нивното патување, тие се ограничени во ресурси, и човечки и финансиски, а градењето и одржувањето на сопствен облак или центар за податоци е премногу скапо и бара труд. Обезбедувачите на облак ви дозволуваат да ги минимизирате овие трошоци; можете брзо да ги добиете од нив ресурсите неопходни за функционирање на услугите овде и сега, и да ги платите овие ресурси после фактот. Што се однесува до компанијата URUS, засега ќе останеме верни на Kubernetes во облакот. Но, кој знае, можеби ќе треба да се прошириме географски или да имплементираме решенија засновани на одредена специфична опрема. Или можеби количината на потрошени ресурси ќе го оправда сопствениот Kubernetes на гол метал, како во старите добри времиња. 🙂

Што научивме од работата со облак услуги

Почнавме да користиме Kubernetes на гол метал, па дури и таму беше добро на свој начин. Но, неговите силни страни беа откриени токму како aaS компонента во облакот. Ако поставите цел и автоматизирате сè што е можно повеќе, ќе можете да избегнете заклучување на продавачот и движењето помеѓу добавувачите на облак ќе потрае неколку часа, а нервните клетки ќе останат кај нас. Можеме да ги советуваме другите компании: ако сакате да лансирате сопствена (облак) услуга, со ограничени ресурси и максимална брзина за развој, започнете веднаш со изнајмување ресурси на облак и изградете го вашиот центар за податоци откако Форбс ќе пишува за вас.

Извор: www.habr.com