यूजर बता रहे हैं कि आपके Kubernetes cluster के अंदर नाम resolve होने में रह रहकर नाकामी आ रही है। आप कहां देखेंगे?

CoreDNS से शुरू करें: pod के restart, CPU throttling, एरर दर, और query की मात्रा के मुकाबले replica की गिनती। फिर ndots जांचें, क्योंकि 5 का डिफॉल्ट हर बाहरी lookup को पहले कई search domain आजमाने पर मजबूर करता है और query का लोड कई गुना कर देता है। क्लासिक अपराधी हैं node पर conntrack टेबल का भर जाना, लोड में UDP पैकेट का गिरना, और single threaded resolver। node local DNS caching के साथ पूरे नाम (FQDN) आम तौर पर मामला शांत कर देते हैं।

मैं अंदाजा लगाने के बजाय नापने से शुरू करूंगा: कौन से नाम फेल हो रहे हैं, अंदरूनी या बाहरी, और क्या यह लोड से जुड़ा है। फिर खुद CoreDNS, क्योंकि अगर वे pod CPU throttled हैं या बड़े cluster के लिए उनकी गिनती सिर्फ दो है, तो आगे सब कुछ रह रहकर टूटता दिखेगा। जो चीज लोगों को चौंकाती है वह ndots है। pod की डिफॉल्ट resolv.conf में ndots 5 होता है, तो किसी बाहरी hostname को देखने से पहले वह हर search domain पर आजमाया जाता है, जिससे एक query पांच बन जाती है और CoreDNS पर काफी अतिरिक्त दबाव पड़ता है। हल है या तो नाम के आखिर में एक बिंदु लगाकर उसे पूरा नाम बना दें, या ndots 2 के साथ कस्टम dnsConfig इस्तेमाल करें। node की तरफ मैं conntrack टेबल का इस्तेमाल जांचता हूं, क्योंकि भरी हुई टेबल UDP जवाब चुपचाप गिरा देती है और यह बिलकुल लड़खड़ाते DNS जैसा दिखता है। व्यवहार में NodeLocal DNSCache लगाने से यह हमारे लिए हमेशा के लिए ठीक हो गया, क्योंकि वह lookup को TCP पर एक local cache तक ले जाता है।