Kā Kubernetes prioritāŔu noteikŔana izraisīja dīkstāvi Grafana Labs

PiezÄ«me. tulk.: Mēs piedāvājam jÅ«su uzmanÄ«bai tehnisko informāciju par nesenās dÄ«kstāves iemesliem mākoņpakalpojumā, ko uztur Grafana veidotāji. Å is ir klasisks piemērs tam, kā jauna un Ŕķietami ārkārtÄ«gi noderÄ«ga funkcija, kas paredzēta infrastruktÅ«ras kvalitātes uzlaboÅ”anai... var nodarÄ«t ļaunumu, ja neparedz neskaitāmās nianses tās pielietoÅ”anā ražoÅ”anas realitātē. Ir lieliski, ja parādās Ŕādi materiāli, kas ļauj mācÄ«ties ne tikai no kļūdām. SÄ«kāka informācija ir Ŕī teksta tulkojumā no Grafana Labs produkta viceprezidenta.

Kā Kubernetes prioritāŔu noteikŔana izraisīja dīkstāvi Grafana Labs

Piektdien, 19. jÅ«lijā, Hosted Prometheus pakalpojums Grafana Cloud pārtrauca darboties aptuveni uz 30 minÅ«tēm. Atvainojos visiem klientiem, kurus skāris pārtraukums. MÅ«su uzdevums ir nodroÅ”ināt jums nepiecieÅ”amos uzraudzÄ«bas rÄ«kus, un mēs saprotam, ka to trÅ«kums var padarÄ«t jÅ«su dzÄ«vi grÅ«tāku. Mēs Å”o incidentu uztveram ārkārtÄ«gi nopietni. Å ajā piezÄ«mē ir paskaidrots, kas notika, kā mēs reaģējām un ko mēs darām, lai nodroÅ”inātu, ka tas neatkārtojas.

Aizvēsture

Grafana Cloud Hosted Prometheus pakalpojums ir balstÄ«ts uz Smadzeņu garoza ā€” CNCF projekts, lai izveidotu horizontāli mērogojamu, ļoti pieejamu, vairāku nomnieku Prometheus pakalpojumu. Cortex arhitektÅ«ra sastāv no atseviŔķu mikropakalpojumu kopuma, no kuriem katrs veic savu funkciju: replikācija, glabāŔana, vaicājumi utt. Cortex tiek aktÄ«vi izstrādāts, un tas pastāvÄ«gi pievieno jaunas funkcijas un uzlabo veiktspēju. Mēs regulāri izvietojam jaunus Cortex laidienus klasteros, lai klienti varētu izmantot Ŕīs funkcijas ā€” par laimi, Cortex var atjaunināt bez dÄ«kstāves.

Lai nodroÅ”inātu nevainojamus atjauninājumus, pakalpojumam Ingester Cortex ir nepiecieÅ”ama papildu Ingester kopija atjaunināŔanas procesa laikā. (PiezÄ«me. tulk.: Ingester - Cortex pamatkomponents. Tās uzdevums ir savākt pastāvÄ«gu paraugu straumi, grupēt tos Prometheus gabalos un uzglabāt datu bāzē, piemēram, DynamoDB, BigTable vai Cassandra.) Tas ļauj vecajiem Ingesteriem pārsÅ«tÄ«t paÅ”reizējos datus jaunajiem Ingesteriem. Ir vērts atzÄ«mēt, ka Ingesteri ir resursietilpÄ«gi. Lai tie darbotos, jums ir jābÅ«t 4 kodoliem un 15 GB atmiņai katrā podā, t.i. 25% no bāzes iekārtas apstrādes jaudas un atmiņas mÅ«su Kubernetes klasteru gadÄ«jumā. Kopumā mums parasti klasterÄ« ir daudz vairāk neizmantoto resursu nekā 4 kodoli un 15 GB atmiņa, tāpēc jaunināŔanas laikā mēs varam viegli izveidot Å”os papildu resursus.

