Kops ஐப் பயன்படுத்தி AWS இல் சமீபத்தில் Kubernetes 1.9 ஐ அறிமுகப்படுத்தினோம். நேற்று, எங்கள் குபெர்னெட்டஸ் கிளஸ்டர்களில் புதிய ட்ராஃபிக்கை சுமூகமாக விரிவுபடுத்தும் போது, எங்கள் பயன்பாட்டினால் பதிவுசெய்யப்பட்ட அசாதாரண DNS பெயர் தெளிவுத்திறன் பிழைகளை நான் கவனிக்க ஆரம்பித்தேன்.
கிட்ஹப்பில் இதைப் பற்றி நிறைய இருக்கிறது , அதனால் நானும் அதை கண்டுபிடிக்க முடிவு செய்தேன். இறுதியில், எங்கள் விஷயத்தில் இது அதிகரித்த சுமையால் ஏற்படுகிறது என்பதை நான் உணர்ந்தேன் kube-dns и dnsmasq. டிஎன்எஸ் கோரிக்கை போக்குவரத்தில் குறிப்பிடத்தக்க அதிகரிப்புக்கு எனக்கு மிகவும் சுவாரஸ்யமான மற்றும் புதிய விஷயம். எனது இடுகை இதைப் பற்றியது மற்றும் இதற்கு என்ன செய்வது.
டிஎன்எஸ் தீர்மானம் கொள்கலனுக்குள் - எந்த லினக்ஸ் அமைப்பிலும் உள்ளதைப் போல - உள்ளமைவு கோப்பால் தீர்மானிக்கப்படுகிறது /etc/resolv.conf. இயல்புநிலை குபெர்னெட்ஸ் dnsPolicy அது ClusterFirst, அதாவது எந்த DNS கோரிக்கையும் அனுப்பப்படும் dnsmasq, ஒரு பொட்டில் ஓடுகிறது kube-dns கிளஸ்டரின் உள்ளே, இது விண்ணப்பத்திற்கு கோரிக்கையை அனுப்பும் 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 உள்ளூர் தேடல் களங்கள் குறிப்பிடப்பட்டுள்ளன
search - ஒரு விருப்பம் உள்ளது
ndots:5
இந்த உள்ளமைவின் சுவாரஸ்யமான பகுதி, உள்ளூர் தேடல் களங்கள் மற்றும் அமைப்புகளை எவ்வாறு அமைக்கிறது என்பதுதான் ndots:5 ஒன்றாக பழக. இதைப் புரிந்து கொள்ள, தகுதியற்ற பெயர்களுக்கான DNS தீர்மானம் எவ்வாறு செயல்படுகிறது என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும்.
முழுப்பெயர் என்றால் என்ன?
முழுத் தகுதியான பெயர் என்பது உள்ளூர் தேடுதல் செய்யப்படாது மற்றும் பெயர் தீர்மானத்தின் போது பெயர் முழுமையானதாகக் கருதப்படும். மரபுப்படி, DNS மென்பொருள் ஒரு பெயர் ஒரு புள்ளியுடன் முடிந்தால் (.) முழுத் தகுதி பெற்றதாகக் கருதுகிறது, இல்லையெனில் அது முழுமையாகத் தகுதி பெறாது. அது google.com. முழுமையாக வரையறுக்கப்பட்ட மற்றும் google.com - இல்லை.
தகுதியற்ற பெயர் எவ்வாறு கையாளப்படுகிறது?
பெயரில் குறிப்பிடப்பட்ட ரிமோட் ஹோஸ்டுடன் ஒரு பயன்பாடு இணைக்கப்படும்போது, DNS பெயர் தீர்மானம் பொதுவாக கணினி அழைப்பைப் பயன்படுத்தி செய்யப்படுகிறது, எ.கா. getaddrinfo(). ஆனால் பெயர் தகுதியற்றதாக இருந்தால் (என்று முடிவடையவில்லை.), கணினி அழைப்பு முதலில் பெயரை ஒரு முழுமையான பெயராகத் தீர்க்க முயற்சிக்குமா அல்லது முதலில் உள்ளூர் தேடல் களங்களுக்குச் செல்லுமா? இது விருப்பத்தைப் பொறுத்தது ndots.
கையேட்டில் இருந்து resolv.conf:
ndots:n
устанавливает порог для количества точек, которые должны появиться в имени, прежде чем будет сделан начальный абсолютный запрос. Значение по умолчанию для n равно 1, что означает, что если в имени есть какие-либо точки, имя будет сначала опробовано как абсолютное имя, прежде чем к нему будут добавлены какие-либо элементы списка поиска.என்றால் என்று அர்த்தம் ndots 5 இன் மதிப்பு கொடுக்கப்பட்டு, பெயரில் 5 புள்ளிகளுக்கும் குறைவான புள்ளிகள் இருந்தால், கணினி அழைப்பு அதை வரிசையாகத் தீர்க்க முயற்சிக்கும், முதலில் அனைத்து உள்ளூர் தேடல் களங்களையும் கடந்து, தோல்வியுற்றால், இறுதியில் அதை ஒரு முழுமையான பெயராகத் தீர்க்கும்.
ஏன் ndots:5 இது பயன்பாட்டின் செயல்திறனை எதிர்மறையாக பாதிக்குமா?
நீங்கள் நினைப்பது போல், உங்கள் பயன்பாடு அதிக வெளிப்புற டிராஃபிக்கைப் பயன்படுத்தினால், நிறுவப்பட்ட ஒவ்வொரு TCP இணைப்புக்கும் (அல்லது இன்னும் துல்லியமாக, ஒவ்வொரு பெயருக்கும் தீர்வு), பெயர் சரியாகத் தீர்க்கப்படுவதற்கு முன்பு அது 5 DNS வினவல்களை வழங்கும், ஏனெனில் அது முதலில் செல்லும். 4 உள்ளூர் தேடல் டொமைன், இறுதியில் ஒரு முழுமையான பெயர் தீர்மானம் கோரிக்கையை வழங்கும்.
பின்வரும் விளக்கப்படம் எங்கள் பயன்பாட்டில் உள்ளமைக்கப்பட்ட சில ஹோஸ்ட்பெயர்களை முழுத் தகுதியானவையாக மாற்றுவதற்கு முன்னும் பின்னும் எங்கள் 3 kube-dns தொகுதிகளின் மொத்த போக்குவரத்தைக் காட்டுகிறது.
பின்வரும் வரைபடம் எங்கள் பயன்பாட்டில் உள்ளமைக்கப்பட்ட பல ஹோஸ்ட் பெயர்களை முழுப் பெயர்களுக்கு மாற்றுவதற்கு முன்னும் பின்னும் பயன்பாட்டு தாமதத்தைக் காட்டுகிறது (செங்குத்து நீலக் கோடு வரிசைப்படுத்தல்):
தீர்வு #1 - முழு தகுதி வாய்ந்த பெயர்களைப் பயன்படுத்தவும்
உங்களிடம் சில நிலையான வெளிப்புற பெயர்கள் இருந்தால் (அதாவது பயன்பாட்டு உள்ளமைவில் வரையறுக்கப்பட்டவை) நீங்கள் அதிக எண்ணிக்கையிலான இணைப்புகளை உருவாக்கினால், அவற்றைச் சேர்ப்பதன் மூலம் அவற்றை முழுத் தகுதியானவற்றுக்கு மாற்றுவதே எளிய தீர்வாக இருக்கலாம். முடிவில்.
இது ஒரு இறுதி தீர்வு அல்ல, ஆனால் இது விரைவாக, சுத்தமாக இல்லாவிட்டாலும், நிலைமையை மேம்படுத்த உதவுகிறது. எங்கள் சிக்கலைத் தீர்க்க இந்த பேட்சைப் பயன்படுத்தினோம், அதன் முடிவுகள் மேலே உள்ள ஸ்கிரீன்ஷாட்களில் காட்டப்பட்டுள்ளன.
தீர்வு #2 - தனிப்பயனாக்கம் ndots в dnsConfig
குபெர்னெட்டஸ் 1.9 இல், செயல்பாடு ஆல்பா பயன்முறையில் (பீட்டா பதிப்பு v1.10) தோன்றியது, இது பாட் சொத்து மூலம் DNS அளவுருக்களை சிறப்பாகக் கட்டுப்படுத்த உங்களை அனுமதிக்கிறது. dnsConfig. மற்றவற்றுடன், மதிப்பை உள்ளமைக்க இது உங்களை அனுமதிக்கிறது ndots ஒரு குறிப்பிட்ட நெற்றுக்கு, அதாவது.
apiVersion: v1
kind: Pod
metadata:
namespace: default
name: dns-example
spec:
containers:
- name: test
image: nginx
dnsConfig:
options:
- name: ndots
value: "1"ஆதாரங்கள்
எங்கள் வலைப்பதிவில் உள்ள மற்ற கட்டுரைகளையும் படிக்கவும்:
ஆதாரம்: www.habr.com