Omówienie zarządzania stanem na platformie Kubernetes

Ukończone

Mówiąc ogólnie o aplikacjach, często można usłyszeć o stanie aplikacji. W tej lekcji zapoznamy się z definicją stanu i różnymi typami stanów, aby lepiej przygotować aplikację do ich obsługi.

Stan

Stan aplikacji to wszystko, co jest przechowywane w pamięci przez czas, w którym działa ta aplikacja. Stan może obejmować różne elementy, ale skupiamy się głównie na danych użytkownika.

Dla pokazania przykładu stanu aplikacji, wyobraź sobie otwarty odtwarzacz muzyczny. Ta aplikacja ma stan. Wie, kim jesteś, czego lubisz słuchać i jaka muzyka została pobrana. Wszystkie te informacje są częścią stanu aplikacji.

Stan w pamięci to informacje, których aplikacja nie musi szukać w żadnym innym miejscu. Stan dysku zawiera informacje, które nie są dostępne w aplikacji, dlatego musi je pobrać z innego źródła danych.

Typy stanów

Rozróżniamy dwa typy stanów aplikacji. Pierwszym typem jest stan efemeryczny, który nie jest trwały i zniknie natychmiast po zamknięciu aplikacji.

Kontenery mają stan efemeryczny. Wszystkie przechowywane w nich dane zostaną natychmiast utracone po usunięciu kontenera. Niektóre aplikacje radzą sobie z tym same, ponieważ mogą odtwarzać stan z innych źródeł, zatem stan nie musi być przechowywany lokalnie. Aplikacje te są nazywane aplikacjami bezstanowymi (stateless).

Cały pozostały stan, który nie jest efemeryczny, jest nazywany stanem trwałym. Stan trwały nadal istnieje po cyklu życia kontenera. Większość używanych technologii kontenerów ma pojęcie woluminu , lokalizację na dysku, w której istnieje stan. Nawet jeśli usuniesz kontener i włączysz go ponownie, stan pozostanie przechowywany w bezpiecznej lokalizacji i może być używany ponownie.

Aplikacje, które bazują na pobieranym stanie zewnętrznym, są nazywane aplikacjami stanowymi (stateful).

Stany a platforma Kubernetes

Platforma Kubernetes może obsługiwać zarówno aplikacje bezstanowe, jak i stanowe. Aplikacje bezstanowe są łatwiejsze, ponieważ możemy skupić się tylko na samej aplikacji, a nie na jej stanie (ponieważ nie istnieje).

W przypadku większości aplikacji bezstanowych zwykłe obciążenie wdrożenia z zasobnika jest wystarczające, aby otrzymać w pełni funkcjonujący system i maksymalnie wykorzystać z możliwości klastra.

Obsługą aplikacji stanowych jest tego przeciwieństwem. W takich przypadkach należy wziąć pod uwagę aplikację i jej stan, miejsce przechowywania stanu oraz sposób bezpiecznego i niezawodnego przechowywania stanu.

Dlatego platforma Kubernetes stosuje również koncepcje PersistentVolumes (PV) i PersistentVolumeClaims (PVC).

Napiwek

W tym module nie omówiono jeszcze bardziej pojęć związanych z magazynem, ale możesz zapoznać się z zasobami usługi Azure Kubernetes Service w podsumowaniu, aby dowiedzieć się więcej.

Woluminy PersistentVolumes są dyskami przydzielonymi w węzłach do przechowywania stanów z kontenera zasobnika. Ponieważ platforma Kubernetes jest najbardziej odpowiednia dla aplikacji rozproszonych, wszystkie utworzone woluminy znajdują się w puli dostępnych woluminów. Następnie kontenery twierdzą, że miejsce dla siebie. Możesz użyć elementu PersistentVolumeClaims, aby powiązać element PersistentVolume z zasobnikiem i używać tego miejsca do przechowywania potrzebnych danych.

Wszyscy dostawcy baz danych to aplikacje stanowe. Jeśli wdrażasz dostawcę bazy danych w klastrze, potrzebujesz pv i PVC do przechowywania danych bazy danych w bezpiecznym miejscu i umożliwienia dostawcy pobierania tych danych, nawet jeśli jego kontenery zostały usunięte.

Najlepsze rozwiązania dotyczące obsługi stanu

Stan jest obecny w większości aplikacji. Jednak najlepszym rozwiązaniem w przypadku obsługi stanu jest nie zajmowanie się nim w ogóle.

Projektujesz dowolną wydajną aplikację, za cel obierając jej wysoką dostępność i skalowalność. Stan zmierza w przeciwnym kierunku. Pomimo opcji oferowanych przez dostawców magazynu i łatwość wdrażania i używania, stan nie jest łatwo skalowany. Nie jest również wysoce dostępny.

Stan o wysokiej dostępności

Aby zapewnić wysoką dostępność, aplikacja musi przez cały czas znajdować się w trybie online. Odbywa się to przy użyciu replikacji strefy i regionu. Platforma Kubernetes obsługuje strefy w większości obciążeń. Oznacza to, że może istnieć kilka wystąpień aplikacji wdrożonych w różnych strefach. Jednak dyski nie obsługują stref.

Podczas wdrażania nowego PersistentVolume obiektu na platformie Kubernetes jest on powiązany z dyskiem w węźle. Ten dysk jest również powiązany z określoną strefą w określonym regionie. Korzystanie z replikacji strefy lub regionu z woluminami VV jest złożone i wymaga dużej konserwacji, zarówno do replikowania, jak i synchronizowania danych.

Stan wysoce skalowalny

Aby zapewnić wysoką skalowalność, aplikacja powinna zwiększyć swoją przepływność wraz z liczbą użytkowników, którzy są z nią połączeni. W zarządzaniu stanami jest to skomplikowane, ponieważ każdy stan zewnętrzny to zasadniczo dysk, a dysk ma ograniczoną szybkość danych wejściowych i wyjściowych. Zarządzanie przepływnością pomaga rozwiązać ten problem.

Rozwiązania bazy danych pojawiły się z pomysłem ReplicaSets, który replikuje całą bazę danych do wielu wystąpień. Replikacja zwiększa liczbę dysków i we/wy dla stanu.

W każdej bazie danych zmiana stanu musi być zsynchronizowana, tak aby wszystkie dyski zawierały te same dane. Ta synchronizacja jest również złożona.

Zewnętrzne przechowywanie stanu

Platforma Azure ma rozwiązania typu "platforma jako usługa" (PaaS), takie jak Azure Cosmos DB, które są wysoce dostępne i skalowalne i rozwiązuje większość problemów z zarządzaniem stanem.

Przechowywanie stanu na zewnątrz i eliminacja potrzeb związanych z konserwacją ułatwia skoncentrowanie się na aplikacji i zmniejszenie nakładu pracy związanego z integralnością danych w infrastrukturze.

Sprawdź swoją wiedzę

1.

Jaki jest trwały stan aplikacji?

2.

W jaki sposób platforma Kubernetes obsługuje stany?

3.

Jakie jest najlepsze rozwiązanie obsługi stanu w aplikacjach platformy Kubernetes?