Site icon bintorosoft.com

Runbook „Pod kann DNS nicht resolven“

Red Snapper

Ein Runbook „Pod kann DNS nicht resolven“ ist in Kubernetes-Umgebungen eines der wertvollsten Standard-Runbooks überhaupt, weil DNS-Probleme extrem häufig auftreten, aber in sehr unterschiedlichen Formen. Ein Pod, der keine Namen auflösen kann, wirkt zunächst wie ein „Anwendungsfehler“: Requests laufen ins Timeout, Image Pulls scheitern, Healthchecks schlagen fehl, Service-to-Service-Kommunikation bricht sporadisch ab. In Wirklichkeit ist DNS ein Querschnittsthema aus mehreren Schichten: Pod-Konfiguration (resolv.conf, search domains), CoreDNS (Kapazität, Upstream, Cache), Netzwerkpfad (NetworkPolicy, CNI-Drops, MTU), Node-Subsysteme (Conntrack, IRQ/CPU-Saturation) und externe Abhängigkeiten (Upstream-Resolver, Firewall, Proxy). Ein gutes Runbook zwingt zu einem strukturierten Vorgehen, das schnell zwischen „lokales Pod-Problem“, „Namespace-Policy“, „CoreDNS-Outage“ und „Upstream-Problem“ trennt. Dieses Runbook ist bewusst so gestaltet, dass es Einsteigern klare Schrittfolgen gibt, aber auch Profis genug Tiefe bietet, um komplexe Failure-Modes zu entwirren. Ziel ist, in wenigen Minuten belastbar zu wissen: Wo liegt der Fehler, wie groß ist der Blast Radius und welche sichere Mitigation ist möglich, ohne blind an DNS oder Netzwerk herumzuschrauben.

Problemdefinition: Was bedeutet „kann DNS nicht resolven“ konkret?

Bevor Sie diagnostizieren, müssen Sie den Fehler sauber einordnen. DNS-Probleme haben unterschiedliche Symptome, die zu unterschiedlichen Ursachen passen. Sammeln Sie zuerst 2–3 konkrete Beispiele (Pod/Namespace, Zielname, Zeitpunkt, Fehlermeldung) und ordnen Sie sie grob ein.

DNS-Grundlagen im Kubernetes-Kontext, insbesondere wie Services und Pods aufgelöst werden, finden Sie hier: DNS for Services and Pods.

Schnellcheck: Blast Radius feststellen

Der wichtigste frühe Schritt ist die Frage: Ist das Problem pod-spezifisch, namespace-spezifisch, node-spezifisch oder clusterweit? Das bestimmt, ob Sie lokal mitigieren können oder sofort eskalieren müssen.

Praktischer Minimaltest: Starten Sie in einem betroffenen Namespace und in einem bekannten „guten“ Namespace jeweils einen Debug-Pod und testen Sie denselben FQDN. Wenn nur ein Namespace scheitert, ist das ein sehr starkes Policy-/Konfigurationssignal.

Schritt 1: In-Pod-Prüfung – resolv.conf, DNS-Policy und Search Domains

Viele DNS-Probleme sind nicht „CoreDNS kaputt“, sondern falsche oder unerwartete Resolver-Konfiguration im Pod. Prüfen Sie deshalb zuerst die DNS-Konfiguration des betroffenen Pods.

Typischer Fehler: Ein Pod nutzt durch dnsPolicy=Default den Node-Resolver und umgeht CoreDNS, während andere Pods korrekt über ClusterFirst laufen. Das kann „nur ein Pod hat DNS-Probleme“ erklären, obwohl CoreDNS gesund ist.

Suchdomain-Fallen: Warum NXDOMAIN manchmal „selbst gemacht“ ist

Wenn Anwendungen Namen ohne Punkt auflösen (z. B. „api“ statt „api.default.svc.cluster.local“), hängt das Ergebnis stark von search domains und ndots ab. Der Resolver probiert dann mehrere Varianten, was unter Last zu Verzögerungen führen kann. Ein Indikator ist eine hohe Zahl DNS-Queries pro Request oder auffällig viele NXDOMAIN-Antworten, bevor die korrekte Auflösung gelingt.

Schritt 2: Erreichbarkeit von CoreDNS prüfen (Netzwerkpfad im Cluster)

