🥇Wie die Prioritäten von Pods in Kubernetes zu Ausfallzeiten bei Grafana Labs führten

Hinweis.: Hiermit präsentieren wir Ihnen technische Details zu den Ursachen des jüngsten Ausfalls des Cloud-Dienstes, der von den Entwicklern von Grafana betrieben wird. Dies ist ein klassisches Beispiel dafür, wie eine neue, scheinbar äußerst nützliche Funktion, die die Qualität der Infrastruktur verbessern soll… schädlich sein kann, wenn man nicht die zahlreichen Nuancen ihrer Anwendung in der Produktionsumgebung berücksichtigt. Es ist großartig, wenn solche Materialien veröffentlicht werden, die es ermöglichen, nicht nur aus eigenen Fehlern zu lernen. Die Details finden Sie in der Übersetzung dieses Textes des Produkt-Vizepräsidenten von Grafana Labs.

Am Freitag, den 19. Juli, funktionierte der Hosted Prometheus-Dienst in Grafana Cloud für etwa 30 Minuten nicht. Ich entschuldige mich bei all unseren Kunden, die durch diesen Ausfall betroffen waren. Unsere Aufgabe ist es, die notwendigen Überwachungstools bereitzustellen, und wir verstehen, dass ihre Unzugänglichkeit Ihnen das Leben erschwert. Wir nehmen diesen Vorfall sehr ernst. In diesem Hinweis erklären wir, was passiert ist, wie wir darauf reagiert haben und was wir unternehmen, um sicherzustellen, dass sich so etwas nicht wiederholt.

Hintergrund

Der Grafana Cloud Hosted Prometheus Service basiert auf Cortex — einem CNCF-Projekt zur Schaffung eines horizontal skalierbaren, hochverfügbaren und multi-tenant (mehrmandantenfähigen) Prometheus-Services. Die Architektur von Cortex besteht aus einer Reihe von separaten Microservices, die jeweils eine bestimmte Funktion erfüllen: Replikation, Speicherung, Abfragen usw. Cortex wird aktiv weiterentwickelt, mit ständig neuen Funktionen und Leistungssteigerungen. Wir implementieren regelmäßig neue Versionen von Cortex in die Cluster, damit unsere Kunden von diesen Möglichkeiten profitieren können — zumal Cortex in der Lage ist, ohne Ausfallzeiten zu aktualisieren.

Für unterbrechungsfreie Updates benötigt der Ingester-Service von Cortex während des Aktualisierungsprozesses eine zusätzliche Ingester-Replik. (Hinweis.: Ingester — ein grundlegender Bestandteil von Cortex. Seine Aufgabe besteht darin, einen kontinuierlichen Strom von Samples zu sammeln, sie in Prometheus-Chunks zu gruppieren und in Datenbanken wie DynamoDB, BigTable oder Cassandra zu speichern. Dies ermöglicht es den alten Ingester, aktuelle Daten an neue Ingester zu übertragen. Es ist erwähnenswert, dass Ingester ressourcenintensiv sind. Für ihren Betrieb werden 4 Kerne und 15 GB RAM pro Pod benötigt, was 25 % der CPU-Leistung und des Speichers der zugrunde liegenden Maschine bei unseren Kubernetes-Clustern entspricht. In der Regel haben wir jedoch viel mehr ungenutzte Ressourcen im Cluster als die benötigten 4 Kerne und 15 GB RAM, sodass wir diese zusätzlichen Ingester während der Updates problemlos starten können.

Es kommt jedoch häufig vor, dass während des normalen Betriebs auf keiner der Maschinen diese 25 % ungenutzten Ressourcen verfügbar sind. Und wir streben das auch nicht an: CPU und RAM sind immer für andere Prozesse nützlich. Um dieses Problem zu lösen, haben wir uns entschieden, Kubernetes Pod Priorities. Die Idee besteht darin, den Ingester einen höheren Prioritätswert zuzuweisen als anderen (stateless) Mikrodiensten. Wenn wir einen zusätzlichen (N+1) Ingester starten müssen, drängen wir vorübergehend andere, kleinere Pods zurück. Diese Pods werden auf freie Ressourcen auf anderen Maschinen verschoben, wodurch ausreichend Platz für den Start des zusätzlichen Ingester entsteht.

Am Donnerstag, dem 18. Juli, haben wir in unseren Clustern vier neue Prioritätsstufen eingeführt: kritisch, hoch, mittel und niedrig. Diese wurden etwa eine Woche in einem internen Cluster ohne Kundenverkehr getestet. Standardmäßig erhielten Pods ohne festgelegte Priorität mittel Priorität, während für Ingester eine Klasse mit hoher Priorität eingestellt. Kritisch für Monitoring-Dienste (Prometheus, Alertmanager, node-exporter, kube-state-metrics usw.) reserviert war. Unsere Konfiguration ist öffentlich und der PR kann eingesehen werden. hier.

Ausfall

Am Freitag, dem 19. Juli, hat einer der Ingenieure ein neues dediziertes Cortex-Cluster für einen Großkunden gestartet. Die Konfiguration für dieses Cluster enthielt keine neuen Pods-Prioritäten, sodass allen neuen Pods die Standardpriorität zugewiesen wurde — mittel.

Im Kubernetes-Cluster fehlten die Ressourcen für das neue Cortex-Cluster, und das bestehende Produktions-Cortex-Cluster wurde nicht aktualisiert (Ingester hatten keinen hohen Priorität). Da die Ingester des neuen Clusters standardmäßig mittel Priorität hatten und die bestehenden Pods im Produktionsumfeld überhaupt keine Priorität hatten, verdrängten die Ingester des neuen Clusters die Ingester aus dem bestehenden Produktions-Cortex-Cluster.

Das ReplicaSet für den verdrängten Ingester im Produktions-Cluster hat den verdrängten Pod erkannt und einen neuen erstellt, um die vorgegebene Anzahl an Kopien aufrechtzuerhalten. Dem neuen Pod wurde standardmäßig mittel eine Priorität zugewiesen, wodurch der ältere Ingester im Produktions-Cluster über Ressourcen entzogen wurde. Das Ergebnis war ein lawinenartiger Prozess, der dazu führte, dass alle Pods mit Ingester für die Produktionscluster von Cortex verdrängt wurden.

Ingester sind zustandsbehaftet und speichern Daten für die letzten 12 Stunden. Dies ermöglicht eine effizientere Komprimierung, bevor sie in einen langfristigen Speicher geschrieben werden. Zu diesem Zweck führt Cortex eine Daten-Sharding nach Serien durch und verwendet eine verteilte Hash-Tabelle (Distributed Hash Table, DHT) zur Replikation jeder Serie auf drei Ingester mit quorum-basierter Konsistenz im Dynamo-Stil. Cortex schreibt keine Daten in Ingester, die deaktiviert sind. Wenn also eine große Anzahl von Ingester die DHT verlässt, kann Cortex keine ausreichende Replikation der Aufzeichnungen gewährleisten, und diese „fallen aus“.

Erkennung und Behebung

Neue Prometheus-Benachrichtigungen basierend auf dem „Fehlerbudget“ (error-budget-based — weitere Informationen werden in einem zukünftigen Artikel veröffentlicht) äußerten sich alarmiert nach vier Minuten seit Beginn der Ausfallzeit. In den nächsten etwa fünf Minuten führten wir Diagnostics durch und erweiterten den darunter liegenden Kubernetes-Cluster, um sowohl neue als auch bestehende Produktionscluster zu hosten.

Fünf Minuten später haben die alten Ingester erfolgreich ihre Daten aufgezeichnet, während die neuen gestartet wurden und die Cortex-Cluster wieder verfügbar waren.

Weitere zehn Minuten benötigten wir für 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 übermäßig aggressiven Anfragen von den Prometheus-Client-Servern).

