Ako migrovať do cloudu za dve hodiny vďaka Kubernetes a automatizácii

Ako migrovať do cloudu za dve hodiny vďaka Kubernetes a automatizácii

Spoločnosť URUS vyskúšala Kubernetes v rôznych formách: nezávislé nasadenie na holom kovu v Google Cloud a potom prenieslo svoju platformu do cloudu Mail.ru Cloud Solutions (MCS). Igor Shishkin hovorí, ako si vybrali nového poskytovateľa cloudu a ako sa im podarilo migrovať k nemu za rekordné dve hodiny (t3ran), senior systémový administrátor v URUS.

Čo robí URUS?

Existuje mnoho spôsobov, ako zlepšiť kvalitu mestského prostredia a jedným z nich je urobiť ho šetrným k životnému prostrediu. Presne na tom pracuje spoločnosť URUS - Smart Digital Services. Tu implementujú riešenia, ktoré pomáhajú podnikom monitorovať dôležité environmentálne ukazovatele a znižovať ich negatívny vplyv na životné prostredie. Senzory zhromažďujú údaje o zložení vzduchu, hladine hluku a ďalších parametroch a následne ich odosielajú na jednotnú platformu URUS-Ekomon na analýzu a tvorbu odporúčaní.

Ako URUS funguje zvnútra

Typickým klientom URUS je spoločnosť sídliaca v obytnej štvrti alebo blízko nej. Môže to byť továreň, prístav, železničné depo alebo akékoľvek iné zariadenie. Ak už náš klient dostal upozornenie, dostal pokutu za znečisťovanie životného prostredia, alebo chce znížiť hluk, znížiť množstvo škodlivých emisií, príde za nami a my mu už ponúkame hotové riešenie monitoringu životného prostredia.

Ako migrovať do cloudu za dve hodiny vďaka Kubernetes a automatizácii
Graf monitorovania koncentrácie H2S ukazuje pravidelné nočné emisie z neďalekého závodu

Zariadenia, ktoré v URUS používame, obsahujú niekoľko senzorov, ktoré zbierajú informácie o obsahu určitých plynov, hladinách hluku a ďalšie údaje na vyhodnotenie environmentálnej situácie. Presný počet snímačov je vždy určený konkrétnou úlohou.

Ako migrovať do cloudu za dve hodiny vďaka Kubernetes a automatizácii
V závislosti od špecifík meraní môžu byť zariadenia so snímačmi umiestnené na stenách budov, stĺpoch a iných ľubovoľných miestach. Každé takéto zariadenie zhromažďuje informácie, agreguje ich a odosiela do brány prijímajúcej údaje. Tam dáta uložíme na dlhodobé uchovanie a predspracujeme pre následnú analýzu. Najjednoduchším príkladom toho, čo získame ako výsledok analýzy, je index kvality ovzdušia, tiež známy ako AQI.

Paralelne na našej platforme funguje mnoho ďalších služieb, ktoré sú však prevažne servisného charakteru. Notifikačná služba napríklad posiela klientom notifikácie, ak niektorý zo sledovaných parametrov (napríklad obsah CO2) prekročí povolenú hodnotu.

Ako ukladáme údaje. Príbeh Kubernetesa na holom kove

Projekt monitorovania životného prostredia URUS má niekoľko dátových skladov. V jednom uchovávame „surové“ dáta – to, čo sme dostali priamo zo samotných zariadení. Toto úložisko je „magnetická“ páska, ako na starých kazetách, s históriou všetkých indikátorov. Druhý typ úložiska slúži na predspracované dáta – dáta zo zariadení, obohatené o metadáta o prepojení medzi senzormi a údajoch samotných zariadení, príslušnosti k organizáciám, miestam a pod. Tieto informácie umožňujú dynamicky posúdiť, ako má konkrétny indikátor sa za určité časové obdobie zmenilo. Úložisko „surových“ dát využívame okrem iného ako zálohu a na obnovu predspracovaných dát, ak takáto potreba vznikne.

Keď sme pred niekoľkými rokmi hľadali riešenie nášho problému s úložiskom, mali sme dve možnosti platformy: Kubernetes a OpenStack. Ale keďže ten druhý vyzerá dosť obludne (len sa pozrite na jeho architektúru, aby ste sa o tom presvedčili), rozhodli sme sa pre Kubernetes. Ďalším argumentom v jeho prospech bolo relatívne jednoduché softvérové ​​ovládanie, možnosť flexibilnejšieho strihania aj hardvérových uzlov podľa zdrojov.

