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

Nota del traduttore.<\/b>: Vi presentiamo i dettagli tecnici riguardanti le cause della recente interruzione del servizio cloud gestito dai creatori di Grafana. Questo \u00e8 un classico esempio di come una nuova, apparentemente utile funzionalit\u00e0, concepita per migliorare la qualit\u00e0 dell'infrastruttura\u2026 possa invece causare danni se non si considerano i numerosi aspetti del suo utilizzo in situazioni di production. \u00c8 fantastico che emergano materiali come questi, che consentono di imparare non solo dai propri errori. Maggiori dettagli nel testo tradotto dal 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. Ci scusiamo con tutti i clienti colpiti dall'interruzione. Il nostro compito \u00e8 fornire gli strumenti necessari per il monitoraggio e comprendiamo che la loro indisponibilit\u00e0 complica la vostra vita. Consideriamo questo incidente con la massima seriet\u00e0. In questo documento spieghiamo cosa \u00e8 successo, come abbiamo reagito e cosa stiamo facendo affinch\u00e9 non accada pi\u00f9.<\/a><\/noindex><\/p>\n

Contesto<\/h2>\n

\nIl servizio Grafana Cloud Hosted Prometheus si basa su Cortex<\/a><\/noindex> \u2014 un progetto CNCF per la creazione di un servizio Prometheus altamente disponibile, scalabile orizzontalmente e multi-tenant. L'architettura di Cortex \u00e8 composta da un insieme di microservizi, ognuno dei quali svolge una propria funzione: replica, archiviazione, query, ecc. Cortex \u00e8 in continua evoluzione con nuove funzionalit\u00e0 e miglioramenti delle prestazioni. Deployiamo regolarmente nuove versioni di Cortex nei cluster affinch\u00e9 i clienti possano beneficiare di queste innovazioni \u2014 fortunatamente, Cortex \u00e8 in grado di aggiornarsi senza downtime.<\/p>\n

Per gli aggiornamenti senza interruzioni, il servizio Ingester di Cortex richiede una replica aggiuntiva dell'Ingester durante il processo di aggiornamento. (Nota del traduttore.<\/b>: Ingester<\/a><\/noindex> \u2014 un componente fondamentale di Cortex. Il suo compito \u00e8 raccogliere un flusso continuo di campioni, raggrupparli in chunk per Prometheus e memorizzarli in un database come DynamoDB, BigTable o Cassandra.)<\/i> Questo consente agli Imbottitori pi\u00f9 vecchi di inviare i dati correnti ai nuovi Imbottitori. \u00c8 importante notare che gli Imbottitori richiedono molte risorse. Per funzionare, necessitano di 4 core e 15 GB di RAM per pod, cio\u00e8 il 25% della potenza di elaborazione e della memoria della macchina di base nei nostri cluster Kubernetes. Di norma, abbiamo di solito molte pi\u00f9 risorse inutilizzate nel cluster rispetto ai 4 core e 15 GB di RAM, quindi possiamo facilmente avviare questi Imbottitori aggiuntivi durante gli aggiornamenti.<\/p>\n

Tuttavia, spesso accade che durante il funzionamento normale non ci siano queste risorse inutilizzate del 25% su nessuna delle macchine. E non aspiriamo nemmeno a farlo: CPU e memoria saranno sempre utili per altri processi. Per affrontare questo problema, abbiamo deciso di utilizzare le prioritizzazioni dei Pod di Kubernetes<\/a><\/noindex>. L'idea \u00e8 quella di assegnare agli Imbottitori una priorit\u00e0 maggiore rispetto ad altri microservizi (stateless). Quando abbiamo bisogno di avviare un Ingester aggiuntivo (N+1), temporaneamente spostiamo altri pod minori. Questi pod sono trasferiti nelle risorse libere su altre macchine, lasciando un \"vuoto\" sufficientemente grande per avviare un Ingester aggiuntivo.<\/p>\n

Gioved\u00ec 18 luglio, abbiamo implementato quattro nuovi livelli di priorit\u00e0 nei nostri cluster: critica<\/b>, alta<\/b>, media<\/b> e bassa<\/b>. Sono stati testati su un cluster interno senza traffico client per circa una settimana. Per impostazione predefinita, i pod senza priorit\u00e0 assegnata ricevevano media<\/b> priorit\u00e0, per gli Ingester \u00e8 stata impostata una classe con alta<\/b> priorit\u00e0. Critica<\/b> \u00e8 stata riservata per il monitoraggio (Prometheus, Alertmanager, node-exporter, kube-state-metrics, ecc.). La nostra configurazione \u00e8 aperta e puoi consultare il PR qui<\/a><\/noindex>.<\/p>\n

