Notiz. Übersetzung: Dies ist eine Übersetzung eines öffentlichen Postmortems aus dem Engineering-Blog des Unternehmens . Darin wird ein Problem mit conntrack in einem Kubernetes-Cluster beschrieben, das zu einem teilweisen Ausfall einiger Produktionsdienste führte.
Dieser Artikel kann für diejenigen nützlich sein, die etwas mehr über Postmortems erfahren oder potenzielle DNS-Probleme in der Zukunft verhindern möchten.
Dies ist kein DNS
Es kann nicht DNS sein
Es war DNS
Ein wenig über Postmortems und Prozesse in Preply
Ein Postmortem beschreibt eine Fehlfunktion oder ein Ereignis in der Produktion. Das Postmortem umfasst eine Zeitleiste der Ereignisse, Auswirkungen auf den Benutzer, Grundursache, ergriffene Maßnahmen und gewonnene Erkenntnisse.
Bei wöchentlichen Treffen mit Pizza tauschen wir innerhalb des technischen Teams verschiedene Informationen aus. Einer der wichtigsten Teile solcher Treffen sind Obduktionen, die meist von einer Präsentation mit Folien und einer tiefergehenden Analyse des Vorfalls begleitet werden. Auch wenn wir nach Obduktionen nicht klatschen, versuchen wir, eine Kultur der „Keine Schuldzuweisungen“ zu entwickeln (). Wir glauben, dass das Verfassen und Präsentieren von Obduktionen uns (und anderen) dabei helfen kann, ähnliche Vorfälle in der Zukunft zu verhindern, weshalb wir sie mit Ihnen teilen.
An einem Vorfall beteiligte Personen sollten das Gefühl haben, dass sie sich ausführlich äußern können, ohne Angst vor Bestrafung oder Vergeltung haben zu müssen. Keine Schuld! Das Schreiben einer Obduktion ist keine Strafe, sondern eine Lernmöglichkeit für das gesamte Unternehmen.
Probleme mit DNS in Kubernetes. Obduktion
Дата: 28.02.2020
Autoren: Amet U., Andrey S., Igor K., Alexey P.
Status: Beendet
Kurz gesagt: Teilweise DNS-Nichtverfügbarkeit (26 Min.) für einige Dienste im Kubernetes-Cluster
Beeinflussen: 15000 Ereignisse verloren für die Dienste A, B und C
Grundursache: Kube-Proxy konnte einen alten Eintrag nicht korrekt aus der Conntrack-Tabelle entfernen, daher versuchten einige Dienste immer noch, eine Verbindung zu nicht vorhandenen Pods herzustellen
E0228 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: ...Auslösen: Aufgrund der geringen Auslastung innerhalb des Kubernetes-Clusters reduzierte CoreDNS-Autoscaler die Anzahl der Pods in der Bereitstellung von drei auf zwei
Lösung: Bei der nächsten Bereitstellung der Anwendung wurde die Erstellung neuer Knoten eingeleitet. CoreDNS-Autoscaler fügte weitere Pods hinzu, um den Cluster zu bedienen, was zu einer Neufassung der Conntrack-Tabelle führte
Erkennung: Die Prometheus-Überwachung erkannte eine große Anzahl von 5xx-Fehlern für die Dienste A, B und C und leitete einen Anruf bei den diensthabenden Ingenieuren ein
5xx-Fehler in Kibana
Aktionen
Aktion
Typ
Verantwortlich
Aufgabe
Deaktivieren Sie die automatische Skalierung für CoreDNS
verhindert
Amet U.
DEVOPS-695
Richten Sie einen Caching-DNS-Server ein
verringern
Max V.
DEVOPS-665
Richten Sie die Conntrack-Überwachung ein
verhindert
Amet U.
DEVOPS-674
Gewonnene Erkenntnisse
Was ging gut:
- Die Überwachung hat gut funktioniert. Die Reaktion erfolgte schnell und organisiert
- Bei den Knoten sind wir auf keine Grenzen gestoßen
Was war falsch:
- Noch unbekannte wahre Grundursache, ähnlich in conntrack
- Alle Aktionen beheben nur die Konsequenzen, nicht die Grundursache (Fehler).
- Wir wussten, dass wir früher oder später Probleme mit DNS haben könnten, aber wir haben die Aufgaben nicht priorisiert
Wo wir Glück hatten:
- Die nächste Bereitstellung wurde durch CoreDNS-Autoscaler ausgelöst, der die Conntrack-Tabelle überschrieb
- Dieser Fehler betraf nur einige Dienste
Zeitleiste (EET)
Zeit
Aktion
22:13
CoreDNS-Autoscaler reduzierte die Anzahl der Pods von drei auf zwei
22:18
Die diensthabenden Ingenieure erhielten Anrufe vom Überwachungssystem
22:21
Die diensthabenden Ingenieure begannen, die Fehlerursache herauszufinden.
22:39
Die diensthabenden Ingenieure begannen damit, einen der neuesten Dienste auf die vorherige Version zurückzusetzen
22:40
5xx-Fehler treten nicht mehr auf, die Situation hat sich stabilisiert
- Zeit bis zur Erkennung: 4 Minuten
- Zeit bis zur Aktion: 21 Minuten
- Zeit zum Reparieren: 1 Minuten
Weitere Informationen
- CoreDNS-Protokolle:
I0228 20:13:53.507780 1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2 - Links zu Kibana (geschnitten), Grafana (geschnitten)
Um die CPU-Auslastung zu minimieren, verwendet der Linux-Kernel etwas namens Conntrack. Kurz gesagt handelt es sich hierbei um ein Dienstprogramm, das eine Liste von NAT-Datensätzen enthält, die in einer speziellen Tabelle gespeichert sind. Wenn das nächste Paket vom selben Pod beim selben Pod ankommt wie zuvor, wird die endgültige IP-Adresse nicht neu berechnet, sondern aus der Conntrack-Tabelle übernommen.
So funktioniert conntrack
Ergebnisse
Dies war ein Beispiel einer unserer Postmortems mit einigen nützlichen Links. Insbesondere in diesem Artikel teilen wir Informationen, die für andere Unternehmen nützlich sein können. Deshalb haben wir keine Angst davor, Fehler zu machen, und deshalb veröffentlichen wir eine unserer Obduktionen. Hier sind einige weitere interessante öffentliche Postmortems:
- GitLab:
- Dropbox:
- Spotify:
- Viele andere aus und Repository
- Auch öffentliche Obduktion mit SRE-Buch
Source: habr.com