Kubernetes-en pod lehentasunek nola eragin zuten geldialdia Grafana Labs-en

Ohar. itzul.: Grafana-ren sortzaileek mantendu duten hodeiko zerbitzuan azken geldialdiaren arrazoiei buruzko xehetasun teknikoak aurkezten dizkizugu. Azpiegituren kalitatea hobetzeko diseinatutako funtzio berri eta oso erabilgarria dirudienaren adibide klasiko bat da hau... kalteak eragin ditzakeen ekoizpenaren errealitateetan aplikatzeko ñabardura ugariak ematen ez badituzu. Oso ona da horrelako materialak agertzen direnean, akatsetatik ez ezik ikasteko aukera ematen dizutenean. Xehetasunak Grafana Labs-eko produktuen presidenteordearen testu honen itzulpenean daude.

Kubernetes-en pod lehentasunek nola eragin zuten geldialdia Grafana Labs-en

Uztailaren 19an, ostirala, Grafana Cloud-eko Hosted Prometheus zerbitzuak 30 minutu gutxi gorabehera funtzionatzeari utzi zion. Barkamena eskatzen diet etenaldiak kaltetutako bezero guztiei. Gure lana behar dituzun monitorizazio tresnak eskaintzea da, eta haiek eskuragarri ez edukitzeak zure bizitza zaildu dezakeela ulertzen dugu. Gertaera hau oso serio hartzen dugu. Ohar honek zer gertatu den, nola erantzun dugun eta zer egiten ari garen azaltzen du berriro gerta ez dadin.

historiaurrea

Grafana Cloud Hosted Prometheus zerbitzuan oinarritzen da Cortex — CNCF proiektua horizontalki eskalagarria, erabilgarritasun handikoa eta maizter anitzeko Prometheus zerbitzu bat sortzeko. Cortex arkitektura banakako mikrozerbitzu multzo batek osatzen du, eta bakoitzak bere funtzioa betetzen du: erreplikazioa, biltegiratzea, kontsultak, etab. Cortex garapen aktiboan dago eta etengabe ari da funtzio berriak gehitzen eta errendimendua hobetzen. Aldian-aldian Cortex-en bertsio berriak zabaltzen ditugu klusteretara, bezeroek eginbide hauek aprobetxa ditzaten; zorionez, Cortex-ek geldialdirik gabe eguneratu daiteke.

Eguneratze egokiak lortzeko, Ingester Cortex zerbitzuak Ingester erreplika gehigarri bat behar du eguneratze prozesuan zehar. (Ohar. itzul.: Irenstea - Cortexaren oinarrizko osagaia. Bere lana lagin-korronte etengabea biltzea da, Prometheus zatietan multzokatzea eta DynamoDB, BigTable edo Cassandra bezalako datu-base batean gordetzea.) Horri esker, Ingesters zaharrek uneko datuak birbidal ditzakete Ingester berrietara. Aipatzekoa da Ingesters baliabideak eskatzen dituela. Funtzionatzeko, 4 nukleo eta 15 GB memoria eduki behar dituzu pod bakoitzeko, hau da. Oinarrizko makinaren prozesatzeko ahalmenaren eta memoriaren %25 gure Kubernetes klusterren kasuan. Oro har, klusterrean erabili gabeko baliabide askoz gehiago ditugu 4 nukleo eta 15 GB memoria baino, beraz, erraz bira ditzakegu ingestgailu gehigarri hauek bertsio berritze garaian.

Hala ere, askotan gertatzen da funtzionamendu arruntean makina batek ere ez duela erabili gabeko baliabideen %25 hori. Bai, ez gara ahalegintzen ere egiten: CPU eta memoria beti izango dira erabilgarriak beste prozesuetarako. Arazo hau konpontzeko, erabiltzea erabaki dugu Kubernetes Pod lehentasunak. Ideia da Ingesters-ek beste mikrozerbitzu (estaturik gabeko) baino lehentasun handiagoa ematea. Ingester gehigarri bat (N+1) exekutatu behar dugunean, aldi baterako beste leka txikiagoak desplazatzen ditugu. Pod hauek beste makinetako doako baliabideetara transferitzen dira, "zulo" nahikoa utziz Ingester gehigarri bat exekutatzeko.

Uztailaren 18an, ostegunean, lau lehentasun-maila berri zabaldu genituen gure klusterrei: kritikoa, altua, batezbesteko и baxua. Bezeroen trafikorik gabeko barne-kluster batean probatu zuten astebetez. Lehenespenez, lehentasun zehatzik gabeko lekak jasotzen dira batezbesteko lehentasuna, klasea ezarri zen Ingesters-ekin handiko lehentasuna. Kritikoa monitorizaziorako gorde zen (Prometheus, Alertmanager, node-exporter, kube-state-metrics, etab.). Gure konfigurazioa irekita dago eta PR ikus dezakezu Hemen.

istripua

Uztailaren 19an, ostirala, ingeniarietako batek Cortex kluster dedikatu berri bat jarri zuen abian bezero handi baterako. Kluster honen konfigurazioak ez zuen podiaren lehentasun berririk sartzen, beraz, pod berri guztiei lehentasun lehenetsia esleitu zitzaien - batezbesteko.

