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

Компанията «УРУС» изпробва Kubernetes в различни форми: самостоятелно внедряване на bare metal, в Google Cloud, а след това прехвърли своята платформа в облака Mail.ru Cloud Solutions (MCS). Как избраха нов облачен доставчик и как успяха да мигрират при рекордните два часа разказва Игорь Шишкин (t3ran), старши системен администратор на «УРУС».

С какво се занимава «УРУС»

Има много начини да се подобри качеството на градската среда, и един от тях е да се направи екологично безопасна. Точно върху това работят в компанията «УРУС — Умни цифрови услуги». Тук внедряват решения, които помагат на предприятията да следят важни екологични показатели и да намалят негативното въздействие върху околната среда. Сензорите събират данни за състава на въздуха, нивото на шум и други параметри, след което ги изпращат в единната платформа «УРУС — Екомон» за анализ и генериране на препоръки.

Как е организирана работата на «УРУС» отвътре

Типичният клиент на «УРУС» е компания, разположена в жилищна зона или в близост до нея. Това може да бъде завод, пристанище, жп депо или всякакъв друг обект. Ако нашият клиент вече е получил предупреждение, е бил глобен за замърсяване на околната среда или сам иска да издава по-малко шум, да намали количеството вредни емисии, той се обръща към нас, и ние вече му предлагаме готово решение за екологичен мониторинг.

На графиката за мониторинг на концентрацията на H2S се виждат редовни нощни емисии от съседното предприятие.

Устройствата, които използваме в «УРУС», съдържат няколко сензора, които събират информация за съдържанието на определени газове, нивото на шум и други данни за оценка на екологичната обстановка. Точното количество сензори винаги се определя от конкретната задача.

В зависимост от спецификата на измерванията, устройствата със сензори могат да се намират на стените на сгради, стълбове и на други произволни места. Всяко такова устройство събира информация, агрегират я и я изпраща на шлюз за прием на данни. Там запазваме данните за дългосрочно съхранение и подготвяме за последващ анализ. Най-простият пример за това, което получаваме на изхода след анализа, е индексът на качеството на въздуха, известен още като AQI.

Паралелно на нашата платформа работят и много други услуги, но основно те имат обслужваща роля. Например, услугата за уведомления изпраща известия на клиентите, ако някой от следените параметри (например, съдържанието на CO2) надхвърли допустимото значение.

Как съхраняваме данни. История с Kubernetes на bare metal

В проекта за екомониторинг „УРУС“ има няколко хранилища на данни. В едно съхраняваме „сурови“ данни — това, което сме получили директно от самите устройства. Това хранилище представлява „магнитна“ лента, подобна на старите касети, с история на всички показатели. Вторият тип хранилище се използва за предварително обработени данни — данни от устройствата, обогатени с метаданни относно връзките на сензорите и показанията на самите устройства, принадлежност към организации, места на разположение и т.н. Тази информация позволява динамична оценка на промените в определен показател за зададен период от време. Хранилището на „суровите“ данни го използваме и като резервно копие и за възстановяване на предварително обработени данни, ако се появи необходимост.

Когато преди няколко години търсехме решение за проблема с съхранението, имахме два варианта на разположение: Kubernetes и OpenStack. Но тъй като последният изглежда доста монструозно (просто погледнете архитектурата му, за да се уверите в това), се спряхме именно на Kubernetes. Още един аргумент в негова полза беше относително лесното програмено управление, възможността да разпределяме дори физическите нодузи по ресурси по-ефективно.

Паралелно с изучаването на самия Kubernetes проучвахме и начините за съхранение на данни, докато всички наши хранилища бяха в Kubernetes на собственото ни оборудване, получихме отлична експертиза. Всичко, което имахме тогава, функционираше именно на Kubernetes: stateful хранилище, система за мониторинг, CI/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 и нарушаваме руските закони, или търсим алтернатива в Русия. Изборът, по принцип, беше предсказуем. 🙂

Какъв идеален облачен сервис виждахме

Към началото на търсенето вече знаехме какво искаме да получим от бъдещия облачен доставчик. Каква услуга търсехме:

Бърза и гъвкава. Такава, с която в момент можем бързо да добавим нова нода или да разположим нещо.
Недорогa. Финансовият въпрос ни тревожеше много, защото бяхме ограничени в ресурсите. Вече знаехме, че искаме да работим с 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, в «УРУС» се занимава само един специалист (и това съм аз). На някакъв етап с мен работеше още един системен администратор, но после стана ясно, че всичката основна рутина вече беше автоматизирана, а откъм нашия основен продукт задачите ставаха все повече и имаше смисъл да пренасочим ресурсите към тях.

Получихме от облачния доставчик именно това, което очаквахме, тъй като започнахме сътрудничество без илюзии. Ако имаше някакви инциденти, то те бяха основно технически и такива, които лесно могат да се обяснят с относителната новост на услугата. Най-важното е, че екипът на 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 и мигрирането между облачни доставчици ще отнеме само няколко часа, а нервните ви клетки ще останат с вас. Другите компании, на които можем да предложим съвет, е: ако искате да стартирате собствен (облачен) сервис с ограничени ресурси и максимална скорост на разработка — започнете веднага с наемане на облачни ресурси, а изграждането на собствен дата център оставете за момента, когато Forbes пише за вас.

Източник: habr.com