अभी कुछ समय पहले, हमने KWS का उपयोग करके AWS पर कुबेरनेट्स 1.9 लॉन्च किया। कल, हमारे कुबेरनेट समूहों में से सबसे बड़े ट्रैफिक को सुचारू रूप से चलाने के दौरान, मैंने अपने एप्लिकेशन द्वारा लॉग किए गए असामान्य DNS नाम रिज़ॉल्यूशन त्रुटियों को नोटिस करना शुरू किया।
GitHub ने इस बारे में काफी देर तक बात की, इसलिए मैंने भी इसका पता लगाने का फैसला किया। अंत में, मुझे एहसास हुआ कि हमारे मामले में यह kube-dns dnsmasq और dnsmasq पर बढ़ते भार के कारण है। मेरे लिए सबसे दिलचस्प और नया डीएनएस प्रश्नों के आवागमन में महत्वपूर्ण वृद्धि का कारण था। इसके बारे में और इसके साथ क्या करना है, मेरी पोस्ट।
कंटेनर के अंदर DNS का रिज़ॉल्यूशन - किसी भी लिनक्स सिस्टम के साथ - कॉन्फ़िगरेशन फ़ाइल /etc/resolv.conf द्वारा निर्धारित किया जाता है। डिफ़ॉल्ट रूप से, Kubernetes dnsPolicy dnsPolicy है, जिसका अर्थ है कि किसी भी DNS क्वेरी को क्लस्टर के अंदर kube-dns में चल रहे dnsmasq पुनर्निर्देशित किया जाएगा, जो बदले में kube-dns एप्लिकेशन को क्वेरी को रीडायरेक्ट करेगा यदि नाम किसी क्लस्टर प्रत्यय के साथ समाप्त होता है, या अन्यथा, एक उच्च स्तर DNS सर्वर के लिए।
प्रत्येक कंटेनर के अंदर /etc/resolv.conf फ़ाइल डिफ़ॉल्ट रूप से इस तरह दिखाई देगी:
nameserver 100.64.0.10 search namespace.svc.cluster.local svc.cluster.local cluster.local eu-west-1.compute.internal options ndots:5
जैसा कि आप देख सकते हैं, तीन निर्देश हैं:
- नाम सर्वर
kube-dns की आईपी सेवा है - 4 स्थानीय खोज डोमेन निर्दिष्ट
- एक विकल्प
ndots:5
इस कॉन्फ़िगरेशन का एक दिलचस्प हिस्सा यह है कि स्थानीय खोज डोमेन और ndots:5 सेटिंग्स कैसे मिलती हैं। इसे समझने के लिए, आपको यह समझने की जरूरत है कि DNS रिज़ॉल्यूशन आंशिक नामों के लिए कैसे काम करता है।
पूरा नाम क्या है?
पूरी तरह से योग्य नाम एक ऐसा नाम है जिसके लिए कोई स्थानीय खोज नहीं की जाएगी, और नाम समाधान के दौरान नाम को पूर्ण माना जाएगा। कन्वेंशन द्वारा, DNS सॉफ़्टवेयर पूरी तरह से योग्य होने के लिए एक नाम पर विचार करता है अगर यह एक अवधि (।) के साथ समाप्त होता है, और अन्यथा पूरी तरह से परिभाषित नहीं है। वह google.com. पूरी तरह से परिभाषित, लेकिन google.com नहीं।
अधूरा नाम कैसे संभाला जाता है?
जब कोई एप्लिकेशन नाम में निर्दिष्ट दूरस्थ होस्ट से कनेक्ट होता है, तो DNS नाम रिज़ॉल्यूशन आमतौर पर सिस्टम कॉल का उपयोग करके किया जाता है, उदाहरण के लिए, getaddrinfo() । लेकिन अगर नाम अधूरा है (के साथ समाप्त नहीं होता है), मुझे आश्चर्य है कि अगर सिस्टम कॉल नाम को पहले निरपेक्ष रूप से हल करने की कोशिश करेगा, या यह पहले स्थानीय खोज डोमेन के माध्यम से जाएगा? यह ndots विकल्प पर निर्भर करता है।
resolv.conf पर मैनुअल से:
ndots:n , , . n 1, , - , , - .
इसका मतलब यह है कि यदि ndots 5 पर सेट है और नाम में 5 से कम अंक हैं, तो सिस्टम कॉल क्रमिक रूप से इसे हल करने का प्रयास करेगा, पहले सभी स्थानीय खोज डोमेन के माध्यम से जा रहा है, और, यदि असफल, अंततः इसे एक निरपेक्ष नाम के रूप में हल करेगा।
ndots:5 क्यों कर सकते हैं ndots:5 आवेदन के प्रदर्शन पर प्रतिकूल प्रभाव डालते हैं?
जैसा कि आप समझते हैं, यदि आपका एप्लिकेशन प्रत्येक स्थापित टीसीपी कनेक्शन (या, अधिक सटीक रूप से, प्रत्येक हल किए गए नाम के लिए) के लिए बहुत सारे बाहरी ट्रैफ़िक का उपयोग करता है, तो यह नाम सही ढंग से हल होने से पहले 5 DNS प्रश्न जारी करेगा, क्योंकि यह 4 के माध्यम से जाएगा स्थानीय खोज डोमेन, और अंत में एक पूर्ण नाम समाधान अनुरोध जारी करेगा।
निम्नलिखित आरेख हमारे 3 kube-dns मॉड्यूल पर कुल ट्रैफ़िक दिखाता है और इससे पहले कि हम पूरी तरह से परिभाषित लोगों के लिए हमारे एप्लिकेशन में कॉन्फ़िगर किए गए कई होस्ट नामों को स्विच करते हैं।
निम्नलिखित आरेख से पहले और बाद में हम अपने आवेदन में कॉन्फ़िगर किए गए कई होस्ट नामों को स्विच करने से पहले आवेदन में देरी दिखाते हैं (ऊर्ध्वाधर नीली रेखा परिनियोजन है):
समाधान # 1 - पूरी तरह से योग्य नामों का उपयोग करें
यदि आपके पास कुछ स्थिर बाहरी नाम हैं (जो कि एप्लिकेशन कॉन्फ़िगरेशन में परिभाषित किया गया है) जिसे आप बड़ी संख्या में कनेक्शन बनाते हैं, तो शायद सबसे सरल समाधान उन्हें पूरी तरह से परिभाषित करके उन्हें केवल जोड़ने के लिए स्विच करना है। आखिर में।
यह अंतिम निर्णय नहीं है, लेकिन यह जल्दी से मदद करता है, भले ही सफाई से न हो, स्थिति में सुधार करें। हमने इस पैच को अपनी समस्या को हल करने के लिए लागू किया, जिसके परिणाम ऊपर स्क्रीनशॉट में दिखाए गए थे।
समाधान # 2 - ndots में dnsConfig कस्टमाइज़ dnsConfig
कुबेरनेट्स 1.9 में, एक विशेषता अल्फा मोड (बीटा संस्करण v1.10) में दिखाई दी, जो dnsConfig में पॉड संपत्ति के माध्यम से DNS मापदंडों के बेहतर नियंत्रण की अनुमति देती है। अन्य बातों के अलावा, यह आपको एक विशेष चूल्हा के लिए ndots मान को समायोजित करने की अनुमति देता है, अर्थात।
apiVersion: v1 kind: Pod metadata: namespace: default name: dns-example spec: containers: - name: test image: nginx dnsConfig: options: - name: ndots value: "1"
सूत्रों का कहना है
हमारे ब्लॉग पर अन्य लेख भी पढ़ें: