{"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\/ro\/blog\/administrirovanie\/kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs","title":{"rendered":"Cum priorit\u0103\u021bile pod-urilor \u00een Kubernetes au dus la \u00eentreruperi \u00een Grafana Labs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota traduc\u0103torului.<\/b>: V\u0103 prezent\u0103m detalii tehnice despre cauzele recentei \u00eentreruperi a func\u021bion\u0103rii serviciului de cloud, administrat de creatorii Grafana. Acesta este un exemplu clasic despre cum o nou\u0103 caracteristic\u0103, care p\u0103rea extrem de util\u0103, destinat\u0103 s\u0103 \u00eembun\u0103t\u0103\u021beasc\u0103 infrastructura\u2026 poate cauza probleme dac\u0103 nu se iau \u00een considerare multiplele nuan\u021be ale utiliz\u0103rii sale \u00een medii de produc\u021bie. Este minunat c\u00e2nd apar materiale care permit \u00eenv\u0103\u021barea nu doar din propriile gre\u0219eli. Detalii \u2014 \u00een traducerea acestui text de la vicepre\u0219edintele de produs de la Grafana Labs.<\/i><\/p>\n

\"Not\u0103
\n
\nVineri, 19 iulie, serviciul Hosted Prometheus din Grafana Cloud a \u00eencetat s\u0103 func\u021bioneze timp de aproximativ 30 de minute. Ne cerem scuze tuturor clien\u021bilor afecta\u021bi de aceast\u0103 \u00eentrerupere. Sarcina noastr\u0103 este s\u0103 furniz\u0103m instrumentele necesare pentru monitorizare \u0219i \u00een\u021belegem c\u0103 lipsa acestora \u00eengreuneaz\u0103 via\u021ba dumneavoastr\u0103. Lu\u0103m acest incident foarte \u00een serios. \u00cen aceast\u0103 not\u0103 explic\u0103m ce s-a \u00eent\u00e2mplat, cum am reac\u021bionat la aceasta \u0219i ce facem pentru a evita ca un astfel de incident s\u0103 se repete.<\/a><\/noindex><\/p>\n

Povestea<\/h2>\n

\nServiciul Grafana Cloud Hosted Prometheus se bazeaz\u0103 pe Cortex<\/a><\/noindex> \u2014 proiectul CNCF pentru crearea unui serviciu Prometheus scalabil horizontal, disponibil \u00een mod \u00eenalt \u0219i multi-tenant. Arhitectura Cortex se compune dintr-un set de microservicii separate, fiecare av\u00e2nd propria func\u021bie: replicare, stocare, interog\u0103ri etc. Cortex este activ dezvoltat, av\u00e2nd \u00een mod constant noi caracteristici \u0219i \u00eembun\u0103t\u0103\u021biri ale performan\u021bei. Implement\u0103m regulat noi versiuni Cortex \u00een clustere, astfel \u00eenc\u00e2t clien\u021bii s\u0103 poat\u0103 beneficia de aceste caracteristici \u2014 de altfel, Cortex permite actualiz\u0103ri f\u0103r\u0103 \u00eentrerupere.<\/p>\n

Pentru actualiz\u0103ri f\u0103r\u0103 \u00eentreruperi, serviciul Ingester al Cortex-ului necesit\u0103 o replic\u0103 suplimentar\u0103 a Ingester-ului \u00een timpul procesului de actualizare. (Nota traduc\u0103torului.<\/b>: Ingester<\/a><\/noindex> \u2014 componenta de baz\u0103 a Cortex-ului. Sarcina sa este de a colecta un flux constant de mostre, de a le grupa \u00een chunk-uri pentru Prometheus \u0219i de a le salva \u00eentr-o baz\u0103 de date precum DynamoDB, BigTable sau Cassandra.<\/i> Acest lucru permite vechilor Ingester-e s\u0103 transmit\u0103 datele curente noilor Ingester-e. Este de men\u021bionat c\u0103 Ingester-ele sunt resursocare. Pentru func\u021bionarea lor, este necesar s\u0103 avem c\u00e2te 4 nuclee \u0219i 15 GB de memorie pe pod, adic\u0103 25% din puterea de procesare \u0219i memoria ma\u0219inii de baz\u0103 \u00een cazul clusterele noastre Kubernetes. \u00cen general, de obicei avem mult mai multe resurse neutilizate \u00een cluster dec\u00e2t cele 4 nuclee \u0219i 15 GB de memorie, astfel \u00eenc\u00e2t putem rula cu u\u0219urin\u021b\u0103 aceste Ingester-e suplimentare \u00een timpul actualiz\u0103rilor.<\/p>\n

Totu\u0219i, adesea se \u00eent\u00e2mpl\u0103 ca, \u00een timpul func\u021bion\u0103rii normale, s\u0103 nu fie disponibile aceste 25% din resursele nefolosite pe nicio ma\u0219in\u0103. \u0218i nici nu dorim asta: CPU-ul \u0219i memoria vor fi \u00eentotdeauna utile pentru alte procese. Pentru a rezolva aceast\u0103 problem\u0103, am decis s\u0103 folosim Priorit\u0103\u021bile Pod-urilor Kubernetes<\/a><\/noindex>. Ideea este de a atribui Ingester-elor o prioritate mai mare dec\u00e2t altor microservicii (stateless). C\u00e2nd trebuie s\u0103 lans\u0103m un Ingester suplimentar (N+1), temporar excludem alte pod-uri mai mici. Aceste pod-uri sunt mutate \u00een resursele libere de pe alte ma\u0219ini, l\u0103s\u00e2nd o \u201egaur\u0103\u201d suficient de mare pentru lansarea unui Ingester suplimentar.<\/p>\n

Pe 18 iulie, joi, am desf\u0103\u0219urat patru noi niveluri de prioritate \u00een clusterele noastre: critic<\/b>, unui<\/b>, mediu<\/b> \u0219i sc\u0103zut<\/b>. Ele au fost testate pe un cluster intern f\u0103r\u0103 trafic de clien\u021bi timp de aproximativ o s\u0103pt\u0103m\u00e2n\u0103. \u00cen mod implicit, pod-urile f\u0103r\u0103 prioritate specificat\u0103 primeau mediu<\/b> prioritate, pentru Ingester-e a fost stabilit un clas\u0103 cu ridicat<\/b> prioritate. Critic<\/b> a fost rezervat pentru monitorizare (Prometheus, Alertmanager, node-exporter, kube-state-metrics etc.). Configura\u021bia noastr\u0103 este deschis\u0103, iar PR-ul poate fi vizualizat aici<\/a><\/noindex>.<\/p>\n

Dezastru<\/h2>\n

\nVineri, 19 iulie, unul dintre ingineri a lansat un nou cluster dedicat Cortex pentru un client mare. Configura\u021bia pentru acest cluster nu includea noi priorit\u0103\u021bi pentru pod-uri, astfel c\u0103 tuturor noilor pod-uri le-a fost atribuit\u0103 prioritatea implicit\u0103 \u2014 mediu<\/b>.<\/p>\n

\u00cen clusterul Kubernetes nu au fost suficiente resurse pentru noul cluster Cortex, iar clusterul de produc\u021bie existent Cortex nu a fost actualizat (Ingester-ele au r\u0103mas f\u0103r\u0103 prioritate<\/b> prioritate). Deoarece Ingester-ele noului cluster aveau implicit mediu<\/b> prioritate, iar pod-urile existente \u00een produc\u021bie func\u021bionau f\u0103r\u0103 nici o prioritate, Ingester-ele noului cluster au exclus Ingester-ele din clusterul de produc\u021bie existent Cortex.<\/p>\n

ReplicaSet pentru Ingester-ul exclus din cluster-ul de produc\u021bie a descoperit pod-ul exclus \u0219i a creat unul nou pentru a men\u021bine num\u0103rul specificat de copii. Nouului pod i s-a atribuit \u00een mod implicit mediu<\/b> prioritate, iar vechiul Ingester din produc\u021bie a r\u0103mas f\u0103r\u0103 resurse. Rezultatul a fost un proces \u00een aval<\/b>, ceea ce a dus la excluderea tuturor pod-urilor cu Ingester pentru clusterele de produc\u021bie ale Cortex-ului.<\/p>\n

Ingester-urile men\u021bin starea (stateful) \u0219i p\u0103streaz\u0103 datele din ultimele 12 ore. Acest lucru ne permite s\u0103 le comprim\u0103m mai eficient \u00eenainte de a le scrie \u00een stocarea pe termen lung. Pentru aceasta, Cortex realizeaz\u0103 \u0219arding-ul datelor pe serii, folosind o tabel\u0103 de dispersie distribuit\u0103 (Distributed Hash Table, DHT), \u0219i replic\u0103 fiecare serie pe trei Ingester-e prin consim\u021b\u0103m\u00e2ntul de tip quorum \u00een stil Dynamo. Cortex nu scrie date \u00een Ingester-urile care sunt deconectate. Astfel, atunci c\u00e2nd un num\u0103r mare de Ingester-e p\u0103r\u0103sesc DHT, Cortex nu poate asigura replicarea suficient\u0103 a \u00eenregistr\u0103rilor, iar acestea \u201ecad\u201d.<\/p>\n

Detectare \u0219i remediere<\/h2>\n

\nNoile notific\u0103ri Prometheus bazate pe \u00abbugetul de erori\u00bb (error-budget-based<\/i> \u2014 detalii vor ap\u0103rea \u00eentr-un articol viitor) au \u00eenceput s\u0103 emit\u0103 alarm\u0103 la 4 minute de la \u00eenceperea opririi. \u00cen urm\u0103toarele aproximativ cinci minute, am realizat diagnostice \u0219i am extins clusterul Kubernetes de baz\u0103 pentru a g\u0103zdui at\u00e2t clusterele de produc\u021bie noi, c\u00e2t \u0219i pe cele existente.<\/p>\n

Dup\u0103 \u00eenc\u0103 cinci minute, vechile Ingester-e au \u00eenregistrat cu succes datele lor, iar noile \u2013 s-au pornit, iar clusterele Cortex au redevenit disponibile.<\/p>\n

\u00cenc\u0103 10 minute au fost necesare pentru diagnosticare \u0219i remedierea erorilor de tip out-of-memory (OOM) de la serverele proxy de autentificare, situate \u00een fa\u021ba Cortex. Erorile OOM au fost cauzate de o cre\u0219tere de zece ori a QPS (a\u0219a cum b\u0103nuim, din cauza solicit\u0103rilor excesiv de agresive de la serverele clientului Prometheus).<\/p>\n

Consecin\u021be<\/h2>\n

\nDurata total\u0103 a \u00eentreruperii a fost de 26 de minute. Datele nu au fost pierdute. Ingester-urile au \u00eenc\u0103rcat cu succes toate datele in-memory \u00een stocarea pe termen lung. \u00cen timpul deconect\u0103rii, serverele Prometheus ale clien\u021bilor au tamponat datele \u00eendep\u0103rtate. (remote)<\/i> \u00eempreun\u0103 cu noul API remote_write<\/a><\/noindex> bazat pe WAL (de autoria Callum Styan<\/a><\/noindex> de la Grafana Labs) \u0219i au repetat \u00eenregistr\u0103rile e\u0219uate dup\u0103 c\u0103dere.<\/p>\n

\"Not\u0103
\nOpera\u021biile de scriere ale clusterului de produc\u021bie<\/i><\/p>\n

Conclusions<\/h2>\n

\nEste important s\u0103 extragem \u00eenv\u0103\u021b\u0103mintele din acest incident \u0219i s\u0103 lu\u0103m m\u0103surile necesare pentru a evita repetarea acestuia.<\/p>\n

Privind \u00eenapoi, trebuie s\u0103 recunoa\u0219tem c\u0103 nu ar fi trebuit s\u0103 stabilim implicit mediu<\/b> prioritate, p\u00e2n\u0103 c\u00e2nd toate Ingester-urile din produc\u021bie au primit. unui<\/b> prioritate. \u00cen plus, ar fi trebuit s\u0103 ne \u00eengrijim \u00een avans de prioritatea lor ridicat\u0103. Acum totul este corectat. Sper\u0103m c\u0103 experien\u021ba noastr\u0103 va ajuta alte organiza\u021bii care iau \u00een considerare utilizarea priorit\u0103\u021bilor pod-urilor \u00een Kubernetes.<\/b> Vom ad\u0103uga un nivel suplimentar de control asupra desf\u0103\u0219ur\u0103rii oric\u0103ror obiecte suplimentare, a c\u0103ror configura\u021bii sunt globale pentru cluster. De acum \u00eenainte, aceste modific\u0103ri vor fi evaluate de<\/p>\n

mai mult\u0103 lume. \u00cen plus, modificarea care a dus la e\u0219ec a fost considerat\u0103 prea nesemnificativ\u0103 pentru un document de proiect separat \u2014 a fost discutat\u0103 doar \u00een problema GitHub. De aici \u00eenainte, toate aceste modific\u0103ri de configura\u021bie vor fi \u00eenso\u021bite de documenta\u021bia corespunz\u0103toare a proiectului.mare<\/i>\u00cen final, vom automatiza redimensionarea serverului proxy de autentificare pentru a preveni OOM \u00een cazul unei suprasarcini, ceea ce am observat, \u0219i vom analiza parametrii Prometheus pe care \u00eei configur\u0103m implicit, legate de rollback \u0219i scalare, pentru a preveni problemele similare \u00een viitor.<\/p>\n

E\u0219ecul experimentat a avut \u0219i unele consecin\u021be pozitive: av\u00e2nd resursele necesare, Cortex s-a restabilit automat f\u0103r\u0103 interven\u021bie suplimentar\u0103. De asemenea, am c\u00e2\u0219tigat experien\u021b\u0103 valoroas\u0103 lucr\u00e2nd cu<\/p>\n

Grafana Loki \u2014 noul nostru sistem de agregare a log-urilor, \u2014 care a ajutat s\u0103 ne asigur\u0103m c\u0103 toate Ingester-urile s-au comportat corect \u00een timpul \u0219i dup\u0103 e\u0219ec.<\/a><\/noindex> \u2013 noua noastr\u0103 sistem de agregare a jurnalelor, \u2013 care a ajutat s\u0103 ne asigur\u0103m c\u0103 toate Ingester-urile s-au comportat corespunz\u0103tor \u00een timpul \u0219i dup\u0103 \u00eentrerupere.<\/p>\n

P.S. de la traduc\u0103tor<\/h2>\n

\nCiti\u021bi \u0219i \u00een blogul nostru:<\/p>\n