{"id":36706,"date":"2019-10-31T22:13:15","date_gmt":"2019-10-31T19:13:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs\/"},"modified":"2019-10-31T22:13:15","modified_gmt":"2019-10-31T19:13:15","slug":"kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs","title":{"rendered":"Jak priorytety pod’\u00f3w w Kubernetes spowodowa\u0142y przestoje w Grafana Labs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Przyp. t\u0142um.<\/b>: Przedstawiamy Pa\u0144stwu szczeg\u00f3\u0142y techniczne dotycz\u0105ce przyczyn niedawnego przestoju w pracy us\u0142ugi chmurowej obs\u0142ugiwanej przez tw\u00f3rc\u00f3w Grafana. To klasyczny przyk\u0142ad tego, jak nowa, wydawa\u0142oby si\u0119, niezwykle przydatna funkcjonalno\u015b\u0107, maj\u0105ca na celu popraw\u0119 jako\u015bci infrastruktury\u2026 mo\u017ce zaszkodzi\u0107, je\u015bli nie przewidzi si\u0119 wielu niuans\u00f3w jej zastosowania w warunkach produkcyjnych. To wspania\u0142e, gdy pojawiaj\u0105 si\u0119 takie materia\u0142y, pozwalaj\u0105ce uczy\u0107 si\u0119 nie tylko na swoich b\u0142\u0119dach. Szczeg\u00f3\u0142y \u2013 w t\u0142umaczeniu tego tekstu od wiceprezesa ds. produkt\u00f3w z Grafana Labs.<\/i><\/p>\n

\"Jak
\n
\nW pi\u0105tek, 19 lipca, us\u0142uga Hosted Prometheus w Grafana Cloud przesta\u0142a funkcjonowa\u0107 na oko\u0142o 30 minut. Przepraszam wszystkich klient\u00f3w, kt\u00f3rzy ucierpieli z powodu tego awarii. Naszym zadaniem jest dostarczanie odpowiednich narz\u0119dzi do monitorowania i rozumiemy, \u017ce ich niedost\u0119pno\u015b\u0107 utrudnia Pa\u0144stwa \u017cycie. Powa\u017cnie traktujemy ten incydent. W tym artykule wyja\u015bniamy, co si\u0119 wydarzy\u0142o, jak na to zareagowali\u015bmy i co robimy, aby podobna sytuacja nie mia\u0142a miejsca w przysz\u0142o\u015bci.<\/a><\/noindex><\/p>\n

T\u0142o<\/h2>\n

\nUs\u0142uga Grafana Cloud Hosted Prometheus oparta jest na Cortex<\/a><\/noindex> \u2014 projekcie CNCF, kt\u00f3rego celem jest stworzenie horyzontalnie skalowalnej, wysoko dost\u0119pnej, multi-tenantowej us\u0142ugi Prometheus. Architektura Cortex sk\u0142ada si\u0119 z zestawu odr\u0119bnych mikrous\u0142ug, z kt\u00f3rych ka\u017cda pe\u0142ni swoj\u0105 funkcj\u0119: replikacj\u0119, przechowywanie, zapytania itp. Cortex jest aktywnie rozwijany, regularnie zyskuje nowe mo\u017cliwo\u015bci i zwi\u0119ksza wydajno\u015b\u0107. Regularnie wdra\u017camy nowe wersje Cortex do klastr\u00f3w, aby klienci mogli korzysta\u0107 z tych usprawnie\u0144 \u2013 co wa\u017cne, Cortex mo\u017ce by\u0107 aktualizowany bez przestoj\u00f3w.<\/p>\n

Aby zrealizowa\u0107 aktualizacje bez przestoj\u00f3w, serwis Ingester Cortexa wymaga dodatkowej repliki Ingestera podczas procesu aktualizacji. (Przyp. t\u0142um.<\/b>: Ingester<\/a><\/noindex> \u2014 podstawowy sk\u0142adnik Cortexa. Jego zadaniem jest zbieranie sta\u0142ego strumienia pr\u00f3bek, grupowanie ich w chunk'i Prometheus i przechowywanie w bazach danych takich jak DynamoDB, BigTable czy Cassandra.<\/i> To pozwala starym Ingester'om przesy\u0142a\u0107 bie\u017c\u0105ce dane nowym Ingester'om. Nale\u017cy zauwa\u017cy\u0107, \u017ce Ingester'y s\u0105 wymagaj\u0105ce pod wzgl\u0119dem zasob\u00f3w. Do ich pracy potrzebne jest 4 rdzenie i 15 GB pami\u0119ci na pod, tj. 25% mocy procesora i pami\u0119ci maszyny bazowej w przypadku naszych klastr\u00f3w Kubernetes. Og\u00f3lnie mamy zazwyczaj znacznie wi\u0119cej niewykorzystanych zasob\u00f3w w klastrze, ni\u017c tylko 4 rdzenie i 15 GB pami\u0119ci, dlatego mo\u017cemy \u0142atwo uruchamia\u0107 te dodatkowe Ingester'y podczas aktualizacji.<\/p>\n

Jednak cz\u0119sto zdarza si\u0119, \u017ce podczas normalnej pracy \u017cadna z maszyn nie ma tych 25% niewykorzystanych zasob\u00f3w. Tak jakby\u015bmy nie d\u0105\u017cyli: CPU i pami\u0119\u0107 zawsze przydadz\u0105 si\u0119 do innych proces\u00f3w. Aby rozwi\u0105za\u0107 ten problem, postanowili\u015bmy skorzysta\u0107 z Priorytet\u00f3w Pod\u00f3w Kubernetes<\/a><\/noindex>. Pomys\u0142 polega na nadawaniu Ingester'om wy\u017cszego priorytetu ni\u017c innym (stateless) mikrous\u0142ugom. Kiedy potrzebujemy uruchomi\u0107 dodatkowego (N+1) Ingester'a, tymczasowo wypraszamy inne, mniejsze pody. Te pody s\u0105 przenoszone do wolnych zasob\u00f3w na innych maszynach, pozostawiaj\u0105c wystarczaj\u0105c\u0105 \"dziur\u0119\" do uruchomienia dodatkowego Ingester'a.<\/p>\n

W czwartek, 18 lipca, wdro\u017cyli\u015bmy cztery nowe poziomy priorytet\u00f3w w naszych klastrach: krytyczny<\/b>, wysoki<\/b>, \u015bredni<\/b> i niski<\/b>. By\u0142y testowane na wewn\u0119trznym klastrze bez ruchu klienta przez oko\u0142o tydzie\u0144. Domy\u015blnie pody bez przypisanego priorytetu otrzymywa\u0142y \u015bredni<\/b> priorytet, dla Ingester'\u00f3w ustalono klas\u0119 z wysokim<\/b> priorytetem. Krytyczny<\/b> zarezerwowany by\u0142 dla monitorowania (Prometheus, Alertmanager, node-exporter, kube-state-metrics itd.). Nasza konfiguracja jest otwarta, a wyci\u0105g PR mo\u017cna zobaczy\u0107 tutaj<\/a><\/noindex>.<\/p>\n

Awaria<\/h2>\n

\nW pi\u0105tek, 19 lipca, jeden z in\u017cynier\u00f3w uruchomi\u0142 nowy dedykowany klaster Cortex dla du\u017cego klienta. Konfiguracja tego klastra nie zawiera\u0142a nowych priorytet\u00f3w pod\u00f3w, dlatego wszystkim nowym podom przypisywano priorytet domy\u015blny \u2014 \u015bredni<\/b>.<\/p>\n

W klastrze Kubernetes zabrak\u0142o zasob\u00f3w dla nowego klastra Cortex, a istniej\u0105cy klaster produkcyjny Cortex nie zosta\u0142 zaktualizowany (Ingester'y pozosta\u0142y bez wysokiego<\/b> priorytetu). Poniewa\u017c Ingester'y nowego klastra mia\u0142y domy\u015blnie \u015bredni<\/b> priorytet, a istniej\u0105ce w produkcji pody dzia\u0142a\u0142y w og\u00f3le bez priorytetu, Ingester'y nowego klastra wypchn\u0119\u0142y Ingester'y istniej\u0105cego klastra produkcyjnego Cortex.<\/p>\n

ReplicaSet dla wypieraj\u0105cego Ingester'a w klastrze produkcyjnym wykry\u0142 wyparty pod i stworzy\u0142 nowy, aby utrzyma\u0107 zadan\u0105 liczb\u0119 kopii. Nowemu pod'owi domy\u015blnie przypisano \u015bredni<\/b> priorytet, przez co tak\u017ce \u201estary\u201d Ingester w produkcji straci\u0142 zasoby. Efektem by\u0142 proces lawinowy<\/b>, kt\u00f3ry doprowadzi\u0142 do wypierania wszystkich pod'\u00f3w z Ingester'a w klastrach produkcyjnych Cortex'a.<\/p>\n

Ingester'y przechowuj\u0105 stan (stateful) i trzymaj\u0105 dane z ostatnich 12 godzin. Dzi\u0119ki temu mo\u017cemy efektywniej je kompresowa\u0107 przed zapisaniem w d\u0142ugoterminowej pami\u0119ci. W tym celu Cortex przeprowadza shardowanie danych wed\u0142ug serii, u\u017cywaj\u0105c rozproszonej tablicy skr\u00f3t\u00f3w (Distributed Hash Table, DHT), i replikacji ka\u017cdej serii na trzech Ingester'ach z pomoc\u0105 kworumowej zgodno\u015bci w stylu Dynamo. Cortex nie zapisuje danych w Ingester'ach, kt\u00f3re s\u0105 wy\u0142\u0105czone. Tak wi\u0119c, gdy du\u017ca liczba Ingester'\u00f3w opuszcza DHT, Cortex nie mo\u017ce zapewni\u0107 wystarczaj\u0105cej replikacji zapis\u00f3w, a one \u201ewpadaj\u0105\u201d.<\/p>\n

Wykrywanie i eliminacja<\/h2>\n

\nNowe powiadomienia Prometheus oparte na \u201ebud\u017cecie b\u0142\u0119d\u00f3w\u201d (error-budget-based<\/i> \u2014 szczeg\u00f3\u0142y pojawi\u0105 si\u0119 w przysz\u0142ym artykule) zacz\u0119\u0142y bi\u0107 na alarm po 4 minutach od momentu rozpocz\u0119cia wy\u0142\u0105czenia. W ci\u0105gu nast\u0119pnych oko\u0142o pi\u0119ciu minut przeprowadzili\u015bmy diagnostyk\u0119 i zwi\u0119kszyli\u015bmy bazowy klaster Kubernetes, aby pomie\u015bci\u0107 zar\u00f3wno nowy, jak i istniej\u0105ce klastry produkcyjne.<\/p>\n

Jeszcze pi\u0119\u0107 minut p\u00f3\u017aniej stare Ingester'y pomy\u015blnie zapisa\u0142y swoje dane, a nowe si\u0119 uruchomi\u0142y, i klastry Cortex ponownie sta\u0142y si\u0119 dost\u0119pne.<\/p>\n

Kolejne 10 minut zaj\u0119\u0142o diagnostyk\u0119 i napraw\u0119 b\u0142\u0119d\u00f3w out-of-memory (OOM) od odwrotnych serwer\u00f3w proxy autoryzacji, znajduj\u0105cych si\u0119 przed Cortex. B\u0142\u0119dy OOM by\u0142y spowodowane dziesi\u0119ciokrotnym wzrostem QPS (jak przypuszczamy, z powodu nadmiernie agresywnych zapyta\u0144 z serwer\u00f3w Prometheus klienta).<\/p>\n

Skutki<\/h2>\n

\nCa\u0142kowity czas przestoju wyni\u00f3s\u0142 26 minut. Dane nie zosta\u0142y utracone. Ingester'y pomy\u015blnie za\u0142adowa\u0142y wszystkie dane w pami\u0119ci do d\u0142ugoterminowej pami\u0119ci. W trakcie wy\u0142\u0105czenia serwery Prometheus klient\u00f3w buforowa\u0142y zdalne (remote)<\/i> zapisy za pomoc\u0105 nowego API remote_write<\/a><\/noindex> opartego na WAL (autorstwa Callum Styan<\/a><\/noindex> z Grafana Labs) i powt\u00f3rzy\u0142y nieudane zapisy po awarii.<\/p>\n

\"Jak
\nOperacje zapisu klastra produkcyjnego<\/i><\/p>\n

Wnioski<\/h2>\n

\nWa\u017cne jest, aby wyci\u0105gn\u0105\u0107 wnioski z tego incydentu i podj\u0105\u0107 niezb\u0119dne kroki, aby unikn\u0105\u0107 jego powt\u00f3rzenia.<\/p>\n

Patrz\u0105c wstecz, nale\u017cy przyzna\u0107, \u017ce nie powinni\u015bmy domy\u015blnie ustala\u0107 \u015bredni<\/b> priorytetu, p\u00f3ki wszystkie Ingester'y w produkcji nie otrzyma\u0142y wysoki<\/b> priorytetu. Ponadto, nale\u017ca\u0142o wcze\u015bniej zatroszczy\u0107 si\u0119 o ich wysoki<\/b> priorytet. Teraz wszystko zosta\u0142o naprawione. Mamy nadziej\u0119, \u017ce nasze do\u015bwiadczenie pomo\u017ce innym organizacjom rozwa\u017caj\u0105cym wykorzystanie priorytet\u00f3w pod'\u00f3w w Kubernetes.<\/p>\n

Dodamy dodatkowy poziom kontroli nad wdra\u017caniem wszelkich dodatkowych obiekt\u00f3w, kt\u00f3rych konfiguracja jest globalna dla klastra. Od teraz takie zmiany b\u0119d\u0105 oceniane przezwi\u0119ksz\u0105<\/i>liczb\u0119 os\u00f3b. Ponadto, modyfikacja, kt\u00f3ra doprowadzi\u0142a do awarii, uwa\u017cana by\u0142a za zbyt nieznacz\u0105c\u0105, aby sporz\u0105dzi\u0107 oddzielny dokument projektowy \u2014 by\u0142a omawiana tylko w zg\u0142oszeniu GitHub. Od teraz wszystkie podobne zmiany w konfiguracjach b\u0119d\u0105 mia\u0142y odpowiedni\u0105 dokumentacj\u0119 projektow\u0105.<\/p>\n

W ko\u0144cu zautomatyzujemy zmiany rozmiaru serwera proxy odwrotnego dla uwierzytelniania, aby zapobiec OOM podczas przeci\u0105\u017cenia, czego byli\u015bmy \u015bwiadkami, oraz przeanalizujemy domy\u015blne parametry Prometheus zwi\u0105zane z wycofywaniem i skalowaniem, aby w przysz\u0142o\u015bci zapobiega\u0107 podobnym problemom.<\/p>\n

Do\u015bwiadczenie z awari\u0105 mia\u0142o r\u00f3wnie\u017c pozytywne skutki: uzyskuj\u0105c niezb\u0119dne zasoby, Cortex automatycznie si\u0119 odbudowa\u0142 bez dodatkowej interwencji. Otrzymali\u015bmy tak\u017ce cenne do\u015bwiadczenie pracy z Grafana Loki<\/a><\/noindex> \u2014 naszym nowym systemem agregacji log\u00f3w, \u2014 kt\u00f3ry pom\u00f3g\u0142 upewni\u0107 si\u0119, \u017ce wszystkie Ingester'y zachowa\u0142y si\u0119 prawid\u0142owo w trakcie i po awarii.<\/p>\n

P.S. od t\u0142umacza<\/h2>\n

\nPrzeczytaj tak\u017ce na naszym blogu:<\/p>\n