Taču nereti gadās, ka normālas darbÄ«bas laikā nevienai no maŔīnām nav Å”o 25% neizmantoto resursu. Jā, mēs pat necenÅ”amies: CPU un atmiņa vienmēr noderēs citiem procesiem. Lai atrisinātu Å”o problēmu, mēs nolēmām izmantot Kubernetes Pod prioritātes. Ideja ir pieŔķirt Ingesteriem augstāku prioritāti nekā citiem (bezvalstniekiem) mikropakalpojumiem. Kad mums ir nepiecieÅ”ams palaist papildu (N+1) Ingester, mēs Ä«slaicÄ«gi izspiežam citus, mazākus pākstis. Å ie podi tiek pārsÅ«tÄ«ti uz brÄ«vajiem resursiem citās iekārtās, atstājot pietiekami lielu ā€œcaurumuā€, lai darbinātu papildu Ingester.

Ceturtdien, 18. jÅ«lijā, mēs saviem klasteriem ieviesām četrus jaunus prioritāŔu lÄ«meņus: kritiski, augsts, vidēja Šø zems. Tie tika pārbaudÄ«ti iekŔējā klasterÄ« bez klientu trafika aptuveni vienu nedēļu. Pēc noklusējuma tiek saņemti podi bez noteiktas prioritātes vidēja prioritāte, klase tika noteikta Ingesteram ar augstu prioritāte. Kritisks tika rezervēts uzraudzÄ«bai (Prometheus, Alertmanager, mezglu eksportētājs, kube-state-metrics utt.). MÅ«su konfigurācija ir atvērta, un jÅ«s varat skatÄ«t PR Å”eit.

Nelaimes gadījums

Piektdien, 19. jÅ«lijā, viens no inženieriem palaida jaunu specializētu Cortex klasteru lielam klientam. Å Ä« klastera konfigurācijā nebija iekļautas jaunas aplikumu prioritātes, tāpēc visām jaunajām aplikācijām tika pieŔķirta noklusējuma prioritāte - vidēja.

Kubernetes klasterim nepietika resursu jaunajam Cortex klasterim, un esoÅ”ais ražoÅ”anas Cortex klasteris netika atjaunināts (Ingesters palika bez augsts prioritāte). Tā kā jaunā klastera Ingesters pēc noklusējuma bija vidēja prioritāti, un esoÅ”ie pāksti ražoÅ”anā darbojās bez prioritātes vispār, jaunā klastera Ingesteri nomainÄ«ja Ingesterus no esoŔā Cortex ražoÅ”anas klastera.

ReplicaSet izliktajam Ingesteram ražoÅ”anas klasterÄ« konstatēja izlikto aplikumu un izveidoja jaunu, lai saglabātu norādÄ«to kopiju skaitu. Jaunais pods tika pieŔķirts pēc noklusējuma vidēja prioritāte, un kārtējais ā€œvecaisā€ Ingesters ražoÅ”anā zaudēja savus resursus. Rezultāts bija lavÄ«nas process, kas noveda pie visu pākstÄ«m no Ingester Cortex ražoÅ”anas klasteriem.

IevadÄ«tāji ir statusa dati un glabā datus par iepriekŔējām 12 stundām. Tas ļauj mums tos efektÄ«vāk saspiest pirms to ierakstÄ«Å”anas ilgtermiņa glabāŔanā. Lai to panāktu, Cortex sadala datus visās sērijās, izmantojot sadalÄ«to hash tabulu (DHT), un atkārto katru sēriju trijos Ingesteros, izmantojot Dinamo stila kvoruma konsekvenci. Cortex neieraksta datus Ingesteriem, kas ir atspējoti. Tādējādi, kad liels skaits ingesteru atstāj DHT, Cortex nevar nodroÅ”ināt pietiekamu ierakstu replikāciju, un tie avarē.

AtklāŔana un sanācija

