Begriff

Container DNS

Containerization Networking S2

3 Quellen 1 Lernpfad 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Früher mussten Programmierer IP-Adressen wissen: "Datenbank ist auf 192.168.1.5". In der Container-Welt ändern sich IPs ständig (siehe ClusterIP). Deshalb brauchen Container ein eigenes Telefonbuch (DNS). Jeder Container bekommt beim Start automatisch die Adresse des internen DNS-Servers (z. B. 127.0.0.11 in Docker). Wenn dein Webserver sagt "Verbinde mit postgres-db", fragt er diesen DNS-Server. Der DNS-Server antwortet sofort mit der aktuellen internen IP des Datenbank-Containers. Du musst dich um IP-Adressen nie wieder kümmern.

Merksatz: Ein internes Namensauflösungssystem innerhalb einer Container-Plattform, das es ermöglicht, Dienste über ihren Namen (z. B. "db", "redis") statt über flüchtige IP-Adressen anzusprechen.

In Docker Compose:

services:
  mein-web: ...
  meine-db: ...

Im Code (Node.js): const db = connect("postgres://meine-db:5432"); Docker setzt automatisch Einträge für meine-db.

In Kubernetes: Service Name: users-api. Namespace: production. Vollständiger Name (FQDN): users-api.production.svc.cluster.local. Innerhalb desselben Namespace reicht kurz: users-api.

Praxisroutine

In der Praxis lernst du Container DNS, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Docker Embedded DNS (127.0.0.11)

Docker fängt DNS-Anfragen auf Port 53 ab. Es prüft: "Ist das ein Container-Name?" -> Antworte mit Container-IP. "Ist das google.com?" -> Leite weiter an den Host-DNS (z. B. 8.8.8.8). Das passiert im Docker Daemon (dockerd). Wichtig: Das funktioniert nur in User-Defined Bridge Networks. Im default Bridge Network gibt es KEIN DNS (Legacy-Altlast).

2. CoreDNS (Kubernetes)

In K8s ist DNS ein eigener Pod: CoreDNS. Er liest die Kubernetes API ("Service Watcher"). Sobald du einen Service erstellst, schreibt CoreDNS einen Record in seinen Speicher. Die /etc/resolv.conf in jedem Pod zeigt auf die Cluster-IP von CoreDNS. Wenn CoreDNS abstürzt, bricht die komplette Cluster-Kommunikation zusammen ("It's always DNS").

3. ndots:5 Problem

Eine berühmte Performance-Falle in K8s. Linux DNS Resolver versuchen, Domänen zu "vervollständigen". Du fragst: google.com. K8s Config sagt: search default.svc.cluster.local svc.cluster.local cluster.local. Der Container fragt erst: google.com.default.svc.cluster.local? (NXDOMAIN). Dann: google.com.svc.cluster.local? (NXDOMAIN). ... Erst beim 5. Versuch (ndots limit) fragt er google.com. (Root). Das verdreifacht die DNS-Latenz für externe Aufrufe. Lösung: FQDN nutzen (google.com.) oder ndots in Pod-Spec tunen.

Das CoreDNS Plugin-System

Die Architektur von Kubernetes-CoreDNS basiert auf einer Kette von hochoptimierten Plugins, die in der Datei Corefile (welche in einer ConfigMap lebt) definiert werden. Wenn eine Query (z. B. db.default.svc.cluster.local.) eintrifft:

Das kubernetes Plugin fängt die Request auf, schaut im Memory-Cache nach, ob ein entsprechender K8s-Service-Typ existiert, und retourniert die ClusterIP.
Schlägt das fehl, übernimmt das forward Plugin und leitet die Request an den Resolver des Host-Nodes, das VPC-DNS der Cloud (z. B. Route53) oder an 8.8.8.8 weiter, um das Internet aufzulösen. Erfahrene Betreiber manipulieren das Corefile oft (z. B. durch das rewrite Plugin), um Anfragen dynamisch von Legacy-Domains (db.legacy.corp) transparent auf K8s-interne ClusterIP-Domains umzuschreiben, ohne Applikationscode anfassen zu müssen.

NodeLocal DNSCache

Bei riesigen Clustern fliegen für jeden kleinen curl-Befehl hunderte DNS UDP-Pakete durch das Overlay-Netzwerk zum CoreDNS Pod. UDP auf stark belasteten Linux-Kernel-Netzwerkstacks (und insbesondere im conntrack Subsystem für NAT) führt extrem schnell zu Paketabwürfen (Drops) und zwingt Clients zu langwierigen 5-Sekunden Retries. Die Enterprise-Abhilfe ist der NodeLocal DNSCache. K8s deployt dabei einen winzigen DNS-Cache (als DaemonSet-Pod) auf jeden verdammten Worker-Node im Cluster und kapert eine eigene Dummy-IP (169.254.20.10). Die Pods auf diesem Node rufen erst den lokalen Cache sofort über das Host-Interface ab, was Latenzen auf Mikrosekunden drückt und das zentrale CoreDNS um bis zu 90 % entlastet.

ExternalDNS

Wie machen wir den "Inside-Out" Weg? Eine ClusterIP ist von außen nicht ansprechbar. Ein Ingress-Controller (Nginx) bekommt zwar externe Traffic, aber wer trägt den Traffic-Router-Eintrag (A-Record) bei Cloudflare oder AWS Route53 ein? Manche Admins machen es manuell – fehleranfällig. Moderne Setups nutzen den ExternalDNS Controller. Dieser Pod läuft im Cluster, beobachtet K8s Ingress- und K8s Service (Type LoadBalancer)-Objekte und pusht deren festgelegte Host-Namen via API direkt zum Cloud-Provider-DNS. So sind interne K8s Services wenige Sekunden nach der YAML-Erstellung weltweit als öffentliche api.firma-xyz.com bekannt.

Quick-Check

Was ist "Service Discovery"?
Der Überbegriff. DNS ist eine Art der Service Discovery (Server-Side). Es gibt auch Client-Side Discovery (App fragt Consul/Eureka API). In K8s ist DNS der Standard.
Warum geht ping google.com im Container manchmal langsam?
Siehe "ndots:5 Problem". Oder UDP-Timeouts (conntrack race condition) in älteren Kerneln. DNS nutzt UDP, was "Fire-and-Forget" ist und bei hoher Last verloren gehen kann.
Kann ich DNS Einträge manuell setzen?
Ja, in Docker mit --add-host host:ip (schreibt in /etc/hosts). In K8s mit hostAliases. Nützlich, um externe Legacy-Systeme unter einem festen Namen erreichbar zu machen.