Kubernetes DNS Auflösung fehlgeschlagen: CoreDNS debuggen

TL;DR

DNS-Probleme in Kubernetes liegen in 3 von 4 Fällen an fehlerhaften CoreDNS Pods, falscher DNS Policy oder zu hohen ndots-Werten. Prüfen Sie zuerst den CoreDNS Pod-Status, dann die /etc/resolv.conf im betroffenen Pod und testen Sie die Auflösung mit nslookup gegen den ClusterIP des kube-dns Service.

3 von 4 Fällen, in denen DNS in Kubernetes nicht funktioniert, lassen sich auf eine Handvoll Ursachen eingrenzen. Bevor Sie stundenlang Netzwerk-Policies durchgehen: Starten Sie hier.

# CoreDNS Pods prüfen - laufen sie überhaupt?
kubectl get pods -n kube-system -l k8s-app=kube-dns

# DNS-Auflösung direkt testen
kubectl run dns-test --rm -it --image=busybox:1.36 --restart=Never -- nslookup kubernetes.default

Wenn der erste Befehl Pods im Status CrashLoopBackOff oder Pending zeigt, ist die Ursache klar. Wenn die Pods laufen, aber der nslookup fehlschlägt, wird es interessanter.

CoreDNS Pods prüfen und reparieren

CoreDNS startet nicht (CrashLoopBackOff)

Die häufigste Ursache: eine fehlerhafte Corefile-Konfiguration oder ein Loop-Problem, bei dem CoreDNS seine eigene Adresse als Upstream-Server verwendet.

# Logs prüfen
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=50

# ConfigMap der Corefile anschauen
kubectl get configmap coredns -n kube-system -o yaml

Ein typischer Fehler in den Logs:

[FATAL] plugin/loop: Loop (127.0.0.1:43523 -> :53) detected for zone ".", see https://coredns.io/plugins/loop#troubleshooting

Das bedeutet: CoreDNS leitet Anfragen an sich selbst weiter. Der Fix hängt von Ihrer Umgebung ab:

Corefile anpassen

kubectl edit configmap coredns -n kube-system

Eine funktionierende Standard-Corefile:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health {
          lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
          ttl 30
        }
        forward . /etc/resolv.conf {
          max_concurrent 1000
        }
        cache 30
        loop
        reload
        loadbalance
    }

Nach der Änderung CoreDNS-Pods neustarten:

kubectl rollout restart deployment coredns -n kube-system

ndots und search domains verstehen

Dieses Problem ist tückisch, weil alles zu funktionieren scheint, nur langsam. Schauen Sie sich die resolv.conf im betroffenen Pod an:

kubectl exec my-app -- cat /etc/resolv.conf

Typische Ausgabe:

nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

Der Wert ndots:5 bedeutet: Jeder Name mit weniger als 5 Punkten wird zuerst mit allen search domains probiert. Wenn Ihre Anwendung api.example.com auflöst (2 Punkte), generiert Kubernetes diese DNS-Queries:

1. api.example.com.default.svc.cluster.local -- schlägt fehl
2. api.example.com.svc.cluster.local -- schlägt fehl
3. api.example.com.cluster.local -- schlägt fehl
4. api.example.com -- funktioniert

Das sind 4 Queries statt einer. Bei hohem Traffic multipliziert sich das.

ndots reduzieren

Für Pods, die hauptsächlich externe Domains auflösen:

spec:
  dnsConfig:
    options:
      - name: ndots
        value: "2"

Alternative: Fügen Sie einen abschließenden Punkt an den Hostnamen an (api.example.com.), um die search domain Expansion komplett zu umgehen.

DNS Policy richtig setzen

Kubernetes bietet vier DNS Policies. Die falsche Wahl ist eine häufige Fehlerquelle:

Ein klassischer Fehler: Pods mit hostNetwork: true verwenden standardmäßig die DNS Policy Default -- sie nutzen dann den DNS-Server des Nodes statt CoreDNS und können keine Services im Cluster auflösen.

