प्रोहोस्टर > ब्लॉग > प्रशासन > कुबेरनेट्स में डीएनएस लुकअप

कुबेरनेट्स में डीएनएस लुकअप

टिप्पणी। अनुवाद।: कुबेरनेट्स में डीएनएस समस्या, या अधिक सटीक रूप से, पैरामीटर सेटिंग्स ndots, आश्चर्यजनक रूप से लोकप्रिय है, और पहले से ही पहले नहीं वर्ष. इस विषय पर एक अन्य नोट में, इसके लेखक, भारत में एक बड़ी ब्रोकरेज कंपनी के एक DevOps इंजीनियर, बहुत ही सरल और संक्षिप्त तरीके से बात करते हैं कि कुबेरनेट्स का संचालन करने वाले सहयोगियों के लिए क्या जानना उपयोगी है।

कुबेरनेट्स में डीएनएस लुकअप

कुबेरनेट्स पर एप्लिकेशन तैनात करने का एक मुख्य लाभ निर्बाध एप्लिकेशन खोज है। सेवा अवधारणा की बदौलत इंट्रा-क्लस्टर इंटरैक्शन बहुत सरल हो गया है (सर्विस), जो एक वर्चुअल आईपी है जो पॉड आईपी पतों के एक सेट का समर्थन करता है। उदाहरण के लिए, यदि सेवा vanilla सेवा से संपर्क करना चाहता है chocolate, यह सीधे वर्चुअल आईपी तक पहुंच सकता है chocolate. सवाल उठता है: इस मामले में DNS अनुरोध का समाधान कौन करेगा chocolate और कैसे?

DNS नाम रिज़ॉल्यूशन को Kubernetes क्लस्टर का उपयोग करके कॉन्फ़िगर किया गया है कोरडीएनएस. क्यूबलेट फाइलों में नेमसर्वर के रूप में CoreDNS के साथ एक पॉड पंजीकृत करता है /etc/resolv.conf सभी पॉड्स. यदि आप सामग्री को देखें /etc/resolv.conf कोई भी पॉड, यह कुछ इस तरह दिखेगा:

search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5

इस कॉन्फ़िगरेशन का उपयोग DNS क्लाइंट द्वारा DNS सर्वर पर अनुरोध अग्रेषित करने के लिए किया जाता है। फाइल मैं resolv.conf निम्नलिखित जानकारी शामिल है:

  • नेम सर्वर: सर्वर जिस पर DNS अनुरोध भेजे जाएंगे। हमारे मामले में, यह CoreDNS सेवा का पता है;
  • यहाँ खोजें: किसी विशिष्ट डोमेन के लिए खोज पथ को परिभाषित करता है। यह दिलचस्प है google.com या mrkaran.dev FQDN नहीं हैं (पूर्णतः योग्य डोमेन नाम). अधिकांश DNS रिज़ॉल्वर जिस मानक परंपरा का पालन करते हैं, उसके अनुसार, केवल वे जो रूट ज़ोन का प्रतिनिधित्व करने वाले बिंदु "।" के साथ समाप्त होते हैं, उन्हें पूरी तरह से योग्य (FDQN) डोमेन माना जाता है। कुछ रिज़ॉल्वर स्वयं एक बिंदु जोड़ सकते हैं। इस प्रकार, mrkaran.dev. पूर्णतः योग्य डोमेन नाम (FQDN) है, और mrkaran.dev - नहीं;
  • ndots: सबसे दिलचस्प पैरामीटर (यह लेख इसके बारे में है)। ndots किसी अनुरोध नाम को "पूर्णतः योग्य" डोमेन नाम मानने से पहले उसमें बिंदुओं की सीमा संख्या निर्दिष्ट करता है। हम इसके बारे में बाद में और अधिक बात करेंगे जब हम DNS लुकअप अनुक्रम का विश्लेषण करेंगे।

कुबेरनेट्स में डीएनएस लुकअप

आइए देखें जब हम पूछते हैं तो क्या होता है mrkaran.dev फली में:

$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53

Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001

इस प्रयोग के लिए, मैंने CoreDNS लॉगिंग स्तर को इस पर सेट किया है all (जो इसे काफी क्रियात्मक बनाता है)। आइए पॉड के लॉग देखें coredns:

[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744s

उफ़्फ़. यहां दो बातें आपका ध्यान खींचती हैं:

  • अनुरोध खोज के सभी चरणों से होकर गुजरता है जब तक कि प्रतिक्रिया में कोड न हो NOERROR (DNS क्लाइंट इसे समझते हैं और परिणामस्वरूप इसे संग्रहीत करते हैं)। NXDOMAIN इसका मतलब है कि दिए गए डोमेन नाम के लिए कोई रिकॉर्ड नहीं मिला। क्योंकि mrkaran.dev एक FQDN नाम नहीं है (के अनुसार) ndots=5), रिज़ॉल्वर खोज पथ को देखता है और अनुरोधों का क्रम निर्धारित करता है;
  • रिकॉर्डिंग А и АААА समानांतर में पहुंचें. तथ्य यह है कि एकमुश्त अनुरोध /etc/resolv.conf डिफ़ॉल्ट रूप से, उन्हें इस तरह से कॉन्फ़िगर किया गया है कि IPv4 और IPv6 प्रोटोकॉल का उपयोग करके समानांतर खोज की जाती है। आप विकल्प जोड़कर इस व्यवहार को रद्द कर सकते हैं single-request в resolv.conf.

