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

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

Какво прави URUS?

Има много начини за подобряване на качеството на градската среда и един от тях е да я направим екологична. Точно върху това работи фирма URUS - Smart Digital Services. Тук те прилагат решения, които помагат на предприятията да наблюдават важни екологични показатели и да намалят отрицателното им въздействие върху околната среда. Сензорите събират данни за състава на въздуха, нивото на шума и други параметри, след което ги изпращат към единната платформа URUS-Ekomon за анализ и изготвяне на препоръки.

Как работи URUS отвътре

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

Графиката за мониторинг на концентрацията на H2S показва редовни нощни емисии от близката инсталация

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

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

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

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

Проектът за мониторинг на околната среда URUS има няколко хранилища за данни. В едната съхраняваме „сурови“ данни – това, което сме получили директно от самите устройства. Това хранилище е "магнитна" лента, като на стари касети, с история на всички индикатори. Вторият тип съхранение се използва за предварително обработени данни - данни от устройства, обогатени с метаданни за връзките между сензорите и показанията на самите устройства, принадлежност към организации, местоположения и т.н. Тази информация ви позволява динамично да оценявате как даден индикатор променяни за определен период от време. Ние използваме „суровото“ хранилище на данни, наред с други неща, като резервно копие и за възстановяване на предварително обработени данни, ако възникне такава необходимост.

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

Успоредно с овладяването на самия Kubernetes, ние също проучихме начини за съхраняване на данни, докато поддържахме цялото си съхранение в Kubernetes на нашия собствен хардуер, получихме отлична експертиза. Всичко, което имахме тогава в Kubernetes: хранилище с пълно състояние, система за наблюдение, CI/CD. Kubernetes се превърна в платформа всичко в едно за нас.

Но искахме да работим с Kubernetes като услуга, а не да се ангажираме с нейната поддръжка и развитие. Освен това не ни харесваше колко ни струваше да го поддържаме на голо метално ниво и постоянно се нуждаехме от развитие! Например, една от първите задачи беше да интегрираме Kubernetes Ingress контролери в мрежовата инфраструктура на нашата организация. Това е тромава задача, особено като се има предвид, че по това време нищо не беше готово за програмно управление на ресурси като DNS записи или разпределяне на IP адреси. По-късно започнахме да експериментираме с външно съхранение на данни. Така и не стигнахме до внедряването на PVC контролера, но още тогава стана ясно, че това е голяма област на работа, която изисква специализирани специалисти.

Преминаването към Google Cloud Platform е временно решение

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

Първият голям проблем се появи на хоризонта, тъй като клиентската ни база нарастваше. Когато имахме нужда да съхраняваме лични данни, бяхме изправени пред избор: или да работим с Google и да нарушаваме руските закони, или да търсим алтернатива в Руската федерация. Като цяло изборът беше предвидим. 🙂

Как видяхме идеалната облачна услуга

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

• Бързо и гъвкаво. Така че можем бързо да добавим нов възел или да внедрим нещо по всяко време.
• Евтино. Бяхме много загрижени за финансовия въпрос, тъй като бяхме ограничени в ресурсите. Вече знаехме, че искаме да работим с Kubernetes и сега задачата беше да минимизираме цената му, за да увеличим или поне да запазим ефективността на използването на това решение.
• Автоматизирано. Планирахме да работим с услугата чрез API, без мениджъри и телефонни обаждания или ситуации, в които трябва ръчно да повдигнем няколко десетки възли в авариен режим. Тъй като повечето от нашите процеси са автоматизирани, очаквахме същото и от облачната услуга.
• Със сървъри в руската федерация. Разбира се, планирахме да спазваме руското законодателство и същия 152-FZ.

По това време имаше малко доставчици на Kubernetes aaS в Русия и когато избирахме доставчик, за нас беше важно да не компрометираме приоритетите си. Екипът на Mail.ru Cloud Solutions, с когото започнахме работа и все още си сътрудничим, ни предостави напълно автоматизирана услуга, с поддръжка на API и удобен контролен панел, който включва Horizon - с него можем бързо да издигнем произволен брой възли.

Как успяхме да мигрираме към MCS за два часа

При подобни ходове много компании се сблъскват с трудности и спънки, но в нашия случай такива нямаше. Имахме късмет: тъй като вече работехме върху Kubernetes преди началото на миграцията, ние просто коригирахме три файла и пуснахме нашите услуги на новата облачна платформа, MCS. Позволете ми да ви напомня, че по това време ние най-накрая бяхме напуснали метала и живеехме в Google Cloud Platform. Следователно самото преместване отне не повече от два часа, плюс малко повече време (около час) беше изразходвано за копиране на данни от нашите устройства. Тогава вече използвахме Spinnaker (мултиоблачна CD услуга за осигуряване на непрекъсната доставка). Също така бързо го добавихме към новия клъстер и продължихме да работим както обикновено.

Благодарение на автоматизацията на процесите на разработка и CI/CD, Kubernetes в URUS се управлява от един специалист (и това съм аз). На някакъв етап друг системен администратор работи с мен, но след това се оказа, че вече сме автоматизирали цялата основна рутина и имаше все повече и повече задачи от страна на основния ни продукт и имаше смисъл да насочваме ресурси към това.

Получихме това, което очаквахме от облачния доставчик, тъй като започнахме сътрудничество без илюзии. Ако имаше някакви инциденти, те бяха предимно технически и лесно можеха да се обяснят с относителната свежест на услугата. Основното е, че екипът на MCS бързо отстранява недостатъците и бързо отговаря на въпроси в месинджърите.

Ако сравня опита си с Google Cloud Platform, в техния случай дори не знаех къде е бутонът за обратна връзка, тъй като просто нямаше нужда от него. И ако възникнат проблеми, самият Google изпраща известия едностранно. Но в случая с MCS мисля, че голямото предимство е, че те са възможно най-близо до руските клиенти - както географски, така и психически.

Как виждаме работата с облаци в бъдеще

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

Сега виждам използването на решения на трети страни - същите облачни платформи - като единственото правилно нещо за младите компании. Обикновено в началото на своя път те са ограничени в ресурси, както човешки, така и финансови, а изграждането и поддържането на собствен облак или център за данни е твърде скъпо и трудоемко. Облачните доставчици ви позволяват да минимизирате тези разходи; можете бързо да получите от тях ресурсите, необходими за работата на услугите тук и сега, и да платите за тези ресурси след факта. Що се отнася до компанията URUS, засега ще останем верни на Kubernetes в облака. Но кой знае, може да се наложи да се разширим географски или да внедрим решения, базирани на някакво специфично оборудване. Или може би количеството консумирани ресурси ще оправдае притежаването на Kubernetes на гол метал, както в добрите стари времена. 🙂

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

Започнахме да използваме Kubernetes на гол метал и дори там беше добре по свой начин. Но неговите силни страни бяха разкрити именно като aaS компонент в облака. Ако си поставите цел и автоматизирате всичко, доколкото е възможно, ще можете да избегнете блокирането на доставчика и преместването между облачните доставчици ще отнеме няколко часа, а нервните клетки ще останат при нас. Можем да посъветваме други компании: ако искате да стартирате своя собствена (облачна) услуга, разполагаща с ограничени ресурси и максимална скорост за развитие, започнете веднага, като наемете облачни ресурси и изградете своя център за данни, след като Forbes напише за вас.

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