Súbežne so samotným ovládaním Kubernetes sme študovali aj spôsoby ukladania dát, pričom sme celé úložisko v Kubernetes ponechali na vlastnom hardvéri, získali sme vynikajúce odborné znalosti. Všetko, čo sme vtedy mali, žilo na Kubernetes: stavové úložisko, monitorovací systém, CI/CD. Kubernetes sa pre nás stal platformou typu všetko v jednom.

Chceli sme však pracovať s Kubernetes ako so službou a nie zapájať sa do jej podpory a vývoja. Navyše sa nám nepáčilo, koľko nás stála údržba na holom kove a neustále sme potrebovali vývoj! Napríklad jednou z prvých úloh bola integrácia kontrolérov Kubernetes Ingress do sieťovej infraštruktúry našej organizácie. Ide o ťažkopádnu úlohu, najmä ak vezmeme do úvahy, že v tom čase nebolo nič pripravené na programovú správu zdrojov, ako sú záznamy DNS alebo prideľovanie IP adries. Neskôr sme začali experimentovať s externým ukladaním dát. Nikdy sme sa nedostali k implementácii ovládača PVC, ale už vtedy bolo jasné, že ide o veľkú oblasť práce, ktorá si vyžaduje špecializovaných špecialistov.

Prechod na Google Cloud Platform je dočasné riešenie

Uvedomili sme si, že to nemôže pokračovať, a presunuli sme naše údaje z holého kovu na platformu Google Cloud Platform. V skutočnosti v tom čase pre ruskú spoločnosť nebolo veľa zaujímavých možností: okrem Google Cloud Platform ponúkal podobnú službu iba Amazon, ale stále sme sa usadili na riešení od spoločnosti Google. Potom sa nám to zdalo ekonomicky výhodnejšie, bližšie k Upstreamu, nehovoriac o tom, že samotný Google je akýmsi PoC Kubernetes vo výrobe.

Prvý veľký problém sa objavil na obzore, keď sa naša zákaznícka základňa rozrástla. Keď sme mali potrebu uchovávať osobné údaje, stáli sme pred voľbou: buď budeme spolupracovať s Google a porušovať ruské zákony, alebo hľadáme alternatívu v Ruskej federácii. Voľba bola celkovo predvídateľná. 🙂

Ako sme videli ideálnu cloudovú službu

Na začiatku hľadania sme už vedeli, čo chceme od budúceho cloudového poskytovateľa získať. Akú službu sme hľadali:

  • Rýchly a flexibilný. Taký, že môžeme kedykoľvek rýchlo pridať nový uzol alebo niečo nasadiť.
  • Lacné. Veľmi nás znepokojovala finančná otázka, keďže sme mali obmedzené zdroje. Už sme vedeli, že chceme pracovať s Kubernetes a teraz bolo úlohou minimalizovať jeho náklady, aby sme zvýšili alebo aspoň zachovali efektivitu používania tohto riešenia.
  • automatizované. Plánovali sme pracovať so službou cez API, bez manažérov a telefonátov či situácií, kedy potrebujeme manuálne zdvihnúť niekoľko desiatok uzlov v núdzovom režime. Keďže väčšina našich procesov je automatizovaná, to isté sme očakávali aj od cloudovej služby.
  • So servermi v Ruskej federácii. Samozrejme, plánovali sme dodržiavať ruskú legislatívu a to isté 152-FZ.

V tom čase bolo v Rusku málo poskytovateľov Kubernetes aaS a pri výbere poskytovateľa bolo pre nás dôležité, aby sme nezľavili z našich priorít. Tím Mail.ru Cloud Solutions, s ktorým sme začali spolupracovať a stále spolupracujeme, nám poskytol plne automatizovanú službu s podporou API a pohodlným ovládacím panelom, ktorý zahŕňa Horizon – s ním sme mohli rýchlo zvýšiť ľubovoľný počet uzlov.

Ako sa nám podarilo migrovať do MCS za dve hodiny

