Kubernetes मा DNS लुकअप

नोट। अनुवाद।: Kubernetes मा DNS समस्या, वा अझ सटीक रूपमा, प्यारामिटर सेटिङहरू ndots, आश्चर्यजनक रूपमा लोकप्रिय छ, र पहिले नै पहिले होइन год। यस विषयमा अर्को टिपोटमा, यसको लेखक, भारतको ठूलो ब्रोकरेज कम्पनीका डेभओप्स इन्जिनियरले कुबेरनेट सञ्चालन गर्ने सहकर्मीहरूलाई जान्नको लागि के उपयोगी छ भनेर धेरै सरल र संक्षिप्त रूपमा कुरा गर्छन्।

Kubernetes मा अनुप्रयोगहरू प्रयोग गर्ने मुख्य फाइदाहरू मध्ये एक सिमलेस अनुप्रयोग खोज हो। सेवा अवधारणा (सेवा), जुन एक भर्चुअल आईपी हो जसले पोड आईपी ठेगानाहरूको सेटलाई समर्थन गर्दछ। उदाहरणका लागि, यदि सेवा vanilla सेवामा सम्पर्क गर्न चाहनुहुन्छ chocolate, यसले प्रत्यक्ष रूपमा भर्चुअल आईपी पहुँच गर्न सक्छ 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

यो कन्फिगरेसन 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 र यो प्यारामिटर कसरी व्यवहार गर्छ हेरौं। विचार सरल छ: ndots DNS क्लाइन्टले डोमेनलाई निरपेक्ष वा सापेक्ष रूपमा व्यवहार गर्नेछ कि भनेर निर्धारण गर्दछ। उदाहरण को लागी, एक साधारण गुगल DNS क्लाइन्ट को मामला मा, यो डोमेन निरपेक्ष छ कि भनेर कसरी थाहा छ? यदि तपाइँ सेट गर्नुहुन्छ ndots १ को बराबर, ग्राहकले भन्नेछ: "ओह, भित्र 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 Kubernetes मा;
• राम्रो सामग्री कसरी ndots परिवर्तन अनुप्रयोग प्रदर्शन असर गर्छ;
• विसंगतिहरू Musl र glibc समाधानकर्ताहरू बीच।

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

DNSing को शुभकामना! पछि भेटौँला!

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «Kubernetes मा नेटवर्किंग को लागी क्यालिको: परिचय र एक सानो अनुभव»;
• «CoreDNS - क्लाउड नेटिभ संसारको लागि DNS सर्भर र Kubernetes को लागि सेवा खोज»;
• "कुबर्नेट्समा नेटवर्किङको लागि एउटा इलस्ट्रेटेड गाइड": भाग १ र २ (नेटवर्क मोडेल, ओभरले नेटवर्क), भाग ३ (सेवा र यातायात प्रशोधन).

स्रोत: www.habr.com