Phenquestions
Začněme s naivní definicí „bezdomovectví“ a poté pomalu přejdeme k přísnějšímu a reálnějšímu pohledu.
Bezstavová aplikace je aplikace, která závisí na žádném trvalém úložišti. Jediná věc, za kterou je váš cluster zodpovědný, je kód a další statický obsah, který je na něm hostován. To je ono, žádné změny databází, žádné zápisy a žádné zbylé soubory, když je modul odstraněn.
Stavová aplikace má na druhou stranu několik dalších parametrů, o které se má v klastru starat. Existují dynamické databáze, které, i když je aplikace offline nebo odstraněna, přetrvávají na disku. V distribuovaném systému, jako je Kubernetes, to vyvolává několik problémů. Podíváme se na ně podrobně, ale nejprve objasníme některé mylné představy.
Služby bez státní příslušnosti nejsou ve skutečnosti „bez státní příslušnosti“
Co to znamená, když řekneme stav systému? Zvažme následující jednoduchý příklad automatických dveří.
Dveře se otevřou, když senzor detekuje, že se někdo blíží, a zavřou se, jakmile senzor nedostane žádný relevantní vstup.
V praxi je vaše bezstavová aplikace podobná výše uvedenému mechanismu. Může mít mnohem více stavů, než jen uzavřený nebo otevřený, a také mnoho různých typů vstupu, takže je složitější, ale v zásadě stejný.
Může vyřešit komplikované problémy pouhým přijetím vstupu a provedením akcí, které závisí jak na vstupu, tak na „stavu“, ve kterém se nachází. Počet možných stavů je předdefinován.
Bezdomovectví je tedy nesprávné pojmenování.
Bezstavové aplikace v praxi mohou také trochu podvádět tím, že ukládají podrobnosti například o relacích klienta na samotném klientovi (skvělým příkladem jsou soubory cookie HTTP) a stále mají pěknou bezstavovost, díky které by bezchybně fungovaly v klastru.
Například podrobnosti o relaci klienta, například jaké produkty byly uloženy v košíku a nebyly rezervovány, lze na klienta uložit všechny a při příštím zahájení relace se tyto relevantní podrobnosti také vzpomínají.
V klastru Kubernetes nemá aplikace bez státní příslušnosti k ní přidružené žádné trvalé úložiště nebo svazek. Z hlediska provozu je to skvělá zpráva. Různé pody v celém klastru mohou pracovat samostatně s více požadavky, které jim přicházejí současně. Pokud se něco pokazí, stačí aplikaci restartovat a vrátí se do původního stavu s malými prostoji.
Stavové služby a věta o SZP
Stavové služby se na druhé straně budou muset starat o spoustu a spoustu okrajových případů a podivných problémů. Pod je doprovázen alespoň jedním svazkem a pokud jsou data v tomto svazku poškozena, pak to přetrvává, i když se celý cluster restartuje.
Například pokud používáte databázi v klastru Kubernetes, všechny pody musí mít místní svazek pro ukládání databáze. Všechna data musí být v dokonalé synchronizaci.
Takže pokud někdo upraví záznam do databáze, a to bylo provedeno na pod A, a na pod B se objeví požadavek na čtení, aby se zobrazila tato upravená data, pak pod B musí ukázat ta nejnovější data nebo vám dát chybovou zprávu. Toto se nazývá konzistence.
Konzistence, v kontextu klastru Kubernetes znamená každé čtení obdrží nejnovější zápis nebo chybovou zprávu.
Ale to je proti dostupnost, jedním z nejdůležitějších důvodů pro distribuovaný systém. Dostupnost znamená, že vaše aplikace funguje co možná nejblíže k dokonalosti, nepřetržitě a s co nejmenší možnou chybou.
Jeden může namítnout, že se tomu můžete vyhnout, pokud máte jen jednu centralizovanou databázi, která je zodpovědná za zpracování všech potřeb trvalého úložiště. Nyní se vracíme k jedinému bodu selhání, což je další problém, který mají klastry Kubernetes řešit.
Musíte mít decentralizovaný způsob ukládání trvalých dat v klastru. Běžně se označuje jako síťové dělení. Kromě toho musí být váš cluster schopen přežít selhání uzlů se spuštěnou stavovou aplikací. Toto je známé jako tolerance rozdělení.
Jakákoli stavová služba (nebo aplikace) spuštěná v klastru Kubernetes musí mít rovnováhu mezi těmito třemi parametry. V tomto odvětví je známá jako věta CAP, kde jsou kompromisy mezi konzistencí a dostupností považovány za přítomnosti síťového dělení.
Další odkazy
Pro další nahlédnutí do věty CAP si možná budete chtít prohlédnout tuto vynikající přednášku Bryana Cantrilla, který se mnohem blíže podívá na běh distribuovaných systémů ve výrobě.
