குபெர்னெட்டஸில் டிஎன்எஸ் தேடல்

குறிப்பு. மொழிபெயர்: குபெர்னெட்டஸில் DNS சிக்கல், அல்லது இன்னும் துல்லியமாக, அளவுரு அமைப்புகளில் ndots, வியக்கத்தக்க வகையில் பிரபலமாக உள்ளது, மற்றும் ஏற்கனவே முதலில் இல்லை год. இந்த தலைப்பில் மற்றொரு குறிப்பில், அதன் ஆசிரியர், இந்தியாவில் உள்ள ஒரு பெரிய தரகு நிறுவனத்தைச் சேர்ந்த டெவொப்ஸ் இன்ஜினியர், குபெர்னெட்ஸை இயக்கும் சக பணியாளர்கள் தெரிந்துகொள்ள என்ன பயனுள்ளது என்பதைப் பற்றி மிகவும் எளிமையாகவும் சுருக்கமாகவும் பேசுகிறார்.

குபெர்னெட்டஸில் பயன்பாடுகளைப் பயன்படுத்துவதன் முக்கிய நன்மைகளில் ஒன்று தடையற்ற பயன்பாட்டுக் கண்டுபிடிப்பு ஆகும். சேவைக் கருத்தின் காரணமாக உள்-கிளஸ்டர் தொடர்பு மிகவும் எளிமைப்படுத்தப்பட்டுள்ளது (சேவை), இது பாட் ஐபி முகவரிகளின் தொகுப்பை ஆதரிக்கும் மெய்நிகர் ஐபி ஆகும். உதாரணமாக, சேவை என்றால் vanilla சேவையை தொடர்பு கொள்ள விரும்புகிறது chocolate, இது நேரடியாக மெய்நிகர் ஐபியை அணுக முடியும் chocolate. கேள்வி எழுகிறது: இந்த விஷயத்தில் DNS கோரிக்கையை யார் தீர்ப்பார்கள் chocolate மற்றும் எப்படி?

டிஎன்எஸ் பெயர் தெளிவுத்திறன் குபெர்னெட்ஸ் கிளஸ்டரில் உள்ளமைக்கப்பட்டுள்ளது கோர்டிஎன்எஸ். Kubelet கோப்புகளில் ஒரு பெயர் சேவையகமாக 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 "முழு தகுதி வாய்ந்த" டொமைன் பெயராகக் கருதப்படுவதற்கு முன், கோரிக்கைப் பெயரில் உள்ள புள்ளிகளின் வரம்பு எண்ணிக்கையைக் குறிப்பிடுகிறது. 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 (டிஎன்எஸ் கிளையண்ட்கள் அதைப் புரிந்துகொண்டு அதன் விளைவாக சேமிக்கிறார்கள்). NXDOMAIN கொடுக்கப்பட்ட டொமைன் பெயருக்கு எந்த பதிவும் கிடைக்கவில்லை என்று அர்த்தம். ஏனெனில் mrkaran.dev FQDN பெயர் அல்ல (படி ndots=5), ரிசல்வர் தேடல் பாதையைப் பார்த்து கோரிக்கைகளின் வரிசையை தீர்மானிக்கிறது;
• பதிவுகளை А и АААА இணையாக வரும். உண்மை என்னவென்றால், ஒரு முறை கோரிக்கைகள் /etc/resolv.conf முன்னிருப்பாக, IPv4 மற்றும் IPv6 நெறிமுறைகளைப் பயன்படுத்தி இணையான தேடல்கள் செய்யப்படும் வகையில் அவை கட்டமைக்கப்படுகின்றன. விருப்பத்தைச் சேர்ப்பதன் மூலம் இந்த நடத்தையை நீங்கள் ரத்து செய்யலாம் single-request в resolv.conf.

குறிப்பு: glibc இந்த கோரிக்கைகளை வரிசையாக அனுப்ப கட்டமைக்க முடியும், மற்றும் musl - இல்லை, எனவே ஆல்பைன் பயனர்கள் கவனத்தில் கொள்ள வேண்டும்.

புள்ளிகளுடன் பரிசோதனை

