Docker Compose, nebo Kubernetes: více paměti nezaručí rychlost

Pro malou službu na jediném serveru, která snese krátké přerušení při nasazení a obnovu po poruše stroje, obvykle stačí Docker Compose. Kubernetes začíná dávat smysl, pokud služba potřebuje sledované postupné nasazování, repliky rozložené mezi uzly a provoz i po ztrátě jednoho z nich.

Rozhodnutí neurčuje počet kontejnerů, ale požadovaná dostupnost, postup návratu verze, umístění dat a schopnost týmu spravovat další platformu. Vyšší spotřeba paměti při nasazení přes Kubernetes sama rychlejší odpověď aplikace nezaručuje; výkon je třeba oddělit od funkcí orchestrace.

Co pokryje Compose na jediném serveru

Produkční postup Dockeru popisuje jediný server jako nejjednodušší cestu k nasazení aplikace s Compose. Doporučuje samostatný soubor pro produkční odchylky, například jiné porty, proměnné prostředí nebo odstranění vazby na zdrojový kód uložený na hostiteli. Uvádí také politiku restartu a příkazy, které při aktualizaci znovu vytvoří jen změněnou službu bez obnovování jejích závislostí.

Takový model dobře sedí webové aplikaci, databázi a pomocným procesům, pokud se vejdou na jeden spravovaný stroj. Služby a jejich závislosti má správce vyjádřené v konfiguraci a může aplikaci vydávat bez přestavby celé sestavy. Výměna běžícího kontejneru však může přerušit požadavky, pokud za ním není připravená další instance a směrování provozu. Compose samo za tým neurčí, kdy nová verze skutečně přijímá provoz.

Politika restartu pomůže po ukončení kontejneru, nikoli po ztrátě hostitelského stroje nebo jeho disku. Proto je u jednoduchého nasazení podstatné určit, odkud se obnoví databáze, konfigurace a obraz aplikace a jak dlouho to smí trvat. Přijatelný čas obnovy je pro volbu platformy užitečnější údaj než samotný počet služeb v souboru.

Kdy má řízený rollout skutečnou hodnotu

Kubernetes Deployment postupně nahrazuje repliku služby, zatímco další repliky zůstávají dostupné.

Dokumentace Kubernetes k Deploymentu popisuje postupné nahrazování podů novými, sledování průběhu nasazení a návrat k dřívější revizi. Řadič průběžně přibližuje běžící stav požadovanému počtu replik. Pokud se rollout zastaví, jeho stav lze zjistit; samotné zjištění chyby však nespouští automaticky návrat na starou verzi.

To pomáhá týmu, který vydává často a potřebuje držet část replik v provozu, zatímco se mění ostatní. Musí však mít kapacitu pro souběh staré a nové verze, správně nastavené ověřování připravenosti a cestu, která posílá požadavky jen funkčním instancím. Řízená výměna podů tedy vytváří podmínky pro plynulé nasazení, ale sama nepřekoná nekompatibilní změnu databáze ani chybu, kterou kontrola připravenosti neodhalí.

Compose dovoluje návrat starého obrazu a automatizaci vydávání vlastními nástroji. Rozdíl spočívá v tom, kolik řízení nasazení už platforma poskytuje a kolik musí tým napsat a udržovat sám. Pokud krátká plánovaná odstávka nevadí, nemusí historie revizí a průběžné řízení replik vyvážit práci se správou clusteru.

Výpadek uzlu rozhoduje jinak než pád procesu

Dokumentace uzlů Kubernetes vysvětluje, že pody běží na uzlech a cluster může mít i jediný uzel. Repliky umístěné na stejném stroji mohou zvýšit odolnost proti pádu procesu, ale společný výpadek stroje nepřežijí. Požadavek pokračovat v provozu při ztrátě uzlu proto znamená také další dostupný uzel a vhodné rozmístění replik.

Výpočetní část je jen polovina tohoto rozhodnutí. Pokud aplikace spoléhá na databázi nebo soubory dostupné pouze na porouchaném stroji, spuštění dalšího podu na jiném uzlu službu neobnoví do použitelného stavu. Tým musí vyřešit dostupnost dat, přístup klientů k přeživším replikám a obnovu konfigurace; žádná z těchto podmínek se nesplní samotnou instalací Kubernetes.

U projektu, který přijme obnovu ze zálohy během sjednaného času, může být jeden server s Compose přiměřený. U služby s požadavkem na pokračování během poruchy je třeba posuzovat celou víceuzlovou architekturu včetně dat. Platforma je v takovém případě prostředek k řízení replik, nikoli náhrada plánu obnovy.

Proč naměřená paměť nepředpovídá latenci

Měření služby pro správu identity ukazuje vyšší paměťovou náročnost v Kubernetes při téměř stejné době ověření jako v Docker Compose.

Cochakova diplomová práce uvádí při vydávání tokenu DVID pro aplikační komponentu Subject-WL průměrnou spotřebu 26,16 MB v Compose a 35,91 MB v Kubernetes; celá operace trvala v těchto prostředích průměrně 59,35 a 63,98 ms. V této konkrétní zátěži tedy vyšší paměť aplikační komponenty nedoprovázela kratší doba dokončení požadavku.

Srovnání stavělo kontejnery Compose spuštěné přímo na hostiteli proti jednouzlovému Minikube, který běžel na stejném fyzickém stroji. Naměřený rozdíl patří této kombinaci aplikačních částí, síťových cest a způsobu nasazení. Čísla nevyjadřují celkovou paměť potřebnou pro provoz libovolného clusteru a nepřepočítávají se na každou běžnou webovou službu.

Při ověřování tokenů se latence mezi prostředími v některých režimech lišila jen málo, v jiném se více projevilo opakované navazování zabezpečeného spojení. Rozptyly části měření se překrývaly. Z výsledků proto neplyne obecné prvenství jedné platformy v rychlosti: při posuzování vlastní aplikace je třeba sledovat její skutečné požadavky, souběh, síťové závislosti a odezvu při zatížení.

Rozhodovací strom pro malou službu

Volbu lze zúžit podle provozních požadavků, které by změna platformy skutečně řešila:

Stačí jeden server a je přijatelná krátká pauza při nasazení i obnova po jeho poruše? Compose je přirozený výchozí bod; určete zálohy, obnovu a postup návratu obrazu.
Musí služba během vydání dál obsluhovat požadavky a tým potřebuje sledovaný rollout s historií revizí? Kubernetes má pro tuto práci zabudovaný Deployment; hodnotu mu dává až použití více připravených replik.
Musí služba přežít výpadek celého stroje? Přidejte další uzly, rozložte repliky a vyřešte dostupnost dat i směrování provozu. Jednouzlový cluster požadavek nesplní.
Má tým kapacitu spravovat cluster, jeho aktualizace, síť a diagnostiku? Pokud ne, započtěte tuto práci do ceny rozhodnutí stejně jako výpočetní prostředky; jednodušší nasazení může být spolehlivější volbou pro službu s mírnějšími nároky.

Praktická hranice tedy neleží na pevném počtu kontejnerů. Leží v okamžiku, kdy požadované nasazování a odolnost potřebují řízené repliky na více uzlech a tým je dokáže udržet v chodu. O rychlosti potom rozhodnou vlastnosti aplikace a jejího provozu, nikoli samotný název orchestrátoru.

Přečtěte si také: