Site icon bintorosoft.com

Kubernetes-DNS (CoreDNS): Outage-Pattern und Mitigation

Red Snapper

Kubernetes-DNS (CoreDNS): Outage-Pattern und Mitigation ist ein Thema, das viele Cluster erst dann ernst nehmen, wenn „plötzlich alles kaputt“ wirkt – obwohl die eigentliche Ursache nur DNS ist. In Kubernetes hängt nahezu jede interne Kommunikation an Namensauflösung: Services, Headless Services, StatefulSets, Webhooks, Sidecars, Ingress-Backends und externe Abhängigkeiten. Wenn CoreDNS ausfällt oder nur noch langsam antwortet, sehen Anwendungen oft nicht „DNS-Error“, sondern Timeouts, sporadische Verbindungsabbrüche, CrashLoops, fehlende Dependencies und unklare 5xx-Fehler. Genau deshalb ist Kubernetes-DNS (CoreDNS) ein klassisches Multiplikator-Risiko: Ein einzelner Engpass kann sich innerhalb von Minuten zu einem flächigen Incident entwickeln, weil Clients anfangen zu retrien, Pods neu starten und dadurch noch mehr DNS-Queries erzeugen. Dieser Artikel beschreibt typische Outage-Pattern in CoreDNS, wie Sie sie frühzeitig erkennen, wie Sie die häufigsten Ursachen sauber voneinander trennen und welche Mitigation-Maßnahmen in der Praxis am zuverlässigsten wirken – von Caching-Strategien über Ressourcenplanung bis hin zu NodeLocal DNSCache, NetworkPolicy-Regeln, Monitoring und incident-sicheren Rollouts.

Was CoreDNS in Kubernetes leistet und warum Ausfälle so weitreichend sind

CoreDNS ist der Standard-DNS-Server in Kubernetes und übernimmt typischerweise die Auflösung von Service-Namen (z. B. myservice.mynamespace.svc.cluster.local), Pod-DNS (je nach Konfiguration) und oft auch das Weiterleiten externer DNS-Anfragen an Upstream-Resolver. CoreDNS ist damit ein zentraler Bestandteil der Service Discovery. Selbst wenn Ihre Anwendungen „eigentlich“ nur IPs nutzen, werden in der Praxis in vielen Libraries, Sidecars, Operatoren und Tools ständig Namen aufgelöst: Datenbanken, Message-Broker, Telemetry-Endpunkte, Object Storage Gateways, Identity Provider oder interne APIs.

Offizielle Grundlagen zu DNS in Kubernetes finden Sie unter DNS for Services and Pods und zur CoreDNS-Konfiguration im Projekt unter CoreDNS Manual.

Die häufigsten Outage-Pattern bei Kubernetes-DNS (CoreDNS)

CoreDNS-Ausfälle sind selten „einfach down“. Häufiger sind degradierte Zustände: Antworten kommen nur langsam, nur teilweise oder nur für bestimmte Query-Typen. Das macht die Diagnose schwierig, weil Symptome zwischen Pods, Nodes und Namespaces variieren können.

Pattern: DNS-Timeouts und „sporadische“ Auflösung

Symptome sind typischerweise: „temporary failure in name resolution“, „no such host“ (auch wenn der Name existiert), oder Verbindungen, die mal funktionieren und mal nicht. Ursache ist oft Überlast (QPS), Paketdrops (UDP), Conntrack-Probleme, CPU-Saturation oder Upstream-Resolver-Probleme. Besonders tückisch: Ein Teil der Anfragen wird noch aus Cache bedient, der Rest läuft in Timeouts.

Pattern: Nur externe Namen sind kaputt, interne Services funktionieren

Wenn Services im Cluster auflösbar bleiben, aber externe Domains nicht, liegt die Ursache häufig im forward-Pfad: Upstream-DNS ist langsam, nicht erreichbar, rate-limited oder liefert fehlerhafte Antworten. Auch NetworkPolicies oder egress-NAT-Pfade können den Upstream blockieren.

Pattern: Nur interne Namen sind kaputt, externe funktionieren

Wenn cluster.local oder die Service-Zone Probleme macht, ist das oft ein Kubernetes-spezifisches Thema: API-Server-Erreichbarkeit (CoreDNS braucht Zugriff auf die Kubernetes API für Service-Records), eine fehlerhafte Corefile-Konfiguration, RBAC-Probleme oder ein Bug/Regression nach einem Upgrade.

Pattern: Große Antwortpakete brechen (EDNS0, Fragmentierung, MTU)

DNS-Antworten können größer werden, etwa bei vielen A/AAAA-Records (Headless Service, viele Pods) oder DNSSEC. Wenn UDP-Fragmente gedroppt werden oder die effektive MTU in Tunneln geringer ist als gedacht, sehen Sie timeouts und Retries. Häufig funktioniert dann „kleines DNS“ (wenige Records), aber „großes DNS“ nicht.

