🥇Probleme mit DNS in Kubernetes. Öffentliches Post-Mortem

Hinw. Ü.: Dies ist die Übersetzung eines öffentlichen Postmortems aus dem Ingenieurtagebuch des Unternehmens. Preply. Es beschreibt ein Problem mit conntrack im Kubernetes-Cluster, das zu einem teilweisen Stillstand einiger Produktionsdienste führte.

Dieser Artikel könnte für diejenigen nützlich sein, die ein wenig mehr über Postmortems erfahren oder potenzielle Probleme mit DNS in der Zukunft vermeiden möchten.

Das ist nicht DNS
Es kann nicht DNS sein
Das war DNS

Ein wenig über Postmortems und Prozesse bei Preply

Im Postmortem wird ein Ausfall oder ein Ereignis in der Produktion beschrieben. Ein Postmortem umfasst eine Chronologie der Ereignisse, eine Beschreibung der Auswirkungen auf den Benutzer, die Hauptursache, die Maßnahmen und die daraus gezogenen Lehren.
Seeking SRE

In unseren wöchentlichen Meetings mit Pizza im Kreis des technischen Teams teilen wir verschiedene Informationen. Ein wichtiger Teil dieser Meetings sind die Postmortems, die oft mit einer Präsentation mit Folien und einer tiefergehenden Analyse des Vorfalls begleitet werden. Obwohl wir nach Postmortems nicht „applaudieren“, bemühen wir uns, eine „schuldlose“ Kultur zu fördern (blameless culture). Wir glauben, dass das Schreiben und Präsentieren von Postmortems uns (und nicht nur uns) helfen kann, ähnliche Vorfälle in der Zukunft zu vermeiden, und deshalb teilen wir sie.

Die an dem Vorfall beteiligten Personen sollten das Gefühl haben, dass sie ausführlich darüber berichten können, ohne Angst vor Bestrafung oder Vergeltung. Keine Tadel! Das Schreiben eines Postmortems ist keine Strafe, sondern eine Lernmöglichkeit für das gesamte Unternehmen.
Keep CALMS & DevOps: S steht für Sharing

DNS-Probleme in Kubernetes. Postmortem

Datum: 28.02.2020

Autoren: Amet U., Andrej S., Igor K., Alexej P.

Status: Beendet

Kurz gesagt: Teilweise Nichterreichbarkeit von DNS (26 Minuten) für einige Dienste im Kubernetes-Cluster

Auswirkungen: 15000 Ereignisse für die Dienste A, B und C verloren

Hauptursache: Kube-proxy konnte den alten Eintrag aus der conntrack-Tabelle nicht korrekt löschen, weshalb einige Dienste weiterhin versuchten, sich mit nicht existierenden Pods zu verbinden.

E0228 20:13:53.795782       1 proxier.go:610] Fehler beim Löschen von kube-system/kube-dns:dns Endpunkte-Verbindungen, Fehler: Fehler beim Löschen der conntrack-Einträge für UDP-Peer {100.64.0.10, 100.110.33.231}, Fehler: conntrack-Befehl hat zurückgegeben: ...

Auslöser: Aufgrund der geringen Last im Kubernetes-Cluster hat der CoreDNS-Autoscaler die Anzahl der Pods im Deployment von drei auf zwei reduziert.

Lösung: Ein weiterer Anwendungs-Deployment hat die Erstellung neuer Nodes ausgelöst, der CoreDNS-Autoscaler hat mehr Pods zur Unterstützung des Clusters hinzugefügt, was zu einer Überschreibung der conntrack-Tabelle führte.

Entdeckung: Die Prometheus-Überwachung hat eine große Anzahl von 5xx-Fehlern für die Services A, B und C festgestellt und einen Anruf an die Bereitschaftstechniker ausgelöst.

5xx-Fehler in Kibana

Aktionen

Aktion
Typ
Verantwortlich
Aufgabe

Autoskaler für CoreDNS deaktivieren
verhindern.
Amet U.
DEVOPS-695

Caching-DNS-Server einrichten
reduzieren.
Max V.
DEVOPS-665

Überwachung von conntrack einrichten
verhindern.
Amet U.
DEVOPS-674

Aus den gewonnenen Erkenntnissen

Was gut lief:

Die Überwachung funktionierte reibungslos. Die Reaktion war schnell und organisiert.
Wir sind auf keine Limits in den Nodes gestoßen.

Was nicht in Ordnung war:

Immer noch unbekannte tatsächliche Ursache, scheint ein spezifischer Bug in conntrack zu sein.
Alle Maßnahmen beheben nur die Folgen, nicht die Ursache (Bug).
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:

Ein weiterer Deployment hat den CoreDNS-Autoscaler ausgelöst, der die conntrack-Tabelle überschrieben hat.
Dieser Bug betraf nur einen Teil der Services.

Chronologie (EET)

Zeit
Aktion

22:13
Der CoreDNS-Autoscaler reduzierte die Anzahl der Pods von drei auf zwei.

22:18
Die Bereitschaftstechniker begannen, Anrufe vom Überwachungssystem zu erhalten.

22:21
Die Bereitschaftstechniker begannen, die Ursache der Fehler zu ermitteln.

22:39
Die Bereitschaftstechniker begannen, einen der letzten Dienste auf die vorherige Version zurückzusetzen.

22:40
Die 5xx-Fehler hörten auf aufzutreten, die Situation stabilisierte sich.

Zeit bis zur Entdeckung: 4 Minuten
Zeit bis zum Handeln: 21 Minuten
Zeit bis zur Behebung: 1 Minute

Zusätzliche Informationen

CoreDNS-Logs:

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:""}): typ: 'Normal' Grund: 'ScalingReplicaSet' Replica Set coredns-6cbb6646c9 auf 2 reduziert.

Links zu Kibana (ausgeschnitten), Grafana (ausgeschnitten)
Wo Linux conntrack nicht mehr dein Freund ist
kube-proxy Feinheiten: Debuggen eines intermittierenden Verbindungsrücksetzers
Rascher conntrack und DNS-Lookup-Zeitüberschreitungen

Um die CPU-Nutzung zu minimieren, verwendet der Linux-Kernel eine Funktion namens conntrack. Kurz gesagt, es handelt sich um ein Dienstprogramm, das eine Liste von NAT-Einträgen enthält, die in einer speziellen Tabelle gespeichert sind. Wenn das nächste Paket aus demselben Pod an dasselbe Pod wie zuvor kommt, wird die endgültige IP-Adresse nicht neu berechnet, sondern aus der conntrack-Tabelle entnommen.

Wie conntrack funktioniert

Ergebnisse

Dies war ein Beispiel für einen unserer Post-Mortems mit einigen nützlichen Links. In diesem Artikel teilen wir Informationen, die für andere Unternehmen nützlich sein könnten. Deshalb haben wir keine Angst, Fehler zu machen, und deshalb haben wir eines unserer Post-Mortems öffentlich gemacht. Hier sind noch einige interessante öffentliche Post-Mortems: