🥇Kuidas Kubernetes'e pod'ide prioriteedid said Grafana Labsis seiskumise põhjuseks

Märk. tõlge.: Tutvustame teile tehnilisi detaile hiljutise seisu kohta Grafana looja poolt hallatava pilveteenuse töös. See on klassikaline näide sellest, kuidas uus ja näiliselt äärmiselt kasulik funktsioon, mille eesmärk on infrastruktuuri kvaliteeti parandada, võib kahjustada, kui ei arvestata selle rakendamise paljusid nüansse tootmises. Imeline, kui sellised materjalid ilmuvad, võimaldades õppida mitte ainult oma vigadest. Üksikasjad leiate Grafana Labs'i toote asepresidendi tõlgitud tekstist.

Reedel, 19. juulil peatus Hosted Prometheus teenus Grafana Cloudis umbes 30 minutiks. Palun vabandust kõigi klientide ees, kes said rikete tõttu kannatada. Meie ülesanne on pakkuda vajalikke jälgimistööriistu ja mõistame, et nende puudumine muudab teie elu keerulisemaks. Suhtume sellesse juhtumisse äärmiselt tõsiselt. selles märkuses selgitatakse, mis juhtus, kuidas me sellele reageerisime ja mida me teeme, et selline asi enam ei korduks.

Eelalugu

Grafana Cloud Hosted Prometheuse teenus põhineb Cortex — CNCF projektis, mille eesmärgiks on luua horisontaalselt skaleeritav, kõrge kättesaadavuse ja mitme kliendi teenus Prometheus. Cortexi arhitektuur koosneb kogumist eraldi mikroteenustest, millest igaühel on oma funktsioon: replikatsioon, salvestamine, päringud jne. Cortexi arendamine on aktiivne, uusi funktsioone lisandub pidevalt ning jõudlus paraneb. Tõukame regulaarselt uusi Cortexi versioone klastritesse, et kliendid saaksid nende võimalustest kasu - õnneks suudab Cortex uuendusi teha katkestusteta.