Pattern: Query-Stürme durch CrashLoops und aggressive Retries

Wenn Workloads bei Start Dependencies auflösen und bei Fehlern sofort neu starten, entsteht ein selbstverstärkender Loop: DNS ist langsam → Apps failen → Restart → noch mehr DNS-Queries. Dieses Pattern sieht man besonders bei Deployments mit kurzen Backoff-Settings, bei Service-Mesh Sidecars, bei Init-Containern oder bei Jobs, die massenhaft parallel starten.

Warum DNS-Probleme oft falsch interpretiert werden

DNS ist selten „sichtbar“ im Fehlerbild. In Logs steht meist nur, dass eine Verbindung nicht aufgebaut werden konnte. Das führt in Incidents häufig in die falsche Richtung: Teams debuggen NetworkPolicies, Ingress, Service-Objekte oder Applikations-Code, obwohl das Problem bereits davor liegt. Ein guter Heuristik-Test ist immer: „Kann der Pod die Ziel-IP erreichen, wenn ich sie direkt nutze?“ Wenn ja, ist die Wahrscheinlichkeit hoch, dass DNS beteiligt ist. Umgekehrt gilt: Wenn DNS-Resolution schon fehlschlägt, sind Layer-4/Layer-7-Checks später in der Kette nicht zuverlässig.

CoreDNS-Architektur: Welche Engpässe realistisch sind

CoreDNS läuft typischerweise als Deployment im kube-system-Namespace und wird über einen Service (meist kube-dns) erreichbar gemacht. Pods nutzen in der Regel die Cluster-DNS-IP in ihrer resolv.conf. CoreDNS selbst verarbeitet Queries, cached optional und forwardet externe Queries an Upstream-Resolver. Daraus ergeben sich mehrere Engpasszonen:

Die CoreDNS-Plugins und deren Verhalten sind im CoreDNS Plugin Reference detailliert beschrieben, insbesondere kubernetes, cache, forward und log.

Diagnose-Playbook: CoreDNS-Outage sauber eingrenzen

Ein zuverlässiges Diagnose-Playbook trennt drei Fragen: (1) Ist DNS wirklich das Problem? (2) Ist es intern (kubernetes-Zone) oder extern (forward)? (3) Ist es Overload, Netzwerkpfad oder Konfiguration? Die folgenden Schritte sind bewusst so formuliert, dass sie ohne Spezialwissen reproduzierbar sind.

Schritt: Interne vs. externe Auflösung unterscheiden

Schritt: Timeout vs. NXDOMAIN vs. SERVFAIL lesen

Schritt: Node-Spezifität prüfen

Wenn DNS-Ausfälle nur auf bestimmten Nodes auftreten, ist es häufig ein Node-Netzproblem (Conntrack, Drops, lokale Firewall, CPU). Das ist ein typisches Muster bei stark belasteten Ingress-Nodes oder Nodes mit vielen kurzlebigen Verbindungen.

Kapazitätsmodell: Warum QPS, Cache-Hit-Rate und Timeout-Settings entscheidend sind

DNS wird stabil, wenn die Last planbar ist und Caching wirkt. In vielen Clustern ist nicht die absolute Zahl an Pods das Problem, sondern die Query-Rate pro Sekunde (QPS) und die Cache-Effektivität. Ein einfaches Kapazitätsdenken hilft, Engpässe sichtbar zu machen: Wenn ein Teil der Queries aus Cache bedient wird, reduziert sich die Last auf Upstream und auf das kubernetes-Plugin massiv.

EffektiveQPS = GesamtQPS × ( 1 − CacheHitRate )

Wenn die CacheHitRate niedrig ist (z. B. weil TTLs sehr klein sind oder viele einzigartige Namen aufgelöst werden), bleibt die EffektiveQPS hoch. Dann sind Overload und Upstream-Timeouts deutlich wahrscheinlicher. Umgekehrt kann eine moderate Verbesserung der CacheHitRate den Cluster stabilisieren, ohne sofort CPU zu verdoppeln.

Mitigation 1: Caching richtig konfigurieren und TTL-Fallen vermeiden

Der Cache ist eine der wirksamsten Maßnahmen gegen DNS-Outages, aber er muss zur Workload passen. Zu kurze TTLs führen zu unnötig vielen Queries. Zu lange TTLs können dagegen Änderungen (z. B. Pod-IP-Wechsel) verzögert sichtbar machen. In Kubernetes ist es besonders wichtig, die Unterschiede zwischen Service-Namen (stabil) und Pod-Records (dynamisch) zu verstehen.

Konzept und Parameter des Cache-Plugins sind im CoreDNS cache Plugin beschrieben.

Mitigation 2: NodeLocal DNSCache einsetzen, um Latenz und Conntrack-Druck zu reduzieren

