Компания «УРУС» изпробва Kubernetes в различни формати: самостоятелен деплоймент на bare metal, в Google Cloud, след което прехвърли платформата си в облака Mail.ru Cloud Solutions (MCS). За това как избраха нов облачен доставчик и как успяха да мигрират към него за рекорден период от два часа разказва Игор Шишкин (), старши системен администратор в «УРУС».
С какво се занимава «УРУС»
Има много начини да се подобри качеството на градската среда и един от тях е да я направим екологично безопасна. Именно това твърдо работят в компанията «УРУС — Умни цифрови услуги». Тук внедряват решения, които помагат на предприятията да контролират важни екологични показатели и да намаляват негативното си въздействие върху околната среда. Сензорите събират данни за състава на въздуха, нивото на шума и други параметри, след което ги изпращат в единната платформа «УРУС — Екомон» за анализ и за изготвяне на препоръки.
Как е устроена работата на «УРУС» отвътре
Типичен клиент на «УРУС» е компания, която се намира в жилищна зона или в непосредствена близост до нея. Това може да бъде завод, порт, железопътно депо или всякакъв друг обект. Ако нашият клиент вече е получил предупреждение, е бил глобен за замърсяване на околната среда или сам иска да генерира по-малко шум, да намали количеството на вредните емисии, той идва при нас и ние вече му предлагаме готово решение за екологичен мониторинг.
На графика за мониторинг на концентрацията на H2S се виждат редовни нощни емисии от съседно предприятие.
Устройствата, които използваме в «УРУС», съдържат няколко сензора, които събират информация за съдържанието на определени газове, нивото на шума и други данни за оценка на екологичната ситуация. Точният брой на сензорите винаги се определя от конкретната задача.
В зависимост от спецификата на измерванията, устройствата със сензори могат да бъдат разположени на стените на сградите, стълбовете и на други произволни места. Всяко такова устройство събира информация, агрегира я и я изпраща на шлюз за прием на данни. Там запазваме данните за дългосрочно съхранение и предварително обработваме за последващ анализ. Най-простият пример на това, което получаваме на изхода след анализа – индексът на качеството на въздуха, известен още като AQI.
Паралелелно на нашата платформа работят много други услуги, но предимно те имат обслужваща роля. Например, услугата за уведомления изпраща известия на клиентите, ако някой от следените параметри (например, съдържанието на СО2) надвиши допустимото значение.
Как съ храним данни. История с Kubernetes на bare metal
В проекта за екомониторинг «УРС» има няколко хранилища за данни. В едното съхраняваме «сурови» данни - тези, които получихме директно от самите устройства. Това хранилище представлява «магнитна» лента, подобна на старите касети, с история на всички показания. Вторият тип хранилище се използва за предварително обработени данни - данни от устройства, обогатени с метаданни за връзките между сензорите и показанията на самите устройства, принадлежности на организации, места на разположение и т.н. Тази информация позволява динамично да оценим как се е променяло конкретно показание за определен период от време. Хранилището на «суровите» данни използваме също така като резервно копие и за възстановяване на предварително обработените данни, ако възникне необходимост.
Когато преди няколко години търсихме как да решим проблема със съхранението, имахме два варианта за избор на платформа: Kubernetes и OpenStack. Но тъй като последният изглежда доста монструозно (просто погледнете архитектурата му, за да се уверите в това), се спряхме именно на Kubernetes. Още един аргумент в полза на Kubernetes беше относително лесното програмирано управление и възможността по-гъвкаво да разпределим дори хардуерните възли по ресурси.
Паралелно с усвояването на самия Kubernetes проучвахме и начините за съхранение на данни. Докато всички наши хранилища бяха на Kubernetes на нашето оборудване, получихме отлична експертиза. Всичко, което имахме тогава, функционираше именно на Kubernetes: statefull хранилище, система за мониторинг, 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 и нарушаваме руските закони, или търсим алтернатива в Русия. Изборът, в общи линии, беше предсказуем. 🙂
Какъв виждахме идеален облачен сервис
В началото на търсенията вече знаехме какво искаме да получим от бъдещия облачен доставчик. Какъв сервис търсехме:
- Бърз и гъвкав. Такъв, с който можем бързо да добавим нов възел или нещо да разположим по всяко време.
- Нисък разход. Финансовият въпрос много ни притесняваше, тъй като бяхме ограничени в ресурсите. Вече знаехме, че искаме да работим с 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, така се научаваме да бъдем подготвени за всякакви неполадки.
В момента виждам използването на външни решения — същите облачни платформи — като единствено правилно за младите компании. Обикновено в началото те са ограничени в ресурси, както кадрови, така и финансови, а изграждането и поддържането на собствено облако или дата център е твърде скъпо и трудоемко. Облачните доставчици позволяват да се минимизират тези разходи, от тях може бързо да се получат необходимите ресурси за работа с услугите тук и сега, като се плаща за тях по факта. Що се отнася до компанията „УРУС“, засега ще останем верни на Kubernetes в облака. Но кой знае, може би ще се наложи да се разширяваме географски, или да внедряваме решения на база на специфично оборудване. Или, може би, количеството консумирани ресурси ще оправдае собствения Kubernetes на bare-metal, както в старите добри времена. 🙂
Какво извлякохме от опита си с облачните услуги
Започнахме да използваме Kubernetes на bare metal и дори там той имаше своите предимства. Но истинските му силни страни се разглеждат именно като aaS-компонент в облака. Ако поставите цел и автоматизирате всичко максимално, ще успеете да избегнете vendor lock-in и преминаването между облачни доставчици ще отнеме само няколко часа, което ще запази нервните клетки при нас. На другите компании можем да препоръчаме: искате да стартирате свой (облачен) сервис, имайки ограничени ресурси и максимална скорост за разработка - започнете веднага с наем на облачни ресурси, а собствен дата център изградете след като за вас пише Forbes.
Източник: habr.com
