{"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 seisakuid Grafana Labs'is","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

M\u00e4rk. t\u00f5lge.<\/b>: Tutvustame teile tehnilisi detaile hiljutise seisu kohta Grafana looja poolt hallatava pilveteenuse t\u00f6\u00f6s. See on klassikaline n\u00e4ide sellest, kuidas uus ja n\u00e4iliselt \u00e4\u00e4rmiselt kasulik funktsioon, mille eesm\u00e4rk on infrastruktuuri kvaliteeti parandada, v\u00f5ib kahjustada, kui ei arvestata selle rakendamise paljusid n\u00fcansse tootmises. Imeline, kui sellised materjalid ilmuvad, v\u00f5imaldades \u00f5ppida mitte ainult oma vigadest. \u00dcksikasjad leiate Grafana Labs'i toote asepresidendi t\u00f5lgitud tekstist.<\/i><\/p>\n

\"Kuidas
\n
\nReedel, 19. juulil peatus Hosted Prometheus teenus Grafana Cloudis umbes 30 minutiks. Palun vabandust k\u00f5igi klientide ees, kes said rikete t\u00f5ttu kannatada. Meie \u00fclesanne on pakkuda vajalikke j\u00e4lgimist\u00f6\u00f6riistu ja m\u00f5istame, et nende puudumine muudab teie elu keerulisemaks. Suhtume sellesse juhtumisse \u00e4\u00e4rmiselt t\u00f5siselt. selles m\u00e4rkuses selgitatakse, mis juhtus, kuidas me sellele reageerisime ja mida me teeme, et selline asi enam ei korduks.<\/a><\/noindex><\/p>\n

Eelalugu<\/h2>\n

\nGrafana Cloud Hosted Prometheuse teenus p\u00f5hineb Cortex<\/a><\/noindex> \u2014 CNCF projektis, mille eesm\u00e4rgiks on luua horisontaalselt skaleeritav, k\u00f5rge k\u00e4ttesaadavuse ja mitme kliendi teenus Prometheus. Cortexi arhitektuur koosneb kogumist eraldi mikroteenustest, millest iga\u00fchel on oma funktsioon: replikatsioon, salvestamine, p\u00e4ringud jne. Cortexi arendamine on aktiivne, uusi funktsioone lisandub pidevalt ning j\u00f5udlus paraneb. T\u00f5ukame regulaarselt uusi Cortexi versioone klastritesse, et kliendid saaksid nende v\u00f5imalustest kasu - \u00f5nneks suudab Cortex uuendusi teha katkestusteta.<\/p>\n

Ilma t\u00f5rgeteta uuenduste jaoks n\u00f5uab Ingester Cortex'i teenus uuendamise protsessi ajal t\u00e4iendavat Ingester'i koopiat. (M\u00e4rk. t\u00f5lge.<\/b>: Ingester<\/a><\/noindex> \u2014 Cortex'i p\u00f5hikomponent. Selle \u00fclesanne on koguda pidevat voolu n\u00e4idiseid, r\u00fchmitada need chunk'ideks Prometheus'e jaoks ja salvestada andmebaasidesse nagu DynamoDB, BigTable v\u00f5i Cassandra.<\/i> See v\u00f5imaldab vanadel Ingester'idelt edastada praegused andmed uuteks Ingester'iteks. Tasub m\u00e4rkida, et Ingester'id on ressursin\u00f5udlikud. Nende t\u00f6\u00f6ks on vajalik 4 tuuma ja 15 GB m\u00e4lu iga pod'i kohta, st 25% p\u00f5himasina protsessoriv\u00f5imsusest ja m\u00e4lust meie Kubernetes'e klastrites. \u00dcldiselt on meil tavaliselt klastrites palju rohkem kasutamata ressursse kui 4 tuuma ja 15 GB m\u00e4lu, seega suudame kergesti k\u00e4ivitada neid t\u00e4iendavaid Ingester'eid uuenduste ajal.<\/p>\n

Kuid sageli juhtub, et normaalse t\u00f6\u00f6 k\u00e4igus ei ole \u00fchelgi masinal neid 25% kasutamata ressursse. Me ei p\u00fc\u00fca ka: CPU ja m\u00e4lu on alati vajalikud teistele protsessidele. Selle probleemi lahendamiseks otsustasime kasutada Kubernetes Pod Priorities<\/a><\/noindex>. Idee on anda Ingester'itele k\u00f5rgem prioriteet kui teistele (stateless) mikroteenustele. Kui meil on vaja k\u00e4ivitada t\u00e4iendav (N+1) Ingester, siis ajutiselt t\u00f5ukame v\u00e4lja teised, v\u00e4iksemad pod'id. Need pod'id liiguvad vabadusse teistes masinates, j\u00e4ttes piisavalt suurt 'avatust' t\u00e4iendava Ingester'i k\u00e4ivitamiseks.<\/p>\n

Neljap\u00e4eval, 18. juulil, k\u00e4ivitasime oma klusterites neli uut prioriteedi taset: kriitiline<\/b>, k\u00f5rge<\/b>, keskmine<\/b> ja madal<\/b>. Need to be tested in an internal cluster without client traffic for about a week. By default, pods without specified priority received keskmine<\/b> priority, while a class was set for the Ingester k\u00f5rge<\/b> Reegel 4a: Kui \u00fclesanne kasutab t\u00e4ielikult ette n\u00e4htud ajavahemikku, siis selle Kriitiline<\/b> oli reserveeritud seire jaoks (Prometheus, Alertmanager, node-exporter, kube-state-metrics jne). Meie konfiguratsioon on avatud, ja PR-i saab vaadata siit<\/a><\/noindex>.<\/p>\n

H\u00e4da<\/h2>\n

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

The Kubernetes cluster lacked resources for the new Cortex cluster, and the existing production Cortex cluster was not updated (the Ingester remained without k\u00f5rge<\/b> priority). Since the Ingester of the new cluster had default keskmine<\/b> priority, while existing production pods operated without any priority, the Ingester of the new cluster pushed out the Ingester 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 by default keskmine<\/b> prioriteet ja j\u00e4rgmine \"vana\" Ingester tootmises kaotas ressursid. Tulemuseks oli lapidaarne protsess<\/b>, which led to the eviction of all ingester pods for the production Cortex clusters.<\/p>\n

Ingester'id on oleku s\u00e4ilitavad (stateful) ja hoiab andmeid viimase 12 tunni jooksul. See v\u00f5imaldab meil neid enne pikaajalisse salvestusse kirjutamist efektiivsemalt tihendada. Selleks jagab Cortex andmeid sarjade kaupa, kasutades hajusatud hash-tabelit (Distributed Hash Table, DHT) ning replitseerib iga sarja kolmele Ingester'ile Dynamo stiilis kvoorumip\u00f5hise kokkuleppega. Cortex ei kirjuta andmeid Ingester'itele, mis on v\u00e4lja l\u00fclitatud. Seega, kui suur hulk Ingester'eid DHT-st lahkub, ei suuda Cortex tagada piisavat kirje replitseerimist ning need \u201elangevad\u201d.<\/p>\n

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

\nUued Prometheuse teavitused, mis p\u00f5hinevad \"veabud\u017eetil\" (error-budget-based<\/i> \u2014 \u00fcksikasjad tulevad tulevases artiklis) hakkasid nad 4 minutit p\u00e4rast katkestust h\u00e4irekella l\u00f6\u00f6ma. J\u00e4rgmise umbes viie minuti jooksul tegime diagnoosi ja suurendasime aluseks olevat Kubernetes klastrit, et majutada nii uut kui ka olemasolevat tootmisclustrit.<\/p>\n

Viis minutit hiljem salvestasid vanad Ingester'id oma andmed edukalt ning uued k\u00e4ivitusid, ja Cortexi klastrid said taas k\u00e4tte.<\/p>\n

Veel 10 minutit kulus diagnoosimiseks ja out-of-memory (OOM) t\u00f5rgete parandamiseks autentimisteenuste tagasiprokseerijates, mis asusid Cortex'i ees. OOM-t\u00f5rked olid p\u00f5hjustatud k\u00fcmnekordsest QPS kasvust (nagu me arvame, p\u00f5hjustatud liiga agressiivsetest p\u00e4ringutest kliendi Prometheuse serveritest).<\/p>\n

Tagaj\u00e4rjed<\/h2>\n

\n\u00dcldine seisakukestus oli 26 minutit. Andmeid ei kadunud. Ingester'id laadisid edukalt k\u00f5ik in-memory andmed pikaajalisse salvestusse. Klientide Prometheus serverid salvestasid eemalduse ajal andmed vahem\u00e4llu. (remote)<\/i> kirjed uus API remote_write<\/a><\/noindex> WAL-i p\u00f5hjal (autor Callum Styan<\/a><\/noindex> Grafana Labs'ist) ja kordasid p\u00e4rast t\u00f5rget eba\u00f5nnestunud salvestusi.<\/p>\n

\"Kuidas
\nTootmisklastra kirjutamise toimingud<\/i><\/p>\n

J\u00e4reldused<\/h2>\n

\nOluline on selle juhtumi \u00f5ppetunnid v\u00e4lja noppida ja v\u00f5tta vajalikud meetmed, et v\u00e4ltida selle kordumist.<\/p>\n

Tagasi vaadates tuleb tunnistada, et me ei pidanud default'ina seadma keskmine<\/b> prioriteet, kuni k\u00f5ik Ingester'id tootmises said k\u00f5rge<\/b> prioriteedi. Lisaks oleks pidanud hoolitsema nende k\u00f5rge<\/b> prioriteedi eest. N\u00fc\u00fcd on k\u00f5ik parandatud. Loodame, et meie kogemus aitab teisi organisatsioone, kes kaaluvad pod'ide prioriteetide kasutuselev\u00f5ttu Kuberneteses.<\/p>\n

Lisame t\u00e4iendava taseme kontrolli igasuguste t\u00e4iendavate objektide juurutamiseks, mille konfiguratsioonid on globaalseted klastrile. Edaspidi hinnatakse sarnaseid muudatusio<\/i>suurema inimeste arvu poolt. Lisaks peeti rikutud modifikatsiooni eraldi projektidokumendi jaoks liiga t\u00fchiseks \u2014 seda arutati ainult GitHubi teemades. Alates sellest hetkest saadik kaasnevad k\u00f5ik sellised konfiguratsioonimuudatused vastava projektidokumentatsiooniga.<\/p>\n

L\u00f5puks automatiseerime autentimiss\u00fcsteemi tagasip\u00f6\u00f6rduva serveri suuruse muutmise, et v\u00e4ltida OOM-i \u00fclekoormuse korral, mida oleme kogeda saanud, ja anal\u00fc\u00fcsime Prometheuse vaikeparameetreid, mis on seotud tagasip\u00f6\u00f6rdumise ja skaleerimisega, et tulevikus selliseid probleeme ennetada.<\/p>\n

Kogetud t\u00f5rkel oli ka positiivseid tagaj\u00e4rgi: vajalikud ressursid k\u00e4eulatuses, Cortex taastati automaatselt ilma t\u00e4iendava sekkumiseta. Samuti saime v\u00e4\u00e4rtuslikke kogemusi t\u00f6\u00f6tades Grafana Loki<\/a><\/noindex> \u2014 meie uue logide agregatsiooni s\u00fcsteemiga, \u2014 mis aitas tagada, et k\u00f5ik Ingester'id k\u00e4itusid n\u00f5uetekohaselt nii katkestuse ajal kui ka p\u00e4rast seda.<\/p>\n

P.S. t\u00f5lkija m\u00e4rkused<\/h2>\n

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