{"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\/et\/blog\/administrirovanie\/kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs","title":{"rendered":"Kuidas Kubernetes'e pod'ide prioriteedid p\u00f5hjustasid Grafana Labs'is seiskumise","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

M\u00e4rkus t\u00f5lke kohta.<\/b>: Tutvustame teie t\u00e4helepanu tehnilisi \u00fcksikasju hiljutise katke otsimine pilveteenuse t\u00f6\u00f6s, mida haldavad Grafana loojad. See on klassikaline n\u00e4ide sellest, kuidas uus ja n\u00e4iliselt erakordselt kasulik funktsioon, mis on m\u00f5eldud infrastruktuuri kvaliteedi parandamiseks\u2026 v\u00f5ib kahjustada, kui ei arvestata paljude n\u00fcanssidega selle kasutamisel tootmisre\u017eiimis. Suurep\u00e4rane, kui sellised materjalid ilmuvad, v\u00f5imaldades \u00f5ppida mitte ainult enda vigadest. \u00dcksikasjad \u2013 selle teksti t\u00f5lkes Grafana Labs toote asepresidendi poolt.<\/i><\/p>\n

\"Kuidas
\n
\nReedel, 19. juulil, l\u00f5petas Hosted Prometheus teenus Grafana Cloudis t\u00f6\u00f6tamise umbes 30 minutiks. Vabandan k\u00f5igi klientide ees, kes said h\u00e4ire t\u00f5ttu kannatada. Meie \u00fclesanne on pakkuda vajalikke t\u00f6\u00f6riistu seireks ja me m\u00f5istame, et nende puudumine raskendab teie elu. Me v\u00f5tame seda intsidenti \u00e4\u00e4rmiselt t\u00f5siselt. Selles m\u00e4rkmes selgitatakse, mis juhtus, kuidas me reageerisime ja mida teeme, et sarnased olukorrad ei korduks.<\/a><\/noindex><\/p>\n

Eellugu<\/h2>\n

\nGrafana Cloud Hosted Prometheuse teenus p\u00f5hineb Cortex<\/a><\/noindex> \u2013 CNCF projekt, mille eesm\u00e4rk on luua horisontaalselt skaleeritav, suure k\u00e4ttesaadavuse ja mitme\u00fc\u00fcrilise (multi-tenant) Prometheuse teenus. Cortexi arhitektuur koosneb r\u00fchmast eraldi mikroteenustest, millest iga\u00fchel on oma funktsioon: replikatsioon, salvestamine, p\u00e4ringud jne. Cortexi arendamine on aktiivne, sellele lisatakse pidevalt uusi v\u00f5imalusi ja selle j\u00f5udlus suureneb. Me jagame regulaarselt uusi Cortexi versioone klastritesse, et kliendid saaksid nendest v\u00f5imalustest kasu \u2013 \u00f5nneks oskab Cortex uuendada ilma katkestusteta.<\/p>\n

T\u00e4nu sujuvale v\u00e4rskendusele n\u00f5uab Ingester Cortex'i teenus v\u00e4rskendamise k\u00e4igus t\u00e4iendavat Ingester'i koopiat. (M\u00e4rkus t\u00f5lke kohta.<\/b>: Andmevastuv\u00f5tja<\/a><\/noindex> \u2014 Cortex'i p\u00f5hikomponent. Selle \u00fclesanne on koguda pidev proovide voog, grupeerida need Prometheuse chunk'idesse ja salvestada andmebaasi nagu DynamoDB, BigTable v\u00f5i Cassandra.<\/i> See v\u00f5imaldab vanadel Ingester'itel edastada praeguseid andmeid uutele Ingester'itele. Tuleb m\u00e4rkida, et Ingester'id on ressursin\u00f5udlikud. Nende toimimiseks on vajalik 4 tuuma ja 15 GB m\u00e4lu pod'i kohta, st 25% protsessoriv\u00f5imsusest ja m\u00e4lu p\u00f5himasinas meie Kubernetes klastrites. \u00dcldiselt on meil klastris tavaliselt palju rohkem kasutamata ressursse kui 4 tuuma ja 15 GB m\u00e4lu, seega saame kergesti k\u00e4ivitada need t\u00e4iendavad Ingester'id v\u00e4rskenduste ajal.<\/p>\n

Kuid sageli on nii, et normaalsete t\u00f6\u00f6de k\u00e4igus ei ole \u00fchelgi masinal neid 25% kasutamata ressursse. Jah, me ei p\u00fc\u00fcdle selle poole: CPU ja m\u00e4lu on alati kasulikud teiste protsesside jaoks. Selle probleemi lahendamiseks otsustasime kasutada Kubernetes Pod Priorities<\/a><\/noindex>. Idee on anda Ingester'itele k\u00f5rgem prioriteet kui muudele (stateless) mikroteenustele. Kui peame k\u00e4ivitama t\u00e4iendava (N+1) Ingester'i, t\u00f5ukame ajutiselt k\u00f5rvale teised, v\u00e4iksemad pod'id. Need pod'id liiguvad vabadesse ressurssidesse teistel masinatel, j\u00e4ttes piisavalt suuresse \"auku\" t\u00e4iendava Ingester'i k\u00e4ivitamiseks.<\/p>\n

K\u00e4esoleval neljap\u00e4eval, 18. juulil, k\u00e4ivitasime oma klastrites neli uut prioriteetide taset: kriitiline<\/b>, k\u00f5rge<\/b>, keskmine<\/b> ja madal<\/b>. Neid testiti sisemises klastris, kus ei olnud kliendit\u00f6\u00f6d, umbes \u00fche n\u00e4dala. Vaikimisi pidi pod'idel, millele ei olnud m\u00e4\u00e4ratud prioriteeti, olema keskmine<\/b> prioriteet, Ingester'itele m\u00e4\u00e4rati klass, millel oli k\u00f5rge<\/b> prioriteedi j\u00e4rjekorda. Kriitiline<\/b> oli reserveeritud j\u00e4lgimiseks (Prometheus, Alertmanager, node-exporter, kube-state-metrics jne). Meie konfiguratsioon on avatud ja PR-i saab vaadata siin<\/a><\/noindex>.<\/p>\n

H\u00e4daolukord<\/h2>\n

\nReedel, 19. juulil, k\u00e4ivitas \u00fcks insener uue p\u00fchendatud Cortex klastrit suure kliendi jaoks. Selle klastri konfiguratsioon ei sisaldanud uusi pod'ide prioriteete, seega m\u00e4\u00e4rati k\u00f5igile uutele pod'idele vaikimisi prioriteet \u2014 keskmine<\/b>.<\/p>\n

Kubernetes klastris ei j\u00e4tkunud ressursse uue Cortex klastrina, ja olemasolevat tootmis-klastrit Cortex ei uuendatud (Ingester'id j\u00e4id ilma k\u00f5rge<\/b> prioriteet). Kuna uue klastri Ingester'id olid vaikimisi prioriteediga, aga olemasolevad tootmis-pod'id t\u00f6\u00f6tasid \u00fcldse ilma prioriteedita, t\u00f5ukasid uue klastri Ingester'id tootmis-klastrist Cortex v\u00e4lja. keskmine<\/b> V\u00e4ljat\u00f5rjutud Ingester'i ReplicaSet tootmis-klastri ning avastas v\u00e4ljat\u00f5rjutud pod'i ja l\u00f5i uue, et s\u00e4ilitada m\u00e4\u00e4ratud koopiate arvu. Uuele pod'ile m\u00e4\u00e4rati vaikimisi<\/p>\n

, mis t\u00f5i kaasa k\u00f5ikide Ingester'itega tootmis-klastrite Cortex'i pod'ide t\u00f5rjumise. keskmine<\/b> prioriteet, ja j\u00e4rgmine \"vana\" Ingester tootmises j\u00e4i ilma ressurssidest. Tulemuseks oli lumepalliprotsess<\/b>, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043f\u0440\u0438\u0432\u0435\u043b \u043a \u0432\u044b\u0442\u0435\u0441\u043d\u0435\u043d\u0438\u044e \u0432\u0441\u0435\u0445 pod’\u043e\u0432 \u0441 Ingester \u0434\u043b\u044f production-\u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u0432 Cortex’\u0430.<\/p>\n

Ingester'id s\u00e4ilitavad olekut (stateful) ja hoiab andmed viimase 12 tunni jooksul. See v\u00f5imaldab meil neid enne pikaajalisse salvestusse kirjutamist t\u00f5husamalt tihendada. Selleks jagab Cortex andmeid seeriate kaupa, kasutades jaotatud hash-tabelit (Distributed Hash Table, DHT), ja replikeerib iga seeria kolmele Ingester'ile kasutades kvoorumite konsensust, mis on sarnane Dynaamole. Cortex ei kirjuta andmeid Ingester'itesse, mis on v\u00e4lja l\u00fclitatud. Seega, kui suur hulk Ingester'eid lahkub DHT-st, ei suuda Cortex tagada piisavat replikatsiooni ja rekordid 'kukuvad'.<\/p>\n

Avastamine ja k\u00f5rvaldamine<\/h2>\n

\nUued Prometheuse teavitused, mis p\u00f5hinevad \"veabud\u017eetil\" (error-budget-based<\/i> \u2014 \u00fcksikasjad ilmuvad tulevikus artiklis) hakkasid alarmi l\u00f6\u00f6ma 4 minuti m\u00f6\u00f6dudes katkestuse algusest. J\u00e4rgneva viie minuti jooksul tegime diagnostikat ja suurendasime alapaneeli Kubernetes klassi nii uute kui ka olemasolevate tootmisklasside jaoks.<\/p>\n

Viie minuti p\u00e4rast olid vanad Ingester'id oma andmed edukalt salvestanud ning uued olid k\u00e4ivitatud, ja Cortex'i klastrid olid j\u00e4lle kergesti ligip\u00e4\u00e4setavad.<\/p>\n

Veel 10 minutit l\u00e4ks diagnostiikaks ja out-of-memory (OOM) vigade parandamiseks, mis esinesid Cortex'i ees asuvate autentimisproksiserverite t\u00f5ttu. OOM-vead olid p\u00f5hjustatud k\u00fcmnekordsest QPS kasvust (eeldame, et see tulenes liiga agressiivsetest p\u00e4ringutest kliendi Prometheuse serveritest).<\/p>\n

M\u00f5jud<\/h2>\n

\nKokkuv\u00f5ttes kestis seisak 26 minutit. Andmeid ei kaotatud. Ingester'id edastasid k\u00f5ik in-memory andmed pikaajalisse salvestusse. Klientide Prometheus serverid salvestasid katkestamise ajal kauged andmed puhverdatud kujul. (remote)<\/i> kirjed uue API remote_write p\u00f5hjal WAL (autor<\/a><\/noindex> Callum Styan Grafana Labs'ist) ja kordasid eba\u00f5nnestunud kirjeid p\u00e4rast riket.<\/a><\/noindex> Tootmisklassi kirjutamisoperatsioonid<\/p>\n

\"Kuidas
\nOluline on \u00f5ppida selle juhtumi \u00f5ppustest ja v\u00f5tta vajalikud meetmed, et v\u00e4ltida selle kordumist.<\/i><\/p>\n

J\u00e4reldused<\/h2>\n

\nOn oluline \u00f5ppida sellest juhtumist ja v\u00f5tta vajalikud meetmed, et v\u00e4ltida selle kordumist.<\/p>\n

Tagasis vaatamata tuleks tunnistada, et me ei pidanud vaikimisi seadma keskmine<\/b> prioriteet, kuni k\u00f5ik Ingester'id tootmisel on saanud k\u00f5rge<\/b> prioriteedi. Samuti oleks pidanud eelnevalt muretsema nende k\u00f5rge<\/b> prioriteedi. N\u00fc\u00fcd on k\u00f5ik parandatud. Loodame, et meie kogemus aitab teisi organisatsioone, kes kaaluvad pod'ide prioriteetide kasutamist Kuberneteses.<\/p>\n

Lisame t\u00e4iendava kontrolli taseme igasuguste t\u00e4iendavate objektide juurutamisel, mille seadistused on globaalsetele klastritele. Edaspidi hindame selliseid muudatusiilotka<\/i>suurema arvu inimeste poolt. Lisaks, muudatus, mis viis t\u00f5rkeni, peeti liiga ebaoluliseks iga\u00fche projektidokumendi jaoks \u2014 sellest arutleti ainult GitHubi probleemis. Edaspidi saadavad k\u00f5ik sellised konfiguratsioonimuudatused vastava projektidokumendiga.<\/p>\n

L\u00f5puks automatiseerime autentimisproksi tagasivahetuse suuruse muutmise, et v\u00e4ltida OOM-i \u00fclevoolu, mida olime tunnistajaks, ja anal\u00fc\u00fcsime m\u00f5\u00f5diku vaikeseadeid, mis on seotud tagasiv\u00f5tmise ja skaleerimisega, et tulevikus sarnaseid probleeme ennetada.<\/p>\n

Kogenud t\u00f5rkel oli ka m\u00f5ned positiivsed tagaj\u00e4rjed: saadud vajalike ressursside abil taastus Cortex automaatselt ilma t\u00e4iendava sekkumiseta. Saime ka v\u00e4\u00e4rtuslikku kogemust t\u00f6\u00f6tades Grafana Loki<\/a><\/noindex> \u2014 meie uue logide kogumise s\u00fcsteemiga, \u2014 mis aitas tagada, et k\u00f5ik Ingester'id k\u00e4itusid \u00f5igesti katkestuse ajal ja p\u00e4rast seda.<\/p>\n

P.S. t\u00f5lkijalt<\/h2>\n

\nLugege ka meie blogist:<\/p>\n