Na konci května uspořádala online schůzku na toto téma . Mluvili jsme o kontejnerech, Kubernetes a orchestraci v principu, kritériích pro výběr infrastruktury a mnohem více. Účastníci sdíleli případy z vlastní praxe.
Účastníci:
- Evgeniy Potapov, generální ředitel společnosti ITSumma. Více než polovina jejích zákazníků se buď již stěhuje, nebo chtějí přejít na Kubernetes.
- Dmitrij Stolyarov, technický ředitel "Flant". Má více než 10 let zkušeností s prací s kontejnerovými systémy.
- Denis Remchukov (aka Eric Oldmann), COO argotech.io, bývalý RAO UES. Slíbil, že promluví o případech v „krvavém“ podniku.
- Andrey Fedorovsky, technický ředitel „News360.com“Poté, co koupil společnost jiným hráčem, je zodpovědný za řadu ML a AI projektů a infrastruktury.
- Ivan Kruglov, systémový inženýr, ex-Booking.com.Stejný člověk, který s Kubernetesem udělal hodně vlastníma rukama.
Témata:
- Názory účastníků na kontejnery a orchestraci (Docker, Kubernetes atd.); co bylo vyzkoušeno v praxi nebo analyzováno.
- Případ: Společnost již roky buduje plán rozvoje infrastruktury. Jak se rozhoduje, zda vybudovat (nebo migrovat současnou) infrastrukturu na kontejnery a Kuber, nebo ne?
- Problémy v cloudovém nativním světě, co chybí, představme si, co bude zítra.
Rozvinula se zajímavá diskuse, názory účastníků byly natolik odlišné a vyvolaly tolik komentářů, že se o ně chci s vámi podělit. Jíst a níže je shrnutí diskuse.
Je Kubernetes už standardní nebo skvělý marketing?
"Přišli jsme na to (Kubernetes. - Ed.), když o tom ještě nikdo nevěděl. Přišli jsme za ním, i když tam nebyl. Chtěli jsme to předtím" - Dmitrij Stolyarov
Fotografie z Reddit.com
Před 5-10 lety existovalo obrovské množství nástrojů a neexistoval jediný standard. Každých šest měsíců se objevil nový produkt, nebo dokonce více než jeden. Nejprve Vagrant, pak Salt, Chef, Puppet,... „a každých šest měsíců obnovujete svou infrastrukturu. Máte pět administrátorů, kteří jsou neustále zaneprázdněni přepisováním konfigurací,“ vzpomíná Andrey Fedorovsky. Věří, že Docker a Kubernetes zbytek „vytěsnili“. Docker se stal standardem v posledních pěti letech, Kubernetes v posledních dvou letech. A to je pro průmysl dobré..
Dmitrij Stolyarov a jeho tým Kubera milují. Chtěli takový nástroj, než se objevil, a přišli k němu, když o něm nikdo nevěděl. V současné době z důvodu pohodlí neberou klienta, pokud chápou, že s ním nebudou implementovat Kubernetes. Zároveň má společnost podle Dmitryho „mnoho obrovských úspěšných příběhů o předělání hrozného dědictví“.
Kubernetes není pouze orchestrace kontejnerů, je to systém pro správu konfigurace s vyvinutým API, síťovou komponentou, vyvažováním L3 a řadiči Ingress, což umožňuje relativně snadno spravovat zdroje, škálovat a abstrahovat od nižších vrstev infrastruktury.
Bohužel v našem životě musíme za všechno platit. A tato daň je velká, zvláště pokud mluvíme o přechodu na Kubernetes společnosti s rozvinutou infrastrukturou, jak se domnívá Ivan Kruglov. Mohl volně pracovat jak ve firmě s tradiční infrastrukturou, tak s Kuberem. Hlavní věcí je pochopit vlastnosti společnosti a trhu. Ale například pro Evgeny Potapov, který by zobecnil Kubernetes na jakýkoli nástroj pro orchestraci kontejnerů, taková otázka nevyvstává.
Evgeniy nakreslil analogii se situací v 1990. letech, kdy se objektově orientované programování objevilo jako způsob programování složitých aplikací. V té době debata pokračovala a objevily se nové nástroje na podporu OOP. Poté se mikroslužby objevily jako způsob, jak se vzdálit od monolitického konceptu. To následně vedlo ke vzniku kontejnerů a nástrojů pro správu kontejnerů. „Myslím, že brzy přijdeme do doby, kdy nebude pochyb o tom, zda má cenu psát malou mikroslužbu, standardně se bude psát jako mikroslužba,“ věří. Stejně tak se Docker a Kubernetes časem stanou standardním řešením bez nutnosti volby.
Problém databází v bezstavovém stavu
Foto
V dnešní době existuje mnoho receptů na provozování databází v Kubernetes. Dokonce i to, jak oddělit část, která pracuje s I/O diskem, od aplikační části databáze. Je možné, že se v budoucnu databáze změní natolik, že budou dodávány v krabici, kde jedna část bude organizována přes Docker a Kubernetes a v jiné části infrastruktury bude prostřednictvím samostatného softwaru poskytnuta úložná část? ? Změní se báze jako produkt?
Tento popis je podobný správě front, ale požadavky na spolehlivost a synchronizaci informací v tradičních databázích jsou mnohem vyšší, domnívá se Andrey. Poměr přístupů do mezipaměti v normálních databázích zůstává na 99 %. Pokud dojde k výpadku pracovníka, spustí se nový a mezipaměť se „zahřeje“ od nuly. Dokud se mezipaměť nezahřeje, pracovník pracuje pomalu, což znamená, že jej nelze načíst uživatelskou zátěží. I když nedochází k žádnému zatížení uživatele, mezipaměť se nezahřívá. Je to začarovaný kruh.
Dmitrij zásadně nesouhlasí – problém řeší kvora a sharding. Andrey ale trvá na tom, že řešení není vhodné pro každého. V některých situacích je kvorum vhodné, ale zvyšuje zatížení sítě. NoSQL databáze není vhodná ve všech případech.
Účastníci setkání byli rozděleni do dvou táborů.
Denis a Andrey tvrdí, že vše, co je zapsáno na disk – databáze a tak dále – je v současném ekosystému Kuber nemožné. Je nemožné zachovat integritu a konzistenci produkčních dat v Kubernetes. To je základní vlastnost. Řešení: hybridní infrastruktura.
Dokonce i moderní cloudové nativní databáze jako MongoDB a Cassandra nebo fronty zpráv jako Kafka nebo RabbitMQ vyžadují trvalá úložiště dat mimo Kubernetes.
Jevgenij namítá: „Základny v Kubeře jsou téměř ruské nebo téměř podnikové zranění, které souvisí se skutečností, že v Rusku neexistuje žádná adopce cloudu. Malé nebo střední firmy na Západě jsou Cloud. Databáze Amazon RDS se používají snadněji, než si sami pohrávat s Kubernetes. V Rusku používají Kuber „on-premise“ a přenášejí do něj základny, když se snaží zbavit zoo.
Dmitry také nesouhlasil s tvrzením, že v Kubernetes nelze vést žádné databáze: „Základ se liší od základny. A pokud budete tlačit obří relační databázi, pak za žádných okolností. Pokud podstrčíte něco malého a cloudového nativního, co je mentálně připraveno na semi-efemérní život, všechno bude v pořádku.“ Dmitry také zmínil, že nástroje pro správu databází nejsou připraveny ani pro Docker, ani pro Kuber, takže vznikají velké potíže.
Ivan si je zase jistý, že i když abstrahujeme od pojmů stavové a bezstavové, ekosystém podnikových řešení v Kubernetes ještě není připraven. S Kuberem je obtížné dodržet legislativní a regulační požadavky. Je například nemožné vytvořit řešení pro poskytování identity tam, kde jsou vyžadovány přísné záruky identifikace serveru, a to až po hardware, který je do serverů vložen. Tato oblast se rozvíjí, ale řešení zatím neexistuje.
Účastníci se nedokázali shodnout, takže v této části nebudou činěny žádné závěry. Uveďme si pár praktických příkladů.
Případ 1. Kybernetická bezpečnost „megaregulátoru“ se základnami mimo Kubera
V případě vyvinutého systému kybernetické bezpečnosti umožňuje použití kontejnerů a orchestrace čelit útokům a průnikům. Například v jednom megaregulátoru Denis a jeho tým implementovali kombinaci orchestrátoru s vyškolenou službou SIEM, která analyzuje protokoly v reálném čase a určuje proces útoku, hackování nebo selhání. V případě útoku, pokusu něco umístit nebo v případě invaze viru ransomware to prostřednictvím orchestrátoru sebere kontejnery s aplikacemi rychleji, než se nakazí, nebo rychleji, než na ně útočník zaútočí.
Případ 2. Částečná migrace databází Booking.com do Kubernetes
V Booking.com je hlavní databází MySQL s asynchronní replikací – je zde master a celá hierarchie otroků. V době, kdy Ivan ze společnosti odešel, byl spuštěn projekt přesunu otroků, kteří by mohli být „zastřeleni“ s určitým poškozením.
Kromě hlavní základny je zde instalace Cassandra se samopsanou orchestrací, která byla napsána ještě předtím, než Kuber vstoupil do hlavního proudu. V tomto ohledu nejsou žádné problémy, ale na místních SSD je trvalý. Vzdálené úložiště, a to ani v rámci stejného datového centra, se nepoužívá kvůli problému s vysokou latencí.
Třetí třídou databází je vyhledávací služba Booking.com, kde každý uzel služby je databází. Pokusy o přenos vyhledávací služby do Kuberu selhaly, protože každý uzel má 60–80 GB místního úložiště, které je obtížné „zvednout“ a „zahřát“.
Výsledkem bylo, že vyhledávač nebyl převeden na Kubernetes a Ivan si nemyslí, že v blízké budoucnosti budou nové pokusy. Databáze MySQL byla převedena napůl: pouze Slave, kteří se nebojí být „zastřeleni“. Cassandra se dokonale zabydlela.
Výběr infrastruktury jako úkol bez obecného řešení
Foto
Řekněme, že máme novou společnost, nebo společnost, kde je část infrastruktury vybudována starým způsobem. Buduje plán rozvoje infrastruktury na roky. Jak se rozhoduje, zda postavit infrastrukturu na kontejnerech a Kuberu, nebo ne?
Společnosti, které bojují o nanosekundy, jsou z diskuse vyloučeny. Zdravý konzervatismus se vyplácí z hlediska spolehlivosti, ale stále existují společnosti, které by měly zvážit nové přístupy.
Ivan: „Určitě bych teď založil společnost na cloudu, jednoduše proto, že je to rychlejší“, i když ne nutně levnější. S rozvojem rizikového kapitalismu nemají startupy velké problémy s penězi a hlavním úkolem je dobýt trh.
Ivan je toho názoru výběrovým kritériem je rozvoj stávající infrastruktury. Pokud v minulosti došlo k vážné investici a funguje to, pak nemá smysl ji předělávat. Pokud infrastruktura není rozvinutá a existují problémy s nástroji, zabezpečením a monitorováním, pak má smysl poohlédnout se po distribuované infrastruktuře.
Daň bude muset být v každém případě zaplacena a Ivan by platil tu, která mu umožnila v budoucnu platit méně. "Protože prostě díky tomu, že jedu vlakem, kterým jedou ostatní, dojedu mnohem dál, než když sednu do jiného vlaku, do kterého musím sám natankovat.“ říká Ivan. Když je společnost nová a požadavky na latenci jsou desítky milisekund, Ivan se poohlédne po „operátorech“, do kterých jsou dnes „zabaleny“ klasické databáze. Vyvolávají replikační řetězec, který se sám přepne v případě selhání atd...
Pro malou společnost s několika servery Kubera nedává smysl,“ říká Andrey. Ale pokud plánuje růst na stovky serverů nebo více, pak potřebuje automatizaci a systém správy zdrojů. 90 % případů stojí za to. Navíc bez ohledu na úroveň zatížení a zdrojů. Pro každého, od startupů až po velké společnosti s milionovým publikem, dává smysl postupně se poohlédnout po produktech pro orchestraci kontejnerů. "Ano, tohle je opravdu budoucnost," je si jistý Andrey.
Denis nastínil dvě hlavní kritéria - škálovatelnost a stabilita provozu. Vybere nástroje, které se pro daný úkol nejlépe hodí. „Mohl by to být noname sestavený na kolenou a je na něm Nutanix Community Edition. Může to být druhý řádek ve formě aplikace na Kuberu s databází na backendu, která je replikována a má specifikované parametry RTO a RPO“ (cíle doby/bodu obnovy – cca).
Evgeniy identifikoval možný problém s personálem. V současné době není na trhu mnoho vysoce kvalifikovaných odborníků, kteří rozumí „vnitřnostem“. Pokud je totiž zvolená technologie stará, pak je těžké najmout někoho jiného než lidi středního věku, kteří jsou znudění a unavení životem. I když ostatní účastníci se domnívají, že jde o školení personálu.
Pokud si položíme otázku volby: spustit malou společnost ve veřejném cloudu s databázemi v Amazon RDS nebo „on premise“ s databázemi v Kubernetes, pak se přes některé nedostatky stal Amazon RDS volbou účastníků.
Protože většina posluchačů setkání není z „krvavého“ podniku distribuovaná řešení jsou to, o co bychom měli usilovat. Systémy pro ukládání dat musí být distribuované, spolehlivé a musí vytvářet latenci měřenou v jednotkách milisekund, maximálně desítkách“ shrnul Andrey.
Hodnocení využití Kubernetes
Posluchač Anton Zhbankov položil apologetům Kubernetes trapnou otázku: jak jste vybrali a provedli studii proveditelnosti? Proč Kubernetes, proč ne například virtuální stroje?
Foto
Dmitrij a Ivan na to odpověděli. V obou případech byla pomocí pokusů a omylů učiněna sekvence rozhodnutí, v jejichž důsledku oba účastníci dorazili do Kubernetes. Nyní podniky začínají samostatně vyvíjet software, který má smysl převést na Kuber. Nemluvíme o klasických systémech třetích stran, jako je 1C. Kubernetes pomáhá, když vývojáři potřebují rychle vydávat vydání, s nepřetržitým neustálým zlepšováním.
Andreyho tým se pokusil vytvořit škálovatelný cluster založený na virtuálních strojích. Uzly padaly jako domino, což někdy vedlo ke zhroucení shluku. „Teoreticky to můžete dokončit a podepřít rukama, ale je to zdlouhavé. A pokud je na trhu řešení, které vám umožní pracovat jako z krabice, pak do toho rádi jdeme. A ve výsledku jsme přešli,“ říká Andrey.
Existují standardy pro takové analýzy a výpočty, ale nikdo nemůže říci, jak přesné jsou na skutečném hardwaru v provozu. Pro výpočty je také důležité porozumět každému nástroji a ekosystému, ale to není možné.
Co nás čeká
Foto
Jak se technologie vyvíjí, objevují se další a další nesourodé kusy a pak dojde k fázovému přechodu, objeví se prodejce, který zabil dost těsta, aby se vše spojilo v jediném nástroji.
Myslíte si, že přijde čas, kdy bude existovat nástroj jako Ubuntu pro svět Linuxu? Možná jediný nástroj pro kontejnerizaci a orchestraci bude zahrnovat Kuber. Usnadní to vytváření cloudů na místě.
Ivan odpověděl: „Google nyní buduje Anthos – toto je jejich zabalená nabídka, která nasazuje cloud a zahrnuje Kuber, Service Mesh, monitorování – veškerý hardware, který je potřeba pro místní mikroslužby.“ Jsme téměř v budoucnosti."
Denis také zmínil Nutanix a VMWare s produktem vRealize Suite, který si s podobným úkolem poradí i bez kontejnerizace.
Dmitrij sdílel svůj názor, že snížení „bolesti“ a snížení daní jsou dvě oblasti, kde můžeme očekávat zlepšení.
Abychom shrnuli diskusi, zdůrazňujeme následující problémy moderní infrastruktury:
- Tři účastníci okamžitě identifikovali problém se stavem.
- Různé problémy s podporou zabezpečení, včetně možnosti, že Docker skončí s více verzemi Pythonu, aplikačních serverů a komponent.
Překročení výdajů, které je lepší projednat na samostatné schůzce.
Výzva k učení, protože orchestrace je složitý ekosystém.
Častým problémem v oboru je zneužívání nástrojů.Zbytek závěrů je na vás. Stále přetrvává pocit, že pro kombinaci Docker+Kubernetes není snadné stát se „centrální“ součástí systému. Například operační systémy se nejprve instalují na hardware, což se nedá říci o kontejnerech a orchestraci. Možná se v budoucnu operační systémy a kontejnery spojí se softwarem pro správu cloudu.
FotoRáda bych využila této příležitosti a pozdravila maminku a připomněla, že máme facebookovou skupinu , kanál se zajímavými publikacemi z různých technických blogů. A můj kanál , kde mluvím o řízení vývoje v produktových společnostech.
Zdroj: www.habr.com