Katkestusteta uuendamiseks nõuab Cortexi Ingester teenus uuendamise ajal täiendavat Ingesteri koopiat. (Märk. tõlge.: Ingester — Cortexi põhikomponent. Selle ülesanne on koguda pidev voog sample'itest, grupeerida need Prometheuse chunk'ideks ja salvestada sellistesse andmebaasidesse nagu DynamoDB, BigTable või Cassandra. See võimaldab vanadel Ingester'itel edastada praeguseid andmeid uutele Ingester'itele. Tuleb märkida, et Ingester'id on ressursikaded. Nende tööks on vajalikud 4 tuuma ja 15 GB mälu pod'i kohta, s.t. 25% protsessorivõimsusest ja mälust põhimasinas meie Kubernetes klasside puhul. Üldiselt on meil tavaliselt palju rohkem kasutamata ressursse klastris, kui 4 tuuma ja 15 GB mälu, seega saame neid täiendavaid Ingester'eid hõlpsasti käivitada uuenduste ajal.

Kuid sageli juhtub, et normaalse töö käigus ei ole ühelgi masinal neid 25% kasutamata ressursse. Me ei püüa ka: CPU ja mälu on alati vajalikud teistele protsessidele. Selle probleemi lahendamiseks otsustasime kasutada Kubernetes Pod Priorities. Idee on selles, et Ingester'itele antakse kõrgem prioriteet kui teistele (stateless) mikroteenustele. Kui peame käivitama täiendava (N+1) Ingester'i, tõukame ajutiselt tagasi teised, väiksemad pod'id. Need pod'id viiakse vabadele ressurssidele teistele masinatele, jättes piisavalt su suure "auku" täiendava Ingester'i käivitamiseks.

Neljapäeval, 18. juulil, käivitasime oma klusterites neli uut prioriteedi taset: kriitiline, kõrge, keskmine ja madal. Need testiti sisemises klustis ilma kliendiliikluse puudumisel umbes nädala jooksul. Vaikimisi pod’id, millele ei olnud määratud prioriteeti, said keskmine prioriteedi; Ingester’itele määrati klassiga kõrge Reegel 4a: Kui ülesanne kasutab täielikult ette nähtud ajavahemikku, siis selle Kriitiline oli reserveeritud seire jaoks (Prometheus, Alertmanager, node-exporter, kube-state-metrics jne). Meie konfiguratsioon on avatud, ja PR-i saab vaadata siit.

Häda

Reede, 19. juulil, käivitas üks insener uue pühendatud Cortex klusteri suurele kliendile. Selle klusteri konfiguratsioon ei sisaldanud uusi pod’ide prioriteete, seega kõigile uutele pod’idele määrati vaikimisi prioriteet - keskmine.

Kubernetes’ klusteris puudusid ressursid uue Cortex klusteri jaoks, ja olemasolevat tootmis-kongesti Cortex’i ei uuendatud (Ingester’id jäid ilma kõrge prioriteedita). Kuna uue klusteri Ingester’id olid vaikimisi keskmine prioriteediga ning olemasolevad tootmis pod’id töötasid üldse ilma prioriteedita, surusid uue klusteri Ingester’id olemasoleva tootmis-kust küljest välja.

ReplicaSet, mis on loodud väljasurnud Ingester'i jaoks tootmisklassis, tuvastas väljasurnud pod'i ja lõi uue, säilitades määratud koopiate arvu. Uuele pod'ile anti vaikimisi keskmine prioriteet ja järgmine "vana" Ingester tootmises kaotas ressursid. Tulemuseks oli lapidaarne protsess, mis tõi kaasa kõigi pod'ide väljasurumise Ingester'i jaoks tootmisklassis Cortex'i.

Ingester'id säilitavad oleku (stateful) ja salvestavad andmeid viimase 12 tunni jooksul. See võimaldab meil neid enne pikaajalisse säilitamisse kirjutamist tõhusamalt tihendada. Selleks viib Cortex läbi andmete partitsioneerimise seeriate kaupa, kasutades jaotatud rämps-tabelit (Distributed Hash Table, DHT) ja replikeerib iga seeria kolmele Ingester'ile, kasutades Dynamo stiilis kvoorumite konsensust. Cortex ei kirjuta andmeid Ingester'itesse, mis on välja lülitatud. Seega, kui suur arv Ingester'e lahkub DHT-st, ei suuda Cortex tagada piisavat salvestusrekordite replikatsiooni, ja need "langevad".

Tuvastamine ja kõrvaldamine

Uued Prometheuse teavitused, mis põhinevad "veabudžetil" (error-budget-based — üksikasjad tulevad tulevases artiklis) hakkasid nad 4 minutit pärast katkestust häirekella lööma. Järgmise umbes viie minuti jooksul tegime diagnoosi ja suurendasime aluseks olevat Kubernetes klastrit, et majutada nii uut kui ka olemasolevat tootmisclustrit.

Veel viie minuti pärast olid vanad Ingester'id edukalt oma andmed salvestanud ning uued olid käivitatud, ja Cortex klastrid said taas kättesaadavaks.

Veel 10 minutit kulus diagnoosimiseks ja out-of-memory (OOM) tõrgete parandamiseks autentimisteenuste tagasiprokseerijates, mis asusid Cortex'i ees. OOM-tõrked olid põhjustatud kümnekordsest QPS kasvust (nagu me arvame, põhjustatud liiga agressiivsetest päringutest kliendi Prometheuse serveritest).

Tagajärjed

Kokkuvõttes kestis seisak 26 minutit. Andmeid ei kadunud. Ingester'id laadisid edukalt kõik in-memory andmed pikaajalisse salvestusse. Katkestuse ajal salvestasid kliendi Prometheuse serverid eemaldatud (remote) kirjed uus API remote_write WAL-i põhjal (autor Callum Styan Grafana Labs'ist) ja kordasid pärast tõrget ebaõnnestunud salvestusi.

Tootmisklastra kirjutamise toimingud

Järeldused

Oluline on selle juhtumi õppetunnid välja noppida ja võtta vajalikud meetmed, et vältida selle kordumist.

Tagasi vaadates tuleb tunnistada, et me ei pidanud default'ina seadma keskmine prioriteeti, kuni kõik Ingester'id tootmises olid saanud kõrge prioriteedi. Lisaks oleks pidanud hoolitsema nende kõrge prioriteedi eest. Nüüd on kõik parandatud. Loodame, et meie kogemus aitab teisi organisatsioone, kes kaaluvad pod'ide prioriteetide kasutuselevõttu Kuberneteses.

Lisame täiendava taseme kontrolli igasuguste täiendavate objektide juurutamiseks, mille konfiguratsioonid on globaalseted klastrile. Edaspidi hinnatakse sarnaseid muudatusiosuurema inimeste arvu poolt. Lisaks peeti rikutud modifikatsiooni eraldi projektidokumendi jaoks liiga tühiseks — seda arutati ainult GitHubi teemades. Alates sellest hetkest saadik kaasnevad kõik sellised konfiguratsioonimuudatused vastava projektidokumentatsiooniga.

Lõpuks automatiseerime autentimissüsteemi tagasipöörduva serveri suuruse muutmise, et vältida OOM-i ülekoormuse korral, mida oleme kogeda saanud, ja analüüsime Prometheuse vaikeparameetreid, mis on seotud tagasipöördumise ja skaleerimisega, et tulevikus selliseid probleeme ennetada.

Kogetud tõrkel oli ka positiivseid tagajärgi: vajalikud ressursid käeulatuses, Cortex taastati automaatselt ilma täiendava sekkumiseta. Samuti saime väärtuslikke kogemusi töötades Grafana Loki — meie uue logide agregatsiooni süsteemiga, — mis aitas veenduda, et kõik Ingester'id käitusid õigesti tõrke ajal ja pärast seda.