Folgen

Die Gesamtdauer des Ausfalls betrug 26 Minuten. Es gingen keine Daten verloren. Die Ingester haben erfolgreich alle in-memory-Daten in langfristigen Speicher überträgt. Während des Ausfalls haben die Prometheus-Server der Clients entfernte (remote) Aufzeichnungen mit Hilfe von der neuen API remote_write basierend auf WAL (geschrieben von Callum Styan von Grafana Labs) und haben fehlgeschlagene Aufzeichnungen nach dem Ausfall wiederholt.

Schreiboperationen des Produktionsclusters

Fazit

Es ist wichtig, aus diesem Vorfall zu lernen und die notwendigen Maßnahmen zu ergreifen, um eine Wiederholung zu vermeiden.

Rückblickend sollten wir anerkennen, dass wir standardmäßig keinen mittel Priorität setzen sollten, bis alle Ingester in der Produktion hoch diese Priorität erhalten haben. Außerdem hätte im Vorfeld auf ihre hohe Priorität geachtet werden müssen. Jetzt ist alles behoben. Wir hoffen, dass unsere Erfahrungen anderen Organisationen helfen, die die Verwendung von Pod-Prioritäten in Kubernetes in Betracht ziehen.

Wir werden eine zusätzliche Kontrollstufe für die Bereitstellung aller zusätzlichen Objekte hinzufügen, deren Konfigurationen global für den Cluster sind. Zukünftig werden solche Änderungen vongrößtenmehr Personen bewertet. Außerdem wurde die Modifikation, die zu dem Ausfall führte, als zu geringfügig für ein separates Projektdokument betrachtet – sie wurde nur im GitHub-Issue diskutiert. Ab sofort werden alle solchen Konfigurationsänderungen mit entsprechender Projektdokumentation begleitet.

Schließlich automatisieren wir die Skalierung des Authentifizierungs-Proxy-Servers, um OOM-Probleme bei Überlastungen zu verhindern, die wir erlebt haben, und analysieren die standardmäßigen Prometheus-Einstellungen im Zusammenhang mit Rollbacks und Skalierung, um zukünftig ähnliche Probleme zu vermeiden.

Der erlebte Ausfall hatte auch einige positive Konsequenzen: Nachdem wir die benötigten Ressourcen erhalten hatten, konnte Cortex automatisch wiederhergestellt werden, ohne dass zusätzliches Eingreifen erforderlich war. Zudem haben wir wertvolle Erfahrungen mit Grafana Loki — unserem neuen Log-Aggregationssystem — das uns half sicherzustellen, dass alle Ingester während und nach dem Ausfall ordnungsgemäß funktionierten.