Společnost „URUS“ vyzkoušela Kubernetes v různých formách: samostatné nasazení na bare metal, v Google Cloud a poté převedla svou platformu do cloudového řešení Mail.ru Cloud Solutions (MCS). Jak vybírali nového cloudového poskytovatele a jak se jim podařilo migrovat k němu během rekordních dvou hodin vypráví Igor Šiškin (), senior systémový administrátor společnosti „URUS“.
Čím se zabývá „URUS“
Existuje mnoho způsobů, jak zlepšit kvalitu městského prostředí, a jedním z nich je učinit ho ekologicky bezpečným. Na tom právě pracují ve společnosti „URUS — Chytré digitální služby“. Zde zavádějí řešení, která pomáhají podnikům sledovat důležité ekologické ukazatele a snižovat negativní dopad na životní prostředí. Senzory shromažďují data o složení vzduchu, úrovni hluku a dalších parametrech, poté je odesílají na jednotnou platformu „URUS — Ekomon“ pro analýzu a vytváření doporučení.
Jak funguje „URUS“ zevnitř
Typickým klientem „URUS“ je společnost, která se nachází v obytné zóně nebo v její blízkosti. Může to být továrna, přístav, železniční depo nebo jakýkoli jiný objekt. Pokud náš klient již dostal varování, byl pokutován za znečištění životního prostředí nebo chce sám vydávat méně hluku a snížit množství škodlivých emisí, obrátí se na nás a my mu nabídneme hotové řešení pro ekologický monitoring.
Na grafu sledování koncentrace H2S jsou viditelné pravidelné noční emise sousedního podniku.
Zařízení, která používáme v „URUS“, obsahují několik senzorů, které shromažďují informace o obsahu určitých plynů, úrovni hluku a dalších datech pro hodnocení ekologického stavu. Přesný počet senzorů je vždy určen konkrétním úkolem.
V závislosti na specifikaci měření se zařízení se senzory mohou umisťovat na stěny budov, sloupy a na dalších libovolných místech. Každé takové zařízení shromažďuje informace, agreguje je a odesílá na bránu příjmu dat. Tam uchováváme data pro dlouhodobé skladování a předzpracováváme je pro následnou analýzu. Nejjednodušší příklad toho, co získáváme po analýze, je index kvality vzduchu, také známý jako AQI.
Na naší platformě běží současně mnoho dalších služeb, ale většinou mají podpůrný charakter. Například notifikační služba posílá klientům upozornění, pokud některý ze sledovaných parametrů (například obsah CO2) překročí povolenou hodnotu.
Jak ukládáme data. Příběh s Kubernetes na bare metal
V projektu ekomonitoringu "URUS" máme několik úložišť dat. V jednom uchováváme "syrová" data — to, co jsme získali přímo od samotných zařízení. Toto úložiště představuje "magnetickou" pásku, jako na starých kazetách, s historií všech ukazatelů. Druhý typ úložiště se používá pro předzpracovaná data — data z zařízení obohacená metadaty o vazbách senzorů a měření samotných zařízení, příslušnosti k organizacím, místům umístění atd. Tyto informace umožňují dynamicky posoudit, jak se v určitém časovém období měnil ten či onen ukazatel. Úložiště "syrových" dat používáme také jako zálohu a k obnově předzpracovaných dat, pokud by taková potřeba vznikla.
Když jsme před několika lety hledali, jak vyřešit problém se skladováním, měli jsme dvě možnosti pro výběr platformy: Kubernetes a OpenStack. Ale protože ta druhá vypadá docela monstrózně (stačí se podívat na její architekturu, abyste se o tom přesvědčili), rozhodli jsme se pro Kubernetes. Dalším argumentem ve prospěch bylo relativně jednoduché programové řízení a možnost flexibilněji rozdělovat i fyzické uzly podle zdrojů.
Současně s osvojením samotného Kubernetes jsme zkoumali také metody ukládání dat, zatímco jsme všechna naše úložiště měli v Kubernetes na vlastní infrastruktuře, získali jsme skvělou odbornost. Všechno, co jsme tehdy měli, běželo právě na Kubernetes: stateful úložiště, monitorovací systém, CI/CD. Kubernetes se pro nás stal univerzální platformou.
Chtěli jsme však pracovat s Kubernetes jako se službou, a ne se zabývat jeho správou a vývojem. Navíc se nám nelíbilo, kolik nás stojí jeho údržba na bare metal, a vývoj byl neustále potřeba! Například jedním z prvních úkolů bylo začlenit Ingress kontroléry Kubernetes do síťové infrastruktury naší organizace. To byl složitý úkol, zejména když vezmete v úvahu, že tehdy nebylo nic připraveno pro programové řízení zdrojů jako jsou DNS záznamy nebo přidělování. IP adressPozději jsme začali experimentovat s externím uložištěm dat. K implementaci PVC kontroléru jsme se však nedostali, ale už tehdy bylo zřejmé, že se jedná o velký objem práce, na který je třeba vyčlenit jednotlivé specialisty.
Přechod na Google Cloud Platform bylo dočasné řešení.
Uvědomili jsme si, že takto to dál pokračovat nemůže, a přenesli jsme naše data z bare metal na Google Cloud Platform. Ve skutečnosti v té době pro ruskou společnost nebylo mnoho zajímavých možností: kromě Google Cloud Platform podobnou službu nabízela jen Amazon, ale nakonec jsme se rozhodli pro řešení od Google. To se nám tehdy zdálo ekonomicky výhodnější a blíž k Upstream, nemluvě o tom, že Google sám o sobě byl jakýmsi PoC Kubernetes v produkci.
První vážný problém se objevil, když rostla naše klientská základna. Když jsme potřebovali uchovávat osobní údaje, ocitli jsme se před volbou: buď budeme pracovat s Googlem a porušovat ruské zákony, nebo hledat alternativu v RF. Výběr byl v zásadě předvídatelný. 🙂
Jaký jsme viděli ideální cloudový servis
Na začátku hledání jsme už věděli, co chceme od budoucího cloudového poskytovatele. Jakou službu jsme hledali:
- Rychlou a flexibilní. Takovou, abychom mohli kdykoliv rychle přidat novou uzel nebo něco nasadit.
- Levnou. Finanční otázka nás velmi zajímala, protože jsme byli omezeni v prostředcích. Už jsme věděli, že chceme pracovat s Kubernetes, a nyní jsme se snažili minimalizovat jeho náklady, abychom zvýšili nebo alespoň udrželi efektivnost využití tohoto řešení.
- Automatizovaný. Plánovali jsme pracovat se službou prostřednictvím API, bez manažerů a telefonických hovorů nebo situací, kdy je třeba manuálně zprovozňovat desítky nodů v časovém stresu. Vzhledem k tomu, že většina procesů je u nás automatizovaná, stejné jsme očekávali od cloudové služby.
- Se servery v RF. Samozřejmě jsme plánovali dodržovat ruské zákony a onen zákon 152-FZ.
V té době bylo v Rusku málo poskytovatelů Kubernetes na modelu aaS a při výběru poskytovatele bylo pro nás důležité neztratit naše priority. Tým Mail.ru Cloud Solutions, se kterým jsme začali pracovat a spolupracujeme dodnes, nám poskytl plně automatizovanou službu s podporou API a uživatelsky přívětivým ovládacím panelem, ve kterém je Horizon — díky tomu jsme mohli rychle spustit libovolný počet nodů.
Jak se nám podařilo migrovat do MCS za dvě hodiny
Při takových přestupech se mnoho společností setkává s obtížemi a neúspěchy, ale v našem případě tomu tak nebylo. Měli jsme štěstí: protože jsme před migrací již pracovali na Kubernetes, jednoduše jsme upravili tři soubory a spustili naše služby na nové cloudové platformě, v MCS. Připomínám, že do té doby jsme zcela přešli z bare metal na Google Cloud Platform. Takže samotný přechod trval maximálně dvě hodiny, plus ještě nějaký čas (asi hodinu) bylo potřeba na zkopírování dat z našich zařízení. Tehdy jsme již používali Spinnaker (multi-cloud CD službu pro zajištění Continous Delivery). Tu jsme také rychle přidali do nového clusteru a pokračovali v běžném režimu.
Díky automatizaci procesů vývoje a CI/CD se o Kubernetes v 'URUS' stará jeden specialista (a to jsem já). V určitém okamžiku se mnou pracoval další systémový administrátor, ale poté se ukázalo, že většinu rutiny jsme již automatizovali a na straně našeho hlavního produktu úkolů přibývá, což má smysl směrovat zdroje na to.
Od cloudového poskytovatele jsme dostali to, co jsme očekávali, protože jsme zahájili spolupráci bez iluzí. Pokud byly nějaké incidenty, většinou to byly technické problémy, které lze snadno vysvětlit relativní novostí služby. Hlavní je, že tým MCS rychle odstraňuje nedostatky a rychle reaguje na otázky v messengerách.
Pokud srovnáme zkušenosti s Google Cloud Platform, v jejich případě jsem ani nevěděl, kde se nachází tlačítko pro zpětnou vazbu, protože to prostě nebylo potřeba. A pokud k nějakým problémům došlo, Google sám rozeslal jednostranná upozornění. Ale v případě MCS považuji za velkou výhodu, že jsou maximálně blízko ruským klientům – jak teritoriálně, tak mentálně.
Jak vidíme práci s cloudovým prostředím v budoucnu
V současnosti je naše práce úzce spojená s Kubernetes a plně vyhovuje našim infrastrukturním potřebám. Proto nemáme v plánu z něj migrovat, i když neustále zavádíme nové praktiky a služby pro zjednodušení rutinních úkolů a automatizaci nových, zvýšení stability a spolehlivosti služeb… Aktuálně spouštíme službu Chaos Monkey (konkrétně používáme chaoskube, ale koncept se nemění :), která byla původně vytvořena v Netflixu. Chaos Monkey dělá jednu jednoduchou věc: v libovolném čase odstraní libovolný pod v Kubernetes. To je potřebné, aby naše služba fungovala správně s počtem instancí n–1, tím se učíme být připraveni na jakékoliv problémy.
Dnes považuji použití externích řešení – těchto cloudových platforem – za jediné správné pro mladé společnosti. Obvykle jsou na začátku omezeni jak v dostupných kapacitách, tak ve financích, a budovat a udržovat vlastní cloud nebo datové centrum je příliš nákladné a pracné. Cloudoví poskytovatelé umožňují minimalizovat tyto náklady, rychle zajistit prostředky potřebné pro fungování služeb tady a teď, s tím, že za tyto prostředky platíte podle skutečné potřeby. Co se týče společnosti „URUS“, zatím zůstaneme věrní Kubernetes v cloudu. Ale kdo ví, možná budeme muset expandovat geograficky, nebo zavádět řešení na specifickém vybavení. A možná množství potřebných prostředků ospravedlní vlastní Kubernetes na bare-metal, jako v dobrých starých časech. 🙂
Co jsme se naučili z práce s cloudovými službami
Začali jsme používat Kubernetes na bare metal, a i tam byl svým způsobem dobrý. Jeho silné stránky se však projevily zejména jako komponenty aaS v cloudu. Pokud si stanovíte cíl a vše maximálně automatizujete, můžete se vyhnout vendor lock-in a přesun mezi cloudovými poskytovateli zabere jen pár hodin, a nervové buňky zůstanou s námi. Jiným společnostem můžeme doporučit: chcete spustit svůj (cloudový) servis s omezenými zdroji a maximální rychlostí vývoje — začněte hned teď s pronájmem cloudových zdrojů a svůj datové centrum budujte až poté, co o vás napíše Forbes.
Zdroj: habr.com
