Na konci května se uskutečnil online meetup na téma . Hovořili jsme o kontejnerech, Kubernetes a orchestraci obecně, o kritériích pro výběr infrastruktury a mnohém dalším. Účastníci sdíleli případy z vlastní praxe.
Účastníci:
- Evgenij Potapov, CEO „ITSumma“. Více než polovina jeho klientů již přechází nebo má zájem přejít na Kubernetes.
- Dmitrij Stoljarov, CTO „Flant“. Má více než 10 let zkušeností s kontejnerovými systémy.
- Denis Remčukov (aka Eric Oldmann), COO argotech.io, ex-RAO EES. Slíbil, že poví o případech v „krvavém“ enterprise.
- Andrej Fedorovskij, CTO „News360.com“Po koupi společnosti jiným hráčem odpovídá za řadu projektů ML a AI a za infrastrukturu.
- Ivan Kruglov, systémový inženýr, ex–Booking.com.Ten člověk, který svou vlastní prací dokázal s Kubernetes opravdu hodně.
Témata:
- Postřehy účastníků o kontejnerech a orchestraci (Docker, Kubernetes a další); co vyzkoušeli v praxi nebo analyzovali.
- Případ: Ve společnosti vytvářejí plán rozvoje infrastruktury na léta. Jak se rozhoduje, zda vybudovat (nebo převést stávající) infrastrukturu na kontejnerech a Kubernetes, či nikoliv?
- Problémy ve světě cloud-native, co nám chybí, pojďme fantazírovat, co bude zítra.
Rozvinula se zajímavá diskuse, názory účastníků se ukázaly být natolik rozdílné a vyvolaly tolik komentářů, že je chce sdílet s vámi. Existuje , a níže je shrnutí diskuse.
Je Kubernetes již standard nebo skvělý marketing?
„K němu (Kubernetes — pozn. red.) jsme přišli tehdy, když o něm ještě nikdo nevěděl. Přišli jsme k němu ještě tehdy, když ani neexistoval. Chtěli jsme ho ještě předtím“ — Dmitrij Stoljarov
Foto z Reddit.com
Před 5–10 lety existoval obrovský počet nástrojů a neexistoval jednotný standard. Každých šest měsíců se objevoval nový produkt, a to i více než jeden. Nejprve Vagrant, pak Salt, Chef, Puppet,… „a ty každých šest měsíců přestavuješ svou infrastrukturu. Máš pět administrátorů, kteří jsou neustále zaneprázdněni přepisováním konfigurací“ — vzpomíná Andrej Fedorovskij. Domnívá se, že Docker a Kubernetes „převzaly moc“ nad ostatními. Docker se stal standardem v posledních pěti letech, Kubernetes — v posledních dvou. A to je dobré pro odvětví..
Dmitrij Stoljaro v jeho tým mají rádi Kubernetes. Chtěli takový nástroj, než se objevil, a dostali se k němu, když se o něm ještě nikdo nevěděl. V současné době, z praktických důvodů, neberou klienta, pokud si pomyslí, že mu neimplementují Kubernetes. Přitom, podle Dmitrije, má firma „mnoho obrovských úspěšných příběhů transformace strašného legacy“.
Kubernetes není pouze orchestrací kontejnerů, je to systém pro správu konfigurace s vyvinutým API, komponentem pro práci se sítí, L3 vyvažováním zátěže a Ingress kontroléry, který umožňuje relativně snadno spravovat zdroje, škálovat a abstrahovat od dolních vrstev infrastruktury.
Bohužel, v našem životě za všechno musíme platit. A tato daň je vysoká, zejména pokud mluvíme o přechodu na Kubernetes ve společnosti s rozvinutou infrastrukturou, jak si myslí Ivan Kruglova. Mohl by svobodně pracovat jak ve společnosti s tradiční infrastrukturou, tak s Kubernetes. Důležité je rozumět zvláštnostem firmy a trhu. Ale například pro Jevgenije Potapova, který by shrnul Kubernetes na jakýkoliv nástroj pro orchestraci kontejnerů, taková otázka nestojí.
Jevgenij udělal analogii se situací v 90. letech, kdy se objevilo objektově orientované programování jako způsob programování složitých aplikací. V té době pokračovaly debaty a objevovaly se nové nástroje podporující OOP. Poté se objevily mikroservisy jako způsob, jak se vyhnout monolitnímu konceptu. To zase vedlo k vzniku kontejnerů a nástrojů pro jejich správu. „Myslím, že brzy přijdeme k okamžiku, kdy nebude otázka, zda psát mikroservisně malou aplikaci, ale bude se to psát jako mikroservis automaticky,“ říká. Podobně se Docker a Kubernetes časem stanou standardním řešením bez nutnosti volby.
Problém databází v stateless.
Foto od
V naší době existuje mnoho receptů na spuštění databází v Kubernetes. Dokonce jak oddělit část pracující s disky I/O od, dejme tomu, aplikační části databáze. Je možné, že v budoucnu databáze změní tak, že budou dodávány v krabici, kde jedna část bude orchestráží prostřednictvím Dockeru a Kubernetes a v jiné části infrastruktury, prostřednictvím samostatného softwaru, bude poskytována část úložného prostoru? Změní se databáze jako produkt?
Tento popis se podobá řízení front, ale požadavky na spolehlivost a synchronizaci informací v tradičních databázích jsou mnohem vyšší, domnívá se Andrej. Poměr hitů v cache v normálních databázích se udržuje na úrovni 99 %. Pokud pracovník spadne, spustí se nový a cache se 'ohřívá' od nuly. Dokud cache není ohřátá, pracovník pracuje pomalu, což znamená, že na něj nelze nasadit uživatelskou zátěž. Dokud není žádná uživatelská zátěž, cache se neohřívá. To je uzavřený cyklus.
Dmitrij zásadně nesouhlasí, — kvóra a shardování tento problém řeší. Ale Andrej trvá na tom, že řešení nevyhovuje všem. V některých situacích může vyhovovat kvórum, ale klade to dodatečnou zátěž na síť. Databáze NoSQL neodpovídá všem případům.
Účastníci meetupu se rozdělili na dva tábory.
Denis a Andrej tvrdí, že vše, co se zapisuje na disk — databáze a další — v současné ekosystému Kuberu není možné realizovat. Není možné zachovat integritu a konzistenci produktivních dat v Kubernetes. To je fundamentální vlastnost. Řešení: hybridní infrastruktura.
I moderní cloud native databáze, jako MongoDB a Cassandra, nebo fronty zpráv, jako Kafka nebo RabbitMQ, vyžadují trvalá úložiště dat mimo Kubernetes.
Evgenij oponuje: „Databáze v Kuberu — to je trauma okolo ruské kultury, nebo téměř podnikové, která souvisí s tím, že v Rusku není cloudová adopce.“ Malé nebo střední společnosti na Západě — to je cloud. Databáze Amazon RDS je snazší použít, než se s Kubernetes zabývat samostatně. V Rusku používají Kuber 'on-premise' a přesouvají do něj databáze, když se snaží zbavit se zoo.
Dmitrij také nesouhlasil s tvrzením, že žádné databáze nelze držet v Kubernetes: „Databáze jsou různé. A pokud zanášet obrovskou relační databázi — tak rozhodně ne. Pokud zasunout něco malého a cloud native, co je morálně připraveno na poluefemérní život, všechno bude v pořádku.“ Dmitrij také zmínil, že nástroje pro správu databází nejsou připraveny ani na Docker, ani na Kuber, a proto vznikají velké potíže.
Ivan je naopak přesvědčen, že i když se abstrahujeme od pojmů stateful a stateless, ekosystém podnikových řešení v Kubernetes ještě není připraven. S Kuberem je obtížné dodržovat požadavky zákonodárných a regulačních orgánů. Například není možné vytvořit řešení pro poskytování identity, kde jsou vyžadovány přísné záruky identifikace serveru, až po hardwarové komponenty, které jsou vloženy do serverů. Tato oblast se vyvíjí, ale zatím není žádné řešení.
Účastníkům se nepodařilo dohodnout, takže v této části závěrů nebude. Raději uvedeme pár praktických příkladů.
Případ 1. Kybernetická bezpečnost „megaregulatora“ s databázemi mimo Kuber
V případě rozvinutého systému kybernetické bezpečnosti umožňuje používání kontejnerů a orchestrace odolávat útokům a vniknutí. Například v jednom megaregulatorovi Denis a jeho tým implementovali spojení orchestrace s vycvičeným SIEM servisem, který analyzuje protokoly v reálném čase a určuje průběh útoku, prolomení nebo selhání. V případě útoku, pokusu něco nahrát, nebo při vniknutí ransomwaru, orchestruje rychlejší nasazení kontejnerů s aplikacemi, než se stihnou infikovat, nebo než je napadnou útočníci.
Případ 2. Částečný přesun databází Booking.com do Kubernetes
V Booking.com je hlavní databází MySQL s asynchronní replikací — existuje master a celá hierarchie slaveů. V době, kdy Ivan opouštěl společnost, byl spuštěn projekt na přesun slaveů, které lze "odstřelit" s určitými ztrátami.
Kromě hlavní databáze existuje instalace Cassandry s vlastním orchestrátorem, který byl napsán ještě před tím, než se Kuber dostal do mainstreamu. V tomto ohledu nejsou žádné problémy, ale má persistentní na lokální SSD. Vzdálená úložiště, i v rámci jednoho datového centra, nejsou používána kvůli problémům s vysokou latencí.
Třetí třída databází je vyhledávací služba Booking.com, kde každá node služby je databází. Pokusy přesunout vyhledávací službu do Kubera se nezdařily, protože každá node má 60—80 GB lokálního úložiště, které je obtížné "zvednout" a "zahřát".
Nakonec nebyl vyhledávací engine v Kubernetes převeden, a Ivan nemyslí, že by v blízké době byly nové pokusy. Databáze MySQL byla přesunuta z poloviny: pouze slave, které není strašné "odstřelit". Cassandra "se uchytila" výborně.
Výběr infrastruktury jako úkol bez obecného řešení
Foto od
Předpokládejme, že máme novou společnost, nebo společnost, jejíž část infrastruktury byla postavena starým způsobem. V ní se vypracovává plán rozvoje infrastruktury na roky. Jak se rozhoduje, zda budovat infrastrukturu na kontejnerech a Kubernetes, nebo ne?
Společnosti, které bojují o nanosekundy, jsou z diskuse vyřazeny. Zdravý konzervatismus se vyplácí z hlediska spolehlivosti, ale stále jsou tu společnosti, které by měly zvážit nové přístupy.
Ivan: „Teď bych rozhodně založil společnost v cloudu, prostě proto, že je to rychlejší,“ i když to nemusí být levnější. S rozvojem rizikového kapitálu mají startupy s penězi velké problémy a hlavním úkolem je získat trh.
Ivan se domnívá, že rozvinutost aktuální infrastruktury je kritériem výběru. Pokud byly v minulosti provedeny vážné investice a vše funguje, nemá smysl to předělávat. Pokud však infrastruktura není rozvinutá a existují problémy s nástroji, bezpečností a monitoringem, má smysl podívat se na distribuovanou infrastrukturu.
Daň se bude platit v každém případě, a Ivan by platil tu, která by mu umožnila v budoucnu platit méně. „Protože jen tím, že jedu ve vlaku, který pohánějí jiní, dojedu mnohem dál, než kdybych sedl do jiného vlaku, do kterého bych musel sám dávat palivo.“ — říká Ivan. Když je společnost nová a požadavky na latenci jsou desítky milisekund, Ivan by se díval směrem k „operátorům“, do kterých se dnes „zabalují“ klasické databáze. Vytvářejí replikaci, která se sama přepíná v případě selhání apod.
Pro malou společnost s několika servery v Kubernetes to nedává smysl, — tvrdí Andrej. Ale pokud plánuje narůst na stovku serverů a více, potřebuje automatizaci a systém správy zdrojů. 90 % případů ospravedlňuje náklady. Přičemž nezávisle na úrovni zátěže a zdrojích. Všem, od startupů až po velké společnosti s milionovým publikem, má smysl postupně se dívat směrem k produktům pro orchestraci kontejnerů. „Ano, to je opravdu budoucnost,“ je přesvědčen Andrej.
Denis vymezil dvě hlavní kritéria — škálovatelnost a spolehlivost provozu. Vybere nástroje, které nejlépe vyhovují této úloze. „Může to být no-name zařízení s Nutanix Community Edition, nebo druhá linie jako aplikace na Kuber s databází na backendu, která se replikovala a má stanovené parametry RTO a RPO“ (cíle času obnovy / bodu obnovy — příklad).
Evgenij poukázal na možný problém s pracovními silami. V současné době není na trhu mnoho vysoce kvalifikovaných specialistů, kteří rozumějí „vnitřnostem“. Opravu, pokud je zvolená technologie zastaralá, je obtížné najít někoho jiného než starší unavené lidi, kteří se nudí životem. Jiní však tvrdí, že to je otázka vzdělávání pracovníků.
Pokud se jedná o výběr: spustit malou firmu v Public Cloudu s databázemi v Amazon RDS nebo „on premise“ s databázemi v Kubernetes, účastníci se rozhodli pro Amazon RDS, i přes některé nevýhody.
Protože většina posluchačů meetupu není z ‚krvavého‘ enterprise sektoru, distribuované řešení je to, co bychom měli usilovat. Systémy ukládání dat by měly být distribuované, spolehlivé a dosahovat latency měřených v jednotkách milisekund, maximálně desítkách., – shrnul Andrey.
Hodnocení použití Kubernetes
Posluchač Anton Zhbankov položil otázku-omyl obhájcům Kubernetes: jak se vybíralo a provedlo technicko-ekonomické zdůvodnění? Proč Kubernetes, proč ne virtuální stroje, například?
Foto od
Dmitrij a Ivan na to odpověděli. V obou případech metodou pokusů a omylů byla vyvinuta posloupnost řešení, díky nimž oba účastníci přešli na Kubernetes. Nyní podniky začínají vyvíjet software, který má smysl přenést do Kuber. Nejde o klasické externí systémy, jako je 1C. Kubernetes pomáhá, když vývojáři potřebují rychle provádět vydání, při nepřetržitém Continuous Improvement.
Andreyho tým se pokoušel vytvořit škálovatelný klastr na základě virtuálních strojů. Uzly padaly jako domino, což občas vedlo k pádu clustera. „Teoreticky lze to dokončit a udržovat ručně, ale je to únavné. A pokud na trhu existuje řešení, které umožňuje fungovat z krabice, rádi se k němu dostaneme. A proto jsme nakonec přešli,“ popisuje Andrey.
Standardy pro tento typ analýzy a výpočtů existují, ale nikdo neví, jak jsou správné na reálném hardwaru během provozu. Je také důležité porozumět každému nástroji a ekosystému, ale to je nemožné.
Co nás čeká
Foto od
Jakmile technologie pokročily, objevuje se stále více roztržených částí, a poté dojde k fázovému přechodu, objeví se dodavatel, který utratil dostatečné množství peněz, aby vše spojil do jednoho nástroje.
Nemyslíte si, že přijde okamžik, kdy se objeví nástroj, jakým se stala Ubuntu pro svět Linuxu? Možná, že jednotný nástroj pro kontejnerizaci a orchestraci zahrne také Kubernetes. S ním bude snadné vytvářet on-premise cloud.
Odpověděl Ivan: „Google nyní buduje Anthos - to je jejich balíčková nabídka, která nasazuje cloud a zahrnuje Kubernetes, Service Mesh, monitoring - veškeré vazby potřebné pro mikroslužby v 'on-premise'. Jsme téměř v budoucnosti.“
Denis také zmínil Nutanix a VMWare s produktem vRealize Suite, které mohou splnit podobný úkol bez kontejnerizace.
Dmitrij sdílel názor, že snížení 'bolesti' a snížení daně jsou dvě oblasti, kde lze očekávat zlepšení.
Shrneme diskusi a vybereme následující problémy současné infrastruktury
- Tři účastníci označili problém se stateful.
- Různé problémy s podporou zabezpečení, včetně pravděpodobnosti, že v Dockeru skončí několik verzí Pythonu, aplikačních serverů a komponent.
Nadměrné výdaje, o kterých je lepší udělat samostatný meetup.
Problém školení, protože orchestrace představuje složitý ekosystém.
Celkový problém odvětví - používání nástrojů k jinému účelu.Ostatní závěry jste si udělejte sami. Zatím stále panuje pocit, že spojení Docker+Kubernetes se jen těžko stane 'centrální' součástí systému. Například operační systémy se instalují na hardware jako první, což nelze říci o kontejnerech a orchestraci. Možná v budoucnu dojde k integraci operačních systémů a kontejnerů s cloud management softwarem.
Foto odDovolte mi, abych tímto pozdravil maminku a připomněl, že máme facebookovou skupinu , kanál s zajímavými příspěvky z různých technoblogů. A můj kanál , kde vyprávím o řízení vývoje ve produktových firmách.
Zdroj: habr.com
