{"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 Priorit\u00e4ten von Pods in Kubernetes zu Ausf\u00e4llen bei Grafana Labs f\u00fchrten","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hinweis.<\/b>: Hiermit pr\u00e4sentieren wir Ihnen technische Details zu den Ursachen des j\u00fcngsten Ausfalls des Cloud-Dienstes, der von den Entwicklern von Grafana betrieben wird. Dies ist ein klassisches Beispiel daf\u00fcr, wie eine neue, scheinbar \u00e4u\u00dferst n\u00fctzliche Funktion, die die Qualit\u00e4t der Infrastruktur verbessern soll\u2026 sch\u00e4dlich sein kann, wenn man nicht die zahlreichen Nuancen ihrer Anwendung in der Produktionsumgebung ber\u00fccksichtigt. Es ist gro\u00dfartig, wenn solche Materialien ver\u00f6ffentlicht werden, die es erm\u00f6glichen, nicht nur aus eigenen Fehlern zu lernen. Die Details finden Sie in der \u00dcbersetzung dieses Textes des Produkt-Vizepr\u00e4sidenten von Grafana Labs.<\/i><\/p>\n

\"Wie
\n
\nAm Freitag, den 19. Juli, funktionierte der Hosted Prometheus-Dienst in Grafana Cloud f\u00fcr etwa 30 Minuten nicht. Ich entschuldige mich bei all unseren Kunden, die durch diesen Ausfall betroffen waren. Unsere Aufgabe ist es, die notwendigen \u00dcberwachungstools bereitzustellen, und wir verstehen, dass ihre Unzug\u00e4nglichkeit Ihnen das Leben erschwert. Wir nehmen diesen Vorfall sehr ernst. In diesem Hinweis erkl\u00e4ren wir, was passiert ist, wie wir darauf reagiert haben und was wir unternehmen, um sicherzustellen, dass sich so etwas nicht wiederholt.<\/a><\/noindex><\/p>\n

Hintergrund<\/h2>\n

\nDer Grafana Cloud Hosted Prometheus Service basiert auf Cortex<\/a><\/noindex> \u2014 einem CNCF-Projekt zur Schaffung eines horizontal skalierbaren, hochverf\u00fcgbaren und multi-tenant (mehrmandantenf\u00e4higen) Prometheus-Services. Die Architektur von Cortex besteht aus einer Reihe von separaten Microservices, die jeweils eine bestimmte Funktion erf\u00fcllen: Replikation, Speicherung, Abfragen usw. Cortex wird aktiv weiterentwickelt, mit st\u00e4ndig neuen Funktionen und Leistungssteigerungen. Wir implementieren regelm\u00e4\u00dfig neue Versionen von Cortex in die Cluster, damit unsere Kunden von diesen M\u00f6glichkeiten profitieren k\u00f6nnen \u2014 zumal Cortex in der Lage ist, ohne Ausfallzeiten zu aktualisieren.<\/p>\n

F\u00fcr unterbrechungsfreie Updates ben\u00f6tigt der Ingester Cortex eine zus\u00e4tzliche Ingester-Instanz w\u00e4hrend des Update-Prozesses. (Hinweis.<\/b>: Ingester<\/a><\/noindex> \u2014 der grundlegende Bestandteil von Cortex. Seine Aufgabe ist es, einen kontinuierlichen Strom von Samples zu sammeln, sie in Prometheus-Chunks zu gruppieren und in einer Datenbank wie DynamoDB, BigTable oder Cassandra zu speichern.<\/i> Dies erm\u00f6glicht es \u00e4lteren Ingester-Instanzen, aktuelle Daten an neue Ingester-Instanzen zu \u00fcbertragen. Zu beachten ist, dass Ingester ressourcenintensiv sind. F\u00fcr ihren Betrieb sind 4 Kerne und 15 GB RAM pro Pod erforderlich, d.h. 25 % der CPU-Leistung und des Speichers der Basismaschine in unseren Kubernetes-Clustern. Insgesamt verf\u00fcgen wir in der Regel \u00fcber viel mehr ungenutzte Ressourcen im Cluster als nur 4 Kerne und 15 GB RAM, weshalb wir diese zus\u00e4tzlichen Ingester w\u00e4hrend der Updates problemlos starten k\u00f6nnen.<\/p>\n

Es kommt jedoch h\u00e4ufig vor, dass w\u00e4hrend des normalen Betriebs auf keiner der Maschinen diese 25 % ungenutzten Ressourcen verf\u00fcgbar sind. Und wir streben das auch nicht an: CPU und RAM sind immer f\u00fcr andere Prozesse n\u00fctzlich. Um dieses Problem zu l\u00f6sen, haben wir uns entschieden, Kubernetes Pod Priorities<\/a><\/noindex>. Die Idee ist, den Ingester eine h\u00f6here Priorit\u00e4t als anderen (zustandslosen) Microservices zuzuweisen. Wenn wir einen zus\u00e4tzlichen (N+1) Ingester starten m\u00fcssen, schieben wir vor\u00fcbergehend andere, kleinere Pods zur Seite. Diese Pods werden auf freie Ressourcen auf anderen Maschinen verschoben, wodurch gen\u00fcgend Platz f\u00fcr den zus\u00e4tzlichen Ingester geschaffen wird.<\/p>\n

Am Donnerstag, dem 18. Juli, haben wir in unseren Clustern vier neue Priorit\u00e4tsstufen eingef\u00fchrt: kritisch<\/b>, hoch<\/b>, mittel<\/b> und niedrig<\/b>. Sie wurden etwa eine Woche lang in einem internen Cluster ohne Kundenverkehr getestet. Standardm\u00e4\u00dfig erhielten Pods ohne festgelegte Priorit\u00e4t mittel<\/b> Priorit\u00e4t, w\u00e4hrend f\u00fcr Ingester Klassen festgelegt wurden hoher<\/b> Priorit\u00e4t eingestellt. Kritisch<\/b> f\u00fcr Monitoring-Dienste (Prometheus, Alertmanager, node-exporter, kube-state-metrics usw.) reserviert war. Unsere Konfiguration ist \u00f6ffentlich und der PR kann eingesehen werden. hier<\/a><\/noindex>.<\/p>\n

Ausfall<\/h2>\n

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

Im Kubernetes-Cluster standen nicht gen\u00fcgend Ressourcen f\u00fcr den neuen Cortex-Cluster zur Verf\u00fcgung, und der bestehende Produktions-Cluster Cortex wurde nicht aktualisiert (Ingester blieben ohne hohen<\/b> Priorit\u00e4t). Da die Ingester des neuen Clusters standardm\u00e4\u00dfig Priorit\u00e4t hatten und die bestehenden Pods im Produktionsbetrieb \u00fcberhaupt keine Priorit\u00e4t hatten, verdr\u00e4ngten die Ingester des neuen Clusters Ingester aus dem bestehenden Produktions-Cluster Cortex. mittel<\/b> Das ReplicaSet f\u00fcr den verdr\u00e4ngten Ingester im Produktions-Cluster entdeckte den verdr\u00e4ngten Pod und erstellte einen neuen, um die festgelegte Anzahl von Kopien aufrechtzuerhalten. Dem neuen Pod wurde standardm\u00e4\u00dfig zugewiesen<\/p>\n

, was zur Verdr\u00e4ngung aller Pods mit Ingester f\u00fcr die Produktionscluster des Cortex f\u00fchrte. mittel<\/b> eine Priorit\u00e4t zugewiesen, wodurch der \u00e4ltere Ingester im Produktions-Cluster \u00fcber Ressourcen entzogen wurde. Das Ergebnis war ein lawinenartiger Prozess<\/b>, der zur Abl\u00f6sung aller Pods mit Ingester f\u00fcr die Produktionscluster von Cortex f\u00fchrte.<\/p>\n

Ingester sind zustandsbehaftet und speichern Daten der letzten 12 Stunden. Das erm\u00f6glicht uns eine effektivere Komprimierung, bevor die Daten in die Langzeitspeicherung geschrieben werden. Hierbei f\u00fchrt Cortex eine Shard-Verteilung der Daten \u00fcber die Serien mithilfe einer verteilten Hash-Tabelle (Distributed Hash Table, DHT) durch und repliziert jede Serie auf drei Ingester mithilfe von Quorum-Konsistenz im Dynamo-Stil. Cortex schreibt keine Daten in Ingester, die sich im Offline-Modus befinden. Dadurch kann Cortex, wenn eine gro\u00dfe Anzahl von Ingester die DHT verl\u00e4sst, keine ausreichende Replikation der Datens\u00e4tze sicherstellen, und diese \u201efallen\u201c aus.<\/p>\n

Erkennung und Behebung<\/h2>\n

\nNeue Prometheus-Benachrichtigungen basierend auf dem \u201eFehlerbudget\u201c (error-budget-based<\/i> \u2014 weitere Informationen werden in einem zuk\u00fcnftigen Artikel ver\u00f6ffentlicht) \u00e4u\u00dferten sich alarmiert nach vier Minuten seit Beginn der Ausfallzeit. In den n\u00e4chsten etwa f\u00fcnf Minuten f\u00fchrten wir Diagnostics durch und erweiterten den darunter liegenden Kubernetes-Cluster, um sowohl neue als auch bestehende Produktionscluster zu hosten.<\/p>\n

F\u00fcnf Minuten sp\u00e4ter hatten die alten Ingester ihre Daten erfolgreich aufgezeichnet und die neuen gestartet, sodass die Cortex-Cluster wieder zug\u00e4nglich waren.<\/p>\n

Weitere zehn Minuten ben\u00f6tigten wir f\u00fcr die Diagnose und Behebung von Out-of-Memory (OOM)-Fehlern bei den Authentifizierungs-Proxy-Servern vor Cortex. Die OOM-Fehler wurden durch einen zehnfachen Anstieg des QPS verursacht (wie wir annehmen, aufgrund von \u00fcberm\u00e4\u00dfig aggressiven Anfragen von den Prometheus-Client-Servern).<\/p>\n

Folgen<\/h2>\n

\nDie Gesamtdauer der Ausfallzeit betrug 26 Minuten. Daten gingen nicht verloren. Ingester luden alle In-Memory-Daten erfolgreich in die langfristige Speicherung. W\u00e4hrend der Abschaltung speicherten die Prometheus-Server der Kunden die entfernten Daten im Puffer. (remote)<\/i> Aufzeichnungen mit Hilfe von der neuen API remote_write<\/a><\/noindex> basierend auf WAL (geschrieben von Callum Styan<\/a><\/noindex> von Grafana Labs) und haben fehlgeschlagene Aufzeichnungen nach dem Ausfall wiederholt.<\/p>\n

\"Wie
\nSchreiboperationen des Produktionsclusters<\/i><\/p>\n

Fazit<\/h2>\n

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

R\u00fcckblickend sollten wir anerkennen, dass wir standardm\u00e4\u00dfig keinen mittel<\/b> Priorit\u00e4t, bis alle Ingester in der Produktion erhalten hatten. hoch<\/b> diese Priorit\u00e4t erhalten haben. Au\u00dferdem h\u00e4tte im Vorfeld auf ihre hohe<\/b> Priorit\u00e4t geachtet werden m\u00fcssen. Jetzt ist alles behoben. Wir hoffen, dass unsere Erfahrungen anderen Organisationen helfen, die die Verwendung von Pod-Priorit\u00e4ten in Kubernetes in Betracht ziehen.<\/p>\n

Wir werden eine zus\u00e4tzliche Kontrollstufe f\u00fcr die Bereitstellung aller zus\u00e4tzlichen Objekte hinzuf\u00fcgen, deren Konfigurationen global f\u00fcr den Cluster sind. Zuk\u00fcnftig werden solche \u00c4nderungen vongr\u00f6\u00dften<\/i>mehr Personen bewertet. Au\u00dferdem wurde die Modifikation, die zu dem Ausfall f\u00fchrte, als zu geringf\u00fcgig f\u00fcr ein separates Projektdokument betrachtet \u2013 sie wurde nur im GitHub-Issue diskutiert. Ab sofort werden alle solchen Konfigurations\u00e4nderungen mit entsprechender Projektdokumentation begleitet.<\/p>\n

Schlie\u00dflich automatisieren wir die Skalierung des Authentifizierungs-Proxy-Servers, um OOM-Probleme bei \u00dcberlastungen zu verhindern, die wir erlebt haben, und analysieren die standardm\u00e4\u00dfigen Prometheus-Einstellungen im Zusammenhang mit Rollbacks und Skalierung, um zuk\u00fcnftig \u00e4hnliche Probleme zu vermeiden.<\/p>\n

Der erlebte Ausfall hatte auch einige positive Konsequenzen: Nachdem wir die ben\u00f6tigten Ressourcen erhalten hatten, konnte Cortex automatisch wiederhergestellt werden, ohne dass zus\u00e4tzliches Eingreifen erforderlich war. Zudem haben wir wertvolle Erfahrungen mit Grafana Loki<\/a><\/noindex> \u2013 unser neues Log-Aggregationssystem, \u2013 das daf\u00fcr sorgte, dass sich alle Ingester w\u00e4hrend und nach dem Ausfall ordnungsgem\u00e4\u00df verhielten.<\/p>\n

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

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