Wenn die Pod-Konfiguration plausibel ist, prüfen Sie als nächstes, ob der Pod CoreDNS überhaupt erreicht. Das ist häufig die Trennlinie zwischen „DNS-Server/Upstream“ und „Netzwerk/Policy“. CoreDNS läuft meist als Service (z. B. kube-dns) im Namespace kube-system.

Viele NetworkPolicies erlauben Egress nur zu „app-internen“ Zielen und vergessen DNS. Das wirkt dann wie „Internet kaputt“, ist aber eine Policy-Lücke. Grundlagen zu NetworkPolicies: Kubernetes Network Policies.

Schritt 3: CoreDNS-Health – Kapazität, Errors, Latenz, Restarts

Wenn CoreDNS erreichbar ist, muss geprüft werden, ob CoreDNS korrekt antwortet und ob es unter Last stabil ist. DNS-Probleme sind häufig Kapazitäts- oder Upstream-Probleme, die erst bei Peaks auftreten.

Wenn Sie Metriken nutzen, sind das typische Pflichtsignale. Auch ohne Metriken gilt: Restarts und hohe CPU sind oft bereits ein klares Signal für Überlast oder Fehlkonfiguration. Für CoreDNS-Konfigurationsprinzipien ist die Projektseite hilfreich: CoreDNS Manual.

Kapazitätsindikator: Query Rate pro CoreDNS-Pod

Eine einfache, operational nützliche Betrachtung ist „Queries pro Sekunde pro CoreDNS-Pod“. Wenn die Last steigt, ohne dass skaliert wird, kippt Latenz zuerst, dann kommen Timeouts. Als grobe Kennzahl:

QPS_pro_Pod = DNS_Queries_pro_Sekunde Anzahl_CoreDNS_Pods

Der absolute Grenzwert hängt stark von Umgebung und Query-Mix ab, aber die Relation hilft, Skalierungsbedarf sichtbar zu machen.

Schritt 4: Upstream-Resolver und externe Abhängigkeiten prüfen

CoreDNS ist selten die letzte Station. Für externe Namen (z. B. api.example.com) hängt CoreDNS am Upstream (VPC/VNet DNS, Unternehmensresolver, Public DNS via Firewall/Proxy). Wenn Upstream langsam oder blockiert ist, sehen Pods DNS-Probleme, obwohl CoreDNS „läuft“.

Wenn EDNS/Fragmentierung eine Rolle spielt, ist es typisch, dass „kleine“ DNS-Antworten funktionieren, große aber timeouten. Das ist ein klassischer Hinweis auf MTU/ICMP/Fragment-Filterung.

Schritt 5: Node-spezifische Ursachen – Conntrack, IRQ/CPU und Drops

Wenn DNS-Probleme nur auf bestimmten Nodes auftreten oder unter Last intermittierend sind, liegt die Ursache oft auf Node-Ebene. DNS ist besonders empfindlich, weil es häufig UDP nutzt (keine Retransmits wie TCP) und weil viele kleine Pakete schnell hohe Paketlast erzeugen.

Ein gutes Signal ist TCP-Retransmits plus DNS-Timeouts plus erhöhte softirq/irq CPU auf denselben Nodes. Dann ist „DNS kaputt“ nur das Symptom eines Node-Engpasses.

Schritt 6: Häufige Konfigurationsfehler, die DNS gezielt brechen

Einige Fehlerbilder tauchen so oft auf, dass sie in jedes Runbook gehören. Prüfen Sie diese Punkte gezielt, bevor Sie tiefer in Spezialanalysen gehen:

Schritt 7: Sichere Mitigation – stabilisieren, ohne neue Risiken einzubauen

Mitigation hängt vom Blast Radius ab. Ziel ist, die Plattform zu stabilisieren, während Sie die Root Cause weiter eingrenzen. Maßnahmen sollten so gewählt sein, dass sie reproduzierbar und rückgängig zu machen sind.

Wichtig: „DNS-Server wechseln“ oder „random resolver“ ist selten eine saubere Mitigation im Cluster und kann Governance und Auditability verschlechtern. Besser sind gezielte, kontrollierte Änderungen am DNS-Pfad.

Schritt 8: Postmortem-Daten sichern – damit das Problem nicht wiederkommt

DNS-Probleme wiederholen sich gern, weil Teams nur „es geht wieder“ feststellen, aber nicht die Ursache absichern. Sammeln Sie deshalb standardisiert:

Minimal-Runbook als kompakte Schrittfolge

Outbound-Quellen für vertiefende Informationen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Lieferumfang:

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Exit mobile version