Stáhnout si Kubernetes a spustit jej je poměrně snadné. Ale co pak? Co když potřebujeme prostřednictvím Kubernetu podporovat jím širokou škálu aplikací, které spadají pod různé byznysové jednotky? A co když máte kontejnerizovaný mix tradičních víceúrovňových aplikací, mikroslužeb nebo dokonce Kubernetes-nativní aplikační architektury?
Veřejný cloud vs. on-premise: rozdíly
Pokud jste již s Kubernetem někdy pracovali, možná jste si všimli rozdílů mezi nasazením ve veřejném cloudu a v on-premise prostředí. Prvním z nich je nepochybně jednodušší práce se spravovaným Kubernetes clusterem v cloudu. Nemusíte se totiž obávat správy, protože vše už za vás vyřešil poskytovatel cloudu. Nicméně tato volba znamená, že nemusíte zcela chápat, jak je základní infrastruktura postavena. Mnoho IT specialistů to pochopitelně ani nemusí zajímat, protože celý systém funguje a to je pro ně podstatné. Problém nastává, jakmile chcete nastavit cluster k obrazu svému, abyste maximalizovali jeho možnosti. Pokud si jej chcete přizpůsobit, pak se vám bude mnohem lépe pracovat s clustery nasazenými v on-premise prostředí.
Dalším rozdílem je nasazení vstupních zdrojů v prostředích veřejného cloudu, jako je například platforma Google Cloud Platform (GCP). Její nastavení nástroje Google Kubernetes Engine již obsahuje vstupní kontrolér, takže IT tým již nemusí žádný instalovat, což je naopak u on-premise prostředí nutné. Díky GCP stačí pouze aplikovat vstupní zdroje a kontroler je již spravuje automaticky. Podíváme-li se na problematiku konektivity, je opět snadnější cestou zvolení cloudového poskytovatele. Tato volba totiž nevyžaduje žádné přesměrovávání portů v bráně (což musíte třeba i u svého domácího routeru). Zkrátka organizace získá veřejnou IP adresu pro vstupní zdroj a může rovnou spustit své služby.
Veřejný cloud vs. on-premise: podobnosti
Kromě výše zmíněných rozdílů se ale práce s Kubernetem v cloudovém či on-premise prostředí velmi podobá. Mnoho hlavních prvků totiž zůstává stejných:
- Aplikační kód
- Aplikační architektura
- Vytváření souborů s manifesty (například Dockerfile)
- Proces publikace obrazů kontejnerů
- Nasazení souborů manifestu (například soubory
.yml) - Překlad jména (například DNS či DDNS)
- Vstupní konektivity (například vstupních zdrojů)
- Platforma příkazového řádku
- Správa balíčků (například pomocí nástroje Helm)
Pokud se tedy rozhodujete, jaké prostředí zvolit, pak záleží na tom, nakolik si chcete svůj systém nastavovat. U nasazení v cloudu získáváte jednoduchost, u on-premise svobodu volby.
Proč začít s mikroslužbami?
Technologický pokrok v průmyslu 4.0 mění některá průmyslová odvětví dynamickým tempem a manažeři hledají nové cesty, jak uspět v konkurenci a najít nové zdroje příjmů. Mnoho podniků se již rozhodlo využívat mikroslužby, které kontejnery umožňují, protože nabízí flexibilitu a škálovatelnost. Vlastní implementace mikroslužeb s kontejnery je spojena s potřebou podniku po dalších funkcích, například:
- Provozní týmy potřebují nasadit nový release softwaru v několika fázích, vybrat specifický provoz (či uživatele) a přesměrovat je na novou testovací verzi. Po finálním nasazení samozřejmě vyžadují, aby mikroslužby bezpečně, a to včetně autentizace, autorizace a šifrování.
- Vývojáři chtějí vědět, jak se jejich distribuované aplikace chovají během prodlení či dokonce výpadku.
- Týmy zajišťující kvalitu služeb potřebují promítnout toto chování a výsledky testování do zlepšení finálního produktu.
Projekt Istio
Právě tyto výzvy pomáhá překonat open-source nástroj Istio, který umožňuje propojení, zabezpečení a kontrolu služeb formou jakési sítě - mesh. Istio lze snadno implementovat do existujících distribuovaných aplikací. Je to také platforma, která má API rozhraní a může být integrována do jakékoliv přihlašovací platformy či systémů pro telemetrii nebo nastavování politik. Istio zjednodušuje komplexitu mikroslužeb díky off-loadované jednotné správě propojení service-to-service. Sidecar proxy umožňují spravovat provoz, nastavovat bezpečná připojení a pracovat v souladu s prvky řídící roviny fungujícími v celém meshi. Load balancing, A/B testování, změny politik či obnovu po výpadku lze zvládnout díky nástroji Istio i bez účasti všech vývojářských týmů. Jedna řídící platforma znamená, že lze snadno aplikovat sety politik napříč všemi mikroslužbami.
Možná jste se dočetli o partnerství společností Cisco a Google v oblasti hybridního cloud (základní model společného řešení můžete vidět na obrázku). Náš tým se tak zapojil do projektu Istio a dle mého názoru bude Istio hrát klíčovou roli v oblasti hybridního computingu napříč veřejnými a privátními cloudu. A tak jako nabízí Kubernetes efektivní orchestraci kontejnerů, může být na Istio nahlíženo, že zajišťuje orchestraci síťování service-to-service a umožňuje tak lepší způsob, jak vyvíjet a nasazovat aplikace postavené na mikroslužbách v multicloudové éře.
Závěrem
Tímto dílem bych se s vámi rád rozloučil a doufám, že jsem vám pomohl blíže poznat alespoň základy ze světa technologie kontejnerů a nástroje Kubernetes. Pevně věřím, že konterjnerizované aplikace mají budoucnost, časem se s nimi setká každý z nás a postupně vytlačí tradiční monolitické aplikace.
Martin Diviš
Autor článku je systémový inženýr společnosti Cisco.
