Hoe peulprioriteite in Kubernetes stilstand by Grafana Labs veroorsaak het

Let wel. vertaal.: Ons bied aan u aandag tegniese besonderhede oor die redes vir die onlangse stilstand in die wolkdiens wat deur die skeppers van Grafana onderhou word. Dit is 'n klassieke voorbeeld van hoe 'n nuwe en oënskynlik uiters nuttige kenmerk wat ontwerp is om die kwaliteit van infrastruktuur te verbeter... skade kan veroorsaak as jy nie voorsiening maak vir die talle nuanses van die toepassing daarvan in die realiteite van produksie nie. Dit is wonderlik wanneer materiale soos hierdie verskyn wat jou toelaat om nie net uit jou foute te leer nie. Besonderhede is in die vertaling van hierdie teks van die vise-president van produk van Grafana Labs.

Hoe peulprioriteite in Kubernetes stilstand by Grafana Labs veroorsaak het

Op Vrydag, 19 Julie, het die Hosted Prometheus-diens in Grafana Cloud vir ongeveer 30 minute opgehou funksioneer. Ek vra om verskoning aan alle kliënte wat deur die onderbreking geraak is. Ons taak is om die moniteringsinstrumente te verskaf wat u benodig, en ons verstaan ​​dat dit u lewe moeiliker kan maak as u dit nie beskikbaar het nie. Ons neem hierdie voorval uiters ernstig op. Hierdie nota verduidelik wat gebeur het, hoe ons gereageer het en wat ons doen om te verseker dat dit nie weer gebeur nie.

voorgeskiedenis

Grafana Cloud Hosted Prometheus diens is gebaseer op Cortex - CNCF-projek om 'n horisontaal skaalbare, hoogs beskikbare, multi-huurder Prometheus-diens te skep. Die Cortex-argitektuur bestaan ​​uit 'n stel individuele mikrodienste, wat elkeen sy eie funksie verrig: replikasie, berging, navrae, ens. Cortex is onder aktiewe ontwikkeling en voeg voortdurend nuwe funksies by en verbeter werkverrigting. Ons ontplooi gereeld nuwe Cortex-vrystellings na groepe sodat kliënte voordeel kan trek uit hierdie kenmerke – gelukkig kan Cortex sonder stilstand opgedateer word.

Vir naatlose opdaterings vereis die Ingester Cortex-diens 'n bykomende Ingester-replika tydens die opdateringsproses. (Let wel. vertaal.: Ingester - die basiese komponent van die Korteks. Sy taak is om 'n konstante stroom monsters te versamel, dit in Prometheus-stukke te groepeer en dit in 'n databasis soos DynamoDB, BigTable of Cassandra te stoor.) Dit laat ou Ingesters toe om huidige data aan nuwe Ingesters aan te stuur. Dit is opmerklik dat Ingesters hulpbronveis is. Vir hulle om te werk, moet jy 4 kerns en 15 GB geheue per peul hê, m.a.w. 25% van die verwerkingskrag en geheue van die basismasjien in die geval van ons Kubernetes-klusters. Oor die algemeen het ons gewoonlik baie meer ongebruikte hulpbronne in die groepie as 4 kerns en 15 GB geheue, so ons kan hierdie bykomende innemers maklik tydens opgraderings opbou.

Dit gebeur egter dikwels dat tydens normale werking nie een van die masjiene hierdie 25% van ongebruikte hulpbronne het nie. Ja, ons streef nie eers na nie: SVE en geheue sal altyd nuttig wees vir ander prosesse. Om hierdie probleem op te los, het ons besluit om te gebruik Kubernetes Pod Prioriteite. Die idee is om Ingesters 'n hoër prioriteit te gee as ander (staatlose) mikrodienste. Wanneer ons 'n addisionele (N+1) Ingester moet laat loop, verplaas ons tydelik ander, kleiner peule. Hierdie peule word oorgedra na gratis hulpbronne op ander masjiene, wat 'n groot genoeg "gat" laat om 'n bykomende Ingester te laat loop.

Op Donderdag, 18 Julie, het ons vier nuwe prioriteitsvlakke na ons klusters bekendgestel: krities, hoog, gemiddelde и lae. Hulle is getoets op 'n interne groepering met geen kliëntverkeer vir ongeveer een week nie. By verstek, peule sonder 'n gespesifiseerde prioriteit ontvang gemiddelde prioriteit, is klas gestel vir Ingesters met hoë prioriteit. Kritiek was gereserveer vir monitering (Prometheus, Alertmanager, node-uitvoerder, kube-state-metrics, ens.). Ons konfigurasie is oop, en jy kan die PR bekyk hier.

ongeluk

Op Vrydag, 19 Julie, het een van die ingenieurs 'n nuwe toegewyde Cortex-kluster vir 'n groot kliënt bekendgestel. Die konfigurasie vir hierdie groepie het nie nuwe peulprioriteite ingesluit nie, so aan alle nuwe peule is 'n verstekprioriteit toegeken - gemiddelde.