Pri takýchto krokoch mnohé spoločnosti čelia ťažkostiam a neúspechom, v našom prípade však žiadne neboli. Mali sme šťastie: keďže sme na Kubernetes pracovali už pred začiatkom migrácie, jednoducho sme opravili tri súbory a spustili naše služby na novej cloudovej platforme MCS. Dovoľte mi pripomenúť, že v tom čase sme konečne opustili holý kov a žili na Google Cloud Platform. Samotný presun preto netrval viac ako dve hodiny, plus trochu viac času (asi hodinu) zabralo kopírovanie údajov z našich zariadení. Už vtedy sme používali Spinnaker (multi-cloudová CD služba na poskytovanie nepretržitého doručovania). Rýchlo sme ho pridali aj do nového klastra a pokračovali v práci ako zvyčajne.

Vďaka automatizácii vývojových procesov a CI/CD má na starosti Kubernetes v URUS jeden špecialista (a to som ja). V určitej fáze so mnou spolupracoval iný správca systému, ale potom sa ukázalo, že sme už zautomatizovali všetky hlavné rutiny a na strane nášho hlavného produktu bolo stále viac a viac úloh a malo zmysel nasmerovať zdroje na to.

Od poskytovateľa cloudu sme dostali to, čo sme očakávali, keďže sme začali spoluprácu bez ilúzií. Ak sa vyskytli nejaké incidenty, boli to väčšinou technické incidenty a tie, ktoré sa dali ľahko vysvetliť relatívnou čerstvosťou služby. Hlavná vec je, že tím MCS rýchlo odstraňuje nedostatky a rýchlo reaguje na otázky v messengeroch.

Ak porovnám svoje skúsenosti s platformou Google Cloud Platform, v ich prípade som ani nevedel, kde je tlačidlo spätnej väzby, pretože to jednoducho nebolo potrebné. A ak sa vyskytli nejaké problémy, samotný Google jednostranne rozoslal upozornenia. Ale v prípade MCS je podľa mňa veľká výhoda, že sú čo najbližšie k ruským klientom – geograficky aj mentálne.

Ako vidíme prácu s cloudmi v budúcnosti

Teraz je naša práca úzko spätá s Kubernetes a z pohľadu infraštruktúrnych úloh nám úplne vyhovuje. Preto neplánujeme z nej nikam migrovať, aj keď neustále zavádzame nové praktiky a služby na zjednodušenie rutinných úloh a automatizáciu nových, zvýšenie stability a spoľahlivosti služieb... Teraz spúšťame službu Chaos Monkey (konkrétne , používame chaoskube, ale to nič nemení na koncepte: ), ktorý pôvodne vytvoril Netflix. Chaos Monkey robí jednu jednoduchú vec: vymaže náhodný Kubernetes modul v náhodnom čase. Je to potrebné, aby naša služba normálne žila s počtom prípadov n–1, takže sa trénujeme, aby sme boli pripravení na akékoľvek problémy.

Teraz vnímam používanie riešení tretích strán – rovnakých cloudových platforiem – ako jedinú správnu vec pre mladé firmy. Zvyčajne sú na začiatku svojej cesty limitovaní zdrojmi, ľudskými aj finančnými, a vybudovanie a údržba vlastného cloudu alebo dátového centra je príliš drahé a náročné na prácu. Cloud poskytovatelia vám umožňujú tieto náklady minimalizovať, môžete od nich rýchlo získať zdroje potrebné na prevádzku služieb tu a teraz a tieto zdroje následne zaplatiť. Čo sa týka spoločnosti URUS, zatiaľ ostaneme verní Kubernetes v cloude. Ale ktovie, možno budeme musieť geograficky expandovať alebo implementovať riešenia založené na nejakom špecifickom vybavení. Alebo možno množstvo spotrebovaných zdrojov ospravedlňuje vlastné Kubernetes na holých kovoch, ako za starých dobrých čias. 🙂

Čo sme sa naučili pri práci s cloudovými službami

Začali sme používať Kubernetes na holom kove a aj tam to bolo svojím spôsobom dobré. Ale jeho silné stránky boli odhalené práve ako komponent aaS v cloude. Ak si stanovíte cieľ a všetko čo najviac zautomatizujete, budete sa môcť vyhnúť vendor lock-in a presun medzi poskytovateľmi cloudu zaberie pár hodín a nervové bunky ostanú nám. Môžeme poradiť iným spoločnostiam: ak chcete spustiť vlastnú (cloudovú) službu s obmedzenými zdrojmi a maximálnou rýchlosťou vývoja, začnite hneď teraz prenájmom cloudových zdrojov a postavte si svoje dátové centrum, keď o vás Forbes napíše.

Zdroj: hab.com

Pridať komentár