🥇Wie Pod-Prioritäten in Kubernetes zu Ausfallzeiten bei Grafana Labs führten

Anmerkung des Übersetzers.: Wir präsentieren Ihnen technische Einzelheiten zu den Gründen für den kürzlichen Ausfall des Cloud-Dienstes, der von den Entwicklern von Grafana betrieben wird. Dies ist ein klassisches Beispiel dafür, wie eine neue und scheinbar überaus nützliche Funktion, die darauf abzielt, die Qualität der Infrastruktur zu verbessern … schädlich sein kann, wenn nicht die zahlreichen Nuancen ihrer Anwendung in einem Produktionsumfeld berücksichtigt werden. Es ist bemerkenswert, wenn solche Materialien auftauchen, die es ermöglichen, nicht nur aus eigenen Fehlern zu lernen. Weitere Einzelheiten finden Sie in der Übersetzung dieses Textes von dem Produkt-Vizepräsidenten aus Grafana Labs.

Am Freitag, dem 19. Juli, hörte der Hosted Prometheus-Dienst in Grafana Cloud etwa 30 Minuten lang auf zu funktionieren. Ich entschuldige mich bei allen Kunden, die von der Störung betroffen sind. Unsere Aufgabe ist es, die notwendigen Werkzeuge für das Monitoring bereitzustellen, und wir verstehen, dass ihre Nichtverfügbarkeit Ihr Leben erschwert. Wir nehmen diesen Vorfall sehr ernst. In diesem Hinweis wird erläutert, was passiert ist, wie wir darauf reagiert haben und was wir tun, um sicherzustellen, dass so etwas nicht noch einmal vorkommt.

Vorgeschichte

Der Service Grafana Cloud Hosted Prometheus basiert auf Cortex — einem CNCF-Projekt zur Erstellung eines horizontal skalierbaren, hochverfügbaren, multi-tenant (multitenanten) Prometheus-Dienstes. Die Architektur von Cortex besteht aus einer Reihe separater Mikrodienste, von denen jeder eine eigene Funktion erfüllt: Replikation, Speicherung, Abfragen usw. Cortex wird aktiv weiterentwickelt, es gibt ständig neue Funktionen und die Leistung wird verbessert. Wir führen regelmäßig neue Versionen von Cortex in den Clustern ein, damit die Kunden von diesen Möglichkeiten profitieren können – glücklicherweise kann Cortex ohne Ausfallzeiten aktualisiert werden.

Für unterbrechungsfreie Aktualisierungen benötigt der Ingester-Dienst von Cortex während des Aktualisierungsprozesses eine zusätzliche Ingester-Replik. (Anmerkung des Übersetzers.: Ingester — die grundlegende Komponente von Cortex. Seine Aufgabe ist es, einen kontinuierlichen Datenstrom von Samples zu sammeln, sie in Chunk-Typen von Prometheus zu gruppieren und sie in Datenbanken wie DynamoDB, BigTable oder Cassandra zu speichern.) Dies ermöglicht es den alten Ingester, aktuelle Daten an neue Ingester weiterzuleiten. Es sollte beachtet werden, dass Ingester ressourcenintensiv sind. Für ihren Betrieb sind 4 Kerne und 15 GB RAM pro Pod erforderlich, d.h. 25 % der Prozessorleistung und des Speichers der Basismaschine in unseren Kubernetes-Clustern. Im Allgemeinen haben wir normalerweise viel mehr ungenutzte Ressourcen im Cluster als 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 vorhanden sind. Wir streben das auch nicht an: CPU und Speicher sind immer für andere Prozesse von Nutzen. Um dieses Problem zu lösen, haben wir uns entschieden, Kubernetes Pod Prioritäteneinzusetzen. Die Idee besteht darin, Ingester einen höheren Prioritätswert zuzuweisen als anderen (statuslosen) Mikrodiensten. Wenn wir einen zusätzlichen (N+1) Ingester starten müssen, verdrängen wir vorübergehend andere, kleinere Pods. Diese Pods werden auf andere Maschinen mit verfügbaren Ressourcen verschoben, um genügend „Raum“ für den Start des zusätzlichen Ingester zu lassen.

Am Donnerstag, den 18. Juli, haben wir vier neue Prioritätsstufen in unseren Clustern bereitgestellt: kritisch, hoch, mittel und niedrig. Sie wurden eine Woche lang in unserem internen Cluster ohne Kundentransaktionen getestet. Standardmäßig erhielten Pods ohne festgelegte Priorität mittel eine Priorität, während für Ingester eine Klasse mit hoher Priorität festgelegt wurde. Kritisch wurde für das Monitoring (Prometheus, Alertmanager, Node-Exporter, Kube-State-Metrics usw.) reserviert. Unsere Konfiguration ist öffentlich, und der PR kann angesehen werden. hier.

Ausfall

Am Freitag, den 19. Juli, startete einer der Ingenieure einen neuen dedizierten Cortex-Cluster für einen großen Kunden. Die Konfiguration für diesen Cluster beinhaltete die neuen Pod-Prioritäten nicht, sodass allen neuen Pods die Standardpriorität zugewiesen wurde — mittel.

