Stateful vs Stantless Applications na Kubernetes
Zacznijmy od naiwnej definicji „bezpaństwowości”, a następnie powoli przejść do bardziej rygorystycznego i rzeczywistego poglądu.
Zastosowanie bezstanowe to taka, która zależy od braku trwałego przechowywania. Jedyną rzeczą, za którą jesteś odpowiedzialny, jest kod i inne treści statyczne, które są na nim hostowane. To wszystko, bez zmieniających się baz danych, bez zapisów i bez resztek plików po usunięciu kapsuły.
Z drugiej strony stanowy zastosowanie ma kilka innych parametrów, na które powinien opiekować się klastrem. Istnieją dynamiczne bazy danych, które nawet gdy aplikacja jest offline lub usunięta, utrzymują się na dysku. W systemie rozproszonym, takim jak Kubernetes, rodzi to kilka problemów. Przyjrzymy się im szczegółowo, ale najpierw wyjaśnijmy niektóre nieporozumienia.
Usługi bezpaństwowe nie są w rzeczywistości „bezpaństwowe”
Co to znaczy, gdy mówimy o stanie systemu? Cóż, rozważmy następujący prosty przykład automatycznych drzwi.
Drzwi otwierają się, gdy czujnik wykrywa kogoś, kto się zbliża, i zamyka się, gdy czujnik nie uzyska istotnego wejścia.
W praktyce Twoja bezpaństwowa aplikacja jest podobna do tego mechanizmu powyżej. Może mieć o wiele więcej stanów niż tylko zamknięte lub otwarte, a wiele różnych rodzajów danych wejściowych, a także czyniąc go bardziej złożonym, ale zasadniczo taki sam.
Może rozwiązać skomplikowane problemy, po prostu otrzymując dane wejściowe i wykonywanie działań, które zależą zarówno od wejścia, jak i „stanu”, w którym jest. Liczba możliwych stanów jest predefiniowana.
Więc bezpaństwowość jest myląca.
W praktyce aplikacje bezstanowe mogą również trochę oszukiwać, zapisując, powiedzmy, sesje klientów na samym kliencie (pliki cookie HTTP są doskonałym przykładem) i nadal mają niezłą bezpaństwowość, która sprawiłaby, że działałoby one bezbłędnie na klastrze.
Na przykład szczegóły sesji klienta, takie jak to, jakie produkty zostały zapisane w koszyku i nie sprawdzone, mogą być przechowywane na kliencie, a następnym razem, gdy rozpocznie się sesja, te istotne szczegóły zostaną również wspomnienia.
W klastrze Kubernetes aplikacja bezstronna nie ma z nim trwałego przechowywania ani woluminu. Z perspektywy operacyjnej jest to świetna wiadomość. Różne strąki w całym klastrze mogą działać niezależnie, a wiele żądań przybywa jednocześnie. Jeśli coś pójdzie nie tak, możesz po prostu ponownie uruchomić aplikację i wróci do stanu początkowego z niewielkim przestojem.
Usługi stanowe i twierdzenie o czapce
Z drugiej strony usługi stanowe będą musiały się martwić o wiele krawędzi i dziwnych problemów. Krące towarzyszy co najmniej jeden wolumin, a jeśli dane w tym tomie są uszkodzone.
Na przykład, jeśli uruchamiasz bazę danych w klastrze Kubernetes, wszystkie kapsuły muszą mieć lokalny wolumin do przechowywania bazy danych. Wszystkie dane muszą być w doskonałej synchronizacji.
Więc jeśli ktoś modyfikuje wpis do bazy danych, a to zostało zrobione na POD A, a żądanie odczytu pojawia się na POD B, aby zobaczyć te zmodyfikowane dane, wówczas POD B musi wyświetlać najnowsze dane lub podać komunikat o błędzie. Jest to znane jako spójność.
Konsystencja, w kontekście klastra Kubernetes, oznacza Każdy odczyt odbiera najnowszy zapis lub komunikat o błędzie.
Ale to się skupia dostępność, Jeden z najważniejszych powodów posiadania systemu rozproszonego. Dostępność implikuje, że aplikacja działa tak blisko perfekcji, jak oparcie, przez całą dobę, z tak niewielkim błędem, jak to możliwe.
Można argumentować, że możesz tego uniknąć, jeśli masz tylko jedną scentralizowaną bazę danych, która jest odpowiedzialna za zaspokojenie wszystkich trwałych potrzeb przechowywania. Teraz wróciliśmy do jednego punktu awarii, co jest kolejnym problemem, który klastry Kubernetes powinny rozwiązać przede wszystkim.
Musisz mieć zdecentralizowany sposób przechowywania trwałych danych w klastrze. Powszechnie określane jako partycjonowanie sieciowe. Ponadto twój klaster musi być w stanie przetrwać niepowodzenie węzłów uruchamiających stanową aplikację. To jest znane jako Tolerancja partycji.
Każda stanowa usługa (lub aplikacja), uruchamiana w klastrze Kubernetes, musi mieć równowagę między tymi trzema parametrami. W branży jest znane jako twierdzenie o CAP, w którym kompromisy między spójnością a dostępnością są rozważane w obecności partycjonowania sieciowego.
Dalsze odniesienia
Aby uzyskać dalszy wgląd w twierdzenie CAP, możesz zobaczyć tę doskonałą rozmowę Bryan Cantrill, który przygląda się znacznie uruchamianiu systemów rozproszonych w produkcji.