Hinweis perev .: Es ist eine Übersetzung des öffentlichen Post-Mortem aus dem Engineering-Blog von Preply . Es beschreibt ein Conntrack-Problem im Kubernetes-Cluster, das zu Ausfallzeiten einiger Produktionsservices führte.Dieser Artikel kann für diejenigen nützlich sein, die etwas mehr über Post-Mortem erfahren oder potenzielle Probleme mit DNS in Zukunft vermeiden möchten.Dies ist kein DNS.
Möglicherweise handelt es sich nicht um DNS.
Es war DNS.Ein bisschen über Post-Mortem und Prozesse in Preply
Die Obduktion beschreibt eine Fehlfunktion oder ein Ereignis im Verkaufsbüro. Post-mortem enthält eine Chronologie der Ereignisse, eine Beschreibung der Auswirkungen auf den Benutzer, die Grundursache, Aktionen und gewonnene Erkenntnisse.
Ich suche SRE
Bei wöchentlichen Treffen mit Pizza im Kreis des technischen Teams teilen wir verschiedene Informationen. Einer der wichtigsten Teile solcher Treffen ist die Obduktion, die meistens von einer Präsentation mit Folien und einer tieferen Analyse des Vorfalls begleitet wird. Trotz der Tatsache, dass wir nicht post mortem „klatschen“, versuchen wir, eine Kultur „ohne Schuld “ ( tadellose Naht ) zu entwickeln. Wir glauben, dass das Schreiben und Präsentieren von Obduktionen uns (und nicht nur) dabei helfen kann, ähnliche Vorfälle in Zukunft zu verhindern, weshalb wir sie teilen.Personen, die an dem Vorfall beteiligt sind, sollten das Gefühl haben, dass sie ohne Angst vor Bestrafung oder Vergeltung ausführlich darüber sprechen können. Keine Kritik! Das Schreiben einer Obduktion ist keine Bestrafung, sondern eine Gelegenheit, für das gesamte Unternehmen zu lernen.
Keep CALMS & DevOps: S dient zum Teilen
Probleme mit DNS in Kubernetes. Post mortem
Datum: 28.02.2020Autoren: Amet U., Andrei S., Igor K., Aleksey P.Status: AbgeschlossenKurz: Teilweise Nichtverfügbarkeit von DNS (26 Minuten) für einige Dienste im Kubernetes-ClusterAuswirkung: 15.000 Ereignisse gingen für Dienste A verloren. B und CGrundursache: Kube-Proxy konnte den alten Eintrag nicht korrekt aus der Conntrack-Tabelle löschen, sodass einige Dienste weiterhin versuchten, eine Verbindung zu nicht vorhandenen Übermittlungen herzustellenE0228 20:13:53.795782 1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...
Trigger: Aufgrund der geringen Belastung innerhalb Kubernetes-Cluster, CoreDNS-autoscaler reduziert die Anzahl der Schoten in deploymenta von drei auf zweiEntscheidung: Weitere deploy Anwendungen initiiert die Schaffung neuer Knoten, CoreDNS-autoscaler mehr Decks für den Cluster - Dienst hinzugefügt, die Überschreibungs conntrack Tabelle provozierteErkennung : Die Prometheus-Überwachung hat eine große Anzahl von 5xx-Fehlern für die Dienste A, B und C festgestellt und einen Anruf bei den 5xx-Fehlern der diensthabenden Ingenieure in Kibana eingeleitet
Aktionen
Gewonnene Erkenntnisse
Was ging gut:- Die Überwachung funktionierte klar. Die Reaktion war schnell und organisiert.
::- CoreDNS-autoscaler, conntrack
(EET)
- Zeit bis zur Erkennung: 4 min.
- Zeit, um die Aktion abzuschließen: 21 min.
- Reparaturzeit: 1 min
Weitere Informationen
Um die Prozessorauslastung zu minimieren, verwendet der Linux-Kernel so etwas wie conntrack. Kurz gesagt, dies ist ein Dienstprogramm, das eine Liste von NAT-Einträgen enthält, die in einer speziellen Tabelle gespeichert sind. Wenn das nächste Paket von demselben Pod zu demselben Pod wie zuvor kommt, wird die endgültige IP-Adresse nicht neu berechnet, sondern aus der Conntrack-Tabelle entnommen.
Wie conntrack funktioniertZusammenfassung
Dies war ein Beispiel für eine unserer Obduktionen mit einigen nützlichen Links. Insbesondere in diesem Artikel geben wir Informationen weiter, die für andere Unternehmen nützlich sein können. Deshalb haben wir keine Angst, Fehler zu machen, und deshalb machen wir eine unserer Obduktionen öffentlich. Hier sind einige weitere interessante öffentliche Post-Mortem-Themen: