{"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":"DNS-Probleme in Kubernetes. \u00d6ffentliches Postmortem","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hinweis zur \u00dcbersetzung:<\/b> Dies ist eine \u00dcbersetzung eines \u00f6ffentlichen Post-Mortems aus dem Ingenieurbereich von Preply. Preply<\/a><\/noindex>. Darin wird ein Problem mit conntrack in einem Kubernetes-Cluster beschrieben, das zu teilweisen Ausf\u00e4llen einiger Produktionsdienste f\u00fchrte.<\/i><\/p>\n

Dieser Artikel k\u00f6nnte hilfreich sein f\u00fcr diejenigen, die mehr \u00fcber Post-Mortems erfahren m\u00f6chten oder potenzielle DNS-Probleme in der Zukunft vermeiden m\u00f6chten.<\/p>\n

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

Ein wenig \u00fcber Post-Mortems und Prozesse bei Preply.<\/h2>\n

<\/p>\n

Das Post-Mortem beschreibt einen Ausfall oder ein Ereignis in der Produktion. Das Post-Mortem enth\u00e4lt eine Chronologie der Ereignisse, eine Beschreibung der Auswirkungen auf die Nutzer, die Grundursache, die ergriffenen Ma\u00dfnahmen und die gewonnenen Erkenntnisse.<\/p>\n

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

\nIn unseren w\u00f6chentlichen Meetings bei Pizza im Kreis des technischen Teams teilen wir verschiedene Informationen. Ein wichtiger Bestandteil dieser Meetings sind die Post-Mortems, die oft von einer Pr\u00e4sentation mit Folien und einer gr\u00fcndlicheren Analyse des aufgetretenen Vorfalls begleitet werden. Auch wenn wir nach den Post-Mortems nicht \u201eApplaus\u201c geben, bem\u00fchen wir uns, eine \u201eschuldlose\u201c Kultur zu f\u00f6rdern (blameless culture<\/a><\/noindex>). Wir glauben, dass das Schreiben und Teilen von Post-Mortems uns (und nicht nur uns) helfen kann, \u00e4hnliche Vorf\u00e4lle in der Zukunft zu vermeiden, weshalb wir sie auch teilen.<\/p>\n

Die Personen, die in den Vorfall verwickelt sind, sollten das Gef\u00fchl haben, dass sie ihn im Detail beschreiben k\u00f6nnen, ohne Angst vor Bestrafung oder Vergeltung zu haben. Kein Vorwurf! Das Schreiben eines Post-Mortems ist keine Bestrafung, 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. Post-Mortem<\/h2>\n

\nLieber Tagebuch,<\/b> 28.02.2020<\/p>\n

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

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

Zusammenfassung:<\/b> Teilweise DNS-Unerreichbarkeit (26 Minuten) f\u00fcr einige Dienste im Kubernetes-Cluster<\/p>\n

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

Ursache:<\/b> Kube-Proxy konnte den alten Eintrag in 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] 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: ...<\/code><\/pre>\n
\nAusl\u00f6ser:<\/b> Aufgrund der niedrigen Last im Kubernetes-Cluster reduzierte der CoreDNS-Autoscaler die Anzahl der Pods im Deployment von drei auf zwei.<\/p>\n
Die L\u00f6sung:<\/b> Ein weiterer Anwendungs-Deployment hat die Erstellung neuer Nodes initiiert, der CoreDNS-Autoscaler hat zus\u00e4tzliche Pods hinzugef\u00fcgt, um den Cluster zu bedienen, was eine Neuschreibung der Conntrack-Tabelle zur Folge hatte.<\/p>\n
Erkennung:<\/b> Das Prometheus-Monitoring hat eine hohe Anzahl von 5xx-Fehlern f\u00fcr die Dienste A, B und C festgestellt und einen Alarm f\u00fcr die Bereitschaftsingenieure ausgel\u00f6st.<\/p>\n
\"DNS-Probleme
\n5xx-Fehler in Kibana<\/i><\/p>\n
Aktionen<\/h3>\n
<\/p>\n
Aktion
\nTyp
\nVerantwortlicher
\nZiel<\/p>\n
Autoscaler f\u00fcr CoreDNS deaktivieren
\nverhindert.
\nAmet U.
\nDEVOPS-695<\/p>\n
Caching-DNS-Server einrichten
\nverringern.
\nMax V.
\nDEVOPS-665<\/p>\n
Conntrack-Monitoring konfigurieren
\nverhindert.
\nAmet U.
\nDEVOPS-674<\/p>\n
<\/p>\n
Erlernte Lektionen<\/h3>\n
\nWas gut gelaufen ist:<\/b><\/p>\n