{"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\/hu\/blog\/administrirovanie\/kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs","title":{"rendered":"Hogyan v\u00e1ltak a Kubernetes pod-ok priorit\u00e1sai a Grafana Labs le\u00e1ll\u00e1s\u00e1nak ok\u00e1v\u00e1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Megjegyz\u00e9s ford\u00edt\u00e1s.<\/b>: Bemutatjuk \u00d6nnek a k\u00f6zelm\u00faltban a Grafana alkot\u00f3i \u00e1ltal \u00fczemeltetett felh\u0151szolg\u00e1ltat\u00e1s le\u00e1ll\u00e1s\u00e1nak technikai r\u00e9szleteit. Ez klasszikus p\u00e9ld\u00e1ja annak, hogyan okozhat egy \u00faj, l\u00e1tsz\u00f3lag rendk\u00edv\u00fcl hasznos lehet\u0151s\u00e9g, amely a infrastrukt\u00fara min\u0151s\u00e9g\u00e9nek jav\u00edt\u00e1s\u00e1ra hivatott\u2026 k\u00e1rt, ha nem sz\u00e1m\u00edtunk a szakszer\u0171 alkalmaz\u00e1s sz\u00e1mos \u00e1rnyalat\u00e1ra a production k\u00f6rnyezetben. Csod\u00e1latos, amikor ilyen anyagok jelennek meg, amelyek lehet\u0151v\u00e9 teszik, hogy ne csak a saj\u00e1t hib\u00e1inkb\u00f3l tanuljunk. R\u00e9szletek a Grafana Labs term\u00e9k\u00e9rt felel\u0151s aleln\u00f6k\u00e9nek sz\u00f6veg\u00e9nek ford\u00edt\u00e1s\u00e1ban.<\/i><\/p>\n

\"\ud83e\udd47Hogyan
\n
\nJ\u00falius 19-\u00e9n, p\u00e9nteken a Grafana Cloud szolg\u00e1ltat\u00e1s Hosted Prometheus k\u00f6r\u00fclbel\u00fcl 30 percre le\u00e1llt. Eln\u00e9z\u00e9st k\u00e9rek minden \u00fcgyf\u00e9lt\u0151l, akit a hiba \u00e9rintett. Feladatunk a megfelel\u0151 monitoroz\u00f3 eszk\u00f6z\u00f6k biztos\u00edt\u00e1sa, \u00e9s tudat\u00e1ban vagyunk annak, hogy ezek hi\u00e1nya megnehez\u00edti az \u00d6n \u00e9let\u00e9t. Nagyon komolyan vessz\u00fck ezt az incidenst. Ebben a jegyzetben elmagyar\u00e1zom, mi t\u00f6rt\u00e9nt, hogyan reag\u00e1ltunk erre, \u00e9s mit tesz\u00fcnk az\u00e9rt, hogy hasonl\u00f3 ne forduljon el\u0151 a j\u00f6v\u0151ben.<\/a><\/noindex><\/p>\n

H\u00e1tt\u00e9r<\/h2>\n

\nA Grafana Cloud Hosted Prometheus szolg\u00e1ltat\u00e1s a k\u00f6vetkez\u0151n alapul Cortex<\/a><\/noindex> \u2014 a CNCF \u00e1ltal l\u00e9trehozott, v\u00edzszintesen sk\u00e1l\u00e1zhat\u00f3, nagy rendelkez\u00e9sre \u00e1ll\u00e1s\u00fa, t\u00f6bb-b\u00e9rl\u0151s Prometheus szolg\u00e1ltat\u00e1s. A Cortex architekt\u00far\u00e1ja k\u00fcl\u00f6n\u00e1ll\u00f3 mikroszolg\u00e1ltat\u00e1sok halmaz\u00e1b\u00f3l \u00e1ll, amelyek mindegyike saj\u00e1t funkci\u00f3t l\u00e1t el: replik\u00e1ci\u00f3, t\u00e1rol\u00e1s, lek\u00e9rdez\u00e9s stb. A Cortex akt\u00edvan fejl\u0151dik, folyamatosan \u00faj lehet\u0151s\u00e9gek jelennek meg, \u00e9s n\u0151 a teljes\u00edtm\u00e9nye. Rendszeresen telep\u00edtj\u00fck az \u00faj Cortex kiad\u00e1sokat a klaszterekbe, hogy az \u00fcgyfelek \u00e9lvezhess\u00e9k ezeket a lehet\u0151s\u00e9geket \u2014 h\u00e1la az \u00e9gnek, a Cortex k\u00e9pes a friss\u00edt\u00e9sek v\u00e9grehajt\u00e1s\u00e1ra le\u00e1ll\u00e1s n\u00e9lk\u00fcl.<\/p>\n

Az Ingester Cortex friss\u00edt\u00e9seihez tov\u00e1bbi Ingester-replik\u00e1ra van sz\u00fcks\u00e9g a friss\u00edt\u00e9si folyamat sor\u00e1n. (Megjegyz\u00e9s ford\u00edt\u00e1s.<\/b>: Ingester<\/a><\/noindex> \u2014 a Cortex alapvet\u0151 \u00f6sszetev\u0151je. Feladata, hogy folyamatosan gy\u0171jtse a sample-okat, csoportos\u00edtsa \u0151ket Prometheus chunk-okba \u00e9s t\u00e1rolja \u0151ket olyan adatb\u00e1zisokban, mint a DynamoDB, BigTable vagy Cassandra.<\/i> Ez lehet\u0151v\u00e9 teszi a r\u00e9gi Ingester-ek sz\u00e1m\u00e1ra, hogy a jelenlegi adatokat \u00faj Ingester-eknek tov\u00e1bb\u00edts\u00e1k. \u00c9rdemes megjegyezni, hogy az Ingester-ek er\u0151forr\u00e1sig\u00e9nyesek. A m\u0171k\u00f6d\u00e9s\u00fckh\u00f6z 4 mag \u00e9s 15 GB mem\u00f3ria sz\u00fcks\u00e9ges pod-onk\u00e9nt, ami a Kubernetes klaszterben a b\u00e1zisg\u00e9p 25%-\u00e1t \u00e9s mem\u00f3ri\u00e1j\u00e1t jelenti. \u00c1ltal\u00e1ban viszont sokkal t\u00f6bb el\u00e9rhet\u0151 er\u0151forr\u00e1s \u00e1ll rendelkez\u00e9sre a klaszterben, mint 4 mag \u00e9s 15 GB mem\u00f3ria, \u00edgy k\u00f6nnyen elind\u00edthat\u00f3k ezek a tov\u00e1bbi Ingester-ek a friss\u00edt\u00e9sek alatt.<\/p>\n

Gyakran azonban el\u0151fordul, hogy a norm\u00e1l m\u0171k\u00f6d\u00e9s sor\u00e1n egyik g\u00e9pen sincsenek ezek a 25%-os felhaszn\u00e1latlan er\u0151forr\u00e1sok. Nem is t\u00f6reksz\u00fcnk r\u00e1: a CPU \u00e9s a mem\u00f3ria mindig hasznos m\u00e1s folyamatokhoz. A probl\u00e9ma megold\u00e1s\u00e1ra \u00fagy d\u00f6nt\u00f6tt\u00fcnk, hogy kihaszn\u00e1ljuk a Kubernetes Pod Priorit\u00e1sokat<\/a><\/noindex>. Az \u00f6tlet az, hogy az Ingester-eknek magasabb priorit\u00e1st adjunk, mint m\u00e1s (stateless) mikroszolg\u00e1ltat\u00e1soknak. Amikor sz\u00fcks\u00e9g van egy tov\u00e1bbi (N+1) Ingester elind\u00edt\u00e1s\u00e1ra, ideiglenesen kiszor\u00edtjuk a kisebb pod-okat. Ezek a pod-ok \u00e1tkonfigur\u00e1l\u00f3dnak, hogy m\u00e1s g\u00e9peken haszn\u00e1lj\u00e1k a szabad er\u0151forr\u00e1sokat, elegend\u0151 \u201eh\u00e9zagot\u201d hagyva egy tov\u00e1bbi Ingester ind\u00edt\u00e1s\u00e1hoz.<\/p>\n

Cs\u00fct\u00f6rt\u00f6k\u00f6n, j\u00falius 18-\u00e1n n\u00e9gy \u00faj priorit\u00e1si szintet telep\u00edtett\u00fcnk a klasztereinkbe: kritikus<\/b>, magas<\/b>, k\u00f6zepes<\/b> \u00e9s alacsony<\/b>. Ezeket k\u00f6r\u00fclbel\u00fcl egy h\u00e9tig tesztelt\u00e9k egy bels\u0151 klaszteren, \u00fcgyf\u00e9lforgalom n\u00e9lk\u00fcl. Alap\u00e9rtelmez\u00e9s szerint a prioriz\u00e1l\u00e1s n\u00e9lk\u00fcli pod-ok k\u00f6zepes<\/b> priorit\u00e1st kaptak, az Ingester-ek sz\u00e1m\u00e1ra pedig egy oszt\u00e1lyt \u00e1ll\u00edtottak be magas<\/b> ker\u00fcl. A Kritikus priorit\u00e1s a megfigyel\u00e9sre volt fenntartva (Prometheus, Alertmanager, node-exporter, kube-state-metrics stb.). A konfigur\u00e1ci\u00f3nk nyitott, \u00e9s a PR megtekinthet\u0151<\/b> Hiba itt<\/a><\/noindex>.<\/p>\n

P\u00e9nteken, j\u00falius 19-\u00e9n egy m\u00e9rn\u00f6k elind\u00edtotta az \u00faj, dedik\u00e1lt Cortex klasztert egy nagy \u00fcgyf\u00e9l sz\u00e1m\u00e1ra. Ennek a klaszternak a konfigur\u00e1ci\u00f3ja nem tartalmazta az \u00faj pod priorit\u00e1sokat, ez\u00e9rt minden \u00faj pod alap\u00e9rtelmezett priorit\u00e1st kapott -<\/h2>\n

\nJ\u00falius 19-\u00e9n, p\u00e9nteken az egyik m\u00e9rn\u00f6k \u00faj dedik\u00e1lt Cortex klasztert ind\u00edtott egy jelent\u0151s \u00fcgyf\u00e9l sz\u00e1m\u00e1ra. Ennek a klaszternak a konfigur\u00e1ci\u00f3ja nem tartalmazta az \u00faj pod priorit\u00e1sokat, \u00edgy minden \u00faj pod alap\u00e9rtelmezett priorit\u00e1ssal indult \u2014 k\u00f6zepes<\/b>.<\/p>\n

A Kubernetes klaszterben nem volt elegend\u0151 er\u0151forr\u00e1s az \u00faj Cortex klaszter sz\u00e1m\u00e1ra, \u00e9s a megl\u00e9v\u0151 production Cortex klaszter nem friss\u00fclt (az Ingester-ek priorit\u00e1s n\u00e9lk\u00fcl maradtak). priorit\u00e1ssal). Mivel az \u00faj klaszter Ingester-ei alap\u00e9rtelmez\u00e9s szerint priorit\u00e1ssal rendelkeztek, m\u00edg a megl\u00e9v\u0151 production pod-ok teljesen priorit\u00e1s n\u00e9lk\u00fcl m\u0171k\u00f6dtek, az \u00faj klaszter Ingester-ei kiszor\u00edtott\u00e1k a megl\u00e9v\u0151 production Cortex klaszter Ingester-eit.<\/b> Mivel az \u00faj klaszter Ingester-einek alap\u00e9rtelmezett priorit\u00e1sa volt, m\u00edg a megl\u00e9v\u0151 production pod-ok egy\u00e1ltal\u00e1n nem rendelkeztek priorit\u00e1ssal, az \u00faj klaszter Ingester-ei kiszor\u00edtott\u00e1k a megl\u00e9v\u0151 production klaszter Cortex Ingester-eit. k\u00f6zepes<\/b> A production klaszter Ingester-\u00e9t kiszor\u00edt\u00f3 ReplicaSet \u00e9szlelte a kiszor\u00edtott pod-ot, \u00e9s l\u00e9trehozott egy \u00fajat a megadott m\u00e1solatok sz\u00e1m\u00e1nak fenntart\u00e1s\u00e1hoz. Az \u00faj pod-nak alap\u00e9rtelmezett priorit\u00e1sa volt<\/p>\n

, ami az \u00f6sszes pod kiszor\u00edt\u00e1s\u00e1hoz vezetett az Ingester-ek sz\u00e1m\u00e1ra a production klaszterek Cortex-\u00e9ben. k\u00f6zepes<\/b> an avalanche process , which led to the eviction of all Ingester pods for the production clusters of Cortex.<\/b>.<\/p>\n

Az ingesztorok \u00e1llapotmeg\u0151rz\u0151k (stateful) \u00e9s az el\u0151z\u0151 12 \u00f3r\u00e1ban t\u00e1rolt adatokat mentenek. Ez lehet\u0151v\u00e9 teszi sz\u00e1munkra, hogy hat\u00e9konyabban t\u00f6m\u00f6r\u00edts\u00fck azokat, miel\u0151tt hossz\u00fa t\u00e1v\u00fa t\u00e1rol\u00e1sra \u00edrn\u00e1nk. Ehhez a Cortex az adatokat sorozatok alapj\u00e1n shardolja, elosztott hasht\u00e1bl\u00e1t (Distributed Hash Table, DHT) haszn\u00e1lva, \u00e9s minden sorozatot h\u00e1rom ingesztorra replik\u00e1l a Dynamo st\u00edlus\u00fa kv\u00f3rum egyes\u00edt\u00e9s\u00e9vel. A Cortex nem \u00edr adatokat azokra az ingesztorokra, amelyek le vannak \u00e1ll\u00edtva. \u00cdgy amikor sok ingesztor elhagyja a DHT-t, a Cortex nem tud elegend\u0151 replik\u00e1ci\u00f3t biztos\u00edtani, \u00e9s az adatok \u201eleesnek\u201d.<\/p>\n

New Prometheus alerts based on the error budget (<\/h2>\n

\nerror-budget-based\u2014 details will appear in a future article) raised alarms 4 minutes after the beginning of the shutdown. During the next approximately five minutes, we conducted diagnostics and scaled up the underlying Kubernetes cluster to accommodate both new and existing production clusters.<\/i> Another five minutes later, the old Ingester nodes successfully recorded their data, and the new ones started up, making the Cortex clusters available again.<\/p>\n

\u00d6t perccel k\u00e9s\u0151bb a r\u00e9gi ingesztorok sikeresen r\u00f6gz\u00edtett\u00e9k adataikat, m\u00edg az \u00fajak elindultak, \u00e9s a Cortex klaszterek \u00fajra el\u00e9rhet\u0151k lettek.<\/p>\n

Consequences<\/p>\n

The total downtime lasted 26 minutes. No data was lost. The Ingester nodes successfully uploaded all in-memory data to long-term storage. During the shutdown, client Prometheus servers cached remote<\/h2>\n

\nA teljes le\u00e1ll\u00e1s id\u0151tartama 26 perc volt. Az adatok nem vesztek el. Az ingesztorok sikeresen bet\u00f6lt\u00f6tt\u00e9k az \u00f6sszes in-memory adatot a tart\u00f3s t\u00e1rol\u00f3ba. A Prometheus szerverek buffered t\u00e1vols\u00e1g\u00e1t mez\u0151-be\u00e1ll\u00edtva meg\u0151rizt\u00e9k az adatok le\u00e1ll\u00edt\u00e1sakor. records using<\/i> the new remote_write API based on WAL (created by<\/a><\/noindex> Callum Styan from Grafana Labs) and replayed the failed records after the crash.<\/a><\/noindex> Production cluster write operations<\/p>\n

\"\ud83e\udd47Hogyan
\nIt is important to learn from this incident and take necessary measures to prevent its recurrence.<\/i><\/p>\n

K\u00f6vetkeztet\u00e9sek<\/h2>\n

\nFontos, hogy levonjuk a tanuls\u00e1gokat az esem\u00e9nyb\u0151l, \u00e9s megtegy\u00fck a sz\u00fcks\u00e9ges l\u00e9p\u00e9seket, hogy elker\u00fclj\u00fck annak megism\u00e9tl\u0151d\u00e9s\u00e9t.<\/p>\n

Visszatekintve el kell ismern\u00fcnk, hogy nem lett volna szabad alap\u00e9rtelmezett priorit\u00e1st megadnunk, am\u00edg az \u00f6sszes ingester a termel\u00e9sben nem kapott priorit\u00e1st. k\u00f6zepes<\/b> priorit\u00e1s, am\u00edg az \u00f6sszes ingesztor a produkci\u00f3s k\u00f6rnyezetben nem kapta meg magas<\/b> Most minden megold\u00f3dott. Rem\u00e9lj\u00fck, hogy a tapasztalatunk seg\u00edt m\u00e1s szervezeteknek, akik a podok priorit\u00e1s\u00e1nak haszn\u00e1lat\u00e1t fontolgatj\u00e1k a Kubernetesben. Hozz\u00e1 fogunk adni egy tov\u00e1bbi ellen\u0151rz\u00e9si szintet b\u00e1rmilyen tov\u00e1bbi objektum telep\u00edt\u00e9sekor, melyek konfigur\u00e1ci\u00f3i glob\u00e1lisak a klaszter sz\u00e1m\u00e1ra. A j\u00f6v\u0151ben az ilyen v\u00e1ltoztat\u00e1sokat t\u00f6bb ember fogja \u00e9rt\u00e9kelni.<\/b> Ezen k\u00edv\u00fcl a meghib\u00e1sod\u00e1shoz vezet\u0151 m\u00f3dos\u00edt\u00e1st t\u00fal jelent\u00e9ktelennek tartott\u00e1k ahhoz, hogy k\u00fcl\u00f6n projekt dokumentuma legyen \u2014 ezt csak a GitHub k\u00e9rd\u00e9sben besz\u00e9lt\u00fck meg. Ett\u0151l kezdve minden ilyen konfigur\u00e1ci\u00f3t k\u00eds\u00e9rni fog a megfelel\u0151 projekt dokument\u00e1ci\u00f3.<\/p>\n

V\u00e9g\u00fcl automatiz\u00e1ljuk a hiteles\u00edt\u00e9si visszafel\u00e9 proxy m\u00e9retez\u00e9s\u00e9t, hogy megel\u0151zz\u00fck az OOM-ot a t\u00falterhel\u00e9s sor\u00e1n, aminek tan\u00fai voltunk, \u00e9s elemezni fogjuk az alap\u00e9rtelmezett Prometheus be\u00e1ll\u00edt\u00e1sokat, amelyek a vissza\u00e1ll\u00edt\u00e1ssal \u00e9s a sk\u00e1l\u00e1z\u00e1ssal kapcsolatosak, hogy megel\u0151zz\u00fck a j\u00f6v\u0151beli hasonl\u00f3 probl\u00e9m\u00e1kat.\u00f3<\/i>A t\u00f6rt\u00e9nt meghib\u00e1sod\u00e1snak voltak pozit\u00edv k\u00f6vetkezm\u00e9nyei is: miut\u00e1n megkaptuk a sz\u00fcks\u00e9ges er\u0151forr\u00e1sokat, a Cortex automatikusan helyre\u00e1llt tov\u00e1bbi beavatkoz\u00e1s n\u00e9lk\u00fcl. \u00c9rt\u00e9kes tapasztalatokat szerezt\u00fcnk a<\/p>\n

Grafana Loki \u2014 a mi \u00faj napl\u00f3aggreg\u00e1l\u00f3 rendszer\u00fcnk \u2014 haszn\u00e1lat\u00e1val, ami seg\u00edtett biztos\u00edtani, hogy az \u00f6sszes ingester megfelel\u0151en viselkedett a meghib\u00e1sod\u00e1s alatt \u00e9s ut\u00e1n.<\/p>\n

A Kubernetes sikeres t\u00f6rt\u00e9netei a termel\u00e9sben. 10. r\u00e9sz: Reddit Hogyan vezettek a Kubernetes pod priorit\u00e1sai le\u00e1ll\u00e1shoz a Grafana Labsn\u00e1l<\/a><\/noindex> \u2014 az \u00faj log aggreg\u00e1l\u00f3 rendszer\u00fcnk, \u2014 amely seg\u00edtett biztos\u00edtani, hogy az \u00f6sszes ingesztor megfelel\u0151en viselkedjen a le\u00e1ll\u00e1s idej\u00e9n \u00e9s ut\u00e1n.<\/p>\n

Fejleszt\u00e9si eszk\u00f6z\u00f6k, amelyek Kubernetesben futnak<\/h2>\n

\nOlvasson tov\u00e1bbi inform\u00e1ci\u00f3kat a blogunkban:<\/p>\n