CRA Cloud: Kontejnerizace a její soužití s tradiční virtualizací

00:00:23
Dobrý den. Moje jméno je Marek Arneker a pracuji v Českých radiokomunikacích jako produktový manažer cloudových služeb. Na dnešním webináři vás tady vítám a to, co bude dneska naším tématem, je v podstatě život kontejnerizace v rámci infrastruktury. Dneska se podíváme na to, srovnat virtualizaci klasickou, takovou, kterou znáte, s kontejnerama. Podíváme se na univerzálnost virtualizace a to, co nám kontejnery nejvíc přináší, Systém, který se jmenuje VMWare Tanzu, který nabízí právě to, že implementuje kontejnery mezi klasickou virtualizaci a dá se využívat, dejme tomu spolupráce zdrojů, o tomhle se budeme povídat a ukážeme si i krátký video. Podíváme se na plánování takového novýho kalastru, na jeho komponenty a na závěr se mrkneme na to, kam s jakým workloadem, k čemu je která z těch infrastruktur vlastně vhodnější. Pokud byste v průběhu webináře měli jakýkoliv dotazy, neváhejte se ptát, budeme mít i část vyhrazenou vyloženě na otázky. Můžete otázky pokládat do chatu hned vedle videa. Takže určitě, určitě neváhejte, budeme za jakoukoliv otázku rádi. Pokud bychom náhodou otázky nestíhli probrat, pošleme je následně offline, takže neváhejte se zeptat na cokoliv, co vás v této souvislosti napadne. A já se hned pustím do prvního slajdu. Diagram, který tady podná své Pravé straně mám, na vaší levé straně, tak typicky znázornuje klasický scénář virtualizace, kdy máme nějakou infrastrukturu. ta disponuje nějakými zdroji a ty poskytují virtuálním serverům. Tyhle virtuální servery sebou nesou klasicky svůj vlastní operační systém, nesou sebou klasicky aplikaci, kterou mají představovat, nějaký libraries a podobné věci, to není však podstatní. To, co my ve virtualizaci velmi často řešíme, dneska už to není příliš běžný, ale na pozadí se to ve skvělosti skutečně řeší, tak je například instrukční sada, takže pokud dneska řešíme virtualizaci, a to je to, co si chceme dneska ukázat. To, co řešíme dalšího, jestli virtualizem na VMwareu, na Hyper-V nebo třeba na KVMku. Víme, že takový systémy nejsme schopní mezi sebou příliš dobře přenášet. Ty systémy, jakmile se lokneme na určitou stíle technologií, je v podstatě jasný, že u ní nějakou dobu zůstaneme. Zase zajímavý téma, protože v kontejnerizaci tenhle svět vypadá malinko jinak a je to něco, vůči čemu se kontejnerizace sama chce vymezit. Musíme pracovat s ideou, že virtuální serviny mají nějakou velikost. Běžně se bavíme o desítkách, respektive někdy až stovkách gigabajtů. A co víme určitě, a je to určitě jako téma pro řadu z nás, je, že takový systémy neustále bobtnají. Musíme je udržovat v chodu, musíme v podstatě pro ně vytvářet určitou míru individualizace. Je to prostě klasický server, který nechceme zapnout a za dva dny zase vypnout, protože skončil jeho čas. Když se podíváme na to samé u kontejnerizace, na podobný schéma, tak kontejnerizace nám říká, že to, co mají společné kontejnery, je operační systém, který se propaguje skrze kontejner engine a vlastní kontejnery si operační systém nedrží. To je idea, kterou asi velmi dobře všichni znáte. Velmi často se sklonňuje právě souvislosti s tím, že díky tomu je kontejner menší a snáze se s ním pracuje. Ale ono to přináší řadu dalších pozitiv nebo dalších změn. To, na co se u kontejnerů soustředíme, tak je zejména ta samotná aplikace a její, dejme tomu, provozní prostředí, který se díky tomu může hodně zmenšit, může se specializovat na tu konkrétní jednu podstatnou věc, kterou má dělat a není potřeba vlastně přidávat tomu nějaký balast. To je jako velmi důležitý point. To, co u kontejnerů současně řešíme, nebo naopak neřešíme, ačkoliv bychom někdy mohli, tak je právě třeba instrukční sada. Zase naopak řešíme, jestli provozujeme Windows nebo Linux, protože nositelem opračního systému je v tomto případě samotná infrastruktura, takže my se vůči tomu musíme samozřejmě vymezit. Ten podstatný rozdíl je, že kontejner tvoří v podstatě ta aplikace. Pro nás, pro určitý zjednodušení, pojďme se tvářit tak, že vlastně kontejner je skutečně v jádru aplikace, kterou na ní chceme provozovat. Samozřejmě plus prostředí, který vedle sebe má. Když se potom podíváme na srovnání obou dvou těchto světů, tak se ukáže, a ještě si vysvětlíme i proč v nějakých dalších slidech, tak se ukáže, že v momentě, kdy mluvíme o virtualizaci, tak mluvíme typicky o nějakých desítkách až stovkách servurů, který v rámci infrastruktury spravujete. Je pravděpodobný, že je dokážete spravovat ručně, případně, že je dokážete spravovat ručně s tím, že máte jenom nějaká smysluplná pravidla, tak, abyste se z toho v úhozovkách nezbláznili. Do určitý míry jste sch A kontejnery právě proto, že většinou představují právě takovouhle mikroslužbu, tak jich zpravujeme řádově více. Ten jejich life cycle je mnohem kratší. Bavíme se o tom, že kontejnery točíme v týdnech, i ve dnech, možná měsících. To se u serverů velmi málo kdy děje. S ohledem na to, jak velký množství kontejnerů spravujeme, tak je nutné pracovat s tím, že už vyžaduje, aby jste byli schopní od nějakého automatického deploymentu. Těžko si dovedeme představit situaci, kdy tisíce služeb spravujete ručně a orientujete se v situaci, kdy některému z kontejnerů se teda nějaký specifický pravidlo, to je pro mě třeba nepředstavitelný, nechci tvrdit, takový situace nikdy v životě nepotkáte a rovnou je doporučuji změnit. To, co zároveň pro kontejnery platí, díky tomu, že máte automatizovaný, je pravděpodobný, že jste schopni automaticky deployovat, máte pro deployment nějaké pevné předpisy a jste schopni vyvíjet jednotlivý kontejnery zvlášť, což vede k tomu, že v tom prostředí vašeho vývoje je vlastně velikánská dynamika. Kontejnery se neustále někde mění, možná se změní jeden z tisíce, možná dvacet z tisíce, ale pro vás to znamená v podstatě už nějaké nové verze, nějaké nové chování vaší aplikace, protože teď se právě podíváme na to, jak vypadá vlastně ta univerzálnost, v našem případě virtualizace, oproti určitý přenositelnosti kontejnerizace. A postupně přejdeme i do typů služeb, kde probereme mikroslužby. aaa To, co jsme chtěli v minulosti od virtualizace, to je v podstatě určitá míra univerzálnosti. To, co virtualizace reálně řeší, tak je propojení od toho spotku, kdy ten host nese určitý device a můžeme se samozřejmě bavit o zařízeních typu CPU nebo RAM, ale to je trošku speciální přístup, ale nese určitý zařízení, zejména třeba storageové zařízení nebo třeba grafické karty. případně jsou i systémy, které nesou zařízení typu třeba licenčních klíčů na USBčku, tak je propaguje skrz svůj hypervizor do jednotlivých virtuálních serverů. To dovoluje obrovskou míru individualizace, dovoluje to, abyste vytvořili virtuální server, který bude mít například pástru sítový karty a neuvěřitelnou propustnost, zatímco vedle něj bude jiný server, který takovou schopnost vůbec mít nebude a budou při tom hostování na společné mostu. Dovoluje vám věci, jako je třeba pinování CPU, v podstatě cokoliv. To je samozřejmě s nadsázkou. V případě kontejnerizace To nikdy nebylo cílem a ani není. Existují nějaké speciální případy, můžeme se na ně krátce podívat, ale ta podstata kontejnerizace je, aby došlo k co největšímu zjednodušení. To, co tady vidíte na obrázku, tak je vlastně popis jednoduchýho kontejneru, který říká velmi jednoduché věci. Ten kontejner je tvořen imidží, je tvořen nějakým sdílenou složkou a je tvořen portem, na kterým poskytuje svoji službu. To jsou v podstatě jediné nutné požadavky, které pro kontejner máte. To, že definujete volume, jste schopni vlastně synchronizovat ten izolovaný svět kontejneru s tím vnějším světem, tím, že synchronizujete nějakou služku s hostem, respektive s klasterem případně. To, že definujete porty, na kterých poskytuje ten kontejner službu a vy je nějakým způsobem vytunulujete ven zase z té izolované složky toho kontejneru do klastru, respektive do některých ze sítí. Fantasticky to funguje právě v momentě, kdy potom provádíte testování na lokálních serverech a lokálních počíhačích a podobných místech. Podíváme se na to hned na srdicím slajdu. A definujete image, který jste připravili buď vy nebo kdokoliv jiný Tím úplně nejznánějším scénářem, který se dneska využívá, tak je Docker. Docker je systém, který je zároveň kontainerizačním enžínem, ale dneska už se v podstatě chápe i jako určitý standard. Takový systém není jediný, existují další kontainerizační systémy, který s Dockerem samotním nemusí být kompatibilní a je dobrý na to myslet, protože budoucnu je přesně tohle to, co by mohlo znamenat, že pokud se vydáte jednou z cest, tak jste uvízli v určitým vendorloku. To, co používáme a pro co se Docker nejčastěji používá, je situace, kdy já si Docker nainstaluji na vlastní počítač a v rámci Dockeru si rozjedu kontejnery, které představují aplikace, které například vyvíjím, či chci otestovat. Tímhle způsobem jsem schopen otestovat i relativně složitý aplikace, ale samozřejmě pořád jsem limitován těmi zdroji, které Docker na tom mým počítači používá, tzn. nejsem schopen kopírovat nějaké velké nebo rozsáhlé systémy. které by vyžadovaly desítky nebo třeba stovky kontejnerů. Docker sám funguje už způsobem, který kopíruje tu strukturu kontejnerů jako takových, kdy si přináší do toho systému něco, čemu se říká Docker registry, kde, pardon, kde si uchováváme imidže, které jsme pro naše kontejnery připravili. Případně do tohohle dokoru registry stahujeme imidže, které chceme využít. Jsme schopni potom aplikovat, případně patchovat, nějakým způsobem dále je rozvíjet a nemusíme je po každé stahovat znova. Tohohle mechanizmu se využívá pro to, abyste byli schopni například zautomatizovat deployment, který jste připojen. Tohle je strašná výhoda. Je to velmi jednoduché, velmi rychle se to dá použít. Existuje k tomu řada nástrojů, který dneska lidé skutečně jako ve velkém míře používají a není výjimkou, že přijdete a lidé vám ukazují svůj produkt, svůj velikánský systém, který vlastně ve svý podstatě představuje zase nějaký soubor nějakých mikroservis právě na svým počítači, kde ty klíčový mikroservisy, který ten systém představují pro tu ukázku dema, Co se však stane, když takový doker chcete nasadit v produkčním prostředí? To není úplně ideální scénář. Doker v tom svým standardním pojetí je vlastně single hostové zařízení a bez toho, abyste vytvořili orchestraci, která vám nabídne, abyste zpravovali víc dokerů v rámci klastru, tak riskujete, že jste vlastně jenom vytvořili standardní infrastrukturu, ať už virtualizmu nevěříte, Pokud bychom takový systém vytvořili třeba jenom pro náš interní vývoj, je to taky běžný způsob, jak se dokry používají. Je potřeba určitě myslet i na to, že týmy, jako jsou DevOpsy nebo obecně vývojáři, tak jsou týmy, který chtějí určitou míru kvality a setkáte se s tím, že pokud vám takový systém půjde nepoběží, tak vám za to nepoděkují. A je to přirozený, i oni chtějí na něčem pracovat a tohle je systém, který jste jim proto vlastně poskytli. Pro vyřešení tohodle problému vznikly v minulosti v podstatě kubernety. Kubernety nebo Kubernetes jako systém je orchestrace v zásadě kontejnerů, v našem případě dokurů, je to nejčastější použitej engine, ale jak říkám, nemusí být, kdy kubernety už chápou ten scénář toho, že využíváte velký množství různých nodů, v tomhle případě jsou to nody dvou různých typů, Ten problém se říká v podstatě řízením přístupu a jedním z nedůhů, kterým kubernety trpí, byť i na tohle je před námi určitý řešení, tak je vlastně určitá neizolovanost těch jednotlivých kontejnerů, kdy vy kontejnery, který v kubernetech provozujete, tak komukoliv, kdo k těm kubernetům má přístup, tak je v podstatě zpřístupňujete. Jednotlivý pody mezi sebou můžou komunikovat. který se v rámci této vnitřní sítě trošku rozhlídne, pozbírá informace, který chce, případně se pokusí získat z těch hnedlových podů nějaký další informace. které už třeba nejsou v kompetenci toho, tak jak je vy sami chcete používat. Tenhle ten konkrétní problém je jako známý, například se doporučuje pracovat rovnou s ideou, že Kubernetes těch klastrů je potřeba z principu vícero, v tom smyslu, že je oddělujete nejenom podle typu toho, jaký provoz na ní chcete provozovat, ale chcete je oddělovat třeba i podle toho, pro který tým konkrétně spadají v případě, Existují nástroje, které dneska nebo v budoucnu budou tenhle problém řešit, ale o tom někdy později. V případě Kubernetes už se rozdělily typy nodů. Nepracujeme s jedním serverem, pracujeme s dvouma typy, typicky s dvouma typy. Jedním z nich je takzvaný master, který celý ten systém řídí a dalším z těch typů je takzvaný worker. U workerů pracujeme rovnou s ideou, že nemáme se mít jeden, máme se jich mít vícero, ale samozřejmě můžete mít postavený i kubernety, který pracují pouze na jednom jediném počítači. Existuje pro to i speciální projekt, kterým se říká MicroKubernetes nebo MicroKS. V případě mástrů je pak zajímavý vědět, že množství mástrů definuje v podstatě potenciální dostupnost ovládání a vůbec produktivity nebo produkce jako takový v případě Kubernetes. Typické je stavět mástry tím pádem například tři, pravidlem je lichý počet, kdy víte, že při výpadku jednoho z mástrů nedojde k tomu, že byste nebyli schopní vlastně z Kubernetes dál pracovat. kteří i automatický deploymenty nebo třeba testy, který vyžadují, aby k tomu API měli přístup a byla to pro ně skutečně fungující služba. To, co máme se tady ještě určitě zmínit, je, že tím, co je pro vás vlastně vstupem do Kubernetes, je dneska skutečně APIčko. Existuje řada UI nástrojů, které jsou schopné to APIčko vizualizovat, takže vám dovolí vidět přehledně a ovládat ten Kubernetes klastr v nějakém grafickém rozhraní. Pro většinu programátorů je dneska běžný využívat komandu, s tím APIčkem jako takovým pracuje. Dneska si ho v krátkosti v jedné ukázce ukážem. Není to až tak složitý a zejména to vede k tomu, že jsme schopni potom právě ty naše kroky automatizovat a jednoduše opakovat, což je samozřejmě důležitá věc. To, co tady větší množství nodů zajišťuje, tak je vysoká dostupnost. Ten worker a množství workerů tady nedefinují samozřejmě pouze tu vysokou dostupnost, ale je to důležitý point, definují i celkový prostředky, který potom v rámci toho klastru budeme schopni využívat. My se podíváme, během pár kroků se podíváme na plánování takového klastru, kde uvidíme, jakým způsobem ty prostředky plánovat, respektive jakým způsobem se ty prostředky, jak počet a velikost toho workerovýho nodu vlastně ovlivňuje prostředky, který potom máte k dispozici pro jednotlivý kontejnery. Je to poměrně důležitý po momentě, kdy ty kubernety jako takový stavíte. Tak teď už se podíváme na to, jak vypadejí typy služeb, který vlastně dneska v kontejnerech většinou budeme. Ne nutně jenom v kontejnerech, pořád se bavíme o kontejnerech. na úrovni nebo v kombinaci s virtualizací. Takže začneme tím, co je tím nejznámějším scénářem a to je monolitická infrastruktura. Monolitická infrastruktura je aplikace, která je v podstatě zveliká. Většinou je v podstatě jedním programem nebo nějakým souborem mnoha skriptů, které jsou od sebe neoddělitelné. Velmi často její vývoj probíhá třeba interně nebo je to velmi specializovaná aplikace. utrhnout vlastně od toho cyklu vývoje, případně říct, OK, tady dost, tady už je čára, potřebujeme tu naši aplikaci vyvíjet jinak. A potřebujeme se dostat do stavu, kdy jsme třeba agilnější v tom vývoji, nebo jsme schopní využívat nějaké prototypy, které už před námi někdo připravil. Tomu, aby se vlastně takovýhle prototypy daly používat, tak k tomu víceméně slouží právě spíš mikroservisní infrastruktura, která je postavená způsobem, kdy jednotlivý, relativně jednoduchý tázky jsou naprogramovány zvlášť, fungují a pracují zvlášť a spolupracují spolu. To znamená, ptají se jedna druhý, jaký to vyšlo v uvozovkách a s výsledkem, který získávají, zase pracují nějakým způsobem dál. Tahle ta změna v uvažování programátorů je přibližně podobná jako momentu, kdy se v minulosti přicházelo z takzvaně procedurálního do takzvaně objektovýho programování, kdy procedurální objektová, pardon, procedurální programování znamenalo psát velký množství velmi dlouhých kódů, které byly těžko znovu použitelné, zatímco objektový programování samozřejmě znamená změnu přístupu, změnu uvažování, vyžaduje to trošku jiný prototypy a v těch hlavách vlastně vytvořit Už proto, že jednotlivý mikroservisy potom můžou představovat to, co byste dneska v tom monolitickém systému chápali, třeba jako objekt a nějakého prostředí, ve kterém se pohybuje, nějaké služby, které v něm využívá. To, co je ještě zajímavé zmínit u monolitické architektury, je schopnost zvyšovat rychlost. Existují dva typy škálování, jednou se říká scale out, druhou se říká scale up. V případě monolitických aplikací se typicky bavíme o takzvaně scale upových aplikacích, kdy ty aplikace navyšují svoji rychlost tím, že podně dáváte čím dátím silnější železo. Pokud chcete zrychlit, nechci říct na dvojnásobek, se škáluje typicky naopak scale outem, což je mechanismus, kdy vedle současně zpracovávaného výkonu přidáváte nový výkon, na který se veškerý ty mikroservisy vlastně rozdistribuovávají. To je to, co nám přináší Kubernetes a je to vlastně i způsob, jakým se pak dá dosahovat obrovských výkonů, kdy daleko přesahuje výkon té aplikace jako takový výkonnost jakýkoliv dneska existujících jednotlivých serverů. Je dobrý nad tím, který pokud se pokazí, tak musíme přicházet na nějakou náhradní část. Případně to pro nás znamená, že ta náhradní část celulů neběží a my máme 50% prostředků v podstatě jenom jako rezervu. To se typicky v mikroservisové infrastruktuře neděje. Třeba množství prostředků jako rezerva je řádově menší. Když se podíváme už na kontejnery, tak kontejnery naopak, nebo ne nikoliv naopak, ale kontejnery samotný dělíme na takzvaně stavový nebo nestavový. Stavový nebo nestavový kontejner se vykládá podle toho, jestli sebou nese nějakou informaci, která je víceméně těžko dosažitelná a vy potřebujete, aby s ní takový kontejner dlouhodobě pracoval. Je vhodný vlastně se na to dívat i způsobem, kdy takzvaně, respektive můžeme si to ukázat na příkladu, nemůžeme na lepší, nestavová aplikace je taková aplikace, která data, se kterými pracuje, ukládá mimo sama sebe a je schopná si je kdykoliv zase vytáhnout, kdykoliv s ním zase znova pracovat a v případě, že je nespracuje, tak se nám nic zvláštního nestane. Ten stav, který sebou ta aplikace nese, není pro nás nějak kritický. V případě, že by nám taková aplikace spadla a my jsme ji museli nahradit, tak jakákoliv jiná aplikace může data To, co je pro rozdíl tady těch dvou kontejnerů typický, je velmi rozdílný mechanismus škálování, kdy právě synchronizace té stavové informace na úrovni těch jednotlivých aplikací vede k tomu, že škálování stavových aplikací je poměrně složitý a existuje k tomu spousta různých teoremů, který vám nakonec řeknou, že to lze, o něco v podstatě přijdete, ať už třeba o rychlost nebo naopak o schopnost pracovat jenom s částečnou informací nebo o podobné jiné věci. To, co je zajímavé řešit v případě nestavových aplikací, respektive přepadu stavových aplikací do nestavových aplikací, tak je i schopnost dosažení daný informace zase zpátky vlastně do procesu. To, co já doporučuji, je se i na některé stavové aplikace případně dívat jako na potenciálně nestavovou aplikaci za přepokladu, že informace, kterou taková aplikace nestavuje, Ještě jeden speciální případ. V případě, že se koukáme na nestavový aplikace, tak tím dnešním trendem je takový aplikace přepisovat do něčeho, čemu se říká function as a service, nebo taky serverless, bezservorová infrastruktura, což vede k tomu, že takovou aplikaci, pokud je velmi jednoduchá, pokud je rozpadnutá na skutečně elementární části, tak jste schopní implementovat v podstatě jenom jako jednotlivý funkce, Existuje jeden velmi specifiální scénář, který tady uvádím právě proto, že se bavíme o využití kontejnerizace v infrastruktuře a nazval jsem ho monolitický kontejner. Představte si, že aplikaci, kterou jste doteďka chápali jako monolitickou, tak byste v podstatě pouze zakontejnerizovali. Takže popsali ji způsobem, který kontejnery vyžadují, napsali si, který služby jsou v podstatě těmi službami, které chcete takzvaně exportovat, expouznut ven. a připravili ji do nějakého doku nebo do Kubernetes. Tou velkou nevýhodou takových monolitických kontejnerů je, že nejste schopni je dělit. To je naprosto klíčový point pro to, abyste byli schopni využívat právě skyoutování, takže v takový moment vlastně nutně narazíte na to, že výkonnost toho kontejneru bude ovlivněná zase jenom výkonností hardwareu, na kterém běží a nebudete schopni je efektivně škálovat. Na druhou stranu, využití takovýhleho konceptu může vést k tomu, že přepnete to uvažování ve dalším vývoji, což znamená, že pro ně v podstatě nevytváříte žádnou zásadní změnu. Je to systém, ve kterém ve kterým vám taková aplikace běží dále jako výjemko nebo případně větší množství výjemek, tak jako pravděpodobně do posud, ale díky tomu, že jste schopni okamžitě a vedle hned kooperovat se zdroji, které takový systém využívá, ať už skrz síť nebo třeba úložiště a v některých hodně speciálních případech třeba i se zdroji, jako je paměť a procesor. tak jste schopni začít oddělovat vlastně části té monolitické infrastruktury do jednotlivých mikroslužeb a přepnout si tak do toho scénáře, kdy je zajímavý začít vlastně přepisovat tu monolitickou infrastrukturu do mikroservisní. Taková věc se nestane ze dne na den, není to technicky možný a ani by to pravděpodobně nikdo nedoporučoval, protože to znamená prostě obrovský třesk, ale představa toho, že jakákoliv nová funkce, Samozřejmě tohle může vypadat způsobem, kdy bych rád řekl, že monolitická infrastruktura je špatná. To není pravda. Monolitická infrastruktura má nějaké své výhody a určitě tady s námi ještě dlouhou dobu bude. Vedle toho infrastruktura se vná mikroservisním způsobem má zase výhody, které přináší třeba právě rychlejší vývoj, přináší trošku jiný přístup z pohledu těch samotných vývojářů nebo v případě, Tak, to, co jsem tady nakresl za jednoduchý diagram, ta schopnost, dejme tomu, spolupráce mezi virtualizací a kontejnerizací. Na úrovni různých systémů se dá dělat různým způsobem. Ten úplně jako nejzajímavější třeba z našeho úlu pohledu je právě ten, kdy využíváte společných zdrojů nejenom na úrovni sítí nebo sítových služeb, to je třeba například sdílených uložišť, ale právě i třeba na úrovni paměti a procesoru. To, co vám to potenciálně přináší, je situace, kdy například kvůli licencování nebo kvůli určitý privátnosti vašeho prostředí Existují i jiné způsoby. Můžete samozřejmě na té virtualizaci, kterou dneska využíváte, kontejnerizaci jako takovou vytvořit. Existuje proto řada různých nástrojů, kdy je samozřejmě nutné počítat s tím, že jakmile vytváříte virtuální server a na něm kontejnerizaci, přicházíte o určitou část zdrojů, případně se takové zdroje trochu hůře plánují nebo se třeba hůře automatizují. Tak, my si pomůžeme takovou krátkou ukázkou. To, co máme připravené, je zmiňovaný VMware Tanzu. VMware Tanzu je nástroj, respektive je infrastruktura, která je vlastně orchestrací kubernetů v rámci standardní infrastruktury jako služby. Navazuje na nástroj výkladu direktoru, který my sami využíváme pro orchestraci samotný infrastruktury SS Service, tzn. standardní virtualizace. A jsme schopni využívat i prostředí, který vy dneska využíváte jako virtuální datový centra. Já poprosím o ukázku. Tak to, co vidíte tady, je právě nástroj výklout Director a přecházíme do sekce, která je označená ku Kubernetes Containers. A vytváříme nový klastr. Dotaz je na název. Ten je v podstatě libovolný. Nicméně neakceptuje některé znaky. Tady je důležitý dotaz na virtuální datové centrum, ve které vzniká. A další důležitý dotaz na verzi. Tady těch částech ještě budu krátce hovořit na dalších slidech. A další neméně důležitá část, která řeší plánování zdrojů, jejich počet a v podstatě šablonu zdrojů, které se mají pro jednotlivé systémy využít. Tak. Tuhle chvíli už přecházíme jenom do určitýho review. Můžeme vidět, že ten task se vlastně založil. My si za chvíli ukážeme i dokončení takového klastru. Jednou z výhod takového systému je i rychlost, takže uvidíte, jakým způsobem a jak dlouho vytváření takového klastru funguje. A to, co nás samozřejmě bude zajímat následně nejvíc, je něco, čemu se tady říká API endpoint. které zatím nemáme a budeme ho mít k dispozici v momentě, kdy se dotvoří klastr. Já vidím, že tady máme zatím jeden z dotazů. Já si dovolím na ten dotaz reagovat až na závěr, jestli to není problém. Myslím si, že to je dobrý dotaz a je fajn o něm možná mluvit i v nějakém širším kontextu. Tak, to, co je ještě zajímavé na VMware Tanzu, tak je právě schopnost vlastně, respektive nikoliv schopnost, ale kompatibilita se standardními Kubernetes. My sami jsme zkoušeli takový systém rovnou nahodit například vůči nástroji, kterému se říká Rancher, který slouží typicky pro orchestraci Kubernetes a ta kompatibilita je na tak vysoké úrovni, Pomůžu si hned v dalších krocích, protože to, co se dělo při tom vytváření kontejnerů, tak je tak je zajímavý i vlastně v kontextu nějakého dlouhodobého užívání. My jsme mohli vidět, že jsme si volili virtuální datový centrum. To je důležitý bod, protože pro nás je to v podstatě schopnost si vybrat virtuální datová centra, kterými ten poskytovatel disponuje. Nemusíme si vybírat to jedno jediné, které tady teď pro tu ukázku máme vytvořené. V případě, že by ten poskytovatel disponoval větší množství virtuální datových centr, případně ve více lokalitách, prostě alternativně prostě jen větší dostupnosti a potenciálně i nezávislosti, protože nikdo vám samozřejmě nediktuje, abyste využívali nutně jednoho jediného providera. Můžete kontejnerovou infrastrukturu kombinovat s providery dalšími a to ať už například s Amazonem nebo s Azurem, případně s Googlem, tak samozřejmě i s providery laděnými trochu více lokálně. Tím druhým krokem, který jste mohli vidět, tak je volba Kubernetes version. To je hrozně důležitý point. Kubernetes version, nebo respektive samotný Kubernetes, se vyvíjí velmi rychle a my můžeme vidět označení, jako je třeba 1.17.17. Ve té standardní terminologii se tomu 1.17 u Kubernetes říká jako major verze a v tuhle chvíli platí, že Kubernetes samotný podporují vlastně tři poslední verze. Mardon k dispozici verze 21. Takže v tuhle chvíli bychom byli schopni provozovat naše kubernety na podporovaných verzích 1.17, 1.18, 1.19, pardon, 1.18, 1.19, 1.20 a 1.17, kterou já jsem v rámci toho dema vytvářel, už by vlastně nespadla do těch podporovaných verzí. Je důležitý vědět, že vývoj kubernete se děje skutečně rychle a není v podstatě výjimkou, že upgradey takových kubernetních klastrů je potom potřeba dělat třeba v horizontu, To, co je tady ještě zajímavé zmínit, je, že VMware Tanzu a to, co jste viděli, zatím pracuje s ničím, čemu se většinou říká takzvaný replacement upgrade, kdy se předpokládá, že upgrade kubernetí verze se děje způsobem, kdy vedle vytvoříte novou infrastrukturu s verzí, na kterou chcete přejít a v podstatě do ní spustíte redeploy aplikací, které máte. To doporučení je jednoznačně takový, že redeploy a vůbec ta schopnost tímhle způsobem pracovat a případně si svůj deployment vůči ním přizpůsobit. Je to takový jako opatrnější způsob oproti například druhýmu, kterému se říká rolling upgrade, což je mechanismus, kdy jednotlivý nody v nějaký moment v podstatě přetlučete novou verzi, přelejete novou verzi a postupně tímhle způsobem přelejete celý klastr, takže pody a aplikace, který na tom klastru provozujete, tak se vlastně v určitý moment objeví na kubernetech s novou verzi. Obojí je možné, existují k tomu různé přístupy, u Rolling Upgrade se třeba doporučuje vytvořit si předem snapshot, To, co jsme ještě v průběhu toho vytváření klastru dělali, tak bylo v podstatě plánování zdrojů. Vy jste mohli vidět, že v rámci toho dialogu jsem byl dotázan na počet právě control plane nodů, což je v našem případě vlastně masternod, který pracuje nebo respektive operuje a řídí celý ten Kubernetes klastr a byl jsem dotázan na počet worker nodů. My sami doporučujeme, aby se Kubernetes děli způsobem, kdy worker nodů je relativně velké množství a to proto, aby docházelo k tomu scaleoutování, aby docházelo k tomu, že se skutečně rozloží zátěž a využije se Maximus infrastruktury způsobem, kdy jednotlivý mikroservisy jsou tak malý a tak jednoduchý, že jsou schopny využívat relativně malé množství zdrojů, ale jejich velké množství. V případě, že byste využívali kubernety pro aplikace, které jsou, řekl bych, těžší nebo jsou více monolitické, tak by bylo potřeba samozřejmě myslet na to, že zdroj jednoho workru nebo respektive zdroje jednoho workru musí odpovídat nějakým konkrétním parametrům, jako třeba počtu CPU a počtu RAM. Já sám jsem tady měl k dispozici pouze jeden template. Ta definice templateu je samozřejmě na straně providera a bývá součástí nějaké dohody, Možná ještě doplním, velikost toho workera vlastně definuje, jak už jsem předtím předesílal, výkon jednoho kontejneru. Je jasný, že my v rámci jednoho kontejneru nejsme schopní překonat výkonnost toho workeru nodu jako takového a samozřejmě jejich počet potom definuje ten celik jako takový. Zapřepakuju, že máte aplikaci napsanou škálovatelně. My se tady teď podíváme na moment, kdy už se Kubernetes dokončily a my z nich jsme schopni získat vlastně ty nástroje, které potřebujeme pro jejich zprávu. Tak já poprosím o pokračování ukázky. Tady vidíme vlastně jenom pokračování toho původního vytváření klastru. Můžete vidět, že ten job jako takový byl dokončen. Je tady čas, který říká asi čtyři minuty. To možná ještě malinko okomentuji později, ale to, co se tady dozvídáme, tak je takzvaný endpoint, což je pro nás v podstatě vstup do toho kubernetesního klastru a je to pro nás místo, vůči kterému vlastně zaměřujeme nástroje, které využívají API. Bez tohle kube konfigu se do kontejneru samotných nemáte šanci dostat. Platí to v podstatě všude. Na druhou stranu, jakmile máte konkrétně třeba tenhle kube konfig, tak se stáváte v podstatě neomezeným vládcem těch kubernet. To, co si ukážeme hned na další ukázce, je, kdy já jsem tenhle kube konfig vzal, nahrál jsem si ho na správný místo, někam do .kube-konfig a tak podobně Jednoduché příkazy, které tady v tom případě nám ukazují počet nodů. Já jsem si v mezičase hrál se škálováním, takže můžete vidět, že mají různý věk. Jinak dlouho běží, ale za chvíli si ukážeme i to. A to, co vidíme tady, tak je vlastně výpis komponent, který který ten klaster od svého začátku obsahuje. Vidíme tady věci, za chvilinku se k něm malinko dostaneme, ale vidíme tam třeba Antreu, vidíme tam Cordenes, Docker registry, jednotlivý nody mají svýho agenta v rámci výsvíry, takže i ty jsou tam znázorněný. My, když se teď podíváme právě na tyhle jednotlivý komponenty, tak to, co je na Kubernetes problematický a je velmi často zdrojem řady, si teď přiznám se nemůžu vzpomenout. System Antrea vychází z OpenVSwitche, což je věc, která se velmi dlouhodobě vyvíjí a má velmi širokou podporu, proto je to zajímavý a jsme schopni na ní vytvářet nějaké další služby a to klíčové, co jsme schopni na ní vytvářet, tak je propojení s NSXT. To je ostatně nativní součástí Tanzu, ta schopnost propojit se s NSXT, což je virtualizace sítí u VMwareu a poskytnout vám skrze tuhle virtualizaci řadu dalších služeb, Součástí Kubernetes je rovnou i registry. Tanzu pracuje typicky s Harberem 1.3., což je teda starší verze Harboru. Zase naše doporučení je buď si vystačit právě s Harberem, nebo respektive naše doporučení je Harbor rozhodně využívat. Harbor je fantastický projekt. To, co je na něm velmi, velmi zajímavé, je schopnost distribuovat se, My sami na některých projektech aktivně využíváme Harbor 2, kdy ty Docker registry, které jste mohli vidět jako součástí Tanzu, aktivně nevyužíváme. To, co je zase výhodou toho, že Tanzu je nad VMWerem, tak je schopnost kooperovat s výsanou. To je zase zajímavý point, protože výsana, kdo znáte výsanu, výsana je distribuovaný storage, softwarově definovaný storage. To klíčové slovo je tam právě to distribuované, které jsem schválně vložil. Tak jak kontejnery samotný jsou distribuované, tak to, že máte storage pod ním zase distribuovaný, vede k řadě výhod, které třeba například zkracují latence při dostupnosti těch voliumů vůči kontejnerům nebo nabízí to, že jste schopní s nimi dělat různé vzdálené repliky typu metroklástru nebo efektivně využívat tu kapacitu tím, že definujete, To, co Tanzu dneska přímo neobsahuje nebo případně vyžaduje nějaký dokončování, tak je tzv. CICD, což je Conscience Integration, Conscience Development, Deployment nástroj. My sami využíváme v některých případech konkurs nebo třeba GitLab. Obojí dovoluje, abyste propojili kubernetí klástr a vlastně využívali té schopnosti toho nástroje jako takového reagovat na deployment nových verzích, například tím, že je automaticky A další dvě velmi důležitý komponenty monitoring a logging. Proto existuje velká řada různých prototypů, takže typický scénář kombinace Prometea a Grafany nebo v případě loggingu třeba například Grafana Locky, byť samozřejmě Kubernetes sami mají nástroj pro sledování logů už do nějaký míry dostupný, ale pokud je chcete systémově a dejme tomu standardně využívat, doporučuje se využít toho. To, co je zajímavou schopností Tanzu a mně se velmi líbí, tak je také škálování. Nahrál jsem proto jednu krátkou ukázku, o kterou teď poprosím. Tanzu obsahuje schopnost škálovat skutečně jako naklik. Ten důvod, proč to tak je, je proto, že Tanzu nevytváří na pozadí virtuální servery jako klasicky virtuální servery, tak jak jste zvyklí z infrastruktury virtualizace, ale pracuje nad jiným v podstatě Kubernetes klastrem, který jako Tanzu jako takový reprezentuje a je pro něj v podstatě, dejme tomu tím hlavním klastrem, ale je velmi podobná a tomu přidáte-li si ještě dalších 10-15 vteřin, aby se sesítěvaly všechny další věci, které kolem toho jsou, tak byste zjistili, že za takhle krátkou dobu jste schopní jak velikost svýho Kubernetes klastru zvětšovat, tak i zmenšovat. Tohle je samozřejmě věc, která mně se samotnímu velmi líbí, taková hračička, ale pro ten běžný vývoj nemusí být nějak kritická. Pokud se samozřejmě nepohybujeme v prostředích, které jsou citlivé na výkon, To, co dává smysl ještě říct tady, je, že to plánování, v případě, že plánujete Kubernetes cluster právě třeba v Tanzu, tak je třeba rovnou pracovat s tím, že škálování se týká pouze workrů, množství masternodů a tím pádem určitou základní dostupnost toho systému jako takovou definujete při vzniku a není možný je třeba v budoucnu potom změnit. Na druhou stranu, celý výklad director je dostupný přes API a je možný ho napojit třeba na další systém, Tak a pomůžu si posledním slajdem, který se snaží zhrnout, pokud už máme infrastrukturu virtualizace a máme infrastrukturu kontejnerizace a jsme schopni využívat stejné společné zdroje, ať už v momentě, kdy se to týká nějakých dalších monolitických celků, jako třeba databází nebo nějakých jiných, dejme tomu už třeba distribuovaní postavených systémů, jako jsou třeba storage, tak kam s kterým workloadem vlastně jít. Je to variabilní záležitost a nelze diktovat, co je lepší. A rozhodně bude platit, že dál budou existovat nějaké monolitické celky, pro které je z principu zajímavější a lepší využívat virtualizaci než kontejnerizaci. V momentě, kdy jste schopni využívat vlastně nějakých společných sítěvých nebo dalších propojů, tak vydeployovat monolitický celek v Kubernetes povede k tomu, že ten systém budete muset designovat vůči tomu, Kontejnerizace je samozřejmě zajímavý v případě DevOpsových nebo obecně nějakých testovacích scénářů, ale v případě produkce se ukáže, že z toho žádná specifická, specifické vylepšení nečíhá. To, co se objevuje v kontejnerech velmi specificky, je to, že vy tak, jak připojete do kontejnerů nějaké sdílené složky, tak je tam v podstatě vždycky připojete na úrovně filesystému, což vede k tomu, že ty systémy, které typicky pracují z bloky, V případě, že máte jakýkoliv aplikace, které vyžadují nějaký konkrétní hardware, vyžadují třeba právě licenční USB klíče nebo podobné věci, je to rovnou věc, která patří jednoznačně na infrastrukturu virtualizace, na kontejnerizaci by byla zbytečná. U kontejnerů sice existuje jeden velmi speciální příklad, nebo možná ne, ani jeden velmi speciální příklad, dneska už je zajímavý a v zásadě i oblíbený, a to je něco, čemu se říká Nvidia Docker, Vede k tomu, že to zejména pro case, který se týkají třeba umělý inteligence, machine learning nebo podobně věcí, kde se systém jako GPUčko ve velký míře použijí. V rámci virtualizace jsem uvedl ještě jednu věc a to je aplikace citlivá na prostředí. Z mý vlastní zkušenosti je to například Solr, což je nástroj, respektive takový databázový systém napsaný v Javě, který je velmi citlivý na to, jaký Java runtime engine pod ním nebo respektive na tom systému, jak to běží. To, co zjistíte, je pravděpodobně to, že řada systémů, který dneska používáte, tak se dají nahradit systémy, které už nikdo vlastně do kontejnerizaci připravil. Může jít o jednoduchý databáze Redisy, Rebity a podobné věci, nebo třeba nějaký NoSQL distribuovaný databáze. To je taky velmi známá, dobrá věc, která patří do kontejnerizace a efektivně využívat potom i schopnost třeba více roklastrů v různých lokalitách, georendunantně, nebo třeba jenom zakončím to tím jednoduchým, nevymýšlejme kolo, on už ho za nás někdo vymyslel. Takže já teď děkuju za pozornost. Vidím, že se nám tady seskupilo pár dotazů, takže já ji zkusím odpovědět. Hned ten první. Jak je to se zpracováním většího množství dat? Neroste pak hodně režie, to je z nároky na komunikaci mezi jednotlivými mikroservisemi, zpoždění, přenos dat. Ano i ne. Je to samozřejmě tak, že různý networkový engine v Kubernetes mají, dejme tomu, různou propustnost. Některý z nich jsou schopní využívat, dejme tomu, něčeho, co by se dalo klasifikovat jako takový SRIOV. Což vede k tomu, že ta propustnost je opravdu obrovská, ale je faktem, že obecně v kontejnerizaci pracujeme spíš s větší mírou virtualizace a to i na úrovni sítí. Typický je, že na pozadí můžou být třeba VX-lany nebo nějaké jiné enkapsulace, které dovolují, aby si ty systémy mezi sebou předávaly informace, jako třeba kde který podběží, jestli je dostupný, není dostupný a podobné věci. Naše zkušenost je taková, že dneska ta technologická propustnost, respektive mohl by za přepokladu, že by jsme s ním byli schopni pracovat jako s distribuovaným, což je téma zase na někdy jindy. Takže rozhodně doporučuju se nad tím zamyslet, jakoby způsobem udržet si to hlavní, co kontejnery přináší, a to je přenositelnost. Přenositelnost a jednoduchost. Jestli je to není možný, nepatří to kontejnerů, respektive může patřit v nějakých speciálních případech. Další dotaz, jak je to s řízením bezpečnosti u architektury mikroservis? No to je zajímavý dotaz, to je problém, to je problém velký dokonce bych řekl. Dneska existují některé networkingové systémy a na nich je to hodně závislý, které izolují nebo jsou schopné izolovat jednotlivé takzvané namespacy nebo případně jednotlivé soubory namespaces takovým způsobem, aby se mezi sebou tyhle části právě mikroservis nebyly schopné komunikovat. v konkrétním, tuhle konkrétní mechaniku využívá právě network interface KANL, což je teda network interface, který my v rámci Tanzu nevyužíváme a spíš pracujeme s tím, že pokud je potřeba od sebe mikroservisy oddělovat, tak pak má smysl je separovat i na té úrovni klastrů jako takových. Takže dotaz je to rozhodně super a je to velký téma právě i v kontainerizovaném světě. Tak, další dotaz tu máme. Můžete prosím ještě zmínit vámi doporučované řešení pro load balancing? Kde je jeho typické použití? Aha, OK. Load balancing. V kontejnerech se load balancing používá v podstatě téměř všude. To, co jsem nezmínil, už zasahuje do takových detailů právě toho, jak ty kontejnery fungují, tak je schopnost v rámci jednoho jediného podu vytvořit těch kontejnerů vícero, případně vytvořit vlastně kopie téhle aplikace na různých nodech a to, co proto potom využíváte, abyste mohli přistupovat k takové službě, tak je právě load balancing. To, co se tady běžně v loadbalancingu nabízí, respektive Kubernetes znají něco, čemu se říká ingress controller, což je nástroj, který vlastně spravuje jednotlivý loadbalancovací pravidla pro ingress controller. Respektive ingress controller funguje na několika známých loadbalancovacích platformách, jako je třeba Nginx, Traffic, AVI Networks, jejich celá řada. A vy potom vlastně definicí služby loadbalancer, Za mě je to tak, že neexistuje úplně jako jedno pevný doporučení. Dá se říct, že asi tím nejoblíbenějším, nejznámějším load balancovacím mechanikou v rámci Kubernetes tak je právě Nginx a v podstatě ingress kontroler založený na Nginxu, ale není to nutně tak, že je to jako nejlepší volba právě pro vás. To záleží skutečně na té infrastruktuře, kterou byste v kontainerech chtěli využívat. Mám tady ještě další dotaz. Jak moc odděluje jednotlivé skupiny kontejnerů použitá platforma VMware Tanzu? Z hlediska toho, co jste zmínil, ono je dokonale na izolaci kontejnerů určitě snad. Ano, rozumím. VMware Tanzu v podstatě jednotlivý kontejnery neodděluje jinak než klasický Kubernetes. Pracuje úplně stejně jako jiný Kubernetes, to znamená, cokoliv se spodu propaguje ven, tak je v rámci interní sítě Kubernetes dostupný. který by dovolovaly izolaci ve větší míře, ale konkrétně dneska v Tanzu implementovaný nejsou. Tak je tady poslední dotaz už netechnický a to, jestli bude záznam možný vidět zpětně. Ano, samozřejmě, jak prezentaci, tak předpokládám i videozáznam, respektive určitě i videozáznam bude k dispozici na našich stránkách a předpokládám, že vám přijde s odkazem e-mailem. Takže já v tuhle chvíli děkuji za pozornost, budu se těšit na příště, rovnou vás zvu. V průběhu dubna plánujeme v podstatě pokračování