இன்னும் கொஞ்சம் பரிசோதனை செய்வோம் ndots இந்த அளவுரு எவ்வாறு செயல்படுகிறது என்பதைப் பார்ப்போம். யோசனை எளிது: ndots 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 கிளையண்டுகளை முழுமையான டொமைனில் நேரடியாக அதிகாரப்பூர்வமான தேடல்களைச் செய்யத் தூண்டும்.

கூடுதலாக, Kubernetes பதிப்பு 1.14, நீட்டிப்புகள் தொடங்கி dnsConfig и dnsPolicy நிலையான நிலையைப் பெற்றது. இவ்வாறு, ஒரு பாட் வரிசைப்படுத்தும் போது, ​​நீங்கள் மதிப்பைக் குறைக்கலாம் ndots, சொல்லுங்கள், 3 வரை (மற்றும் 1 வரை கூட!). இதன் காரணமாக, ஒரு முனையில் உள்ள ஒவ்வொரு செய்தியும் முழு டொமைனையும் சேர்க்க வேண்டும். செயல்திறன் மற்றும் பெயர்வுத்திறன் ஆகியவற்றிற்கு இடையே நீங்கள் தேர்வு செய்ய வேண்டிய உன்னதமான வர்த்தக பரிமாற்றங்களில் இதுவும் ஒன்றாகும். டிஎன்எஸ் முடிவுகள் உள்நாட்டிலும் தற்காலிகமாக சேமிக்கப்பட்டிருப்பதால், உங்கள் பயன்பாட்டிற்கு மிகக் குறைந்த தாமதம் இன்றியமையாததாக இருந்தால் மட்டுமே நீங்கள் இதைப் பற்றி கவலைப்பட வேண்டும் என்று எனக்குத் தோன்றுகிறது.

குறிப்புகள்

இந்த அம்சத்தைப் பற்றி நான் முதலில் அறிந்தேன் K8s-சந்திப்பு, ஜனவரி 25 அன்று நடைபெற்றது. இப்பிரச்னை உள்ளிட்டவை குறித்தும் விவாதம் நடந்தது.

மேலும் ஆய்வுக்கான சில இணைப்புகள் இங்கே:

• விளக்கம், ஏன் ndots=5 in Kubernetes;
• பெரிய பொருள் ndotகளை மாற்றுவது பயன்பாட்டின் செயல்திறனை எவ்வாறு பாதிக்கிறது;
• முரண்பாடுகள் musl மற்றும் glibc தீர்வுகளுக்கு இடையே.

குறிப்பு: நான் பயன்படுத்த வேண்டாம் என்று தேர்வு செய்தேன் dig இந்த கட்டுரையில். dig தானாக ஒரு புள்ளியைச் சேர்க்கிறது (ரூட் மண்டல அடையாளங்காட்டி), டொமைனை "முழு தகுதியுடையது" (FQDN), இல்லை முதலில் அதை தேடல் பட்டியலில் இயக்குவதன் மூலம். இதைப் பற்றி எழுதியுள்ளார் முந்தைய வெளியீடுகளில் ஒன்று. இருப்பினும், பொதுவாக, நிலையான நடத்தைக்கு ஒரு தனி கொடி குறிப்பிடப்பட வேண்டும் என்பது மிகவும் ஆச்சரியமாக இருக்கிறது.

இனிய DNSing! பிறகு சந்திப்போம்!

மொழிபெயர்ப்பாளரிடமிருந்து பி.எஸ்

எங்கள் வலைப்பதிவிலும் படிக்கவும்:

• «குபெர்னெட்ஸில் நெட்வொர்க்கிங்கிற்கான காலிகோ: அறிமுகம் மற்றும் ஒரு சிறிய அனுபவம்";
• «CoreDNS - கிளவுட் நேட்டிவ் வேர்ல்டுக்கான டிஎன்எஸ் சர்வர் மற்றும் குபெர்னெட்ஸிற்கான சர்வீஸ் டிஸ்கவரி";
• "குபெர்னெட்ஸில் நெட்வொர்க்கிங் செய்ய ஒரு விளக்கப்பட வழிகாட்டி": பாகங்கள் 1 மற்றும் 2 (நெட்வொர்க் மாடல், மேலடுக்கு நெட்வொர்க்குகள்), பகுதி 3 (சேவைகள் மற்றும் போக்குவரத்து செயலாக்கம்).

ஆதாரம்: www.habr.com