Die Kubernetes-kluster het nie genoeg hulpbronne vir die nuwe Cortex-kluster gehad nie, en die bestaande produksie Cortex-kluster is nie opgedateer nie (Ingewers is sonder hoog prioriteit). Sedert die Ingesters van die nuwe cluster by verstek het gemiddelde prioriteit, en die bestaande peule in produksie het enigsins sonder prioriteit gewerk, het die Ingesters van die nuwe kluster die Ingesters van die bestaande Cortex-produksiekluster vervang.

ReplicaSet vir die uitgesit Ingester in die produksiegroepering het die uitgesitte peul bespeur en 'n nuwe een geskep om die gespesifiseerde aantal kopieë te behou. Die nuwe peul is by verstek toegewys gemiddelde prioriteit, en nog 'n "ou" Ingester in produksie het sy hulpbronne verloor. Die resultaat was stortvloed proses, wat gelei het tot die verplasing van alle peule vanaf Ingester vir Cortex-produksieklusters.

Inneemers is statig en stoor data vir die vorige 12 uur. Dit stel ons in staat om hulle meer doeltreffend saam te druk voordat hulle na langtermynberging geskryf word. Om dit te bereik, verdeel Cortex data oor reekse met behulp van 'n Distributed Hash Table (DHT) en herhaal elke reeks oor drie Ingesters met behulp van Dynamo-styl kworumkonsekwentheid. Cortex skryf nie data aan Ingesters wat gedeaktiveer is nie. Dus, wanneer 'n groot aantal Ingesters die DHT verlaat, kan Cortex nie voldoende replikasie van die inskrywings verskaf nie, en hulle stort neer.

Opsporing en Remediëring

Nuwe Prometheus-kennisgewings gebaseer op "foutbegroting" (fout-begroting gebaseer — besonderhede sal in 'n toekomstige artikel verskyn) het die alarm begin maak 4 minute na die begin van die afskakeling. Oor die volgende vyf minute of wat het ons 'n paar diagnostiek uitgevoer en die onderliggende Kubernetes-kluster opgeskaal om beide die nuwe en bestaande produksieklusters te huisves.

Na nog vyf minute het die ou Ingesters hul data suksesvol geskryf, die nuwes het begin en die Cortex-klusters het weer beskikbaar geword.

Nog 10 minute is bestee aan die diagnose en regstelling van buite-geheue (OOM)-foute van verifikasie-omgekeerde gevolmagtigdes wat voor Cortex geleë is. OOM-foute is veroorsaak deur 'n tienvoudige toename in QPS (ons glo as gevolg van te aggressiewe versoeke van die kliënt se Prometheus-bedieners).

Nadraai

Die totale stilstand was 26 minute. Geen data het verlore gegaan nie. Innemers het alle data in die geheue suksesvol in langtermynberging gelaai. Tydens die afskakeling is kliënt Prometheus-bedieners wat gebuffer is, uitgevee (op afstand) opnames met behulp van nuwe API remote_write gebaseer op WAL (geskryf deur Callum Styan van Grafana Labs) en het die mislukte skrywes na die ongeluk herhaal.

Hoe peulprioriteite in Kubernetes stilstand by Grafana Labs veroorsaak het
Produksie kluster skryf bedrywighede

Bevindinge

Dit is belangrik om uit hierdie voorval te leer en die nodige stappe te neem om die herhaling daarvan te voorkom.

By nabetragting moes ons nie die verstek gestel het nie gemiddelde prioriteit totdat alle Ingesters in produksie ontvang het hoog 'n prioriteit. Boonop was dit nodig om vooraf vir hulle te sorg hoog prioriteit. Alles is nou reggemaak. Ons hoop dat ons ervaring ander organisasies sal help wat dit oorweeg om pod-prioriteite in Kubernetes te gebruik.

Ons sal 'n bykomende vlak van beheer byvoeg oor die ontplooiing van enige bykomende voorwerpe waarvan die konfigurasies wêreldwyd in die groepering is. Voortaan sal sulke veranderinge beoordeel word bоmeer mense. Boonop is die wysiging wat die ongeluk veroorsaak het, as te gering beskou vir 'n aparte projekdokument - dit is slegs in 'n GitHub-uitgawe bespreek. Van nou af sal al sulke veranderinge aan konfigurasies vergesel word van toepaslike projekdokumentasie.

Laastens sal ons die grootte van die verifikasie-omgekeerde instaanbediener outomatiseer om die oorlading OOM wat ons gesien het te voorkom, en sal Prometheus verstekinstellings wat verband hou met terugval en skaal ontleed om soortgelyke probleme in die toekoms te voorkom.

Die mislukking het ook 'n paar positiewe gevolge gehad: nadat hy die nodige hulpbronne ontvang het, het Cortex outomaties herstel sonder bykomende ingryping. Ons het ook waardevolle ondervinding opgedoen om mee te werk Grafana Loki - ons nuwe log-aggregasiestelsel - wat gehelp het om te verseker dat alle Ingesters behoorlik gedra het tydens en na die mislukking.

PS van vertaler

Lees ook op ons blog:

Bron: will.com

Voeg 'n opmerking