{"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\/da\/blog\/administrirovanie\/kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs","title":{"rendered":"Hvordan prioriteringer af pods i Kubernetes for\u00e5rsagede nedetid i Grafana Labs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bem. overs.<\/b>: Vi pr\u00e6senterer her de tekniske detaljer om \u00e5rsagerne til den seneste nedetid i det cloud-baserede service leveret af skaberne af Grafana. Dette er et klassisk eksempel p\u00e5, hvordan en ny og tilsyneladende nyttig funktion, der er designet til at forbedre kvaliteten af infrastrukturen... kan skade, hvis man ikke tager h\u00f8jde for de mange nuancer ved dens anvendelse i realiteterne i produktion. Det er fantastisk, n\u00e5r s\u00e5danne materialer dukker op, hvor man kan l\u00e6re ikke kun af sine egne fejl. Flere detaljer findes i overs\u00e6ttelsen af denne tekst fra vicepr\u00e6sidenten for produktet hos Grafana Labs.<\/i><\/p>\n

\"Hvordan
\n
\nFredag den 19. juli stoppede Hosted Prometheus servicen i Grafana Cloud med at fungere i omtrent 30 minutter. Jeg beklager over for alle kunder, der blev ramt af nedbruddet. Vores opgave er at levere de n\u00f8dvendige v\u00e6rkt\u00f8jer til overv\u00e5gning, og vi forst\u00e5r, at deres utilg\u00e6ngelighed g\u00f8r dit liv sv\u00e6rere. Vi tager denne h\u00e6ndelse meget alvorligt. I denne note forklares, hvad der skete, hvordan vi reagerede og hvad vi g\u00f8r for at sikre, at det ikke sker igen.<\/a><\/noindex><\/p>\n

Background<\/h2>\n

\nGrafana Cloud Hosted Prometheus servicen er baseret p\u00e5 Cortex<\/a><\/noindex> \u2014 et CNCF projekt til at skabe en horisontalt skalerbar, h\u00f8jt tilg\u00e6ngelig, multi-tenant Prometheus service. Cortex-arkitekturen best\u00e5r af et s\u00e6t separate mikrotjenester, hvor hver udf\u00f8rer sin funktion: replikering, opbevaring, foresp\u00f8rgsler osv. Cortex udvikles aktivt, og nye funktioner tilf\u00f8jes konstant, hvilket forbedrer ydeevnen. Vi deployerer regelm\u00e6ssigt nye versioner af Cortex i klyngerne, s\u00e5 kunderne kan drage fordel af disse muligheder \u2014 heldigvis kan Cortex opdateres uden nedetid.<\/p>\n

For seamless updates, the Ingester Cortex service requires an additional Ingester replica during the update process. (Bem. overs.<\/b>: Ingester<\/a><\/noindex> \u2014 a core component of Cortex. Its task is to collect a constant stream of samples, group them into chunks for Prometheus, and store them in a database like DynamoDB, BigTable, or Cassandra.<\/i> This allows old Ingesters to forward current data to new Ingesters. It is worth noting that Ingesters are resource-intensive. They require 4 cores and 15 GB of memory per pod, which is 25% of the CPU power and memory of the base machine in our Kubernetes clusters. Generally, we usually have much more unused resources in the cluster than the 4 cores and 15 GB of memory, so we can easily run these additional Ingesters during updates.<\/p>\n

Men ofte er der under normal drift ikke disse 25 % ubrugte ressourcer p\u00e5 nogen af maskinerne. Ja, og vi str\u00e6ber ikke efter det: CPU og hukommelse er altid nyttige til andre processer. For at l\u00f8se dette problem besluttede vi at benytte os af Kubernetes Pod Prioriteter<\/a><\/noindex>The idea is to assign Ingesters a higher priority than other (stateless) microservices. When we need to launch an additional (N+1) Ingester, we temporarily evict other, smaller pods. These pods are moved to free resources on other machines, leaving a large enough \"gap\" to launch the additional Ingester.<\/p>\n

Torsdag den 18. juli implementerede vi fire nye prioriteringsniveauer i vores klynger: kritisk<\/b>, h\u00f8j<\/b>, middel<\/b> og lav<\/b>They were tested in an internal cluster without client traffic for about a week. By default, pods without a specified priority received middel<\/b> priority, while a class was set for Ingesters with h\u00f8j<\/b> prioritet til Ingester. Kritisk<\/b> blev reserveret til overv\u00e5gning (Prometheus, Alertmanager, node-exporter, kube-state-metrics osv.). Vores konfiguration er \u00e5ben, og PR'en kan ses her<\/a><\/noindex>.<\/p>\n

Nedbrud<\/h2>\n

\nOn Friday, July 19, one of the engineers launched a new dedicated Cortex cluster for a large client. The config for this cluster did not include the new pod priorities, so all new pods were assigned the default priority \u2014 middel<\/b>.<\/p>\n

The Kubernetes cluster lacked the resources for the new Cortex cluster, and the existing production Cortex cluster was not updated (Ingesters remained without h\u00f8j<\/b> priority). Since the Ingesters of the new cluster by default had middel<\/b> priority, while the existing production pods operated without any priority, the Ingesters of the new cluster displaced Ingesters from the existing production Cortex cluster.<\/p>\n

The ReplicaSet for the evicted Ingester in the production cluster detected the evicted pod and created a new one to maintain the specified number of replicas. The new pod was assigned middel<\/b> priority, causing another 'old' Ingester in production to lose resources. The result was an avalanche process<\/b>, which led to the eviction of all pods with Ingesters for the production Cortex clusters.<\/p>\n

Ingesterne er stateful og gemmer data for de sidste 12 timer. Dette giver os mulighed for at komprimere dem mere effektivt, f\u00f8r de skrives til langtidslager. Cortex udf\u00f8rer datasjardinering efter serier ved hj\u00e6lp af en distribueret hash-tabel (Distributed Hash Table, DHT) og replikerer hver serie til tre ingesters ved hj\u00e6lp af quorum-consensus i stil med Dynamo. Cortex skriver ikke data til ingesters, der er offline. S\u00e5 n\u00e5r et stort antal ingesters forlader DHT, kan Cortex ikke sikre tilstr\u00e6kkelig replikation af poster, og de 'faldt'.<\/p>\n

Detection and resolution<\/h2>\n

\nNew Prometheus alerts based on 'error budget' (error-budget-based<\/i> \u2014 details will appear in a future article) started sounding the alarm four minutes after the outage began. Over the next five minutes, we conducted diagnostics and scaled the underlying Kubernetes cluster to host both new and existing production clusters.<\/p>\n

Fem minutter senere havde de gamle ingesters med succes skrevet deres data, og de nye var startet, og Cortex-klyngerne var tilg\u00e6ngelige igen.<\/p>\n

Another 10 minutes were spent on diagnostics and fixing out-of-memory (OOM) errors from the authentication reverse proxy servers located in front of Cortex. The OOM errors were caused by a tenfold increase in QPS (which we believe was due to overly aggressive requests from the client\u2019s Prometheus servers).<\/p>\n

Consequences<\/h2>\n

\nDen samlede nedetid var 26 minutter. Dataene blev ikke tabt. Ingesterne havde med succes indl\u00e6st alle in-memory-data i det langsigtede lager. Under nedlukningen buffede kundernes Prometheus-servere de fjerne (remote)<\/i> records using the new remote_write API<\/a><\/noindex> based on WAL (authored by Callum Styan<\/a><\/noindex> from Grafana Labs) and repeated the failed records after the failure.<\/p>\n

\"Hvordan
\nOperations of the production cluster<\/i><\/p>\n

Konklusioner<\/h2>\n

\nIt is crucial to learn lessons from this incident and take the necessary measures to prevent its recurrence.<\/p>\n

N\u00e5r vi ser tilbage, m\u00e5 vi erkende, at vi ikke skulle have sat standard middel<\/b> prioritet, indtil alle ingesters i produktionen havde f\u00e5et h\u00f8j<\/b> prioriteten. Derudover skulle der have v\u00e6ret taget h\u00f8jde for deres h\u00f8je<\/b> prioritet p\u00e5 forh\u00e5nd. Nu er alt rettet op. Vi h\u00e5ber, at vores erfaring vil hj\u00e6lpe andre organisationer, der overvejer at bruge pod-prioriteter i Kubernetes.<\/p>\n

Vi vil tilf\u00f8je et ekstra niveau af kontrol for udrulningen af enhver yderligere objekt, hvis konfigurationer er globale for klyngen. Fremover vil s\u00e5danne \u00e6ndringer blive vurderet affleste af<\/i>et st\u00f8rre antal personer. Desuden blev den modificering, der f\u00f8rte til fejlen, anset for at v\u00e6re for ubetydelig til et separat projekt dokument \u2014 den blev kun diskuteret i et GitHub-issue. Fra nu af vil alle s\u00e5danne konfigurations\u00e6ndringer blive ledsaget af den relevante projekt dokumentation.<\/p>\n

Endelig vil vi automatisere omdimensioneringen af den omvendte proxy-authenticator for at forhindre OOM ved overbelastning, som vi har v\u00e6ret vidne til, og gennemg\u00e5 Prometheus standardindstillinger vedr\u00f8rende rollback og skaleringsmuligheder for at forhindre lignende problemer i fremtiden.<\/p>\n

Den oplevede fejl havde ogs\u00e5 nogle positive konsekvenser: ved at have de n\u00f8dvendige ressourcer til r\u00e5dighed, genoprettede Cortex automatisk uden yderligere indblanding. Vi fik ogs\u00e5 v\u00e6rdifuld erfaring med Grafana Loki<\/a><\/noindex> \u2013 vores nye logaggregationssystem, \u2013 som hjalp med at sikre, at alle ingesters opf\u00f8rte sig korrekt under og efter fejlen.<\/p>\n

P.S. fra overs\u00e6tteren<\/h2>\n

\nL\u00e6s ogs\u00e5 p\u00e5 vores blog:<\/p>\n