{"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\/sv\/blog\/administrirovanie\/kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs","title":{"rendered":"Hur prioriteringar av poddar i Kubernetes orsakade driftstopp p\u00e5 Grafana Labs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Obs. \u00f6vers.<\/b>: Vi presenterar tekniska detaljer om orsaken till det senaste driftstoppet hos molntj\u00e4nsten som drivs av skaparna av Grafana. Detta \u00e4r ett klassiskt exempel p\u00e5 hur en ny och, till synes, oerh\u00f6rt nyttig funktion, avsedd att f\u00f6rb\u00e4ttra infrastrukturen\u2026 kan orsaka problem om man inte tar h\u00e4nsyn till de m\u00e5nga nyanser som p\u00e5verkar dess anv\u00e4ndning i produktion. Det \u00e4r fantastiskt n\u00e4r s\u00e5dana h\u00e4r material dyker upp som g\u00f6r att man kan l\u00e4ra sig inte bara av sina egna misstag. Detaljer finns i \u00f6vers\u00e4ttningen av denna text fr\u00e5n vice VD f\u00f6r produkt p\u00e5 Grafana Labs.<\/i><\/p>\n

\"Hur
\n
\nFredagen den 19 juli slutade tj\u00e4nsten Hosted Prometheus i Grafana Cloud att fungera i ungef\u00e4r 30 minuter. Jag ber om urs\u00e4kt till alla kunder som drabbades av avbrottet. V\u00e5rt m\u00e5l \u00e4r att tillhandah\u00e5lla de verktyg som beh\u00f6vs f\u00f6r \u00f6vervakning, och vi f\u00f6rst\u00e5r att deras otillg\u00e4nglighet f\u00f6rsv\u00e5rar er vardag. Vi tar denna incident p\u00e5 stort allvar. I denna notis f\u00f6rklaras vad som h\u00e4nde, hur vi reagerade och vad vi g\u00f6r f\u00f6r att f\u00f6rhindra att detta h\u00e4nder igen.<\/a><\/noindex><\/p>\n

Bakgrund<\/h2>\n

\nGrafana Cloud Hosted Prometheus-tj\u00e4nsten \u00e4r baserad p\u00e5 Cortex<\/a><\/noindex> \u2014 CNCF-projektet f\u00f6r att skapa en horisontellt skalbar, h\u00f6g tillg\u00e4nglighet, multitenant-tj\u00e4nst f\u00f6r Prometheus. Cortex-arkitekturen best\u00e5r av en upps\u00e4ttning separata mikroservicer, var och en med sin egen funktion: replikering, lagring, f\u00f6rfr\u00e5gningar osv. Cortex utvecklas aktivt, nya funktioner tillkommer st\u00e4ndigt och prestandan f\u00f6rb\u00e4ttras. Vi distribuerar regelbundet nya versioner av Cortex till kluster s\u00e5 att kunderna kan dra nytta av dessa funktioner - tack och lov kan Cortex uppdateras utan driftstopp.<\/p>\n

F\u00f6r s\u00f6ml\u00f6sa uppdateringar kr\u00e4ver Ingester Cortex en ytterligare Ingester-kopia under uppdateringsprocessen. (Obs. \u00f6vers.<\/b>: Ingester<\/a><\/noindex> \u2014 den grundl\u00e4ggande komponenten i Cortex. Dess uppgift \u00e4r att samla in en kontinuerlig str\u00f6m av samples, gruppera dem i chunkar f\u00f6r Prometheus och spara dem i databaser som DynamoDB, BigTable eller Cassandra.)<\/i> Detta g\u00f6r att gamla Ingster kan f\u00f6ra vidare aktuella data till nya Ingester. Det \u00e4r v\u00e4rt att notera att Ingester \u00e4r resurskr\u00e4vande. F\u00f6r sin drift kr\u00e4vs 4 k\u00e4rnor och 15 GB minne per pod, vilket inneb\u00e4r 25 % av den grundl\u00e4ggande maskinens processor- och minneskapacitet i v\u00e5ra Kubernetes-kluster. Generellt sett har vi vanligtvis mycket mer oanv\u00e4nda resurser i klustret \u00e4n 4 k\u00e4rnor och 15 GB minne, s\u00e5 vi kan enkelt k\u00f6ra dessa extra Ingester under uppdateringar.<\/p>\n

Men det h\u00e4nder ofta att det under normala driftf\u00f6rh\u00e5llanden inte finns n\u00e5gra 25% oanv\u00e4nda resurser p\u00e5 n\u00e5gon av maskinerna. Och vi str\u00e4var inte efter det: CPU och minne beh\u00f6vs alltid f\u00f6r andra processer. F\u00f6r att l\u00f6sa detta problem har vi beslutat att anv\u00e4nda Kubernetes Pod Prioriteter<\/a><\/noindex>. Id\u00e9n \u00e4r att ge Ingester h\u00f6gre prioritet \u00e4n andra (stateless) mikrotj\u00e4nster. N\u00e4r vi beh\u00f6ver k\u00f6ra en extra (N+1) Ingester, tempor\u00e4rt f\u00f6rflyttas andra, mindre poddar. Dessa poddar flyttas till lediga resurser p\u00e5 andra maskiner, vilket l\u00e4mnar en tillr\u00e4ckligt stor \"lucka\" f\u00f6r att starta en extra Ingester.<\/p>\n

Torsdagen den 18 juli inf\u00f6rde vi fyra nya niv\u00e5er av prioriteringar i v\u00e5ra kluster: kritisk<\/b>, en h\u00f6g<\/b>, medel<\/b> och l\u00e5g<\/b>. De testades p\u00e5 det interna klustret utan kundtrafik i ungef\u00e4r en vecka. Som standard fick poddar utan angiven prioritet medel<\/b> prioritet, medan en klass f\u00f6r Ingester hade satts till h\u00f6g<\/b> prioritet. Kritisk<\/b> var reserverad f\u00f6r \u00f6vervakning (Prometheus, Alertmanager, node-exporter, kube-state-metrics osv.). V\u00e5r konfiguration \u00e4r \u00f6ppen, och du kan se PR:en h\u00e4r<\/a><\/noindex>.<\/p>\n

Krasch<\/h2>\n

\nFredagen den 19 juli lanserade en av ingenj\u00f6rerna ett nytt dedikerat Cortex-kluster f\u00f6r en stor kund. Konfigurationen f\u00f6r detta kluster inkluderade inte nya podprioriteter, s\u00e5 alla nya poddar tilldelades standardprioritet \u2014 medel<\/b>.<\/p>\n

Kubernetes-klustret hade inte tillr\u00e4ckligt med resurser f\u00f6r det nya Cortex-klustret, och det befintliga produktionsklustret f\u00f6r Cortex var inte uppdaterat (Ingester f\u00f6rblev utan h\u00f6g<\/b> prioritet). Eftersom Ingester i det nya klustret hade prioritet som standard, medan de befintliga i produktionspoddarna helt saknade prioritet, tr\u00e4ngde Ingester i det nya klustret ut Ingester fr\u00e5n det befintliga produktionsklustret f\u00f6r Cortex. medel<\/b> ReplicaSet f\u00f6r den tr\u00e4ngda Ingester i produktionsklustret uppt\u00e4ckte den tr\u00e4ngda podden och skapade en ny f\u00f6r att uppr\u00e4tth\u00e5lla det angivna antalet kopior. Den nya podden fick som standard<\/p>\n

, vilket ledde till att alla poddar med Ingester f\u00f6r produktionsklusterna f\u00f6r Cortex tr\u00e4ngdes ut. medel<\/b> prioritet, och den \"gamla\" Ingester i produktionen f\u00f6rlorade resurser. Resultatet blev en lavinartad process<\/b>.<\/p>\n

Ingester \u00e4r tillst\u00e5ndsbevarande och lagrar data fr\u00e5n de senaste 12 timmarna. Detta g\u00f6r att vi kan komprimera dem mer effektivt innan de skrivs till l\u00e5ngsiktig lagring. F\u00f6r detta g\u00f6r Cortex datasharding \u00f6ver serier, anv\u00e4nder en distribuerad hash-tabell (Distributed Hash Table, DHT), och replikerar varje serie p\u00e5 tre Ingester med hj\u00e4lp av kvorumkoherens i stil med Dynamo. Cortex skriver inte data till Ingester som \u00e4r avst\u00e4ngda. S\u00e5ledes, n\u00e4r ett stort antal Ingester l\u00e4mnar DHT, kan Cortex inte s\u00e4kerst\u00e4lla tillr\u00e4cklig replikering av poster, och de \"faller\".<\/p>\n

Uppt\u00e4ckta och \u00e5tg\u00e4rdande<\/h2>\n

\nNya Prometheus-notifikationer baserade p\u00e5 \"felbudget\" (error-budget-based<\/i> \u2014 detaljer kommer i en framtida artikel) b\u00f6rjade ge larm efter 4 minuter fr\u00e5n det att avst\u00e4ngningen b\u00f6rjade. Under de f\u00f6ljande fem minuterna diagnostiserade vi problemet och \u00f6kade den underliggande Kubernetes-klustret f\u00f6r att rymma b\u00e5de nya och befintliga produktionskluster.<\/p>\n

Efter ytterligare fem minuter hade de gamla Ingester framg\u00e5ngsrikt skrivit sina data och de nya hade startat, och Cortex-kluster \u00e5terblev tillg\u00e4ngliga.<\/p>\n

Ytterligare 10 minuter gick \u00e5t till att diagnostisera och \u00e5tg\u00e4rda out-of-memory (OOM) fel fr\u00e5n autentiseringens omv\u00e4nda proxyservrar som l\u00e5g framf\u00f6r Cortex. OOM-felen orsakades av en tiodubbling av QPS (som vi misst\u00e4nker beror p\u00e5 \u00f6verdrivet aggressiva f\u00f6rfr\u00e5gningar fr\u00e5n klientens Prometheus-servrar).<\/p>\n

Konsekvenser<\/h2>\n

\nDen totala stillest\u00e5ndstiden uppgick till 26 minuter. Inga data gick f\u00f6rlorade. Ingester lyckades ladda alla in-memory-data till l\u00e5ngsiktig lagring. Under avst\u00e4ngningen buffrade Prometheus-servrar f\u00f6r kunderna borttagna (remote)<\/i> poster med hj\u00e4lp av den nya API:en remote_write<\/a><\/noindex> baserad p\u00e5 WAL (skapad av Callum Styan<\/a><\/noindex> fr\u00e5n Grafana Labs) och upprepade de misslyckade posterna efter kraschen.<\/p>\n

\"Hur
\nSkrivoperationer f\u00f6r produktionsklustret<\/i><\/p>\n

Slutsatser<\/h2>\n

\nDet \u00e4r viktigt att dra l\u00e4rdomar fr\u00e5n denna incident och vidta n\u00f6dv\u00e4ndiga \u00e5tg\u00e4rder f\u00f6r att f\u00f6rhindra att den upprepas.<\/p>\n

N\u00e4r man ser tillbaka m\u00e5ste man erk\u00e4nna att vi inte skulle ha st\u00e4llt in prioritet som standard medel<\/b> prioritet, tills alla Ingester i produktion hade mottagit en h\u00f6g<\/b> prioritet. Dessutom borde vi ha sett till deras h\u00f6ga<\/b> prioritet i f\u00f6rv\u00e4g. Nu \u00e4r allt \u00e5tg\u00e4rdat. Vi hoppas att v\u00e5r erfarenhet kommer att hj\u00e4lpa andra organisationer som \u00f6verv\u00e4ger att anv\u00e4nda pod-prioriteringar i Kubernetes.<\/p>\n

Vi kommer att l\u00e4gga till en extra kontrollniv\u00e5 f\u00f6r distributionen av eventuella ytterligare objekt vars konfigurationer \u00e4r globala f\u00f6r klustret. Fram\u00f6ver kommer s\u00e5dana \u00e4ndringar att bed\u00f6mas avb\u00e4sta resultatet (subjektiv \u00e5sikt).<\/i>ett st\u00f6rre antal personer. Dessutom ans\u00e5gs modifieringen som ledde till felet vara f\u00f6r obetydlig f\u00f6r ett separat projekt dokument \u2014 den diskuterades endast i GitHub-\u00e4rendet. Fr\u00e5n och med nu kommer alla s\u00e5dana konfigurations\u00e4ndringar att \u00e5tf\u00f6ljas av motsvarande projektdokumentation.<\/p>\n

Slutligen kommer vi att automatisera skalningen av autentiseringsproxy-servern f\u00f6r att f\u00f6rhindra OOM vid \u00f6verbelastning, vilket vi bevittnat, och analysera standardinst\u00e4llningarna i Prometheus relaterade till rollback och skalning f\u00f6r att f\u00f6rhindra liknande problem i framtiden.<\/p>\n

Det fel som upplevdes hade ocks\u00e5 vissa positiva konsekvenser: genom att f\u00e5 tillg\u00e5ng till de n\u00f6dv\u00e4ndiga resurserna \u00e5terh\u00e4mtade sig Cortex automatiskt utan ytterligare ingripande. Vi fick ocks\u00e5 v\u00e4rdefull erfarenhet av att arbeta med Grafana Loki<\/a><\/noindex> \u2013 v\u00e5rt nya loggaggregationssystem, \u2013 som hj\u00e4lpte till att s\u00e4kerst\u00e4lla att alla Ingester fungerade korrekt under och efter avbrottet.<\/p>\n

P.S. fr\u00e5n \u00f6vers\u00e4ttaren<\/h2>\n

\nL\u00e4s \u00e4ven i v\u00e5r blogg:<\/p>\n