नोट: glibc इन अनुरोधों को क्रमिक रूप से भेजने के लिए कॉन्फ़िगर किया जा सकता है, और musl - नहीं, इसलिए अल्पाइन उपयोगकर्ताओं को ध्यान देना चाहिए।

एनडॉट्स के साथ प्रयोग

आइए इसके साथ थोड़ा और प्रयोग करें ndots और आइए देखें कि यह पैरामीटर कैसे व्यवहार करता है। विचार सरल है: ndots यह निर्धारित करता है कि DNS क्लाइंट डोमेन को पूर्ण या सापेक्ष मानेगा या नहीं। उदाहरण के लिए, एक साधारण Google DNS क्लाइंट के मामले में, यह कैसे पता चलेगा कि यह डोमेन पूर्ण है? यदि आप सेट करते हैं ndots 1 के बराबर, ग्राहक कहेगा: "ओह, इन google एक भी बिंदु नहीं है; मुझे लगता है कि मैं पूरी खोज सूची देख लूंगा। हालाँकि, यदि आप पूछें google.com, प्रत्ययों की सूची को पूरी तरह से नजरअंदाज कर दिया जाएगा क्योंकि अनुरोधित नाम सीमा को पूरा करता है ndots (कम से कम एक बिंदु तो है)।

आइए यह सुनिश्चित करें:

$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53

** server can't find mrkaran: NXDOMAIN

CoreDNS लॉग:

[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s
[INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s
[INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s
[INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s

चूंकि mrkaran एक भी बिंदु नहीं है, प्रत्ययों की पूरी सूची में खोज की गई।

नोट: व्यवहार में अधिकतम मूल्य ndots 15 तक सीमित; कुबेरनेट्स में डिफ़ॉल्ट रूप से यह 5 है।

उत्पादन में आवेदन

यदि कोई एप्लिकेशन बहुत अधिक बाहरी नेटवर्क कॉल करता है, तो सक्रिय ट्रैफ़िक के मामले में DNS एक बाधा बन सकता है, क्योंकि नाम समाधान कई अनावश्यक प्रश्न बनाता है (सिस्टम के सही तक पहुंचने से पहले)। एप्लिकेशन आमतौर पर डोमेन नामों में रूट ज़ोन नहीं जोड़ते हैं, लेकिन यह एक हैक की तरह लगता है। यानी पूछने की बजाय api.twitter.com, आप हार्डकोड कर सकते हैं api.twitter.com. (एक बिंदु के साथ) एप्लिकेशन में, जो DNS क्लाइंट को सीधे निरपेक्ष डोमेन पर आधिकारिक लुकअप करने के लिए प्रेरित करेगा।

इसके अतिरिक्त, कुबेरनेट्स संस्करण 1.14 से शुरू करके, एक्सटेंशन dnsConfig и dnsPolicy स्थिर स्थिति प्राप्त हुई। इस प्रकार, पॉड तैनात करते समय, आप मूल्य कम कर सकते हैं ndots, मान लीजिए, 3 तक (और 1 तक भी!)। इस वजह से, नोड के भीतर प्रत्येक संदेश में पूरा डोमेन शामिल करना होगा। जब आपको प्रदर्शन और पोर्टेबिलिटी के बीच चयन करना होता है तो यह क्लासिक ट्रेड-ऑफ़ में से एक है। मुझे ऐसा लगता है कि आपको इस बारे में केवल तभी चिंता करनी चाहिए यदि आपके एप्लिकेशन के लिए अल्ट्रा-लो विलंबता महत्वपूर्ण है, क्योंकि DNS परिणाम भी आंतरिक रूप से कैश किए जाते हैं।

संदर्भों

मैंने सबसे पहले इस सुविधा के बारे में सीखा K8s-मीटअप, 25 जनवरी को आयोजित किया गया। अन्य बातों के अलावा इस समस्या पर भी चर्चा हुई.

आगे की खोज के लिए यहां कुछ लिंक दिए गए हैं:

नोट: मैंने उपयोग न करने का निर्णय लिया है dig इस लेख में। dig स्वचालित रूप से एक बिंदु (रूट ज़ोन पहचानकर्ता) जोड़ता है, जिससे डोमेन "पूरी तरह से योग्य" (FQDN) बन जाता है, नहीं पहले इसे खोज सूची के माध्यम से चलाकर। में इस बारे में लिखा पिछले प्रकाशनों में से एक. हालाँकि, यह काफी आश्चर्यजनक है कि, सामान्य तौर पर, मानक व्यवहार के लिए एक अलग ध्वज निर्दिष्ट करना पड़ता है।

हैप्पी डीएनएसिंग! बाद में मिलते हैं!

अनुवादक से पी.एस

हमारे ब्लॉग पर भी पढ़ें:

स्रोत: www.habr.com

एक टिप्पणी जोड़ें