{"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\/de\/blog\/administrirovanie\/kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs","title":{"rendered":"Wie die Priorit\u00e4ten von Pods in Kubernetes zu Ausfallzeiten bei Grafana Labs f\u00fchrten","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Anmerkung des \u00dcbersetzers.<\/b>: Wir pr\u00e4sentieren Ihnen technische Einzelheiten zu den Gr\u00fcnden f\u00fcr den k\u00fcrzlichen Ausfall des Cloud-Dienstes, der von den Entwicklern von Grafana betrieben wird. Dies ist ein klassisches Beispiel daf\u00fcr, wie eine neue und scheinbar \u00fcberaus n\u00fctzliche Funktion, die darauf abzielt, die Qualit\u00e4t der Infrastruktur zu verbessern \u2026 sch\u00e4dlich sein kann, wenn nicht die zahlreichen Nuancen ihrer Anwendung in einem Produktionsumfeld ber\u00fccksichtigt werden. Es ist bemerkenswert, wenn solche Materialien auftauchen, die es erm\u00f6glichen, nicht nur aus eigenen Fehlern zu lernen. Weitere Einzelheiten finden Sie in der \u00dcbersetzung dieses Textes von dem Produkt-Vizepr\u00e4sidenten aus Grafana Labs.<\/i><\/p>\n

\"Anm.
\n
\nAm Freitag, dem 19. Juli, h\u00f6rte der Hosted Prometheus-Dienst in Grafana Cloud etwa 30 Minuten lang auf zu funktionieren. Ich entschuldige mich bei allen Kunden, die von der St\u00f6rung betroffen sind. Unsere Aufgabe ist es, die notwendigen Werkzeuge f\u00fcr das Monitoring bereitzustellen, und wir verstehen, dass ihre Nichtverf\u00fcgbarkeit Ihr Leben erschwert. Wir nehmen diesen Vorfall sehr ernst. In diesem Hinweis wird erl\u00e4utert, was passiert ist, wie wir darauf reagiert haben und was wir tun, um sicherzustellen, dass so etwas nicht noch einmal vorkommt.<\/a><\/noindex><\/p>\n

Vorgeschichte<\/h2>\n

\nDer Service Grafana Cloud Hosted Prometheus basiert auf Cortex<\/a><\/noindex> \u2014 einem CNCF-Projekt zur Erstellung eines horizontal skalierbaren, hochverf\u00fcgbaren, multi-tenant (multitenanten) Prometheus-Dienstes. Die Architektur von Cortex besteht aus einer Reihe separater Mikrodienste, von denen jeder eine eigene Funktion erf\u00fcllt: Replikation, Speicherung, Abfragen usw. Cortex wird aktiv weiterentwickelt, es gibt st\u00e4ndig neue Funktionen und die Leistung wird verbessert. Wir f\u00fchren regelm\u00e4\u00dfig neue Versionen von Cortex in den Clustern ein, damit die Kunden von diesen M\u00f6glichkeiten profitieren k\u00f6nnen \u2013 gl\u00fccklicherweise kann Cortex ohne Ausfallzeiten aktualisiert werden.<\/p>\n

F\u00fcr unterbrechungsfreie Updates ben\u00f6tigt der Ingester-Service von Cortex eine zus\u00e4tzliche Ingester-Instanz w\u00e4hrend des Aktualisierungsprozesses. (Anmerkung des \u00dcbersetzers.<\/b>: Ingester<\/a><\/noindex> \u2014 das grundlegende Element von Cortex. Seine Aufgabe ist es, einen stetigen Datenstrom von Samples zu sammeln, sie in Chunks f\u00fcr Prometheus zu gruppieren und in einer Datenbank wie DynamoDB, BigTable oder Cassandra zu speichern.)<\/i> Dies erm\u00f6glicht es \u00e4lteren Ingester-Instanzen, aktuelle Daten an die neuen Ingester zu \u00fcbermitteln. Es ist erw\u00e4hnenswert, dass Ingester ressourcenintensiv sind. F\u00fcr ihren Betrieb sind 4 Kerne und 15 GB RAM pro Pod erforderlich, d.h. 25 % der Prozessorleistung und des Arbeitsspeichers der Basismaschine in unseren Kubernetes-Clustern. Insgesamt haben wir normalerweise viel mehr ungenutzte Ressourcen im Cluster als 4 Kerne und 15 GB RAM, weshalb wir diese zus\u00e4tzlichen Ingester w\u00e4hrend der Updates problemlos ausf\u00fchren k\u00f6nnen.<\/p>\n

Es kommt jedoch h\u00e4ufig vor, dass w\u00e4hrend des normalen Betriebs auf keiner der Maschinen diese 25 % ungenutzten Ressourcen vorhanden sind. Wir streben das auch nicht an: CPU und Speicher sind immer f\u00fcr andere Prozesse von Nutzen. Um dieses Problem zu l\u00f6sen, haben wir uns entschieden, Kubernetes Pod Priorit\u00e4ten<\/a><\/noindex>. Die Idee besteht darin, den Ingester eine h\u00f6here Priorit\u00e4t als anderen (zustandslosen) Mikrodiensten zuzuweisen. Wenn wir einen zus\u00e4tzlichen (N+1) Ingester starten m\u00fcssen, verdr\u00e4ngen wir vor\u00fcbergehend andere, kleinere Pods. Diese Pods werden auf freie Ressourcen auf anderen Maschinen verschoben, sodass gen\u00fcgend Platz f\u00fcr den zus\u00e4tzlichen Ingester bleibt.<\/p>\n

Am Donnerstag, den 18. Juli, haben wir vier neue Priorit\u00e4tsstufen in unseren Clustern bereitgestellt: kritisch<\/b>, hoch<\/b>, mittel<\/b> und niedrig<\/b>. Sie wurden etwa eine Woche lang in einem internen Cluster ohne Kunden-Traffic getestet. Standardm\u00e4\u00dfig erhielten Pods ohne festgelegte Priorit\u00e4t mittel<\/b> Priorit\u00e4t, f\u00fcr Ingester wurde eine Klasse mit hoher<\/b> Priorit\u00e4t festgelegt wurde. Kritisch<\/b> wurde f\u00fcr das Monitoring (Prometheus, Alertmanager, Node-Exporter, Kube-State-Metrics usw.) reserviert. Unsere Konfiguration ist \u00f6ffentlich, und der PR kann angesehen werden. hier<\/a><\/noindex>.<\/p>\n

Ausfall<\/h2>\n

\nAm Freitag, den 19. Juli, startete einer der Ingenieure einen neuen dedizierten Cortex-Cluster f\u00fcr einen gro\u00dfen Kunden. Die Konfiguration f\u00fcr diesen Cluster beinhaltete keine neuen Pod-Priorit\u00e4ten, sodass allen neuen Pods die Standardpriorit\u00e4t zugewiesen wurde \u2014 mittel<\/b>.<\/p>\n

Im Kubernetes-Cluster standen nicht gen\u00fcgend Ressourcen f\u00fcr den neuen Cortex-Cluster zur Verf\u00fcgung, und der vorhandene Produktions-Cortex-Cluster wurde nicht aktualisiert (Ingester blieben ohne hohen<\/b> Priorit\u00e4t). Da die Ingester des neuen Clusters standardm\u00e4\u00dfig eine mittel<\/b> Priorit\u00e4t hatten und die in der Produktion laufenden Pods \u00fcberhaupt keine Priorit\u00e4t hatten, verdr\u00e4ngten die Ingester des neuen Clusters die Ingester aus dem bestehenden Produktions-Cortex-Cluster.<\/p>\n

Das ReplicaSet f\u00fcr den verdr\u00e4ngten Ingester im Produktionscluster entdeckte den verdr\u00e4ngten Pod und erstellte einen neuen, um die festgelegte Anzahl an Kopien aufrechtzuerhalten. Dem neuen Pod wurde standardm\u00e4\u00dfig eine mittel<\/b> eine Priorit\u00e4t zugewiesen, und ein weiterer \"alter\" Ingester im Produktions-Cluster verlor Ressourcen. Das Ergebnis war ein lawinenartiger Prozess<\/b>, die zur Verdr\u00e4ngung aller Pods mit Ingester f\u00fcr die Produktionscluster von Cortex f\u00fchrte.<\/p>\n

Ingester sind zustandsbehaftet und speichern Daten der letzten 12 Stunden. Dies erm\u00f6glicht es uns, sie effizienter zu komprimieren, bevor sie in den Langzeit-Speicher geschrieben werden. Dazu f\u00fchrt Cortex eine Daten-Sharding nach Serien durch, verwendet eine verteilte Hash-Tabelle (Distributed Hash Table, DHT) und repliziert jede Serie auf drei Ingester mit quorum-basierter Konsistenz nach Dynamo-Art. Cortex schreibt keine Daten in Ingester, die abgeschaltet sind. So kann Cortex, wenn viele Ingester die DHT verlassen, keine ausreichende Replikation der Aufzeichnungen gew\u00e4hrleisten, und diese \u201efallen aus\u201c.<\/p>\n

Erkennung und Behebung<\/h2>\n

\nNeue Prometheus-Benachrichtigungen auf Basis des \"Fehlerbudgets\" (error-budget-based<\/i> \u2014 Details werden in einem zuk\u00fcnftigen Artikel erscheinen) wurden nach 4 Minuten nach Beginn der Abschaltung laut. In den folgenden etwa f\u00fcnf Minuten f\u00fchrten wir Diagnosen durch und erweiterten den darunterliegenden Kubernetes-Cluster, um sowohl neue als auch bestehende Produktions-Cluster unterzubringen.<\/p>\n

F\u00fcnf Minuten sp\u00e4ter haben die alten Ingester erfolgreich ihre Daten gespeichert, w\u00e4hrend die neuen starteten und die Cortex-Cluster wieder verf\u00fcgbar wurden.<\/p>\n

Weitere 10 Minuten gingen f\u00fcr die Diagnose und Behebung von Out-of-Memory (OOM) Fehlern von den vor Cortex stehenden Authentifizierungs-Proxy-Servern verloren. Die OOM-Fehler wurden durch einen zehnfachen Anstieg der QPS verursacht (wie wir vermuten, aufgrund \u00fcberm\u00e4\u00dfig aggressiver Anfragen von den Prometheus-Client-Servern).<\/p>\n

Folgen<\/h2>\n

\nDie gesamte Ausfallzeit betrug 26 Minuten. Es gingen keine Daten verloren. Ingester haben erfolgreich alle in memory-Daten in den Langzeitspeicher hochgeladen. W\u00e4hrend der Abschaltung speicherten die Prometheus-Server der Kunden entfernte Daten im Puffer. (remote)<\/i> Eintr\u00e4ge mit dem neuen API remote_write<\/a><\/noindex> basierend auf WAL (geschrieben von Callum Styan<\/a><\/noindex> von Grafana Labs) gepuffert und wiederholten fehlgeschlagene Eintr\u00e4ge nach dem Ausfall.<\/p>\n

\"Anm.
\nOperationsaufzeichnungen des Produktions-Clusters<\/i><\/p>\n

Das DBMS Tarantool ist ein attraktives, zukunftstr\u00e4chtiges Produkt zur Erstellung von hochbelasteten Anwendungen.<\/h2>\n

\nEs ist wichtig, aus diesem Vorfall zu lernen und die notwendigen Ma\u00dfnahmen zu ergreifen, um eine Wiederholung zu vermeiden.<\/p>\n

Wenn man zur\u00fcckblickt, sollte man zugeben, dass es nicht sinnvoll war, standardm\u00e4\u00dfig Priorit\u00e4ten zu vergeben, solange nicht alle Ingester in der Produktion diese erhalten hatten. mittel<\/b> Priorit\u00e4t, bis alle Ingester in der Produktion erhalten haben. hoch<\/b> hohen Priorit\u00e4t k\u00fcmmern sollen. Jetzt ist alles behoben. Wir hoffen, dass unsere Erfahrungen anderen Organisationen helfen, die den Einsatz von Pod-Priorit\u00e4ten in Kubernetes in Betracht ziehen.<\/b> Wir werden eine zus\u00e4tzliche Kontrolle \u00fcber das Deployment aller zus\u00e4tzlichen Objekte einf\u00fchren, deren Konfiguration global f\u00fcr den Cluster ist. Zuk\u00fcnftig werden solche \u00c4nderungen von<\/p>\n

vielen Menschen bewertet werden. Dar\u00fcber hinaus wurde die Modifikation, die zu dem Ausfall f\u00fchrte, als zu unwesentlich f\u00fcr ein separates Projekt-Dokument angesehen \u2014 sie wurde nur in einem GitHub-Issue diskutiert. Ab diesem Moment werden alle \u00e4hnlichen \u00c4nderungen der Konfigurationsdateien von der entsprechenden Projektdokumentation begleitet.o<\/i>Schlie\u00dflich automatisieren wir die Gr\u00f6\u00dfen\u00e4nderung des Authentifizierungs-Reverse-Proxys, um OOM bei \u00dcberlastung zu verhindern, was wir erlebt haben, und analysieren die Standard-Prometheus-Parameter, die mit Rollbacks und Skalierungen zusammenh\u00e4ngen, um in Zukunft \u00e4hnliche Probleme zu vermeiden.<\/p>\n

Der erlebte Ausfall hatte auch einige positive Folgen: Nachdem die notwendigen Ressourcen bereitgestellt wurden, erholte sich Cortex automatisch ohne zus\u00e4tzliche Eingriffe. Au\u00dferdem haben wir wertvolle Erfahrungen im Umgang mit<\/p>\n

Grafana Loki \u2014 unserem neuen Log-Aggregationssystem \u2014 das sichergestellt hat, dass alle Ingester sich w\u00e4hrend und nach dem Ausfall ordnungsgem\u00e4\u00df verhalten haben.<\/a><\/noindex> \u2013 unserem neuen Log-Aggregationssystem, \u2013 das geholfen hat, sicherzustellen, dass sich alle Ingester w\u00e4hrend und nach dem Ausfall ordnungsgem\u00e4\u00df verhalten haben.<\/p>\n

P.S. vom \u00dcbersetzer<\/h2>\n

\nLesen Sie auch in unserem Blog:<\/p>\n