Incidente<\/h2>\n

\nVenerd\u00ec 19 luglio, uno degli ingegneri ha avviato un nuovo cluster dedicato Cortex per un importante 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 per impostazione predefinita \u2014 media<\/b>.<\/p>\n

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

Il ReplicaSet per l'Ingester soppiantato nel cluster di produzione ha trovato il pod soppiantato e ne ha creato uno nuovo per mantenere il numero di repliche specificato. Al nuovo pod \u00e8 stata assegnata per impostazione predefinita media<\/b> la priorit\u00e0, e un altro \"vecchio\" Ingester nel production ha perso risorse. Il risultato \u00e8 stato un processo a catena<\/b>, il che ha portato alla sostituzione di tutti i pod con Ingester per i cluster di produzione di Cortex.<\/p>\n

Gli Ingester sono stati progettati per mantenere lo stato (stateful) e registrano i dati per le ultime 12 ore. Questo ci consente di effettuarne una compressione pi\u00f9 efficiente prima di scriverli nello storage a lungo termine. A tal fine, Cortex esegue lo sharding dei dati per serie utilizzando una tabella hash distribuita (Distributed Hash Table, DHT) e replica ogni serie su tre Ingester utilizzando una coerenza di quorum in stile Dynamo. Cortex non scrive dati sugli Ingester che sono disattivati. Pertanto, quando un numero elevato di Ingester lascia la DHT, Cortex non riesce a garantire una replicazione adeguata delle registrazioni, e queste \"falliscono\".<\/p>\n

Rilevamento e risoluzione<\/h2>\n

\nNuove notifiche di Prometheus basate sul \"budget degli errori\" (error-budget-based<\/i> \u2014 i dettagli saranno disponibili in un futuro articolo) hanno iniziato a suonare l'allerta dopo 4 minuti dall'inizio dell'interruzione. Nei successivi circa cinque minuti, abbiamo effettuato la diagnosi e abbiamo scalato il cluster sottostante di Kubernetes per ospitare sia i nuovi cluster che quelli esistenti in produzione.<\/p>\n

Altri cinque minuti dopo, gli Ingester vecchi hanno registrato con successo i loro dati e quelli nuovi sono stati avviati, ripristinando l'accessibilit\u00e0 ai cluster Cortex.<\/p>\n

Altri 10 minuti sono stati necessari per la diagnosi e la risoluzione degli errori out-of-memory (OOM) dai server proxy inversi di autenticazione situati davanti a Cortex. Gli errori OOM sono stati causati da un aumento decuplicato del QPS (presumibilmente a causa di richieste eccessivamente aggressive dai server Prometheus dei clienti).<\/p>\n

Conseguenze<\/h2>\n

\nLa durata totale dell'interruzione \u00e8 stata di 26 minuti. I dati non sono andati perduti. Gli Ingester hanno caricato con successo tutti i dati in memoria nello storage a lungo termine. Durante l'interruzione, i server Prometheus dei clienti hanno messo in buffer i dati remoti. (remote)<\/i> con il nuovo API remote_write<\/a><\/noindex> basato su WAL (di 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, dobbiamo riconoscere che non avremmo dovuto impostare per impostazione predefinita media<\/b> priorit\u00e0, finch\u00e9 tutti gli Ingester in produzione non hanno ricevuto alta<\/b> la priorit\u00e0. Inoltre, avremmo dovuto assicurarci in anticipo del loro elevato<\/b> priorit\u00e0. Ora tutto \u00e8 risolto. 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. In futuro, tali modifiche saranno valutate daun<\/i>maggiore numero di persone. Inoltre, la modifica che ha portato al fallimento \u00e8 stata considerata troppo insignificante per un documento di progetto separato - \u00e8 stata discussa solo in un problema di GitHub. D'ora in poi, tutte le modifiche alle configurazioni simili saranno accompagnate dalla documentazione di progetto appropriata.<\/p>\n

Infine, automatizziamo il ridimensionamento del server proxy inverso di autenticazione per prevenire l'OOM durante il sovraccarico, un episodio che abbiamo vissuto, e analizzeremo le impostazioni di default di Prometheus relative al rollback e al ridimensionamento, per evitare in futuro problemi simili.<\/p>\n

Il guasto subito ha avuto anche alcune conseguenze positive: avendo a disposizione le risorse necessarie, Cortex si \u00e8 ripristinato automaticamente senza ulteriori interventi. Abbiamo anche acquisito preziosa esperienza 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

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