Kubernetes klusterrak ez zuen baliabide nahikorik Cortex kluster berrirako, eta lehendik zegoen ekoizpen Cortex klusterra ez zen eguneratu (Ingesters gabe geratu ziren altua lehentasuna). Lehenespenez kluster berriaren Ingesters izan zutenez batezbesteko lehentasuna, eta ekoizpenean zeuden podek batere lehentasunik gabe funtzionatu zuten, kluster berriko Ingesterrek lehendik zegoen Cortex ekoizpen klusterreko Ingesters ordezkatu zituzten.

Produkzio-klusterrean kanporatutako Ingester-erako ReplicaSet-ek desalojatutako poda detektatu zuen eta beste bat sortu zuen zehaztutako kopia kopurua mantentzeko. Pod berria lehenespenez esleitu zen batezbesteko lehentasuna, eta ekoizpeneko beste Ingester “zahar” batek baliabideak galdu zituen. Emaitza izan zen elur-jausi prozesua, eta horrek Ingester-etik leka guztiak desplazatzea ekarri zuen Cortex ekoizpen-klusterretarako.

Ingesters egoerak dira eta aurreko 12 orduetako datuak gordetzen dituzte. Horrek modu eraginkorragoan konprimitzeko aukera ematen digu epe luzerako biltegiratze batean idatzi aurretik. Hori lortzeko, Cortex-ek datuak serieetan banatzen ditu Distributed Hash Table (DHT) erabiliz eta serie bakoitza hiru Ingesteretan errepikatzen du Dynamo estiloko quorum koherentzia erabiliz. Cortex-ek ez ditu desgaituta dauden Ingesters-en daturik idazten. Horrela, Ingester kopuru handi batek DHTtik irteten direnean, Cortex-ek ezin du sarreren nahikoa erreplika eman, eta huts egiten dute.

Detekzioa eta konponketa

Prometheus-en jakinarazpen berriak "errorearen aurrekontuan" oinarrituta (akatsetan aurrekontuetan oinarrituta — xehetasunak etorkizuneko artikulu batean agertuko dira) itzalaldia hasi eta 4 minutura alarma jotzen hasi zen. Hurrengo bost minutuetan edo, diagnostiko batzuk egin genituen eta azpian zegoen Kubernetes klusterra eskalatu genuen produkzio-kluster berriak eta lehendik zeudenak hartzeko.

Beste bost minuturen buruan, Ingester zaharrek ongi idatzi zituzten euren datuak, berriak martxan jarri ziren eta Cortex klusterrak berriro erabilgarri geratu ziren.

Beste 10 minutu igaro ziren Cortex-en aurrean kokatutako autentifikazio-alderantzizko proxyen memoriaz kanpoko akatsak diagnostikatzen eta zuzentzen (OOM). OOM akatsak QPS-en hamar aldiz handitzearen ondorioz sortu ziren (uste dugu bezeroaren Prometheus zerbitzarien eskaera oldarkorrengatik).

efektu

Guztizko geldialdi-denbora 26 minutukoa izan zen. Ez da daturik galdu. Ingesters-ek behar bezala kargatu dituzte memoriako datu guztiak epe luzerako biltegiratze batean. Itzaltzean, bezero Prometheus zerbitzariak bufferean ezabatu ziren (urrunekoa) grabaketak erabiliz API berria remote_write WAL-en oinarrituta (egilea Callum Styan Grafana Labs-etik) eta huts egindako idazketak errepikatu zituen kraskaduraren ostean.

Kubernetes-en pod lehentasunek nola eragin zuten geldialdia Grafana Labs-en
Produkzio-kluster idazketa-eragiketak

Findings

Garrantzitsua da gertakari honetatik ikastea eta beharrezkoak diren neurriak hartzea berriro errepika ez dadin.

Atzera begiratuta, ez genuke lehenetsia ezarri behar batezbesteko lehentasuna ekoizpenean Ingester guztiak jaso arte altua lehentasuna. Gainera, aldez aurretik zaintzea beharrezkoa zen altua lehentasuna. Dena konponduta dago orain. Espero dugu gure esperientziak beste erakunde batzuei laguntzea Kubernetesen pod lehentasunak erabiltzea aztertzen.

Kontrol maila gehigarri bat gehituko dugu klustererako konfigurazioak globalak diren objektu gehigarrien hedapenari buruz. Hemendik aurrera, halako aldaketak baloratuko dira bоjende gehiago. Gainera, hutsegitea eragin zuen aldaketa txikiegia izan zen proiektuko dokumentu bereizi baterako - GitHub-en arazo batean bakarrik eztabaidatu zen. Hemendik aurrera, konfigurazioetan egindako aldaketa guztiak proiektuaren dokumentazio egokiarekin batera joango dira.

Azkenik, autentifikazioaren alderantzizko proxyaren tamaina aldatzea automatizatuko dugu ikusi genuen gainkargako OOM-a saihesteko, eta Prometheus-en ezarpen lehenetsiak berrikusiko ditugu atzera eta eskalatzearekin erlazionatutako etorkizunean antzeko arazoak saihesteko.

Porrotak ondorio positibo batzuk ere izan zituen: beharrezko baliabideak jasota, Cortex automatikoki berreskuratu zen esku-hartze gehigarririk gabe. Lanean esperientzia baliotsua ere lortu genuen Grafana Loki - Gure erregistroak gehitzeko sistema berria - Ingester guztiak ondo portatu zirela ziurtatzen lagundu zuen hutsegitean eta ondoren.

PS itzultzailetik

Irakurri ere gure blogean:

Iturria: www.habr.com

Gehitu iruzkin berria