{"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\/it\/blog\/administrirovanie\/kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs","title":{"rendered":"Come le priorit\u00e0 dei pod in Kubernetes hanno causato downtime in Grafana Labs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota di traduzione.<\/b>: Presentiamo alla vostra attenzione i dettagli tecnici sui motivi del recente downtime del servizio cloud, gestito dai creatori di Grafana. Questo \u00e8 un esempio classico di come una nuova e apparentemente utile funzionalit\u00e0, destinata a migliorare la qualit\u00e0 dell'infrastruttura... possa invece nuocere se non si prevedono i numerosi aspetti del suo utilizzo nella realt\u00e0 di produzione. \u00c8 meraviglioso quando emergono materiali come questi, che consentono di imparare non solo dai propri errori. I dettagli sono nella traduzione di questo testo da parte del vicepresidente del prodotto di Grafana Labs.<\/i><\/p>\n

\"Come
\n
\nVenerd\u00ec 19 luglio, il servizio Hosted Prometheus in Grafana Cloud ha smesso di funzionare per circa 30 minuti. Mi scuso con tutti i clienti che hanno subito il guasto. Il nostro compito \u00e8 fornire gli strumenti necessari per il monitoraggio, e comprendiamo che la loro mancanza complica la vostra vita. Prendiamo molto sul serio questo incidente. In questa nota spieghiamo cosa \u00e8 successo, come abbiamo reagito e cosa stiamo facendo per evitare che accada di nuovo.<\/a><\/noindex><\/p>\n

Antefatti<\/h2>\n

\nIl servizio Grafana Cloud Hosted Prometheus si basa su Cortex<\/a><\/noindex> \u2014 un progetto CNCF volto a creare un servizio Prometheus orizzontalmente scalabile, altamente disponibile e multi-tenant. L'architettura di Cortex consiste in un insieme di microservizi separati, ognuno dei quali svolge una propria funzione: replica, archiviazione, richieste, ecc. Cortex \u00e8 in attiva sviluppo e sta continuamente acquisendo nuove funzionalit\u00e0 e migliorando le prestazioni. Rilasciamo regolarmente nuove versioni di Cortex nei cluster, affinch\u00e9 i clienti possano beneficiare di queste funzionalit\u00e0, dato che Cortex \u00e8 capace di aggiornarsi senza downtime.<\/p>\n

Per aggiornamenti senza interruzioni, il servizio Ingester di Cortex richiede un'istanza aggiuntiva di Ingester durante il processo di aggiornamento. (Nota di traduzione.<\/b>: Ingester<\/a><\/noindex> \u2014 componente fondamentale di Cortex. Il suo compito \u00e8 raccogliere un flusso costante di campioni, raggrupparli in chunk per Prometheus e salvarli in un database come DynamoDB, BigTable o Cassandra.<\/i> Questo consente agli Ingester pi\u00f9 vecchi di inviare i dati attuali ai nuovi Ingester. Vale la pena notare che gli Ingester sono esigenti in termini di risorse. Per il loro funzionamento \u00e8 necessario avere 4 core e 15 GB di memoria per pod, ovvero il 25% della potenza di calcolo e della memoria della macchina di base nei nostri cluster Kubernetes. In generale, abbiamo solitamente molte pi\u00f9 risorse inutilizzate nel cluster rispetto a 4 core e 15 GB di memoria, quindi possiamo facilmente avviare questi ulteriori Ingester durante gli aggiornamenti.<\/p>\n

Tuttavia, spesso accade che durante un funzionamento normale nessuna delle macchine disponga di queste risorse inutilizzate del 25%. E non ci aspettiamo nemmeno che sia cos\u00ec: CPU e memoria saranno sempre utili per altri processi. Per risolvere questo problema, abbiamo deciso di utilizzare le Priorit\u00e0 dei Pod di Kubernetes<\/a><\/noindex>L'idea \u00e8 di assegnare agli Ingester una priorit\u00e0 pi\u00f9 elevata rispetto ad altri microservizi (stateless). Quando dobbiamo avviare un Ingester aggiuntivo (N+1), spostiamo temporaneamente altri pod di minori dimensioni. Questi pod vengono trasferiti a risorse disponibili su altre macchine, lasciando una 'fessura' sufficientemente ampia per avviare il nuovo Ingester.<\/p>\n

Gioved\u00ec, 18 luglio, abbiamo distribuito quattro nuovi livelli di priorit\u00e0 nei nostri cluster: critico<\/b>, alto<\/b>, medio<\/b> e basso<\/b>Sono stati testati su un cluster interno senza traffico client per circa una settimana. Per impostazione predefinita, i pod senza priorit\u00e0 specificata ricevevano medio<\/b> priorit\u00e0, per gli Ingester \u00e8 stata impostata una classe con alta<\/b> priorit\u00e0. Critico<\/b> \u00e8 stato riservato per il monitoraggio (Prometheus, Alertmanager, node-exporter, kube-state-metrics, ecc.). La nostra configurazione \u00e8 aperta e puoi visualizzare la PR qui<\/a><\/noindex>.<\/p>\n

Guasto<\/h2>\n

\nVenerd\u00ec 19 luglio, un ingegnere ha avviato un nuovo cluster Cortex dedicato per un grande cliente. La configurazione per questo cluster non includeva nuove priorit\u00e0 per i pod, quindi a tutti i nuovi pod veniva assegnata la priorit\u00e0 predefinita \u2014 medio<\/b>.<\/p>\n

Nel cluster Kubernetes non c'erano risorse sufficienti per il nuovo cluster Cortex, e il cluster di produzione esistente non \u00e8 stato aggiornato (gli Ingester sono rimasti senza alta<\/b> priorit\u00e0). Poich\u00e9 gli Ingester del nuovo cluster avevano per impostazione predefinita medio<\/b> priorit\u00e0, mentre i pod esistenti in produzione funzionavano senza priorit\u00e0, gli Ingester del nuovo cluster hanno sovrascritto gli Ingester del cluster di produzione esistente di Cortex.<\/p>\n

Il ReplicaSet per l'Ingester sovrascritto nel cluster di produzione ha rilevato il pod espulso e ha creato un nuovo pod per mantenere il numero di repliche specificato. Al nuovo pod \u00e8 stata assegnata per impostazione predefinita medio<\/b> la priorit\u00e0, e un altro \"vecchio\" Ingester nel production ha perso risorse. Il risultato \u00e8 stato un processo a valanga<\/b>, che ha portato all'espulsione di tutti i pod con Ingester per i cluster di produzione di Cortex.<\/p>\n

Gli Ingester sono stateful e conservano i dati delle ultime 12 ore. Questo ci consente di comprimere i dati in modo pi\u00f9 efficace prima di registrarli nello storage a lungo termine. Per questo Cortex effettua lo sharding dei dati per serie, utilizzando una tabella hash distribuita (Distributed Hash Table, DHT), e replica ogni serie su tre Ingester utilizzando la coerenza di quorum in stile Dynamo. Cortex non scrive dati su Ingester disattivati. Pertanto, quando un numero elevato di Ingester lascia la DHT, Cortex non pu\u00f2 garantire una replica sufficiente delle registrazioni, e queste<\/p>\n

Rilevamento e risoluzione<\/h2>\n

\nNuove notifiche Prometheus basate sul \"budget degli errori\" (error-budget-based<\/i> \u2014 i dettagli saranno forniti in un articolo futuro) hanno iniziato a suonare l'allerta dopo 4 minuti dall'inizio dello spegnimento. Nei successivi cinque minuti circa abbiamo eseguito la diagnostica e abbiamo aumentato il cluster Kubernetes sottostante per ospitare sia i nuovi che i gi\u00e0 esistenti cluster di produzione.<\/p>\n

Cinque minuti dopo, i vecchi Ingester hanno registrato con successo i loro dati, mentre i nuovi sono stati avviati e i cluster Cortex sono tornati di nuovo disponibili.<\/p>\n

Ci sono voluti altri 10 minuti per la diagnostica e la risoluzione degli errori di out-of-memory (OOM) dai server proxy di autenticazione inversa, posizionati davanti a Cortex. Gli errori OOM sono stati causati da un incremento dieci volte superiore delle QPS (presumibilmente a causa di richieste eccessivamente aggressive dai server Prometheus dei clienti).<\/p>\n

Conseguenze<\/h2>\n

\nLa durata totale del downtime \u00e8 stata di 26 minuti. I dati non sono stati persi. Gli Ingester hanno caricato con successo tutti i dati in-memory nello storage a lungo termine. Durante l'interruzione, i server Prometheus dei clienti hanno mantenuto in buffer i dati remoti (remote)<\/i> utilizzando il nuovo API remote_write<\/a><\/noindex> basato su WAL (scritto da Callum Styan<\/a><\/noindex> di Grafana Labs) e hanno ripetuto le registrazioni non riuscite dopo il guasto.<\/p>\n

\"Come
\nOperazioni di scrittura del cluster di produzione<\/i><\/p>\n

Conclusioni<\/h2>\n

\n\u00c8 importante trarre insegnamenti da questo incidente e adottare le misure necessarie per evitare che si ripeta.<\/p>\n

Guardando indietro, bisogna ammettere che non avremmo dovuto impostare per default medio<\/b> priorit\u00e0, finch\u00e9 tutti gli Ingester in produzione non hanno ricevuto alto<\/b> con priorit\u00e0. Inoltre, sarebbe stato opportuno prendersi cura in anticipo delle loro alte<\/b> priorit\u00e0. Ora tutto \u00e8 sistemato. Ci auguriamo che la nostra esperienza possa aiutare altre organizzazioni che stanno considerando l'uso delle priorit\u00e0 dei pod in Kubernetes.<\/p>\n

Aggiungeremo un ulteriore livello di controllo sul dispiegamento di eventuali oggetti aggiuntivi, la cui configurazione \u00e8 globale per il cluster. Da ora in poi, tali modifiche saranno valutate daun<\/i>numero maggiore di persone. Inoltre, la modifica che ha portato al guasto \u00e8 stata ritenuta troppo insignificante per un documento di progetto separato \u2014 \u00e8 stata discussa solo in un'issue di GitHub. Da questo momento in poi, tutte le modifiche simili alle configurazioni saranno accompagnate dalla relativa documentazione di progetto.<\/p>\n

Infine, automatizzeremo il ridimensionamento del reverse proxy per l'autenticazione per prevenire OOM durante un sovraccarico, di cui siamo stati testimoni, e analizzeremo i parametri di Prometheus predefiniti relativi al rollback e al ridimensionamento, per prevenire in futuro problemi simili.<\/p>\n

Il guasto subito ha avuto anche alcune conseguenze positive: ottenendo le risorse necessarie, Cortex si \u00e8 riavviato automaticamente senza ulteriori interventi. Abbiamo anche appreso preziose lezioni lavorando con Grafana Loki<\/a><\/noindex> \u2014 il nostro nuovo sistema di aggregazione dei log, \u2014 che ha aiutato a garantire che tutti gli Ingester si comportassero correttamente durante e dopo il guasto.<\/p>\n

P.S. dal traduttore<\/h2>\n

\nLeggi anche nel nostro blog:<\/p>\n