Kontejnery a systém pro jejich řízení (orchestraci) Kubernetes představují jeden výrazných trendů podnikových aplikací. Na několik otázek souvisejících s jejich nasazením odpovídá David Bečvařík, Senior Solution Architect pro region CEE ve společnosti Red Hat, která své celosvětově nejvýznamnější R&D centrum provozuje v České republice.
Jsou-li kontejnery „jen“ dalším stupněm virtualizace, není jim věnovaná pozornost trochu přehnaná? Čím se z hlediska podniku obě technologie liší, pomineme-li, že kontejnery oproti klasické virtualizaci z podstaty věci šetří zdroje (např. z hlediska zabezpečení, vývoje, nasazování a samotného provozu aplikací)?
Není to tak jednoduché, jak se na první pohled může zdát. Pokud se na tuto oblast budeme dívat pouze z pohledu funkčnosti jednotlivých technologií, pak se určitě může pozornost upřená na kontejnery zdát přehnaná. Na druhou stranu si je ale třeba uvědomit, že v oblasti kontejnerizace paradoxně nejde přímo o samotnou technologii kontejnerizace, ale zejména o návazné technologie, jako je Kubernetes a na něm založená kontejnerová platforma Red Hat OpenShift Container Platform, které toho už umožňují mnohem více. V těchto řešeních má kontejnerizace roli snadno přenositelného, zabezpečeného a škálovatelného obalu pro naše aplikace – nakonec odtud pochází i slovo kontejner.
Kontejnery se mnohdy uvádějí málem jako synonymum cloudu? Souhlasíte s tvrzením, že obě technologie bez vzájemné kombinace plně nevyužívají svůj potenciál?
Nemyslím si, že cloud nutně vyžaduje kontejnery, nebo naopak kontejnery vyžadují cloud. Avšak synergie při vzájemném využití těchto technologií skýtá velký potenciál. Projevuje se to nejvíce v oblastech tzv. otevřeného hybridního cloudu, kdy je díky kontejnerizaci možné snadno a bez zásahu do aplikačního kódu převádět aplikace mezi různými poskytovateli cloudu a/nebo on-premise prostředím, a tím zabránit riziku vytvoření závislosti na jediném dodavateli a ochránit a efektivněji využít investice vložené do jednotlivých aplikací.
Máte nějaké tipy pro provoz kontejnerů v on-premise prostředí (i některé distribuce Kubernetes to podporují)?
On-premise podpora je velmi důležitá, a proto i Red Hat OpenShift jako distribuce Kubernetes tuto podporu zachovává. Ale vidíme i trendy v podobě provozu Kubernetes přímo na fyzickém hardwaru bez zbytečných mezivrstev jako je například tradiční virtualizace. Tímto se výrazně zjednodušuje správa jednotlivých clusterů a snižuje i množství bezpečnostních rizik, které provoz Kubernetes nad zastaralou virtualizací může přinášet.
Pokud organizace potřebuje nadále provozovat virtuální servery, může využít řešení k tomu přímo určená, například KubeVirt nebo OpenShift Virtualization, které jednotlivé virtuální stroje spouští uvnitř kontejnerů, a tím zajišťují moderní a jednotný přístup jak ke kontejnerizaci, tak i k virtualizaci.
Dále se kontejnery spojují s mikroslužbami. Někdy se uvádí, že není vhodné jen tak převést do cloudu či kontejnerů stávající podnikovou aplikaci, např. monolitickou („velkou“), ale je lepší ji přepsat. Jindy se však za současný trend pokládá právě převod těch monolitických aplikací (stávajících, původních, zastaralých…) v jejich současné podobě („jinak to nejde“; co šlo předělat, bylo předěláno už dřív). Jaký je na tuto problematiku Váš názor?
Zde je odpověď velmi jednoduchá – ve výsledku jde jen o kopírování trendu a hraní si se slovy. Monolitická architektura neznamená nic špatného, stejně jako mikroslužby nemusí být vždy vhodné. Jak naznačuje otázka, dnešní trendem je přepis aplikací do mikroslužeb, bohužel dost často ale vidíme, že k tomu dochází bezmyšlenkovitě a chybně. Pokud chceme převádět zastaralou aplikaci do cloudu, musíme k tomu mít pádný důvod, protože její provoz v cloudových platformách může být nákladný a nutně nemusí přinést žádné benefity. Jako první krok v rámci adopce cloudu by měl být připraven plán a vize nové architektury aplikačního portfolia, které bude správně využívat moderní platformy. Myšlenka, že stávající stav jednoduše převedu do nového prostředí, je velmi naivní a vede k řadě problémů a prohlubování technického dluhu.
Koncepty mikroslužeb a FaaS (funkce jako služba) spolu rovněž souvisejí, ale nejsou totožné. Kde je podle vás místo speciálně pro FaaS?
Případů využití FaaS bychom našli hodně, přičemž se víceméně jedná spíše jen o architektonický vzor. Aplikaci lze jako celek postavit pomocí FaaS stejně jako pomocí mikroslužeb či monolitické architektury. To, co nám ale nabízí FaaS, je snadná škálovatelnost a určitá přímočarost. Takže použít tento koncept bude vhodné například pokud má aplikace v rámci dne velmi nerovnoměrně rozdělené požadavky na výkon – pak je vhodné zvážit její přepis do FaaS, a tím šetřit mimo špičky významné množství zdrojů oproti klasickým řešením.
Zpět k orchestraci Kubernetes. Můžete v této souvislosti poskytnout nějaké tipy týkající se:
◦ bezpečnosti,
Bezpečnost je komplexní a složité téma, ale v dnešní době už i zde existuje velké množství zdrojů informací, ze kterých lze čerpat. Určitě bych doporučil věnovat pozornost distribuci Kubernetes a jednotlivým vendorům a míře zabezpečení dodavatelského řetězce softwaru.
Zejména proto, že i zabezpečená platforma, v rámci které provozujete zranitelné aplikace, je jen mrháním prostředky, protože bezpečnost musí být řešena komplexně. Pro inspiraci bych zmínil Red Hat Trusted Software Supply Chain, který doplňuje Red Hat OpenShift o bezpečnostní aspekty. Dobré je mít i přehled o typických problémech v zabezpečení, a zde bych doporučil začít studiem OWASP Kubernetes Top Ten.
◦ způsobů nasazení (volba distribuce Kubernetes? Nasazovat Kubernetes jako službu od poskytovatelů veřejného cloudu? Volit řízenou službu? Jak nasazovat samotné clustery?),
Hlavními parametry pro volbu distribuce budou její možnosti. Z mého pohledu je aktuálně zejména pro větší nasazení nejlepší volbou Red Hat OpenShift, právě díky své rozmanitosti funkcí a svobodě volby, kterou nabízí. Jako jedna z mála distribucí podporuje běh v on-premise prostředí i ve veřejném cloudu, a to jako plně spravovaná služba nebo i formou klasické instalace.
◦ nákladové efektivity (např. kolik clusterů, omezování zdrojů pro jednotlivé kontejnery, sledování nákladů…)?
Množství clusterů je v současnosti velké téma, osobně bych doporučoval volit spíše méně, zato větších clusterů. Kubernetes se svým autorizačním systémem přístupu k Azure (role-based access control, RBAC) je plně multitenantní prostředí, takže není problém v rámci jednoho clusteru provozovat více aplikací různých uživatelů. Tímto nejenom, že šetříme lidské zdroje potřebné pro správu velkého množství clusterů, ale i HW zdroje, protože provoz každého clusteru se sebou přináší jisté režijní náklady z hlediska tzv. Master nodes, tedy jakýchsi řídicích jednotek Kubernetes clusterů, a podpůrných nástrojů pro sběr metrik, logů atp.
Pro efektivní omezování zdrojů a řízení nákladů můžeme využít celou řadu možností, jako např. službu Red Hat Cost Management, která umožňuje sběr metrik z jednotlivých clusterů a snadné rozpočítávání nákladů na jednotlivé aplikace včetně základních predikcí růstu.
Jaké jsou alternativy ke Kubernetes?
Alternativ ke Kubernetes moc nemáme, existují sice určité projekty, ale jejich adopce v rámci komunity je nižší a často řeší velmi specifické problémy. Běžné firmě bych alternativu nedoporučoval, Kubernetes je plně otevřená platforma a díky svému širokému přijetí nabízí standardizované prostředí a snadno dostupné ověřené postupy.
Viz také: Bezpečnost platformy Kubernetes v roce 2023
Red Hat Trusted Software Supply Chain má zvýšit odolnost dodavatelského řetězce softwaru