spec:
  hostNetwork: true
  dnsPolicy: ClusterFirstWithHostNet  # Das ist der Fix

CoreDNS Performance-Probleme diagnostizieren

Wenn DNS grundsätzlich funktioniert, aber langsam oder unzuverlässig ist:

# CoreDNS Metriken prüfen (wenn Prometheus läuft)
kubectl port-forward -n kube-system svc/kube-dns 9153:9153
curl http://localhost:9153/metrics | grep coredns_dns_request_duration

# Anzahl der DNS-Anfragen pro Sekunde
curl -s http://localhost:9153/metrics | grep coredns_dns_requests_total

Bei hoher Last auf CoreDNS helfen diese Maßnahmen:

# CoreDNS Replicas erhöhen
kubectl scale deployment coredns -n kube-system --replicas=3

# Oder NodeLocal DNSCache einsetzen (empfohlen ab 50+ Nodes)
# Das installiert einen DNS-Cache auf jedem Node

NodeLocal DNSCache

Ab einer gewissen Clustergröße lohnt sich NodeLocal DNSCache. Es spart Netzwerk-Hops und entlastet CoreDNS:

# Prüfen ob NodeLocal DNSCache läuft
kubectl get ds -n kube-system | grep node-local-dns

Debugging-Checkliste

Wenn Sie nicht weiterkommen, arbeiten Sie diese Liste durch:

# 1. CoreDNS Pods laufen?
kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide

# 2. kube-dns Service hat Endpoints?
kubectl get endpoints kube-dns -n kube-system

# 3. DNS direkt gegen CoreDNS IP testen
kubectl run dns-debug --rm -it --image=nicolaka/netshoot --restart=Never \
  -- dig @10.96.0.10 kubernetes.default.svc.cluster.local

# 4. Network Policy blockiert DNS?
kubectl get networkpolicy -A | grep -i dns

# 5. DNS vom Node aus testen (SSH auf den Node)
nslookup kubernetes.default.svc.cluster.local 10.96.0.10

FAQ

Warum funktioniert nslookup im Pod nicht, aber ping schon?

Ping nutzt die libc-Auflösung und liest /etc/hosts. nslookup fragt direkt den DNS-Server. Wenn /etc/hosts einen Eintrag hat, funktioniert Ping, aber nslookup scheitert trotzdem. Prüfen Sie die resolv.conf im Pod.

Kann ich externe DNS-Server statt CoreDNS verwenden?

Technisch ja, aber dann verlieren Sie die Service Discovery im Cluster. Besser: CoreDNS so konfigurieren, dass es externe Queries an Ihren bevorzugten DNS-Server weiterleitet.

Wie finde ich heraus, ob eine Network Policy den DNS-Traffic blockiert?

DNS läuft über UDP Port 53. Prüfen Sie mit kubectl get networkpolicy -A -o yaml ob ausgehender Traffic auf Port 53 zum Namespace kube-system erlaubt ist. Viele Teams vergessen beim Einführen von Network Policies den DNS-Egress.

CoreDNS zeigt "SERVFAIL" -- was bedeutet das?

SERVFAIL bedeutet, dass CoreDNS die Anfrage zwar erhalten hat, aber den Upstream-Server nicht erreichen kann. Prüfen Sie die forward-Direktive in der Corefile und ob der Upstream DNS-Server vom Node aus erreichbar ist.

Wenn DNS-Probleme in Ihrem Cluster regelmäßig auftreten oder Sie Unterstützung beim Aufbau einer stabilen DNS-Infrastruktur brauchen, helfen wir gerne -- Kontakt aufnehmen.

Weiterführende Artikel:

• CoreDNS Troubleshooting: Kubernetes DNS Probleme lösen
• Kubernetes Service nicht erreichbar: Netzwerk-Troubleshooting