{"id":80532,"date":"2020-05-07T01:42:17","date_gmt":"2020-05-06T23:42:17","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/problemy-s-dns-v-kubernetes-publichnyj-postmortem"},"modified":"2020-05-07T01:42:17","modified_gmt":"2020-05-06T23:42:17","slug":"problemy-s-dns-v-kubernetes-publichnyj-postmortem","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/problemy-s-dns-v-kubernetes-publichnyj-postmortem","title":{"rendered":"Probleme mit DNS in Kubernetes. \u00d6ffentlicher Post-Mortem","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hinw. \u00dc.:<\/b> Dies ist die \u00dcbersetzung eines \u00f6ffentlichen Postmortems aus dem Ingenieurtagebuch des Unternehmens. Preply<\/a><\/noindex>. Es beschreibt ein Problem mit conntrack im Kubernetes-Cluster, das zu einem teilweisen Stillstand einiger Produktionsdienste f\u00fchrte.<\/i><\/p>\n

Dieser Artikel k\u00f6nnte f\u00fcr diejenigen n\u00fctzlich sein, die ein wenig mehr \u00fcber Postmortems erfahren oder potenzielle Probleme mit DNS in der Zukunft vermeiden m\u00f6chten.<\/p>\n

\"Probleme
\nDas ist nicht DNS
\nEs kann nicht DNS sein
\nDas war DNS<\/i>
\n<\/a><\/noindex><\/p>\n

Ein wenig \u00fcber Postmortems und Prozesse bei Preply<\/h2>\n

<\/p>\n

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\u00dfnahmen und die daraus gezogenen Lehren.<\/p>\n

Seeking SRE<\/a><\/noindex><\/i><\/p><\/blockquote>\n

\nIn unseren w\u00f6chentlichen 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\u00e4sentation mit Folien und einer tiefergehenden Analyse des Vorfalls begleitet werden. Obwohl wir nach Postmortems nicht \u201eapplaudieren\u201c, bem\u00fchen wir uns, eine \u201eschuldlose\u201c Kultur zu f\u00f6rdern (blameless culture<\/a><\/noindex>). Wir glauben, dass das Schreiben und Pr\u00e4sentieren von Postmortems uns (und nicht nur uns) helfen kann, \u00e4hnliche Vorf\u00e4lle in der Zukunft zu vermeiden, und deshalb teilen wir sie.<\/p>\n

Die an dem Vorfall beteiligten Personen sollten das Gef\u00fchl haben, dass sie ausf\u00fchrlich dar\u00fcber berichten k\u00f6nnen, ohne Angst vor Bestrafung oder Vergeltung. Keine Tadel! Das Schreiben eines Postmortems ist keine Strafe, sondern eine Lernm\u00f6glichkeit f\u00fcr das gesamte Unternehmen.<\/p>\n

Keep CALMS & DevOps: S steht f\u00fcr Sharing<\/a><\/noindex><\/i><\/p><\/blockquote>\n

<\/p>\n

DNS-Probleme in Kubernetes. Postmortem<\/h2>\n

\nDatum:<\/b> 28.02.2020<\/p>\n

Autoren:<\/b> Amet U., Andrej S., Igor K., Alexej P.<\/p>\n

Status:<\/b> Beendet<\/p>\n

Kurz gesagt:<\/b> Teilweise Nichterreichbarkeit von DNS (26 Minuten) f\u00fcr einige Dienste im Kubernetes-Cluster<\/p>\n

Auswirkungen:<\/b> 15000 Ereignisse f\u00fcr die Dienste A, B und C verloren<\/p>\n

Hauptursache:<\/b> Kube-proxy konnte den alten Eintrag aus der conntrack-Tabelle nicht korrekt l\u00f6schen, weshalb einige Dienste weiterhin versuchten, sich mit nicht existierenden Pods zu verbinden.<\/p>\n

E0228 20:13:53.795782       1 proxier.go:610] Fehler beim L\u00f6schen von kube-system\/kube-dns:dns Endpunkte-Verbindungen, Fehler: Fehler beim L\u00f6schen der conntrack-Eintr\u00e4ge f\u00fcr UDP-Peer {100.64.0.10, 100.110.33.231}, Fehler: conntrack-Befehl hat zur\u00fcckgegeben: ...<\/code><\/pre>\n
\nAusl\u00f6ser:<\/b> Aufgrund der geringen Last im Kubernetes-Cluster hat der CoreDNS-Autoscaler die Anzahl der Pods im Deployment von drei auf zwei reduziert.<\/p>\n
L\u00f6sung:<\/b> Ein weiterer Anwendungs-Deployment hat die Erstellung neuer Nodes ausgel\u00f6st, der CoreDNS-Autoscaler hat mehr Pods zur Unterst\u00fctzung des Clusters hinzugef\u00fcgt, was zu einer \u00dcberschreibung der conntrack-Tabelle f\u00fchrte.<\/p>\n
Entdeckung:<\/b> Die Prometheus-\u00dcberwachung hat eine gro\u00dfe Anzahl von 5xx-Fehlern f\u00fcr die Services A, B und C festgestellt und einen Anruf an die Bereitschaftstechniker ausgel\u00f6st.<\/p>\n
\"Probleme
\n5xx-Fehler in Kibana<\/i><\/p>\n
Aktionen<\/h3>\n
<\/p>\n
Aktion
\nTyp
\nVerantwortlich
\nAufgabe<\/p>\n
Autoskaler f\u00fcr CoreDNS deaktivieren
\nverhindern.
\nAmet U.
\nDEVOPS-695<\/p>\n
Caching-DNS-Server einrichten
\nreduzieren.
\nMax V.
\nDEVOPS-665<\/p>\n
\u00dcberwachung von conntrack einrichten
\nverhindern.
\nAmet U.
\nDEVOPS-674<\/p>\n
<\/p>\n
Aus den gewonnenen Erkenntnissen<\/h3>\n
\nWas gut lief:<\/b><\/p>\n