🥇Jak priorytety pod’ów w Kubernetes wpłynęły na przestoje w Grafana Labs

Przyp. tłum.: Przedstawiamy Państwu szczegóły techniczne dotyczące przyczyn niedawnego przestoju w pracy usługi chmurowej obsługiwanej przez twórców Grafana. To klasyczny przykład tego, jak nowa, wydawałoby się, niezwykle przydatna funkcjonalność, mająca na celu poprawę jakości infrastruktury… może zaszkodzić, jeśli nie przewidzi się wielu niuansów jej zastosowania w warunkach produkcyjnych. To wspaniałe, gdy pojawiają się takie materiały, pozwalające uczyć się nie tylko na swoich błędach. Szczegóły – w tłumaczeniu tego tekstu od wiceprezesa ds. produktów z Grafana Labs.

W piątek, 19 lipca, usługa Hosted Prometheus w Grafana Cloud przestała funkcjonować na około 30 minut. Przepraszam wszystkich klientów, którzy ucierpieli z powodu tego awarii. Naszym zadaniem jest dostarczanie odpowiednich narzędzi do monitorowania i rozumiemy, że ich niedostępność utrudnia Państwa życie. Poważnie traktujemy ten incydent. W tym artykule wyjaśniamy, co się wydarzyło, jak na to zareagowaliśmy i co robimy, aby podobna sytuacja nie miała miejsca w przyszłości.

Tło

Usługa Grafana Cloud Hosted Prometheus oparta jest na Cortex — projekcie CNCF, którego celem jest stworzenie horyzontalnie skalowalnej, wysoko dostępnej, multi-tenantowej usługi Prometheus. Architektura Cortex składa się z zestawu odrębnych mikrousług, z których każda pełni swoją funkcję: replikację, przechowywanie, zapytania itp. Cortex jest aktywnie rozwijany, regularnie zyskuje nowe możliwości i zwiększa wydajność. Regularnie wdrażamy nowe wersje Cortex do klastrów, aby klienci mogli korzystać z tych usprawnień – co ważne, Cortex może być aktualizowany bez przestojów.

Do bezbłędnych aktualizacji usługa Ingester Cortex wymaga dodatkowego replikatu Ingester podczas procesu aktualizacji. (Przyp. tłum.: Ingester — podstawowy komponent Cortex. Jego zadaniem jest gromadzenie ciągłego strumienia próbek, grupowanie ich w chunk’i Prometheus i zapisywanie w bazie danych takiej jak DynamoDB, BigTable lub Cassandra.) Pozwala to starym Ingesterom na przesyłanie bieżących danych do nowych Ingesterów. Należy zauważyć, że Ingestry są wymagające w kwestii zasobów. Do ich działania wymagane jest posiadanie 4 rdzeni i 15 GB pamięci na podzie, co stanowi 25% mocy procesora i pamięci maszyny bazowej w przypadku naszych klastrów Kubernetes. Ogólnie mamy zazwyczaj znacznie więcej niewykorzystanych zasobów w klastrze niż 4 rdzenie i 15 GB pamięci, dlatego możemy łatwo uruchamiać te dodatkowe Ingstery podczas aktualizacji.

Jednak często zdarza się, że podczas normalnej pracy żadna z maszyn nie ma tych 25% niewykorzystanych zasobów. Tak jakbyśmy nie dążyli: CPU i pamięć zawsze przydadzą się do innych procesów. Aby rozwiązać ten problem, postanowiliśmy skorzystać z Priorytetów Podów Kubernetes. Idea polega na nadawaniu Ingesterom wyższego priorytetu niż innym (stateless) mikroserwisom. Kiedy musimy uruchomić dodatkowego (N+1) Ingester, tymczasowo wypieramy inne, mniejsze pady. Te pady są przenoszone do dostępnych zasobów na innych maszynach, pozostawiając wystarczającą „dziurę” na uruchomienie dodatkowego Ingester.

W czwartek, 18 lipca, wdrożyliśmy cztery nowe poziomy priorytetów w naszych klastrach: krytyczny, wysoki, średni i niski. Były testowane na wewnętrznym klastrze bez ruchu klientów przez około tydzień. Domyślnie pady bez określonego priorytetu otrzymywały średni priorytet, dla Ingesterów ustalono klasę z wysokim priorytetem. Krytyczny zarezerwowany był dla monitorowania (Prometheus, Alertmanager, node-exporter, kube-state-metrics itd.). Nasza konfiguracja jest otwarta, a wyciąg PR można zobaczyć tutaj.

Awaria

W piątek, 19 lipca, jeden z inżynierów uruchomił nowy dedykowany klaster Cortex dla dużego klienta. Konfiguracja tego klastra nie obejmowała nowych priorytetów padów, więc wszystkim nowym padom nadawano priorytet domyślny — średni.

