Zarządzanie systemami rozproszonymi może być trudne z powodu licznych zmieniających się elementów, które muszą działać poprawnie, aby zapewnić funkcjonalność systemu. Jeśli jeden z elementów ulegnie awarii, system musi go wykryć, obejść i naprawić, a wszystko to powinno odbywać się automatycznie. W tej serii „Najlepsze praktyki Kubernetes” dowiemy się, jak skonfigurować testy Readiness i Liveness do sprawdzania żywotności klastra Kubernetes.
Sprawdzanie stanu Health Check to prosty sposób informowania systemu, czy instancja twojej aplikacji działa, czy nie. Jeśli instancja twojej aplikacji jest wyłączona, inne usługi nie powinny do niej kierować zapytań ani dzwonić. Zamiast tego zapytanie powinno być kierowane do innej instancji aplikacji, która już działa lub zostanie uruchomiona później. Dodatkowo system powinien przywrócić twojej aplikacji utraconą dostępność.
Domyślnie Kubernetes zacznie kierować ruch do podu, gdy wszystkie kontenery wewnątrz podów będą uruchomione, a kontenery będą restartowane, gdy ulegną awarii. Takie domyślne zachowanie systemu może być wystarczające na początek, jednak możesz poprawić niezawodność wdrożenia swojego produktu, korzystając z niestandardowych kontroli dostępności.
Na szczęście, Kubernetes umożliwia to stosunkowo prosto, więc nie ma żadnego usprawiedliwienia dla ignorowania takich kontroli. Kubernetes oferuje dwa typy testów Health Check, a zrozumienie różnic w ich zastosowaniu jest istotne.
Test gotowości Readiness ma na celu informowanie Kubernetes o gotowości twojej aplikacji do obsługi ruchu. Zanim service pozwoli na przesyłanie ruchu do podu, Kubernetes musi upewnić się, że test gotowości został pomyślnie przeprowadzony. Jeśli test Readiness zakończy się niepowodzeniem, Kubernetes przestanie kierować ruch do podu, dopóki testowanie nie powiedzie się.
Test żywotności Liveness informuje Kubernetes, czy twoja aplikacja jest żywa, czy martwa. W pierwszym przypadku Kubernetes pozostawi ją w spokoju, w drugim usunie martwy pod i zastąpi go nowym.
Wyobraźmy sobie scenariusz, w którym uruchomienie i rozgrzewka Twojej aplikacji zajmują 1 minutę. Twój serwis nie zacznie działać, dopóki aplikacja całkowicie się nie załaduje i nie uruchomi, mimo że proces roboczy już się rozpoczął. Ponadto, napotkasz również problemy, jeśli zechcesz zwiększyć skalę tego wdrożenia do kilku kopii, ponieważ te kopie nie powinny otrzymywać ruchu, dopóki nie będą całkowicie gotowe. Jednak domyślnie Kubernetes natychmiast zacznie przesyłać ruch zaraz po rozpoczęciu procesów wewnątrz kontenera.
Podczas korzystania z testu gotowości Readiness, Kubernetes będzie czekać, aż aplikacja będzie całkowicie uruchomiona, a dopiero potem pozwoli serwisowi przesyłać ruch do nowej kopii.
Wyobraźmy sobie inny scenariusz, w którym aplikacja zawiesza się na dłuższy czas, przestając obsługiwać zapytania. Ponieważ proces nadal działa, domyślnie Kubernetes uzna, że wszystko jest w porządku, i będzie kontynuować przesyłanie zapytań do nie działającego poda. Jednak przy użyciu Liveness, Kubernetes wykryje, że aplikacja już nie obsługuje zapytań, i domyślnie zrestartuje niedziałający pod.
Rozważmy, czym testuje się gotowość i żywotność. Istnieją trzy sposoby testowania — HTTP, Command i TCP. Możesz użyć dowolnego z nich do weryfikacji. Najbardziej powszechnym sposobem testowania przez użytkowników jest probe HTTP.
Nawet jeśli Twoja aplikacja nie jest serwerem HTTP, nadal możesz stworzyć lekki serwer HTTP wewnątrz swojej aplikacji, aby współpracować z testem Liveness. Po tym Kubernetes zacznie pingować poda, a jeśli odpowiedź HTTP będzie w zakresie 200 lub 300 ms, oznacza to, że pod jest 'zdrowy'. W przeciwnym razie moduł zostanie oznaczony jako 'niedziałający'.
W przypadku testów za pomocą Command, Kubernetes wykonuje polecenie wewnątrz Twojego kontenera. Jeśli polecenie zwróci kod wyjścia równy zero, kontener zostanie oznaczony jako zdrowy, w przeciwnym razie, w przypadku otrzymania statusu wyjścia od 1 do 255, kontener zostanie oznaczony jako 'chory'. Ten sposób testowania jest przydatny, jeśli nie możesz lub nie chcesz uruchamiać serwera HTTP, ale jesteś w stanie uruchomić polecenie, które sprawdzi 'zdrowie' Twojej aplikacji.
Ostatnia metoda weryfikacji to test TCP. Kubernetes spróbuje nawiązać połączenie TCP na wskazanym porcie. Jeśli uda się to zrobić, kontener jest uznawany za zdrowy, a jeśli nie — za nieszczelny. Ten sposób może być przydatny, jeśli używasz skryptu, w którym testowanie za pomocą żądania HTTP lub wykonywania komendy nie działa zbyt dobrze. Na przykład, głównymi usługami do testowania za pomocą 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 sukcesu i porażki oraz jak długo czekać na odpowiedzi. Bardziej szczegółowe informacje znajdują się w dokumentacji dotyczącej testów Readiness i Liveness. Jest jednak jeden bardzo ważny aspekt konfiguracji testu Liveness — początkowe opóźnienie w teście initialDelaySeconds. Jak wspomniałem, nieudane wykonanie tego testu spowoduje ponowne uruchomienie modułu. Dlatego musisz upewnić się, że testowanie nie rozpocznie się, dopóki aplikacja nie będzie gotowa do pracy, w przeciwnym razie zacznie cyklicznie się uruchamiać. Zalecam użycie P99 czasu uruchomienia lub średniego czasu uruchomienia aplikacji z bufora. Pamiętaj, aby dostosować tę wartość w miarę jak czas uruchomienia Twojej aplikacji staje się coraz szybszy lub wolniejszy.
Większość specjalistów potwierdzi, że Health Check jest obowiązkową kontrolą dla każdego rozproszonego systemu, a Kubernetes nie jest wyjątkiem. Użycie weryfikacji „zdrowia” usług zapewnia niezawodne działanie Kubernetes i nie sprawia użytkownikom żadnego kłopotu.
Ciąg dalszy wkrótce…
Trochę reklamy 🙂
Dziękujemy, że jesteś z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej interesujących materiałów? Wspieraj nas składając zamówienie lub polecając nas znajomym, , unikatowy odpowiednik serwerów entry-level, który został stworzony przez nas dla Ciebie: (dostępne opcje z RAID1 i RAID10, do 24 rdzeni i do 40GB DDR4).
Dell R730xd dwa razy tańszy w centrum danych Equinix Tier IV w Amsterdamie? Tylko u nas w Holandii! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 dolarów! Czytaj o tym
Źródło: habr.com