Im Kubernetes-Cluster standen nicht genügend Ressourcen für den neuen Cortex-Cluster zur Verfügung, und der bestehende Produktionscluster Cortex wurde nicht aktualisiert (die Ingester hatten keinen hohen Prioritätswert). Da die Ingester des neuen Clusters standardmäßig die mittel Priorität hatten, während die bestehenden Pods in der Produktion überhaupt keine Priorität hatten, verdrängten die Ingester des neuen Clusters die Ingester aus dem bestehenden Produktionscluster Cortex.

ReplicaSet für den verdrängten Ingester im Produktions-Cluster hat den verdrängten Pod erkannt und einen neuen zur Aufrechterhaltung der gewünschten Anzahl von Kopien erstellt. Dem neuen Pod wurde standardmäßig mittel eine Priorität zugewiesen, und ein weiterer "alter" Ingester im Produktions-Cluster verlor Ressourcen. Das Ergebnis war ein lawinenartiger Prozess, der zur Verdrängung aller Pods mit Ingester für die Produktions-Cluster von Cortex führte.

Ingester sind zustandsbehaftet und speichern Daten der letzten 12 Stunden. Dies ermöglicht uns, sie effizienter zu komprimieren, bevor sie in den Langzeit-Speicher geschrieben werden. Zu diesem Zweck führt Cortex eine Shard-Verteilung der Daten nach Serien durch, indem eine verteilte Hashtabelle (Distributed Hash Table, DHT) verwendet wird und repliziert jede Serie auf drei Ingester mithilfe von quorum-basierten Konsens im Dynamo-Stil. Cortex schreibt keine Daten in Ingester, die abgeschaltet werden. Somit kann Cortex, wenn eine große Anzahl von Ingester die DHT verlässt, keine ausreichende Replikation der Einträge sicherstellen, und diese "fallen".

Erkennung und Behebung

Neue Prometheus-Benachrichtigungen auf Basis des "Fehlerbudgets" (error-budget-based — Details werden in einem zukünftigen Artikel erscheinen) wurden nach 4 Minuten nach Beginn der Abschaltung laut. In den folgenden etwa fünf Minuten führten wir Diagnosen durch und erweiterten den darunterliegenden Kubernetes-Cluster, um sowohl neue als auch bestehende Produktions-Cluster unterzubringen.

Weitere fünf Minuten später haben die alten Ingester erfolgreich ihre Daten geschrieben und die neuen wurden gestartet, und die Cortex-Cluster waren wieder verfügbar.

Weitere 10 Minuten gingen für 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 übermäßig aggressiver Anfragen von den Prometheus-Client-Servern).

Folgen

Die Gesamtdauer des Ausfalls betrug 26 Minuten. Daten gingen nicht verloren. Ingester haben alle In-Memory-Daten erfolgreich in den Langzeit-Speicher geladen. Während der Abschaltung haben die Prometheus-Server der Clients entfernte (remote) Einträge mit dem neuen API remote_write basierend auf WAL (geschrieben von Callum Styan von Grafana Labs) gepuffert und wiederholten fehlgeschlagene Einträge nach dem Ausfall.

Operationsaufzeichnungen des Produktions-Clusters

Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.

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

Wenn man zurückblickt, sollte man zugeben, dass es nicht sinnvoll war, standardmäßig Prioritäten zu vergeben, solange nicht alle Ingester in der Produktion diese erhalten hatten. mittel Priorität. Außerdem hätte man sich im Voraus um ihren hoch hohen Priorität kümmern sollen. Jetzt ist alles behoben. Wir hoffen, dass unsere Erfahrungen anderen Organisationen helfen, die den Einsatz von Pod-Prioritäten in Kubernetes in Betracht ziehen. Wir werden eine zusätzliche Kontrolle über das Deployment aller zusätzlichen Objekte einführen, deren Konfiguration global für den Cluster ist. Zukünftig werden solche Änderungen von

vielen Menschen bewertet werden. Darüber hinaus wurde die Modifikation, die zu dem Ausfall führte, als zu unwesentlich für ein separates Projekt-Dokument angesehen — sie wurde nur in einem GitHub-Issue diskutiert. Ab diesem Moment werden alle ähnlichen Änderungen der Konfigurationsdateien von der entsprechenden Projektdokumentation begleitet.oSchließlich automatisieren wir die Größenänderung des Authentifizierungs-Reverse-Proxys, um OOM bei Überlastung zu verhindern, was wir erlebt haben, und analysieren die Standard-Prometheus-Parameter, die mit Rollbacks und Skalierungen zusammenhängen, um in Zukunft ähnliche Probleme zu vermeiden.

Der erlebte Ausfall hatte auch einige positive Folgen: Nachdem die notwendigen Ressourcen bereitgestellt wurden, erholte sich Cortex automatisch ohne zusätzliche Eingriffe. Außerdem haben wir wertvolle Erfahrungen im Umgang mit

Grafana Loki — unserem neuen Log-Aggregationssystem — das sichergestellt hat, dass alle Ingester sich während und nach dem Ausfall ordnungsgemäß verhalten haben. Autoskalierung und Ressourcenmanagement in Kubernetes (Überblick und Video-Präsentation)