Fang mit CoreDNS an: Pod-Neustarts, CPU-Throttling, Fehlerrate und Replica-Zahl im Verhältnis zum Query-Volumen. Prüf dann ndots, denn der Standardwert 5 lässt jedes externe Lookup zuerst mehrere Search Domains durchprobieren und vervielfacht die Query-Last. Klassische Übeltäter sind erschöpfte conntrack-Tabellen auf Nodes, UDP-Paketverlust unter Last und einthreadige Resolver. Node-local DNS-Caching plus vollqualifizierte Namen bringt das meist zur Ruhe.
Warum Interviewer das fragen
DNS-Probleme in Kubernetes sind häufig, schlecht verstanden und zeigen, wie tief dein Plattformwissen wirklich geht. Der Interviewer will Konkretes: ndots und Search Domains, conntrack, CoreDNS-Skalierung und -Caching. Vage Antworten über DNS prüfen zeigen, dass du darüber gelesen hast, während das Benennen der ndots-Verstärkung zeigt, dass du es debuggt hast.
So baust du deine Antwort auf
- Quantifizier das Symptom: welche Pods, welche Namen, welcher Fehler, welche Rate.
- Prüf zuerst CoreDNS-Gesundheit, Throttling und Replica-Kapazität.
- Erklär ndots und die Search-Domain-Verstärkung bei externen Lookups.
- Deck Ursachen auf Node-Ebene ab: conntrack-Limits und UDP-Verlust.
- Gib die dauerhaften Fixes: Node-local Cache, getuntes ndots, FQDNs.
Beispielantwort
Ich würde mit Messen statt Raten anfangen: Welche Namen scheitern, intern oder extern, und korreliert es mit der Last. Dann CoreDNS selbst, denn wenn diese Pods CPU-gethrottelt sind oder es nur zwei davon für einen großen Cluster gibt, sieht alles dahinter sporadisch aus. Was Leute überrascht, ist ndots. Die Standard-resolv.conf im Pod setzt ndots auf 5, ein externer Hostname wird also gegen jede Search Domain probiert, bevor er echt aufgelöst wird, aus einer Query werden fünf und CoreDNS bekommt viel zusätzlichen Druck. Der Fix ist entweder ein abschließender Punkt am Namen, um ihn vollzuqualifizieren, oder eine eigene dnsConfig mit ndots auf 2. Auf Node-Seite prüfe ich die Auslastung der conntrack-Tabelle, denn eine volle Tabelle verwirft UDP-Antworten stillschweigend und sieht exakt aus wie flakiges DNS. In der Praxis hat NodeLocal DNSCache das bei uns dauerhaft gelöst, weil es Lookups auf einen lokalen Cache über TCP verlagert.
Steht dieses Vorstellungsgespräch bald an? GhostPilot hört bei deinem Live-Call mit, erkennt die Frage in dem Moment, in dem sie gestellt wird, und bringt dir eine strukturierte Antwort in Echtzeit auf den Bildschirm. Probier es im nächsten Mock aus, oder hol dir einen $29 Session Pass, kein Abo, für den Ernstfall.
So funktioniert esNachfragen, mit denen du rechnen solltest
- Was ändert NodeLocal DNSCache am Query-Pfad?
- Wie würdest du eine conntrack-Erschöpfung auf einer Node bestätigen?
- Warum könnte ein niedrigeres ndots die Service Discovery für kurze Namen brechen?
Weitere Fragen für Site Reliability Engineer
Dein Interviewer stellt seine eigene Version davon. Kopier deine echte Stellenbeschreibung in den kostenlosen Question Predictor und bekomm die 20 Fragen, die diese Rolle am wahrscheinlichsten stellt, samt dem, worauf jede wirklich abzielt.
Meine Fragen vorhersagen