Kontejnerizace pracovních postupů vývoje, testování a produkčního provozu způsobuje revoluci v řízení IT na všech úrovních, ať už se jedná o aplikace a služby orientované na zákazníka nebo interní. Organizace dosahují efektivity vývoje a zkrácení doby nasazení používáním architektur založených na mikroslužbách postavených na kontejnerech a využíváním frameworků pro orchestraci kontejnerů, jako je Kubernetes.
Přechod od klasického IT k kontejnerovým přístupům často pramení z úsilí DevOps týmů nebo oddělení o vytvoření prototypového prostředí, které pak ostatní týmy replikují. I když to tyto týmy dělají za účelem zvýšení efektivity a flexibility, výsledkem jsou často izolovaná DevOps clustery, a tedy buď špatný výkon (nedostatek zdrojů), nebo špatné využití (zdroje nevyužité mimo špičku). Obvykle je to obojí; zatímco jeden tým je „pod vodou“ s ohledem na poptávku a nabídku zdrojů, ostatní týmy mohou mít k dispozici mnoho nečinných cyklů. Ještě horší je, že týmy často zajišťují nadměrné zřizování zdrojů, což vede k obrovským nákladům. Průmyslové standardy pro využití clusterů se často pohybují v rozmezí 20 %.
Konsolidace clusterů (nebo cloudových účtů) z mnoha do menšího počtu, ideálně do jednoho, a sdílení zdrojů mezi týmy a případy užití je receptem na zvýšení výkonu a výstupů a zároveň na snížení nákladů. Konsolidace a sdílení vám skutečně umožňuje dělat více s menšími prostředky – pokud se dokážete sdílet efektivně, automaticky a spravedlivě.
Současné frameworky pro orchestraci kontejnerů, jako jsou Kubernetes , Docker Swarm nebo Mesos, vám však neumožňují dosáhnout tohoto cíle ihned po instalaci. Kubernetes a Swarm poskytují zjednodušená schémata distribuce úloh, jako je „spread“ (round-robin), „pack“ nebo „random“, a jinak vyžadují ruční segmentaci zdrojů clusteru pomocí konceptů, jako jsou jmenné prostory nebo popisky. V Mesosu si různé typy úloh (např. Spark, Hadoop nebo služby pod Marathonem) přinášejí vlastní plánovač, který může, ale nemusí nabízet určité zásady sdílení zdrojů (s vlastní logikou a konfigurací), ale úlohy budou mezi sebou bojovat o přístup k zdrojům a neexistuje žádný zastřešující systém zásad, který by chápal, jaké úlohy jsou pro firmu nejdůležitější a jak uspokojit její potřeby, aniž by na ni bylo přetíženo množství zdrojů.
V netriviálních případech použití sdílení zdrojů bude každý z těchto systémů vyžadovat mnoho manuálních zásahů a bude buď vyžadovat nadměrné zřizování, nebo bude trpět dopady na výkon způsobenými konflikty zdrojů.
Pro sdílení fondu zdrojů napříč organizacemi a libovolnými typy (kontejnerizovaných, ale i nekontejnerizovaných) úloh je skutečně potřeba pokročilý systém politik, který rozumí charakteristikám úloh a obchodním prioritám, aby mohl automatizovat rozhodování o alokaci zdrojů a přerozdělovat zdroje na vyžádání, když se změní okrajové podmínky nebo požadavky.
Navops Command je v současnosti poměrně unikátním příkladem takové funkce. Rozšiřuje Kubernetes a přidává sofistikované, dynamické a na poptávku řízené zásady, které automatizují rozhodování o prioritizaci úloh a spotřebě zdrojů v daném okamžiku. Ve srovnání s jinými frameworky pro orchestraci kontejnerů poskytuje Kubernetes nejbohatší sadu produkčních silových funkcí pro spolehlivou správu úloh (například automatizované řadiče pro repliky, úlohy, nasazení, přijímání úloh atd.). S Navops Command nad Kubernetes můžete spouštět sestavení softwaru, automatizované testy a produkční nasazení několika aplikací a servisních prostředí ve stejném clusteru nebo cloudovém poolu. Úlohy DevOps a produkční služby mohou pocházet z více týmů a mají různou důležitost, která se může v průběhu dne měnit. Navops Command zajišťuje, že žádná ze souvisejících úloh si navzájem nepřekáží a zároveň plní požadavky.
Obrázek 1: Zásady Navops Command „Proporcionální sdílení“ automatizují sdílení zdrojů mezi skupinami, projekty a jednotlivci
S Navops Command je možné dosáhnout míry využití clusteru 80 % a dokonce i vyšší. Své výhody přináší i v rámci jednoho týmu, když spouštíte různé úkoly, jako je sestavení, testování a provoz, a ještě více výhod nabízí sdílení napříč týmy.
Navops Command demonstruje, co je potřeba k efektivnímu spouštění aplikací založených na mikroslužbách a dalších kontejnerizovaných úloh ve sdíleném prostředí (on-premise nebo cloudovém). V současné době je k dispozici pro jakýkoli typ distribuce Kubernetes a lze jej snadno otestovat, jak je popsáno zde.
O autorovi
Fritz Ferstl je v současnosti technickým ředitelem a ředitelem pro rozvoj obchodu v regionu EMEA ve společnosti Univa Corporation.
Fritz Ferstl přináší do společnosti Univa 20 let zkušeností v oblasti gridových a cloudových technologií a jako technický ředitel bude pomáhat s nastavováním technické vize a zároveň bude iniciovat strategické aliance. Fritz, dlouho považován za otce softwaru Grid Engine a jeho předchůdců Codine a GRD, vedl posledních 10 let softwarovou divizi Grid Engine v rámci společností Sun Microsystems a Oracle a posunul ji od nově vznikající technologie k nejrozšířenějšímu řešení pro správu pracovní zátěže v některých z nejnáročnějších prostředí datových center na planetě. Pod Fritzovým vedením byl software Grid Engine open source a vybudoval si živou komunitu.
Amazon