W klastrze Kubernetes zabrakło zasobów dla nowego klastra Cortex, a istniejący klaster produkcyjny Cortex nie został zaktualizowany (Ingstery pozostały bez wysokiego priorytetu). Ponieważ Ingstery nowego klastra domyślnie miały średni priorytet, a istniejące w produkcji pady działały w ogóle bez priorytetu, Ingstery nowego klastra wypchnęły Ingstera z istniejącego klastra produkcyjnego Cortex.

ReplicaSet dla wypchniętego Ingstera w klastrze produkcyjnym wykrył wypchnięty pod i stworzył nowy, aby utrzymać zadaną liczbę kopii. Nowemu podowi domyślnie przyznano średni priorytet, przez co także „stary” Ingester w produkcji stracił zasoby. Efektem był proces lawinowy, co doprowadziło do wypchnięcia wszystkich padów z Ingsterem dla klastrów produkcyjnych Cortex.

Ingester'y zachowują stan (stateful) i przechowują dane przez ostatnie 12 godzin. Umożliwia to skuteczniejsze ich kompresowanie przed zapisaniem w długoterminowym magazynie. Cortex realizuje partycjonowanie danych według serii, wykorzystując rozproszoną tablicę haseł (DHT) i replikuję każdą serię na trzech Ingester'ach z użyciem quorum consistency w stylu Dynamo. Cortex nie zapisuje danych w Ingester'ach, które są wyłączone. Gdy wiele Ingester'ów opuszcza DHT, Cortex nie może zapewnić wystarczającej replikacji zapisów, co prowadzi do ich "upadku".

Wykrywanie i eliminacja

Nowe powiadomienia Prometheus oparte na „budżecie błędów” (error-budget-based — szczegóły pojawią się w przyszłym artykule) zaczęły bić na alarm po 4 minutach od momentu rozpoczęcia wyłączenia. W ciągu następnych około pięciu minut przeprowadziliśmy diagnostykę i zwiększyliśmy bazowy klaster Kubernetes, aby pomieścić zarówno nowy, jak i istniejące klastry produkcyjne.

Jeszcze pięć minut później stare Ingester'y pomyślnie zapisały swoje dane, a nowe — uruchomiły się, a klastry Cortex znów stały się dostępne.

Kolejne 10 minut zajęło diagnostykę i naprawę błędów out-of-memory (OOM) od odwrotnych serwerów proxy autoryzacji, znajdujących się przed Cortex. Błędy OOM były spowodowane dziesięciokrotnym wzrostem QPS (jak przypuszczamy, z powodu nadmiernie agresywnych zapytań z serwerów Prometheus klienta).

Skutki

Całkowity czas przestoju wyniósł 26 minut. Dane nie zostały utracone. Ingester'y pomyślnie załadowały wszystkie dane in-memory do długoterminowego magazynu. Podczas wyłączenia serwery Prometheus klientów buforowały odległe (remote) zapisy za pomocą nowego API remote_write opartego na WAL (autorstwa Callum Styan z Grafana Labs) i powtórzyły nieudane zapisy po awarii.

Operacje zapisu klastra produkcyjnego

Wnioski

Ważne jest, aby wyciągnąć wnioski z tego incydentu i podjąć niezbędne kroki, aby uniknąć jego powtórzenia.

Patrząc wstecz, należy przyznać, że nie powinniśmy domyślnie ustalać średni priorytet, aż wszystkie Ingester'y w produkcji otrzymały wysoki priorytetu. Ponadto, należało wcześniej zatroszczyć się o ich wysoki priorytet. Teraz wszystko zostało naprawione. Mamy nadzieję, że nasze doświadczenie pomoże innym organizacjom rozważającym wykorzystanie priorytetów pod'ów w Kubernetes.

Dodamy dodatkowy poziom kontroli nad wdrażaniem wszelkich dodatkowych obiektów, których konfiguracja jest globalna dla klastra. Od teraz takie zmiany będą oceniane przezwiększąliczbę osób. Ponadto, modyfikacja, która doprowadziła do awarii, uważana była za zbyt nieznaczącą, aby sporządzić oddzielny dokument projektowy — była omawiana tylko w zgłoszeniu GitHub. Od teraz wszystkie podobne zmiany w konfiguracjach będą miały odpowiednią dokumentację projektową.

W końcu zautomatyzujemy zmiany rozmiaru serwera proxy odwrotnego dla uwierzytelniania, aby zapobiec OOM podczas przeciążenia, czego byliśmy świadkami, oraz przeanalizujemy domyślne parametry Prometheus związane z wycofywaniem i skalowaniem, aby w przyszłości zapobiegać podobnym problemom.

Doświadczenie z awarią miało również pozytywne skutki: uzyskując niezbędne zasoby, Cortex automatycznie się odbudował bez dodatkowej interwencji. Otrzymaliśmy także cenne doświadczenie pracy z Grafana Loki — naszym nowym systemem agregacji logów, — który pomógł upewnić się, że wszystkie Ingester'y odpowiednio zachowały się podczas i po awarii.