Ważnym elementem pracy systemów rozproszonych jest radzenie sobie z awariami. Kubernetes wspiera to, wykorzystując kontrolery, które monitorują stan twojego systemu i ponownie uruchamiają usługi, które przestały działać. Jednak Kubernetes może również wymuszać zatrzymanie pracy twoich aplikacji, aby zapewnić ogólną żywotność systemu. W tej serii przyjrzymy się, jak można wspomóc Kubernetes w efektywniejszym działaniu i skracaniu czasu przestojów aplikacji.
Przed wprowadzeniem kontenerów większość aplikacji działała na maszynach wirtualnych lub fizycznych. Jeśli aplikacja doświadczyła awarii lub zawieszenia, potrzebowano wiele czasu, aby zakończyć wykonywaną operację i ponownie załadować program. W najgorszym przypadku ktoś musiał rozwiązywać ten problem ręcznie w nocy, w najdogodniejszym czasie. Jeśli ważne zadanie realizowały tylko 1-2 maszyny robocze, taka awaria była całkowicie nieakceptowalna.
Dlatego zamiast ręcznego ponownego uruchamiania zaczęto stosować monitoring na poziomie procesów do automatycznego ponownego uruchamiania aplikacji w przypadku jej nagłego zakończenia. Jeśli program uległ awarii, proces monitorujący przechwytuje kod wyjścia i ponownie uruchamia serwer. Dzięki takim systemom jak Kubernetes, ten rodzaj reakcji na awarie został po prostu zintegrowany z infrastrukturą.
Kubernetes wykorzystuje pętlę zdarzeń 'obserwacja - zapis różnic - podjęcie działania', aby upewnić się, że zasoby pozostają operacyjne w drodze z kontenerów do samych węzłów.
Oznacza to, że nie musisz już ręcznie uruchamiać monitorowania procesów. Jeśli zasób nie przeszedł kontroli zdrowia (Health Check), Kubernetes po prostu automatycznie zapewni jego zastępstwo. Przy tym Kubernetes robi znacznie więcej niż tylko monitoruje awarie twoich aplikacji. Może tworzyć więcej kopii aplikacji do pracy na wielu maszynach, aktualizować aplikację lub uruchamiać równocześnie kilka wersji twojej aplikacji.
Istnieje wiele powodów, dla których Kubernetes może przerwać działanie zupełnie zdrowego kontenera. Na przykład, gdy aktualizujesz swoje wdrożenie, Kubernetes powoli zatrzymuje stare pody, jednocześnie uruchamiając nowe. Jeśli wyłączasz węzeł, Kubernetes zatrzyma wszystkie pody na tym węźle. Na koniec, jeśli węzeł zabraknie zasobów, Kubernetes wyłączy wszystkie pody, aby zwolnić te zasoby.
Dlatego bardzo ważne jest, aby Twoja aplikacja przerywała działanie z minimalnym wpływem na użytkownika końcowego i minimalnym czasem przywracania. Oznacza to, że przed wyłączeniem powinna zachować wszystkie dane, które musi, zamknąć wszystkie połączenia sieciowe, zakończyć pozostałe zadania i zdążyć wykonać inne pilne zadania.
W praktyce oznacza to, że Twoja aplikacja powinna być w stanie obsłużyć komunikat SIGTERM – sygnał zakończenia procesu, który jest domyślnym sygnałem dla narzędzia kill w systemach operacyjnych z rodziny Unix. Po otrzymaniu tego komunikatu aplikacja powinna się wyłączyć.
Po tym, jak Kubernetes zdecyduje się na zakończenie poda, zachodzi szereg zdarzeń. Przyjrzyjmy się każdemu krokowi, który podejmuje Kubernetes, gdy zamyka kontener lub pod.
Załóżmy, że chcemy zakończyć jeden z podów. W tym momencie przestanie on otrzymywać nowy ruch – działające w podzie kontenery nie będą dotknięte, ale cały nowy ruch zostanie zablokowany.
Przyjrzyjmy się hakowi preStop – to specjalne polecenie lub żądanie HTTP, które jest wysyłane do kontenerów w podzie. Jeśli Twoja aplikacja przy otrzymaniu SIGTERM wyłącza się niepoprawnie, możesz użyć preStop do prawidłowego zakończenia.
Większość programów poprawnie kończy działanie po otrzymaniu sygnału SIGTERM, ale jeśli korzystasz z zewnętrznego kodu lub systemu, którego nie możesz w pełni kontrolować, hak preStop jest doskonałym sposobem na wywołanie eleganckiego wyłączenia bez modyfikacji aplikacji.
Po wykonaniu tego haka Kubernetes wyśle do kontenerów w podzie sygnał SIGTERM, który poinformuje je, że wkrótce zostaną wyłączone. Po otrzymaniu tego sygnału twój kod przejdzie do procesu wyłączania. Proces ten może obejmować zatrzymanie wszelkich długoterminowych połączeń, takich jak połączenia z bazą danych czy strumienie WebSocket, zapisanie bieżącego stanu i tym podobne.
Nawet jeśli używasz haka preStop, niezwykle ważne jest, aby sprawdzić, co dokładnie dzieje się z twoją aplikacją, gdy wysyłasz jej sygnał SIGTERM, jak się zachowuje, aby zdarzenia lub zmiany w działaniu systemu spowodowane wyłączeniem poda nie stały się dla ciebie zaskoczeniem.
W tym momencie, zanim podejmiesz dalsze kroki, Kubernetes będzie czekał przez określony czas, zwany terminationGracePeriodSecond, czyli okresem na poprawne wyłączenie po otrzymaniu sygnału SIGTERM.
Domyślnie ten okres wynosi 30 sekund. Ważne jest, aby zauważyć, że trwa równolegle z hakiem preStop i sygnałem SIGTERM. Kubernetes nie będzie czekał, aż zakończy się hak preStop i sygnał SIGTERM — jeśli twoja aplikacja zakończy działanie przed końcem okresu terminationGracePeriod, Kubernetes natychmiast przejdzie do następnego kroku. Dlatego upewnij się, że wartość tego okresu w sekundach jest nie mniejsza niż czas wymagany do poprawnego wyłączenia poda, a jeśli przekracza 30 s, zwiększ ten okres do potrzebnej wielkości w YAML. W podanym przykładzie wynosi on 60 s.
I w końcu, ostatni krok — jeśli kontenery wciąż działają po upływie terminationGracePeriod, wysyłają sygnał SIGKILL i są wymuszane do usunięcia. W tym momencie Kubernetes również wyczyści wszystkie inne obiekty poda.
Kubernetes wyłącza pody z wielu powodów, dlatego upewnij się, że w każdym przypadku twoja aplikacja zakończy działanie poprawnie, aby zapewnić stabilne działanie usługi.
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
