Kubernetes मध्ये DNS लुकअप

नोंद. अनुवाद: Kubernetes मध्ये DNS समस्या, किंवा अधिक अचूकपणे, पॅरामीटर सेटिंग्ज ndots, आश्चर्यकारकपणे लोकप्रिय आहे, आणि आधीच प्रथम नाही गोद. या विषयावरील दुसर्‍या टीपमध्ये, त्याचे लेखक, भारतातील एका मोठ्या ब्रोकरेज कंपनीतील DevOps अभियंता, कुबेरनेट्स ऑपरेट करणार्‍या सहकार्‍यांना जाणून घेण्यासाठी काय उपयुक्त आहे याबद्दल अतिशय सोप्या आणि संक्षिप्त पद्धतीने बोलतात.

Kubernetes वर अनुप्रयोग उपयोजित करण्याचा एक मुख्य फायदा म्हणजे अखंड अनुप्रयोग शोध. सेवा संकल्पनेमुळे इंट्रा-क्लस्टर परस्परसंवाद मोठ्या प्रमाणात सरलीकृत आहे (सेवा), जे पॉड आयपी पत्त्यांच्या संचाला समर्थन देणारा आभासी IP आहे. उदाहरणार्थ, जर सेवा vanilla सेवेशी संपर्क साधण्याची इच्छा आहे chocolate, ते थेट व्हर्च्युअल IP मध्ये प्रवेश करू शकते chocolate. प्रश्न उद्भवतो: या प्रकरणात DNS विनंतीचे निराकरण कोण करेल chocolate आणि कसे?

DNS नाव रिझोल्यूशन कुबर्नेट्स क्लस्टरवर वापरून कॉन्फिगर केले आहे CoreDNS. कुबेलेट फाईल्समध्ये नेमसर्व्हर म्हणून 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

हे कॉन्फिगरेशन डीएनएस क्लायंटद्वारे डीएनएस सर्व्हरवर विनंत्या अग्रेषित करण्यासाठी वापरले जाते. फाईलमध्ये 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 आणि हे पॅरामीटर कसे वागते ते पाहू. कल्पना सोपी आहे: 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 पर्यंत मर्यादित; Kubernetes मध्ये डीफॉल्टनुसार ते 5 आहे.

उत्पादनात अर्ज

एखादे ॲप्लिकेशन बरेचसे बाह्य नेटवर्क कॉल करत असल्यास, DNS सक्रिय रहदारीच्या बाबतीत अडथळे ठरू शकते, कारण नावाचे निराकरण अनेक अनावश्यक क्वेरी करते (सिस्टम उजवीकडे येण्यापूर्वी). ऍप्लिकेशन्स सहसा डोमेन नावांमध्ये रूट झोन जोडत नाहीत, परंतु हे हॅकसारखे वाटते. म्हणजे विचारण्याऐवजी api.twitter.com, तुम्ही हार्डकोड करू शकता api.twitter.com. ऍप्लिकेशनमध्ये (बिंदूसह), जे DNS क्लायंटना निरपेक्ष डोमेनवर थेट अधिकृत लुकअप करण्यास प्रवृत्त करेल.

याव्यतिरिक्त, Kubernetes आवृत्ती 1.14 सह प्रारंभ करून, विस्तार dnsConfig и dnsPolicy स्थिर स्थिती प्राप्त झाली. अशा प्रकारे, पॉड तैनात करताना, आपण मूल्य कमी करू शकता ndots, म्हणा, 3 पर्यंत (आणि अगदी 1 पर्यंत!). यामुळे, नोडमधील प्रत्येक संदेशामध्ये संपूर्ण डोमेन समाविष्ट करणे आवश्यक आहे. जेव्हा तुम्हाला परफॉर्मन्स आणि पोर्टेबिलिटी यापैकी एक निवडायची असते तेव्हा हे क्लासिक ट्रेड-ऑफपैकी एक आहे. मला असे वाटते की तुमच्या अनुप्रयोगासाठी अति-कमी विलंबता महत्वाची असेल तरच तुम्ही याची काळजी करावी, कारण DNS परिणाम देखील आंतरिकरित्या कॅश केलेले आहेत.

संदर्भ

मी प्रथम या वैशिष्ट्याबद्दल शिकलो K8s-बैठक25 जानेवारी रोजी आयोजित करण्यात आला आहे. इतर गोष्टींसह या समस्येवर चर्चा झाली.

पुढील अन्वेषणासाठी येथे काही दुवे आहेत:

• स्पष्टीकरण, कुबर्नेट्समध्ये ndots=5 का;
• छान सामान ndots बदलल्याने अनुप्रयोगाच्या कार्यक्षमतेवर कसा परिणाम होतो;
• विसंगती musl आणि glibc रिझोल्व्हर्स दरम्यान.

टीप: मी न वापरणे निवडले dig या लेखात. dig डोमेनला "पूर्णपणे पात्र" (FQDN) बनवून आपोआप डॉट (रूट झोन आयडेंटिफायर) जोडतो, नाही प्रथम शोध सूचीद्वारे चालवून. मध्ये याबद्दल लिहिले मागील प्रकाशनांपैकी एक. तथापि, हे आश्चर्यकारक आहे की, सर्वसाधारणपणे, मानक वर्तनासाठी स्वतंत्र ध्वज निर्दिष्ट करणे आवश्यक आहे.

आनंदी DNSing! पुन्हा भेटू!

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

• «कुबर्नेट्समध्ये नेटवर्किंगसाठी कॅलिको: परिचय आणि थोडासा अनुभव";
• «CoreDNS - क्लाउड नेटिव्ह वर्ल्डसाठी DNS सर्व्हर आणि Kubernetes साठी सर्व्हिस डिस्कवरी";
• "कुबर्नेट्समधील नेटवर्किंगसाठी सचित्र मार्गदर्शक": भाग १ आणि २ (नेटवर्क मॉडेल, आच्छादन नेटवर्क), भाग 3 (सेवा आणि वाहतूक प्रक्रिया).

स्त्रोत: www.habr.com