Kubernetes-DNS

Die wichtigsten Befehle zum Merken

• kubectl config current-context — den gewählten Clusterkontext prüfen.
• kubectl exec … -- cat /etc/resolv.conf — Resolverkonfiguration im Pod lesen.
• kubectl exec … -- nslookup NAME — DNS aus dem Pod abfragen.

Befehle und Optionen

Befehl oder Option	Bedeutung
config current-context	Aktiven kubeconfig-Kontext unverändert anzeigen.
-n lab	Namespace lab wählen.
exec dns-lab -- BEFEHL	Befehl im vorhandenen Pod ausführen; -- beendet kubectl-Optionen.
cat /etc/resolv.conf	Nameserver, Suchliste und Resolveroptionen lesen.
nslookup kubernetes.default	Servicenamen im Namespace default auflösen.

Ein interaktives Terminal ist unnötig. Die Werkzeuge müssen im Pod vorhanden sein; kubectl installiert sie nicht. Die Abfrage nutzt den Netzwerk- und DNS-Kontext des Pods, nicht des Laptops.

Die entscheidenden Konzepte

1. DNS gibt wechselnden Backends einen stabilen Namen

Pods können ersetzt werden und neue Adressen erhalten. Kubernetes-DNS bietet Servicenamen aus Service und Namespace, statt einzelne Podadressen fest einzubauen.

Ein normaler Service löst häufig zu einer stabilen virtuellen ClusterIP auf. Ein Headless Service kann stattdessen Endpunktadressen liefern. Der Name allein verrät deshalb nicht, ob die Verbindung eine virtuelle Service-IP oder direkt einen Endpunkt verwendet.

2. Der Namespace prägt kurze Namen

Die Suchliste enthält normalerweise die Servicedomäne des eigenen Namespace und weitere Clusterdomänen. Kurze Namen können dadurch lokale Services, namespacequalifizierte Namen andere Namespaces auswählen.

Die Clusterdomäne ist konfigurierbar; cluster.local ist verbreitet, nicht zwingend. ndots beeinflusst, ob zuerst Suchsuffixe versucht werden. Eine Anwendungsauflösung kann deshalb mehrere DNS-Anfragen auslösen.

3. Der Podresolver ist eine eigene Abhängigkeit

Das Kubelet konfiguriert Pod-DNS nach Richtlinie und Clustereinstellungen. Ein DNS-Dienst, häufig CoreDNS, beantwortet Clusternamen und kann weitere Anfragen an Upstreamresolver geben.

Funktionierendes Laptop-DNS beweist keinen funktionierenden Podpfad. Interne Namen können gelingen, während externe Weiterleitung scheitert. Prüfe Konfiguration und Abfrage dort, wo die Anwendung tatsächlich läuft.

4. Auflösung ist nur der erste Schritt

Eine DNS-Antwort liefert Adressen oder Records. Sie belegt weder erlaubte Network Policy noch Listener, bereites Backend, erfolgreiches TLS oder gültige Anwendungsantwort.

Caches beeinflussen zusätzlich die Sichtbarkeit von Änderungen. Unterscheide Namens-, Verbindungs- und Anwendungsfehler. DNS wegen einer HTTP-Fehlerantwort umzubauen kann die falsche Schicht treffen.

Ein kleines Beispiel

Optional: Prüfe vor exec, dass der Kontext den vorgesehenen Testcluster auswählt. Nutze den vorhandenen Diagnose-Pod. Das Beispiel erstellt keine Ressourcen.

kubectl config current-context
kubectl -n lab exec dns-lab -- cat /etc/resolv.conf
kubectl -n lab exec dns-lab -- nslookup kubernetes.default

Untersuche nameserver, search und options. Vergleiche danach die Antwort für kubernetes.default mit dem vorgesehenen Servicenamespace. Die angezeigte DNS-Serveradresse ist der Resolver, nicht zwingend der abgefragte Service.

Eine Antwort belegt Pod-DNS-Auflösung, keine API-Authentifizierung oder HTTPS-Anfrage. NXDOMAIN, Timeout und fehlendes nslookup sind unterschiedliche Fehler. Weil nur gelesen und abgefragt wird, entfällt Ressourcenbereinigung.

Merke dir: Kubernetes-DNS ordnet Servicenamen aus Sicht des Pods zu. Erfolgreiche Auflösung beginnt die Verbindungsprüfung, sie beendet sie nicht.