Zarządzanie systemami rozproszonymi może być trudne, ponieważ zawierają wiele ruchomych i zmieniających się elementów, z których wszystkie muszą działać prawidłowo, aby system mógł działać. Jeśli któryś z elementów ulegnie awarii, system musi to wykryć, ominąć i naprawić, a wszystko to musi odbywać się automatycznie. W tej serii najlepszych praktyk Kubernetes dowiemy się, jak skonfigurować testy gotowości i żywotności, aby sprawdzić kondycję klastra Kubernetes.
Kontrola stanu to prosty sposób na powiadomienie systemu, czy instancja aplikacji działa, czy nie. Jeśli instancja aplikacji nie działa, inne usługi nie powinny uzyskiwać do niej dostępu ani wysyłać do niej żądań. Zamiast tego żądanie musi zostać wysłane do innej instancji aplikacji, która już działa lub zostanie uruchomiona później. Dodatkowo system powinien przywrócić utraconą funkcjonalność Twojej aplikacji.
Domyślnie Kubernetes rozpocznie wysyłanie ruchu do poda, gdy wszystkie kontenery w obrębie podów będą działać, i ponownie uruchomi kontenery, gdy ulegną awarii. To domyślne zachowanie systemu może być wystarczające na początek, ale można poprawić niezawodność wdrażania produktu, korzystając z niestandardowych kontroli poprawności.
Na szczęście Kubernetes sprawia, że jest to dość łatwe, więc nie ma usprawiedliwienia, aby ignorować te kontrole. Kubernetes udostępnia dwa typy kontroli stanu i ważne jest, aby zrozumieć różnice w sposobie korzystania z każdego z nich.
Test gotowości ma na celu poinformowanie Kubernetesa, że Twoja aplikacja jest gotowa do obsługi ruchu. Przed zezwoleniem usłudze na wysyłanie ruchu do podu Kubernetes musi sprawdzić, czy sprawdzenie gotowości zakończyło się pomyślnie. Jeśli test gotowości zakończy się niepowodzeniem, Kubernetes przestanie wysyłać ruch do zasobnika do czasu zakończenia testu.
Test żywotności informuje Kubernetes, czy Twoja aplikacja działa, czy nie. W pierwszym przypadku Kubernetes zostawi go w spokoju, w drugim usunie martwego poda i zastąpi go nowym.
Wyobraźmy sobie scenariusz, w którym nagrzewanie i uruchamianie aplikacji zajmuje 1 minutę. Twoja usługa nie zacznie działać, dopóki aplikacja nie zostanie w pełni załadowana i uruchomiona, mimo że przepływ pracy już się rozpoczął. Problemy wystąpią również, jeśli chcesz skalować to wdrożenie do wielu kopii, ponieważ te kopie nie powinny odbierać ruchu, dopóki nie będą w pełni gotowe. Jednak domyślnie Kubernetes rozpocznie wysyłanie ruchu, gdy tylko rozpoczną się procesy wewnątrz kontenera.
Podczas korzystania z testu gotowości Kubernetes poczeka, aż aplikacja będzie w pełni uruchomiona, zanim zezwoli usłudze na wysłanie ruchu do nowej kopii.
Wyobraźmy sobie inny scenariusz, w którym aplikacja zawiesza się przez dłuższy czas, wstrzymując obsługę żądań. W miarę kontynuowania procesu Kubernetes domyślnie zakłada, że wszystko jest w porządku i kontynuuje wysyłanie żądań do niedziałającego poda. Jednak podczas korzystania z Liveness Kubernetes wykryje, że aplikacja nie obsługuje już żądań i domyślnie zrestartuje martwy pod.
Przyjrzyjmy się, jak testuje się gotowość i rentowność. Istnieją trzy metody testowania - HTTP, Command i TCP. Możesz użyć dowolnego z nich do sprawdzenia. Najczęstszym sposobem testowania użytkownika jest sonda HTTP.
Nawet jeśli Twoja aplikacja nie jest serwerem HTTP, nadal możesz utworzyć w niej lekki serwer HTTP, który będzie współdziałał z testem żywotności. Następnie Kubernetes rozpocznie pingowanie poda, a jeśli odpowiedź HTTP będzie mieściła się w zakresie 200 lub 300 ms, wskaże, że pod jest w dobrej kondycji. W przeciwnym razie moduł zostanie oznaczony jako „niezdrowy”.
W przypadku testów poleceń Kubernetes uruchamia polecenie w kontenerze. Jeżeli polecenie zwróci z zerowym kodem wyjścia, to kontener zostanie oznaczony jako zdrowy, w przeciwnym razie po otrzymaniu numeru statusu wyjścia od 1 do 255, kontener zostanie oznaczony jako „chory”. Ta metoda testowania jest przydatna, jeśli nie możesz lub nie chcesz uruchomić serwera HTTP, ale możesz uruchomić polecenie, które sprawdzi kondycję Twojej aplikacji.
Ostatnim mechanizmem weryfikacji jest test TCP. Kubernetes spróbuje nawiązać połączenie TCP na określonym porcie. Jeśli można to zrobić, pojemnik uważa się za zdrowy; jeśli nie, uważa się go za nieopłacalny. Ta metoda może być przydatna, jeśli używasz scenariusza, w którym testowanie za pomocą żądania HTTP lub wykonania polecenia nie działa zbyt dobrze. Na przykład głównymi usługami weryfikacji przy użyciu protokołu TCP będą gRPC lub FTP.
Testy można konfigurować na kilka sposobów z różnymi parametrami. Możesz określić, jak często mają być wykonywane, jakie są progi powodzenia i niepowodzenia oraz jak długo należy czekać na odpowiedzi. Więcej informacji można znaleźć w dokumentacji testów gotowości i żywotności. Jednakże przy konfigurowaniu testu Liveness jest jeden bardzo ważny punkt - początkowe ustawienie opóźnienia testowania originDelaySeconds. Jak wspomniałem, niepowodzenie tego testu będzie skutkowało ponownym uruchomieniem modułu. Musisz więc upewnić się, że testowanie nie rozpocznie się, dopóki aplikacja nie będzie gotowa do działania, w przeciwnym razie zacznie cyklicznie uruchamiać się ponownie. Polecam stosować czas uruchamiania P99 lub średni czas uruchamiania aplikacji z bufora. Pamiętaj o dostosowaniu tej wartości w miarę przyspieszania lub zwalniania czasu uruchamiania aplikacji.
Większość ekspertów potwierdzi, że kontrole stanu są obowiązkowym sprawdzeniem każdego systemu rozproszonego, a Kubernetes nie jest wyjątkiem. Korzystanie z kontroli kondycji usług zapewnia niezawodne, bezproblemowe działanie Kubernetes i nie wymaga wysiłku dla użytkowników.
Ciąg dalszy już wkrótce...
Kilka reklam 🙂
Dziękujemy za pobyt z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej ciekawych treści? Wesprzyj nas składając zamówienie lub polecając znajomym, , unikalny odpowiednik serwerów klasy podstawowej, który został przez nas wymyślony dla Ciebie: (dostępne z RAID1 i RAID10, do 24 rdzeni i do 40 GB DDR4).
Dell R730xd 2 razy taniej w centrum danych Equinix Tier IV w Amsterdamie? Tylko tutaj w Holandii! Dell R420 — 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gb/s 100 TB — od 99 USD! Czytać o
Źródło: www.habr.com