{"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\/nl\/blog\/administrirovanie\/kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs","title":{"rendered":"Hoe de prioriteiten van pods in Kubernetes leidde tot downtime bij Grafana Labs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Opmerking vertaler.<\/b>: Hier zijn de technische details over de redenen voor de recente uitval van de cloudservice, beheerd door de makers van Grafana. Dit is een klassiek voorbeeld van hoe een nieuwe en ogenschijnlijk uiterst nuttige functie, bedoeld om de kwaliteit van de infrastructuur te verbeteren, schadelijk kan zijn als niet goed rekening wordt gehouden met de vele nuancen van het gebruik in production. Het is geweldig wanneer dergelijke materialen verschijnen, die ons in staat stellen niet alleen van onze eigen fouten te leren. De details - in de vertaling van deze tekst door de vice-president product van Grafana Labs.<\/i><\/p>\n

\"Hoe
\n
\nOp vrijdag 19 juli functioneerde de Hosted Prometheus-service in Grafana Cloud ongeveer 30 minuten niet. Mijn excuses aan alle klanten die door deze storing zijn getroffen. Onze taak is om de juiste monitoringtools te bieden, en we begrijpen dat hun onbeschikbaarheid uw leven bemoeilijkt. We nemen dit voorval zeer serieus. In deze notitie wordt uitgelegd wat er is gebeurd, hoe we hebben gereageerd en wat we doen om ervoor te zorgen dat dit niet opnieuw gebeurt.<\/a><\/noindex><\/p>\n

Achtergrond<\/h2>\n

\nDe Grafana Cloud Hosted Prometheus-service is gebaseerd op Cortex<\/a><\/noindex> \u2014 het CNCF-project voor het cre\u00ebren van een horizontaal schaalbare, zeer beschikbare, multi-tenant Prometheus-service. De Cortex-architectuur bestaat uit een set afzonderlijke microservices, die elk hun eigen functie vervullen: replicatie, opslag, aanvragen, etc. Cortex is actief in ontwikkeling, er komen voortdurend nieuwe mogelijkheden en de prestaties worden verbeterd. We implementeren regelmatig nieuwe versies van Cortex in clusters, zodat klanten gebruik kunnen maken van deze mogelijkheden - gelukkig kan Cortex zonder uitvaltijd worden bijgewerkt.<\/p>\n

Voor naadloze updates vereist de Ingester van Cortex een extra Ingester tijdens het updateproces. (Opmerking vertaler.<\/b>: Ingester<\/a><\/noindex> - de basiscomponent van Cortex. De taak ervan is om een constante stroom van samples te verzamelen, deze te groeperen in chunks voor Prometheus en op te slaan in een database zoals DynamoDB, BigTable of Cassandra.<\/i> Dit stelt oudere Ingester in staat om actuele gegevens naar nieuwe Ingester te verzenden. Het is belangrijk op te merken dat Ingester veeleisend is qua middelen. Voor hun werking is 4 cores en 15 GB geheugen per pod vereist, d.w.z. 25% van de processorcapaciteit en geheugen van de basismachine in onze Kubernetes-clusters. Over het algemeen hebben we normaal gesproken veel meer ongebruikte middelen in de cluster dan 4 cores en 15 GB geheugen, zodat we deze extra Ingester gemakkelijk kunnen draaien tijdens updates.<\/p>\n

Echter, het komt vaak voor dat er tijdens normaal gebruik geen van deze 25% ongebruikte middelen op een van de machines beschikbaar zijn. Ja, en we streven er ook niet naar: CPU en geheugen zijn altijd nuttig voor andere processen. Om dit probleem op te lossen, hebben we besloten om gebruik te maken van Kubernetes Pod Prioriteiten<\/a><\/noindex>. Het idee is om Ingester een hogere prioriteit toe te wijzen dan andere (stateless) microservices. Wanneer we een extra (N+1) Ingester moeten starten, verdringen we tijdelijk andere, kleinere pods. Deze pods worden verplaatst naar vrije middelen op andere machines, waardoor er een voldoende grote 'opening' ontstaat om een extra Ingester te starten.<\/p>\n

Op donderdag 18 juli hebben we vier nieuwe prioriteitsniveaus in onze clusters uitgerold: kritisch<\/b>, hoog<\/b>, gemiddeld<\/b> en laag<\/b>. Ze zijn ongeveer een week getest op een interne cluster zonder klantverkeer. Standaard kregen pods zonder toegewezen prioriteit gemiddeld<\/b> prioriteit, voor Ingester was een klasse ingesteld met hoge<\/b> prioriteit geplaatst. Kritisch<\/b> werd gereserveerd voor monitoring (Prometheus, Alertmanager, node-exporter, kube-state-metrics, enz.). Onze configuratie is openbaar, en je kunt de PR bekijken hier<\/a><\/noindex>.<\/p>\n

Storing<\/h2>\n

\nOp vrijdag 19 juli startte een van de ingenieurs een nieuwe toegewijde Cortex-cluster voor een grote klant. De configuratie voor deze cluster bevatte geen nieuwe pods prioriteiten, dus alle nieuwe pods kregen de standaard prioriteit - gemiddeld<\/b>.<\/p>\n

In de Kubernetes-cluster was er niet genoeg middelen voor de nieuwe Cortex-cluster, en de bestaande productie-cluster van Cortex was niet bijgewerkt (Ingester bleef zonder hoge<\/b> prioriteit). Aangezien de Ingester van de nieuwe cluster standaard prioriteit had, en de bestaande productie pods helemaal zonder prioriteit werkten, verdrongen de Ingester van de nieuwe cluster de Ingester van de bestaande productie-cluster van Cortex. gemiddeld<\/b> De ReplicaSet voor de verdrongen Ingester in de productie-cluster ontdekte de verdrongen pod en cre\u00eberde een nieuwe om het vereiste aantal kopie\u00ebn te handhaven. De nieuwe pod kreeg standaard een<\/p>\n

, wat leidde tot de verdringing van alle pods met Ingester voor de productie-clusters van Cortex. gemiddeld<\/b> prioriteit, waardoor een andere 'oude' Ingester in productie zijn middelen verloor. Het resultaat was een sneeuwbaleffect<\/b>, die leidde tot het verdrijven van alle pod's met Ingester voor de productieclusters van Cortex.<\/p>\n

Ingester's behouden de staat (stateful) en slaan gegevens van de afgelopen 12 uur op. Dit stelt ons in staat om ze effici\u00ebnter te comprimeren voordat ze in de lange-termijn opslag worden geschreven. Hiervoor voert Cortex data-sharding uit op series, gebruikmakend van een distributed hash table (DHT), en repliceert elke serie op drie Ingester's met behulp van quorum-consistentie in de stijl van Dynamo. Cortex schrijft geen gegevens naar Ingester's die zijn uitgeschakeld. Daardoor, wanneer een groot aantal Ingester's de DHT verlaat, kan Cortex geen voldoende replicatie van records garanderen, en vallen ze 'weg'.<\/p>\n

Detectie en oplossing<\/h2>\n

\nNieuwe meldingen van Prometheus op basis van het 'foutbudget' (error-budget-based<\/i> \u2014 details volgen in een toekomstige artikel) begonnen alarm te slaan na 4 minuten na het begin van de uitval. Gedurende de volgende ongeveer vijf minuten voerden we diagnostiek uit en schalen het onderliggende Kubernetes-cluster op om zowel nieuwe als bestaande productieclusters te plaatsen.<\/p>\n

Vijf minuten later hadden de oude Ingester's succesvol hun gegevens opgeslagen, en de nieuwe waren opgestart, waardoor de Cortex-clusters weer beschikbaar waren.<\/p>\n

Nog eens 10 minuten gingen voorbij aan diagnostiek en het oplossen van out-of-memory (OOM) fouten van de reverse proxy-authenticatieservers voor Cortex. De OOM-fouten werden veroorzaakt door een tienvoudige toename van QPS (vermoedelijk door overmatig agressieve verzoeken van de Prometheus-clientservers).<\/p>\n

Gevolgen<\/h2>\n

\nDe totale downtime bedroeg 26 minuten. Er ging geen gegevens verloren. Ingester's hebben alle in-memory-gegevens met succes opgeslagen in de langetermijnopslag. Tijdens de onderbreking hebben de Prometheus-servers van de klanten de verwijderde gegevens in de buffer opgeslagen. (remote)<\/i> records in de buffer opgeslagen via de nieuwe remote_write API<\/a><\/noindex> op basis van WAL (geschreven door Callum Styan<\/a><\/noindex> van Grafana Labs) en herhaalden de mislukte records na de storing.<\/p>\n

\"Hoe
\nDe schrijfoperaties van het productiecluster<\/i><\/p>\n

Conclusies<\/h2>\n

\nHet is belangrijk om lessen te trekken uit dit voorval en de nodige maatregelen te nemen om herhaling te voorkomen.<\/p>\n

Bij het terugkijken moeten we erkennen dat we de prioriteit niet standaard hadden moeten instellen gemiddeld<\/b> prioriteit, totdat alle Ingester's in productie hebben ontvangen hoog<\/b> prioriteit. Daarnaast hadden we beter voor hun hoge<\/b> prioriteit kunnen zorgen. Nu is alles opgelost. We hopen dat onze ervaring andere organisaties zal helpen die overwegen gebruik te maken van pod-prioriteiten in Kubernetes.<\/p>\n

We zullen een extra niveau van controle toevoegen bij de implementatie van eventuele aanvullende objecten waarvan de configuraties globaal zijn voor het cluster. Voortaan zullen dergelijke wijzigingen beoordeeld worden doorgroter publiek.<\/i>meer mensen. Bovendien werd de wijziging die tot de storing leidde als te onbeduidend beschouwd voor een afzonderlijk projectdocument \u2014 deze werd alleen besproken in een GitHub-issue. Voortaan zullen alle dergelijke configuratiewijzigingen vergezeld gaan van de bijbehorende projectdocumentatie.<\/p>\n

Tenslotte zullen we het schalen van de authenticatie reverse proxy automatiseren om OOM-gevallen bij overbelasting te voorkomen, waarvan we getuige waren, en we zullen de standaard Prometheus-instellingen met betrekking tot terugrollen en schaling analyseren om in de toekomst soortgelijke problemen te vermijden.<\/p>\n

De ervaren storing had ook enkele positieve gevolgen: met de benodigde middelen herstelde Cortex zich automatisch zonder extra tussenkomst. Ook verkregen we waardevolle ervaring met Grafana Loki<\/a><\/noindex> \u2014 ons nieuwe logaggregatiesysteem, \u2014 dat heeft geholpen om ervoor te zorgen dat alle Ingester's zich correct hebben gedragen tijdens en na de storing.<\/p>\n

P.S. van de vertaler<\/h2>\n

\nLees ook op onze blog:<\/p>\n