NodeLocal DNSCache ist ein Kubernetes-Ansatz, um DNS-Anfragen lokal auf jedem Node zu cachen und damit den zentralen CoreDNS-Service zu entlasten. Der Effekt ist oft spürbar: kürzere Wege, weniger Paketdrops auf dem Weg zu CoreDNS, weniger Conntrack-Einträge und weniger Lastspitzen auf den CoreDNS-Pods. Besonders in großen Clustern oder bei hoher DNS-Last ist NodeLocal DNSCache eine bewährte Mitigation.

Details und Setup finden Sie in der Kubernetes-Dokumentation zu NodeLocal DNSCache.

Mitigation 3: Ressourcen, Autoscaling und Pod-Platzierung für CoreDNS

CoreDNS sollte nicht „irgendwo“ laufen. Als kritische Infrastruktur gehört es auf stabile Nodes, mit ausreichender CPU, klaren Requests/Limits und sinnvoller Replikation. Eine zu knappe CPU-Limitierung führt bei Lastspitzen zu Latenz, Timeouts und schließlich zu Retry-Stürmen. Gleichzeitig sollte CoreDNS über mehrere Nodes verteilt sein, damit ein einzelner Node-Ausfall nicht sofort DNS lahmlegt.

Mitigation 4: NetworkPolicies und Egress-Regeln so gestalten, dass DNS nicht unabsichtlich blockiert wird

Ein klassischer Outage-Auslöser ist eine Egress-Default-Deny-Policy, die DNS nicht explizit erlaubt. Dann „funktioniert alles“ im Test, bis eine Policy flächig ausgerollt wird oder ein neuer Namespace ohne DNS-Allow entsteht. Wichtig ist, DNS für Pods in der richtigen Richtung zu erlauben: UDP 53 (und je nach Umgebung auch TCP 53) zum DNS-Service beziehungsweise zu NodeLocal DNSCache, falls aktiv.

Grundlagen zur Policy-Logik finden Sie unter Kubernetes Network Policies.

Mitigation 5: Upstream-Resolver robust machen und Forwarding bewusst konfigurieren

Wenn externe Auflösung ein Problem ist, reicht es nicht, CoreDNS zu skalieren. Dann müssen Sie die Upstream-Kette betrachten: Welche Resolver werden genutzt? Gibt es Rate-Limits? Sind Latenzen stabil? Werden bestimmte Zonen über interne Resolver beantwortet? Eine robuste Forwarding-Konfiguration vermeidet Single Points of Failure und verhindert, dass ein langsamer Upstream den gesamten DNS-Server blockiert.

Das Verhalten des Forwarding-Plugins ist im CoreDNS forward Plugin dokumentiert.

Mitigation 6: Große Antworten, EDNS0 und MTU-Probleme aktiv adressieren

Wenn Outages mit großen Antwortpaketen zusammenhängen, ist das oft ein Netzwerkpfadproblem: UDP-Fragmente werden gedroppt, ICMP wird blockiert oder die effektive MTU ist zu klein (Overlay, VPN, IPsec). In solchen Fällen wirkt DNS „flaky“, obwohl der Resolver korrekt arbeitet. Mitigation besteht dann aus einer Kombination aus Netzwerk-Disziplin und DNS-spezifischen Maßnahmen:

Monitoring und Alerting: Signale, die DNS-Outages früh sichtbar machen

DNS-Outages lassen sich zuverlässig verhindern, wenn Sie die richtigen Metriken beobachten. Entscheidend ist, nicht nur „CoreDNS läuft“ zu prüfen, sondern die Qualität der Antworten. Dazu gehören Latenz, Fehlerraten, Zeitüberschreitungen, Cache-Hit-Raten und die Verteilung nach Zone (intern vs. extern).

Für CoreDNS-spezifische Observability ist die Plugin-Dokumentation zu CoreDNS metrics relevant, da sie beschreibt, welche Metriken exportiert werden können.

Incident-sichere Betriebspraktiken: Was in der Realität wirklich hilft

Viele CoreDNS-Outages entstehen nicht durch „Normalbetrieb“, sondern durch Änderungen: Cluster-Upgrades, Corefile-Anpassungen, neue NetworkPolicies, massenhaftes Deployment-Rollout oder das Einschalten von Sidecars. Ein stabiler Betrieb setzt daher auf Change Safety und klare Guardrails.

Typische Ursachen nach Ursache-Kategorie: Schnellzuordnung für die Praxis

Wenn Sie in einem Incident schnell handeln müssen, hilft eine Zuordnung nach Kategorien. Die folgende Liste ist bewusst „praktisch“ und nicht akademisch: Sie soll helfen, die wahrscheinlichste Ursache früh zu treffen.

Outbound-Quellen für Vertiefung und Best Practices

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