Společnost URUS vyzkoušela Kubernetes v různých formách: nezávislé nasazení na holém kovu v Google Cloud a poté přenesla svou platformu do cloudu Mail.ru Cloud Solutions (MCS). Igor Shishkin vypráví, jak si vybrali nového poskytovatele cloudu a jak se jim podařilo migrovat k němu za rekordní dvě hodiny (), senior system administrator ve společnosti URUS.
Co dělá URUS?
Existuje mnoho způsobů, jak zlepšit kvalitu městského prostředí a jedním z nich je učinit ho šetrným k životnímu prostředí. Právě na tom pracuje společnost URUS - Smart Digital Services. Zde implementují řešení, která podnikům pomáhají sledovat důležité environmentální indikátory a snižovat jejich negativní dopad na životní prostředí. Senzory shromažďují data o složení vzduchu, hladině hluku a dalších parametrech a poté je odesílají do jednotné platformy URUS-Ekomon k analýze a doporučení.
Jak URUS funguje zevnitř
Typickým klientem URUS je společnost sídlící v rezidenční čtvrti nebo v její blízkosti. Může to být továrna, přístav, železniční depo nebo jakékoli jiné zařízení. Pokud náš klient již dostal varování, dostal pokutu za znečištění životního prostředí, nebo chce méně hlučnět, snížit množství škodlivých emisí, přijde za námi a my mu již nabízíme hotové řešení monitoringu životního prostředí.
Graf monitorování koncentrace H2S ukazuje pravidelné noční emise z blízkého závodu
Zařízení, která ve společnosti URUS používáme, obsahují několik senzorů, které shromažďují informace o obsahu určitých plynů, hladinách hluku a další údaje pro vyhodnocení situace prostředí. Přesný počet senzorů je vždy určen konkrétním zadáním.
V závislosti na specifikách měření mohou být zařízení se snímači umístěna na stěnách budov, sloupech a dalších libovolných místech. Každé takové zařízení shromažďuje informace, agreguje je a posílá je do brány pro příjem dat. Tam data uložíme pro dlouhodobé uložení a předzpracujeme je pro následnou analýzu. Nejjednodušším příkladem toho, co získáme jako výsledek analýzy, je index kvality ovzduší, známý také jako AQI.
Paralelně na naší platformě funguje mnoho dalších služeb, které jsou však převážně servisního charakteru. Notifikační služba například zasílá klientům upozornění, pokud některý ze sledovaných parametrů (například obsah CO2) překročí přípustnou hodnotu.
Jak uchováváme data. Příběh Kubernetese na holém kovu
Projekt monitorování životního prostředí URUS má několik datových skladů. V jednom uchováváme „surová“ data – to, co jsme obdrželi přímo ze samotných zařízení. Toto úložiště je „magnetická“ páska, jako na starých kazetách, s historií všech indikátorů. Druhý typ úložiště slouží pro předzpracovaná data – data ze zařízení, obohacená o metadata o spojení mezi senzory a odečty samotných zařízení, příslušnost k organizacím, lokalitám apod. Tyto informace umožňují dynamicky posoudit, jak má konkrétní indikátor se za určité časové období změnilo. Úložiště „surových“ dat využíváme mimo jiné jako zálohu a pro obnovu předzpracovaných dat, pokud taková potřeba nastane.
Když jsme před několika lety hledali řešení našeho problému s úložištěm, měli jsme dvě možnosti platformy: Kubernetes a OpenStack. Ale protože ten druhý vypadá docela monstrózně (stačí se podívat na jeho architekturu, abyste se o tom přesvědčili), rozhodli jsme se pro Kubernetes. Dalším argumentem v jeho prospěch bylo relativně jednoduché softwarové ovládání, možnost flexibilněji řezat i hardwarové uzly podle zdrojů.
Paralelně se zvládnutím samotného Kubernetes jsme také studovali způsoby ukládání dat, zatímco jsme veškeré úložiště v Kubernetes drželi na vlastním hardwaru, získali jsme vynikající odborné znalosti. Vše, co jsme tehdy měli, žilo na Kubernetes: stavové úložiště, monitorovací systém, CI/CD. Kubernetes se pro nás stal all-in-one platformou.
Ale chtěli jsme s Kubernetes pracovat jako se službou a ne se zapojovat do její podpory a vývoje. Navíc se nám nelíbilo, kolik nás stála údržba na holém kovu, a neustále jsme potřebovali vývoj! Jedním z prvních úkolů byla například integrace kontrolérů Kubernetes Ingress do síťové infrastruktury naší organizace. Jedná se o těžkopádný úkol, zvláště vezmeme-li v úvahu, že v té době nebylo nic připraveno na programovou správu zdrojů, jako jsou záznamy DNS nebo přidělování IP adres. Později jsme začali experimentovat s externím úložištěm dat. Nikdy jsme se nedostali k implementaci ovladače PVC, ale už tehdy bylo jasné, že to byla velká oblast práce, která vyžadovala specializované specialisty.
Přechod na Google Cloud Platform je dočasné řešení
Uvědomili jsme si, že to nemůže pokračovat, a přesunuli jsme naše data z holého kovu do Google Cloud Platform. Ve skutečnosti v té době nebylo pro ruskou společnost mnoho zajímavých možností: kromě Google Cloud Platform nabízel podobnou službu pouze Amazon, ale i tak jsme se spokojili s řešením od Googlu. Pak se nám to zdálo ekonomicky výhodnější, blíže Upstreamu, nemluvě o tom, že samotný Google je jakýmsi PoC Kubernetes ve výrobě.
První velký problém se objevil na obzoru, když se naše zákaznická základna rozrostla. Když jsme měli potřebu uchovávat osobní údaje, stáli jsme před volbou: buď spolupracujeme s Googlem a porušujeme ruské zákony, nebo hledáme alternativu v Ruské federaci. Volba byla celkově předvídatelná. 🙂
Jak jsme viděli ideální cloudovou službu
Na začátku hledání jsme již věděli, co chceme od budoucího cloudového poskytovatele získat. Jakou službu jsme hledali:
- Rychlé a flexibilní. Takový, že můžeme kdykoli rychle přidat nový uzel nebo něco nasadit.
- Levný. Velmi nás znepokojovala finanční otázka, protože jsme měli omezené zdroje. Už jsme věděli, že chceme pracovat s Kubernetes a nyní bylo úkolem minimalizovat jeho náklady, abychom zvýšili nebo alespoň udrželi efektivitu používání tohoto řešení.
- Automatizovaný. Plánovali jsme pracovat se službou přes API, bez manažerů a telefonátů nebo situací, kdy potřebujeme ručně nazvednout několik desítek uzlů v nouzovém režimu. Protože většina našich procesů je automatizovaná, očekávali jsme totéž od cloudové služby.
- Se servery v Ruské federaci. Samozřejmě jsme plánovali splnit ruskou legislativu a to samé 152-FZ.
V té době bylo v Rusku málo poskytovatelů Kubernetes aaS a při výběru poskytovatele bylo pro nás důležité neslevit ze svých priorit. Tým Mail.ru Cloud Solutions, se kterým jsme začali spolupracovat a stále spolupracujeme, nám poskytl plně automatizovanou službu s podporou API a pohodlným ovládacím panelem, který zahrnuje Horizon – s ním jsme mohli rychle zvýšit libovolný počet uzlů.
Jak jsme zvládli migraci na MCS za dvě hodiny
Při takových krocích se mnoho společností potýká s obtížemi a neúspěchy, v našem případě však žádné nebyly. Měli jsme štěstí: protože jsme na Kubernetes pracovali již před začátkem migrace, jednoduše jsme opravili tři soubory a spustili naše služby na nové cloudové platformě MCS. Dovolte mi připomenout, že do té doby jsme konečně opustili holý kov a žili na Google Cloud Platform. Samotné stěhování tedy netrvalo déle než dvě hodiny, plus trochu více času (asi hodinu) zabralo kopírování dat z našich zařízení. Už tehdy jsme používali Spinnaker (multi-cloudová CD služba pro zajištění nepřetržitého doručování). Také jsme jej rychle přidali do nového clusteru a pokračovali v práci jako obvykle.
Díky automatizaci vývojových procesů a CI/CD se o Kubernetes v URUS stará jeden specialista (a to jsem já). V určité fázi se mnou spolupracoval jiný systémový administrátor, ale pak se ukázalo, že jsme již zautomatizovali všechny hlavní rutiny a na straně našeho hlavního produktu bylo stále více a více úkolů a mělo smysl nasměrovat zdroje na to.
Od poskytovatele cloudu jsme dostali to, co jsme očekávali, protože jsme zahájili spolupráci bez iluzí. Pokud se vyskytly nějaké incidenty, byly to většinou technické události, které bylo možné snadno vysvětlit relativní čerstvostí služby. Hlavní věc je, že tým MCS rychle odstraňuje nedostatky a rychle reaguje na dotazy v messengerech.
Pokud porovnám své zkušenosti s Google Cloud Platform, v jejich případě jsem ani nevěděl, kde je tlačítko zpětné vazby, protože to prostě nebylo potřeba. A pokud se vyskytly nějaké problémy, sám Google jednostranně rozeslal upozornění. Ale v případě MCS je podle mě velká výhoda, že jsou co nejblíže ruským klientům – geograficky i mentálně.
Jak vidíme práci s cloudy v budoucnosti
Nyní je naše práce úzce svázána s Kubernetes a z hlediska infrastrukturních úkolů nám zcela vyhovuje. Neplánujeme proto z ní nikam migrovat, i když neustále zavádíme nové praktiky a služby pro zjednodušení rutinních úkonů a automatizaci nových, zvýšení stability a spolehlivosti služeb... Nově spouštíme službu Chaos Monkey (konkrétně , používáme chaoskube, ale to nic nemění na konceptu: ), který původně vytvořil Netflix. Chaos Monkey dělá jednu jednoduchou věc: smaže náhodný Kubernetes modul v náhodném čase. To je nezbytné, aby naše služba normálně žila s počtem instancí n–1, takže se trénujeme, abychom byli připraveni na jakékoli problémy.
Nyní vidím použití řešení třetích stran – stejných cloudových platforem – jako jediné správné pro mladé firmy. Obvykle jsou na začátku své cesty omezeni zdroji, lidskými i finančními, a vybudování a údržba vlastního cloudu nebo datového centra je příliš nákladná a pracná. Poskytovatelé cloudu vám umožňují tyto náklady minimalizovat, můžete u nich rychle získat prostředky potřebné pro provoz služeb tady a teď a tyto prostředky následně zaplatit. Co se týče společnosti URUS, zatím zůstaneme věrni Kubernetes v cloudu. Ale kdo ví, možná budeme muset geograficky expandovat nebo implementovat řešení založená na nějakém konkrétním vybavení. Nebo možná množství spotřebovaných zdrojů ospravedlní vlastní Kubernetes na bare-metal, jako za starých dobrých časů. 🙂
Co jsme se naučili při práci s cloudovými službami
Začali jsme používat Kubernetes na holém kovu a i tam to bylo svým způsobem dobré. Ale jeho silné stránky byly odhaleny právě jako součást aaS v cloudu. Pokud si stanovíte cíl a vše co nejvíce zautomatizujete, budete se moci vyhnout vendor lock-in a přesun mezi cloudovými poskytovateli zabere pár hodin a nervové buňky nám zůstanou. Můžeme poradit dalším společnostem: pokud chcete spustit vlastní (cloudovou) službu s omezenými zdroji a maximální rychlostí vývoje, začněte hned teď pronájmem cloudových zdrojů a postavte si své datové centrum poté, co o vás Forbes napíše.
Zdroj: www.habr.com