{"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\/cs\/blog\/administrirovanie\/kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs","title":{"rendered":"Jak priority pod\u016f v Kubernetes zp\u016fsobily prostoje v Grafana Labs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pozn. p\u0159ek.<\/b>: P\u0159edstavujeme v\u00e1m technick\u00e9 podrobnosti o d\u016fvodech ned\u00e1vn\u00e9ho v\u00fdpadku v provozu cloudov\u00e9 slu\u017eby, kterou spravuj\u00ed tv\u016frci Grafany. To je klasick\u00fd p\u0159\u00edklad toho, jak nov\u00e1 a zd\u00e1nliv\u011b u\u017eite\u010dn\u00e1 funkce, ur\u010den\u00e1 ke zlep\u0161en\u00ed kvality infrastruktury\u2026 m\u016f\u017ee u\u0161kodit, pokud se neberou v potaz \u010detn\u00e9 nuance jej\u00edho pou\u017eit\u00ed v produk\u010dn\u00edch prost\u0159ed\u00edch. Je skv\u011bl\u00e9, kdy\u017e se objevuj\u00ed takov\u00e9 materi\u00e1ly, kter\u00e9 umo\u017e\u0148uj\u00ed u\u010dit se nejen na vlastn\u00edch chyb\u00e1ch. Podrobnosti najdete v p\u0159ekladu tohoto textu od viceprezidenta pro produkt z Grafana Labs.<\/i><\/p>\n

\"Pozn.
\n
\nV p\u00e1tek 19. \u010dervence p\u0159estala slu\u017eba Hosted Prometheus v Grafana Cloud fungovat p\u0159ibli\u017en\u011b na 30 minut. Omlouv\u00e1m se v\u0161em klient\u016fm, kte\u0159\u00ed byli t\u00edmto v\u00fdpadkem zasa\u017eeni. Na\u0161\u00edm \u00fakolem je poskytovat pot\u0159ebn\u00e9 n\u00e1stroje pro monitoring a ch\u00e1peme, \u017ee jejich nedostupnost v\u00e1m zt\u011b\u017euje \u017eivot. Tento incident bereme velmi v\u00e1\u017en\u011b. V t\u00e9to pozn\u00e1mce vysv\u011btluji, co se stalo, jak jsme na to reagovali a co d\u011bl\u00e1me, abychom podobn\u00e9 situace odstranili.<\/a><\/noindex><\/p>\n

Pozad\u00ed<\/h2>\n

\nSlu\u017eba Grafana Cloud Hosted Prometheus je zalo\u017eena na Cortex<\/a><\/noindex> \u2014 projektu CNCF pro vytvo\u0159en\u00ed horizont\u00e1ln\u011b \u0161k\u00e1lovateln\u00e9, vysoce dostupn\u00e9, multitenantn\u00ed slu\u017eby Prometheus. Architektura Cortex se skl\u00e1d\u00e1 z \u0159ady samostatn\u00fdch mikroslu\u017eeb, z nich\u017e ka\u017ed\u00e1 pln\u00ed svou funkci: replikaci, ukl\u00e1d\u00e1n\u00ed, dotazy atd. Cortex se aktivn\u011b vyv\u00edj\u00ed, st\u00e1le se objevuj\u00ed nov\u00e9 mo\u017enosti a zvy\u0161uje se v\u00fdkonnost. Pravideln\u011b nasazujeme nov\u00e9 verze Cortex do cluster\u016f, aby klienti mohli vyu\u017e\u00edt t\u011bchto mo\u017enost\u00ed \u2013 Cortex m\u00e1 schopnost aktualizovat se bez v\u00fdpadk\u016f.<\/p>\n

Pro bezprobl\u00e9mov\u00e9 aktualizace slu\u017eba Ingester Cortex vy\u017eaduje dal\u0161\u00ed replikaci Ingesteru b\u011bhem procesu aktualizace. (Pozn. p\u0159ek.<\/b>: Ingester<\/a><\/noindex> \u2014 z\u00e1kladn\u00ed komponenta Cortexu. Jej\u00edm \u00fakolem je shroma\u017e\u010fovat trval\u00fd tok vzork\u016f, seskupovat je do chunk\u016f Prometheus a ukl\u00e1dat do datab\u00e1z\u00ed jako DynamoDB, BigTable nebo Cassandra.)<\/i> To umo\u017e\u0148uje star\u00fdm Ingester\u016fm p\u0159epos\u00edlat aktu\u00e1ln\u00ed data nov\u00fdm Ingester\u016fm. Je t\u0159eba poznamenat, \u017ee Ingesteri jsou n\u00e1ro\u010dn\u00ed na zdroje. Pro jejich fungov\u00e1n\u00ed je nutn\u00e9 m\u00edt 4 j\u00e1dra a 15 GB pam\u011bti na pod, tj. 25 % procesorov\u00e9ho v\u00fdkonu a pam\u011bti z\u00e1kladn\u00edho stroje v p\u0159\u00edpad\u011b na\u0161ich klastr\u016f Kubernetes. Obecn\u011b m\u00e1me v klastru obvykle mnohem v\u00edce nevyu\u017eit\u00fdch zdroj\u016f ne\u017e 4 j\u00e1dra a 15 GB pam\u011bti, proto m\u016f\u017eeme b\u011bhem aktualizac\u00ed snadno spou\u0161t\u011bt tyto dal\u0161\u00ed Ingesteri.<\/p>\n

Nicm\u00e9n\u011b \u010dasto se st\u00e1v\u00e1, \u017ee b\u011bhem norm\u00e1ln\u00edho provozu nen\u00ed na \u017e\u00e1dn\u00e9m ze stroj\u016f t\u011bchto 25 % nevyu\u017eit\u00fdch zdroj\u016f. A ani se o to nesna\u017e\u00edme: CPU a pam\u011b\u0165 jsou v\u017edy u\u017eite\u010dn\u00e9 pro jin\u00e9 procesy. Pro \u0159e\u0161en\u00ed tohoto probl\u00e9mu jsme se rozhodli vyu\u017e\u00edt Prioritizace Pod\u016f v Kubernetes<\/a><\/noindex>. My\u0161lenka spo\u010d\u00edv\u00e1 v tom, aby byl Ingester\u016fm p\u0159i\u0159azen vy\u0161\u0161\u00ed priorita ne\u017e jin\u00fdm (stateless) mikroslu\u017eb\u00e1m. Kdy\u017e pot\u0159ebujeme spustit dal\u0161\u00ed (N+1) Ingester, do\u010dasn\u011b vytla\u010dujeme jin\u00e9 men\u0161\u00ed pody. Tyto pody jsou p\u0159esunuty na voln\u00e9 zdroje na jin\u00fdch stroj\u00edch, \u010d\u00edm\u017e se vytvo\u0159\u00ed dostate\u010dn\u011b velk\u00e1 \"d\u00edra\" pro spu\u0161t\u011bn\u00ed dal\u0161\u00edho Ingesteru.<\/p>\n

Ve \u010dtvrtek 18. \u010dervence jsme nasadili \u010dty\u0159i nov\u00e9 \u00farovn\u011b priorit v na\u0161ich clusterech: kritick\u00e1<\/b>, vysokou<\/b>, st\u0159edn\u00ed<\/b> a n\u00edzk\u00e1<\/b>. Byly testov\u00e1ny na vnit\u0159n\u00edm klastru bez klientsk\u00e9ho provozu p\u0159ibli\u017en\u011b jeden t\u00fdden. Pody bez ur\u010den\u00e9 priority dostaly st\u0159edn\u00ed<\/b> prioritu, pro Ingester byla nastavena t\u0159\u00edda s vysokou<\/b> Pravidlo 4b: Pokud \u00faloha uvoln\u00ed CPU p\u0159ed vypr\u0161en\u00edm sv\u00e9ho \u010dasov\u00e9ho okna, jej\u00ed Kritick\u00e1<\/b> byla vyhrazena pro monitorov\u00e1n\u00ed (Prometheus, Alertmanager, node-exporter, kube-state-metrics atd.). N\u00e1\u0161 konfigura\u010dn\u00ed soubor je otev\u0159en\u00fd a m\u016f\u017eete se pod\u00edvat na PR zde<\/a><\/noindex>.<\/p>\n

Hav\u00e1rie<\/h2>\n

\nV p\u00e1tek 19. \u010dervence jeden z in\u017een\u00fdr\u016f spustil nov\u00fd vyhrazen\u00fd klastr Cortex pro velk\u00e9ho klienta. Konfigurace tohoto klastru nezahrnovala nov\u00e9 priority pod\u016f, a proto byly v\u0161em nov\u00fdm pod\u016fm p\u0159i\u0159azeny v\u00fdchoz\u00ed priority \u2014 st\u0159edn\u00ed<\/b>.<\/p>\n

V klastru Kubernetes chyb\u011bly zdroje pro nov\u00fd klastr Cortex a existuj\u00edc\u00ed produk\u010dn\u00ed klastr Cortex nebyl aktualizov\u00e1n (Ingesteri z\u016fstali bez vysok\u00e9<\/b> priorit). Proto\u017ee Ingesteri nov\u00e9ho klastru m\u011bli v\u00fdchoz\u00ed st\u0159edn\u00ed<\/b> prioritu, zat\u00edmco existuj\u00edc\u00ed produk\u010dn\u00ed pody pracovaly bez priority, Ingesteri nov\u00e9ho klastru vytla\u010dili Ingester z existuj\u00edc\u00edho produk\u010dn\u00edho klastru Cortex.<\/p>\n

ReplicaSet pro vytla\u010den\u00e9ho Ingesteru v produk\u010dn\u00edm klastru zjistil vytla\u010den\u00fd pod a vytvo\u0159il nov\u00fd, aby udr\u017eel stanoven\u00fd po\u010det replik. Nov\u00e9mu podu byla v\u00fdchoz\u00ed p\u0159i\u0159azena st\u0159edn\u00ed<\/b> priorita, a dal\u0161\u00ed \"star\u00fd\" Ingester v produkci p\u0159i\u0161el o zdroje. V\u00fdsledkem bylo lavinov\u00e9 proces<\/b>, co\u017e vedlo k vytla\u010den\u00ed v\u0161ech pod\u016f s Ingesterem pro produk\u010dn\u00ed klastry Cortex.<\/p>\n

Ingester uchov\u00e1vaj\u00ed stav (stateful) a ukl\u00e1daj\u00ed data za posledn\u00edch 12 hodin. To n\u00e1m umo\u017e\u0148uje je efektivn\u011bji komprimovat p\u0159ed zapisov\u00e1n\u00edm do dlouhodob\u00e9ho \u00falo\u017ei\u0161t\u011b. Cortex prov\u00e1d\u00ed shardov\u00e1n\u00ed dat podle s\u00e9ri\u00ed pomoc\u00ed distribuovan\u00e9 hash tabulky (Distributed Hash Table, DHT) a replikace ka\u017ed\u00e9 s\u00e9rie na t\u0159i Ingester se shodou v kv\u00f3rach ve stylu Dynamo. Cortex nezapisuje data do Ingester, kter\u00e9 jsou vypnut\u00e9. T\u00edmto zp\u016fsobem, kdy\u017e velk\u00e9 mno\u017estv\u00ed Ingester opou\u0161t\u00ed DHT, Cortex nem\u016f\u017ee zajistit dostate\u010dnou replikaci z\u00e1znam\u016f, a tyto \u201espadnou\u201c.<\/p>\n

Detekce a odstran\u011bn\u00ed<\/h2>\n

\nNov\u00e1 upozorn\u011bn\u00ed Prometheus na z\u00e1klad\u011b \"rozpo\u010dtu chyb\" (error-budget-based<\/i> \u2014 podrobnosti se objev\u00ed v budouc\u00edm \u010dl\u00e1nku) za\u010dala alarmovat po 4 minut\u00e1ch od zapo\u010det\u00ed v\u00fdpadku. B\u011bhem n\u00e1sleduj\u00edc\u00edch p\u0159ibli\u017en\u011b p\u011bti minut jsme provedli diagnostiku a nav\u00fd\u0161ili podkladov\u00fd cluster Kubernetes pro um\u00edst\u011bn\u00ed jak nov\u00fdch, tak existuj\u00edc\u00edch produk\u010dn\u00edch cluster\u016f.<\/p>\n

O p\u011bt minut pozd\u011bji star\u00e9 Ingester \u00fasp\u011b\u0161n\u011b zapsaly sv\u00e1 data, zat\u00edmco nov\u00e9 se spustily a clustery Cortex byly op\u011bt dostupn\u00e9.<\/p>\n

Dal\u0161\u00edch 10 minut bylo vy\u010dlen\u011bno na diagnostiku a opravy chyb out-of-memory (OOM) od reverzn\u00edch proxy server\u016f autentizace, um\u00edst\u011bn\u00fdch p\u0159ed Cortexem. OOM chyby byly zp\u016fsobeny desetin\u00e1sobn\u00fdm n\u00e1r\u016fstem QPS (jak se domn\u00edv\u00e1me, kv\u016fli p\u0159\u00edli\u0161 agresivn\u00edm po\u017eadavk\u016fm z klientsk\u00fdch server\u016f Prometheus).<\/p>\n

D\u016fsledky<\/h2>\n

\nCelkov\u00e1 doba v\u00fdpadku byla 26 minut. Data nebyla ztracena. Ingester \u00fasp\u011b\u0161n\u011b nahr\u00e1ly v\u0161echny in-memory data do dlouhodob\u00e9ho \u00falo\u017ei\u0161t\u011b. B\u011bhem v\u00fdpadku servery Prometheus klient\u016f ukl\u00e1daly do vyrovn\u00e1vac\u00ed pam\u011bti vzd\u00e1len\u00e9 (remote)<\/i> z\u00e1znamy pomoc\u00ed nov\u00e9ho API remote_write<\/a><\/noindex> na z\u00e1klad\u011b WAL (podle Callum Styan<\/a><\/noindex> z Grafana Labs) a opakovali ne\u00fasp\u011b\u0161n\u00e9 z\u00e1znamy po chyb\u011b.<\/p>\n

\"Pozn.
\nOperace z\u00e1pisu produk\u010dn\u00edho clusteru<\/i><\/p>\n

Z\u00e1v\u011bry<\/h2>\n

\nJe d\u016fle\u017eit\u00e9 se z tohoto incidentu pou\u010dit a p\u0159ijmout nezbytn\u00e1 opat\u0159en\u00ed, aby se p\u0159ede\u0161lo jeho opakov\u00e1n\u00ed.<\/p>\n

Kdy\u017e se ohl\u00e9dneme zp\u011bt, mus\u00edme p\u0159iznat, \u017ee byste nem\u011bli nastavovat v\u00fdchoz\u00ed st\u0159edn\u00ed<\/b> prioritu, dokud v\u0161echny Ingester v produkci nedostaly vysokou<\/b> prioritu. D\u00e1le bylo pot\u0159eba se v\u010das postarat o jejich vysokou<\/b> prioritu. Nyn\u00ed je v\u0161e opraveno. Douf\u00e1me, \u017ee na\u0161e zku\u0161enost pom\u016f\u017ee dal\u0161\u00edm organizac\u00edm, kter\u00e9 uva\u017euj\u00ed o pou\u017e\u00edv\u00e1n\u00ed priorit pod\u016f v Kubernetes.<\/p>\n

P\u0159id\u00e1me dal\u0161\u00ed \u00farove\u0148 kontroly nad nasazen\u00edm jak\u00fdchkoli dal\u0161\u00edch objekt\u016f, jejich\u017e konfigurace jsou glob\u00e1ln\u00ed pro cluster. Do budoucna budou takov\u00e9 zm\u011bny posuzov\u00e1ny v\u011bt\u0161\u00edm po\u010dtem lid\u00ed. D\u00e1le byla modifikace, kter\u00e1 vedla k selh\u00e1n\u00ed, pova\u017eov\u00e1na za p\u0159\u00edli\u0161 nev\u00fdznamnou pro samostatnou projektovou dokumentaci \u2014 byla projedn\u00e1v\u00e1na pouze v GitHub issue. Od tohoto okam\u017eiku budou v\u0161echny podobn\u00e9 zm\u011bny konfigurac\u00ed doprov\u00e1zeny odpov\u00eddaj\u00edc\u00ed projektovou dokumentac\u00ed.o<\/i>Nakonec automatizujeme zm\u011bnu velikosti reverzn\u00edho proxy serveru pro autentizaci, abychom p\u0159ede\u0161li OOM p\u0159i p\u0159et\u00ed\u017een\u00ed, \u010demu\u017e jsme byli sv\u011bdky, a analyzujeme v\u00fdchoz\u00ed parametry Promethea souvisej\u00edc\u00ed s n\u00e1vratem a \u0161k\u00e1lov\u00e1n\u00edm, abychom se do budoucna vyhnuli podobn\u00fdm probl\u00e9m\u016fm.<\/p>\n

Zaznamenan\u00e9 selh\u00e1n\u00ed m\u011blo tak\u00e9 n\u011bkter\u00e9 pozitivn\u00ed d\u016fsledky: po z\u00edsk\u00e1n\u00ed pot\u0159ebn\u00fdch zdroj\u016f se Cortex automaticky zotavil bez dal\u0161\u00edho z\u00e1sahu. Z\u00edskali jsme tak\u00e9 cenn\u00e9 zku\u0161enosti s<\/p>\n

\u2014 na\u0161\u00edm nov\u00fdm syst\u00e9mem agregace log\u016f, \u2014 kter\u00fd pomohl zajistit, \u017ee v\u0161echny ingestry spr\u00e1vn\u011b fungovaly b\u011bhem a po selh\u00e1n\u00ed. Grafana Loki<\/a><\/noindex> \u2014 n\u00e1\u0161 nov\u00fd syst\u00e9m agregace log\u016f, \u2014 kter\u00fd pomohl zajistit, \u017ee se v\u0161echny Ingester chovaly spr\u00e1vn\u011b b\u011bhem a po selh\u00e1n\u00ed.<\/p>\n

P.S. od p\u0159ekladatele<\/h2>\n

\nP\u0159e\u010dt\u011bte si tak\u00e9 n\u00e1\u0161 blog:<\/p>\n