Jauni Prometheus paziņojumi, pamatojoties uz "kļūdu budžetu" (kļūdu budžeta pamatā ā€” sÄ«kāka informācija tiks parādÄ«ta nākamajā rakstā) sāka atskanēt trauksmi 4 minÅ«tes pēc izslēgÅ”anas sākuma. Aptuveni nākamo piecu minÅ«Å”u laikā mēs veicām diagnostiku un palielinājām pamatā esoÅ”o Kubernetes klasteru, lai mitinātu gan jaunos, gan esoÅ”os ražoÅ”anas klasterus.

Vēl pēc piecām minūtēm vecie ingesteri veiksmīgi ierakstīja savus datus, sāka darboties jaunie, un Cortex klasteri atkal kļuva pieejami.

Vēl 10 minÅ«tes tika pavadÄ«tas, lai diagnosticētu un labotu ārpus atmiņas (OOM) kļūdas no autentifikācijas reversajiem starpniekserveriem, kas atrodas Cortex priekŔā. OOM kļūdas izraisÄ«ja desmitkārtÄ«gs QPS pieaugums (uzskatām, ka klienta Prometheus serveru pārāk agresÄ«vo pieprasÄ«jumu dēļ).

efekti

Kopējais dÄ«kstāves laiks bija 26 minÅ«tes. Dati netika zaudēti. Ingesters ir veiksmÄ«gi ielādējis visus atmiņā esoÅ”os datus ilgtermiņa krātuvē. IzslēgÅ”anas laikā klienta Prometheus serveru buferis tika izdzēsts (tālvadÄ«bas pults) ierakstus izmantojot jauns API remote_write pamatojoties uz WAL (autors Kalums Stjans no Grafana Labs) un atkārtoja neveiksmÄ«gos ierakstus pēc avārijas.

Kā Kubernetes prioritāŔu noteikŔana izraisīja dīkstāvi Grafana Labs
RažoŔanas klastera rakstīŔanas darbības

Atzinumi

Ir svarīgi mācīties no Ŕī incidenta un veikt nepiecieŔamos pasākumus, lai izvairītos no tā atkārtoŔanās.

Atskatoties, mums nevajadzēja iestatÄ«t noklusējuma iestatÄ«jumu vidēja prioritāte, kamēr nav saņēmuÅ”i visi ražoÅ”anā esoÅ”ie Ingesteri augsts prioritāte. Turklāt par tiem bija jāparÅ«pējas jau iepriekÅ” augsts prioritāte. Tagad viss ir sakārtots. Mēs ceram, ka mÅ«su pieredze palÄ«dzēs citām organizācijām, kuras apsver iespēju Kubernetes lietot pod prioritāŔu.

Mēs pievienosim papildu kontroles lÄ«meni visu papildu objektu izvietoÅ”anai, kuru konfigurācijas klasterim ir globālas. Turpmāk Ŕādas izmaiņas tiks vērtētas bŠ¾vairāk cilvēku. Turklāt modifikācija, kas izraisÄ«ja avāriju, tika uzskatÄ«ta par pārāk nelielu atseviŔķam projekta dokumentam ā€” tā tika apspriesta tikai GitHub izdevumā. Turpmāk visām Ŕādām izmaiņām konfigurācijās tiks pievienota atbilstoÅ”a projekta dokumentācija.

Visbeidzot, mēs automatizēsim autentifikācijas reversā starpniekservera izmēru maiņu, lai novērstu OOM pārslodzi, ko mēs novērojām, un pārskatÄ«sim Prometheus noklusējuma iestatÄ«jumus, kas saistÄ«ti ar atkāpÅ”anos un mērogoÅ”anu, lai novērstu lÄ«dzÄ«gas problēmas nākotnē.

Neveiksmei bija arÄ« dažas pozitÄ«vas sekas: saņemot nepiecieÅ”amos resursus, Cortex automātiski atkopās bez papildu iejaukÅ”anās. Mēs arÄ« guvām vērtÄ«gu pieredzi, strādājot ar Grafana Loki - mÅ«su jaunā baļķu apkopoÅ”anas sistēma, kas palÄ«dzēja nodroÅ”ināt, ka visi Ingesteri rÄ«kojās pareizi kļūmes laikā un pēc tās.

PS no tulka

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru