కుబెర్నెట్స్‌లో DNS శోధన

గమనిక. అనువాదం.: కుబెర్నెట్స్‌లో DNS సమస్య లేదా మరింత ఖచ్చితంగా, పారామీటర్ సెట్టింగ్‌లు ndots, ఆశ్చర్యకరంగా ప్రజాదరణ పొందింది మరియు ఇప్పటికే మొదటిది కాదు год. ఈ అంశంపై మరొక గమనికలో, దాని రచయిత, భారతదేశంలోని ఒక పెద్ద బ్రోకరేజ్ కంపెనీకి చెందిన DevOps ఇంజనీర్, Kubernetes ఆపరేటింగ్ సహోద్యోగులు తెలుసుకోవడానికి ఉపయోగపడే వాటి గురించి చాలా సరళంగా మరియు సంక్షిప్తంగా మాట్లాడుతున్నారు.

కుబెర్నెట్స్‌లో అప్లికేషన్‌లను అమలు చేయడం వల్ల కలిగే ప్రధాన ప్రయోజనాల్లో ఒకటి అతుకులు లేని అప్లికేషన్ డిస్కవరీ. సేవా కాన్సెప్ట్‌కు ధన్యవాదాలు (ఇంట్రా-క్లస్టర్ ఇంటరాక్షన్) చాలా సరళీకృతం చేయబడింది.సర్వీస్), ఇది పాడ్ IP చిరునామాల సమితికి మద్దతు ఇచ్చే వర్చువల్ IP. ఉదాహరణకు, సేవ ఉంటే vanilla సేవను సంప్రదించాలని కోరుకుంటున్నాను chocolate, ఇది నేరుగా వర్చువల్ IPని యాక్సెస్ చేయగలదు chocolate. ప్రశ్న తలెత్తుతుంది: ఈ సందర్భంలో DNS అభ్యర్థనను ఎవరు పరిష్కరిస్తారు chocolate మరి ఎలా?

DNS పేరు రిజల్యూషన్ ఉపయోగించి కుబెర్నెట్స్ క్లస్టర్‌లో కాన్ఫిగర్ చేయబడింది కోర్డిఎన్ఎస్. 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 (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 క్లయింట్‌లను సంపూర్ణ డొమైన్‌లో నేరుగా అధీకృత లుకప్‌లను నిర్వహించడానికి ప్రాంప్ట్ చేస్తుంది.

అదనంగా, Kubernetes వెర్షన్ 1.14, పొడిగింపులతో ప్రారంభించండి dnsConfig и dnsPolicy స్థిరమైన స్థితిని పొందింది. అందువల్ల, పాడ్‌ను అమలు చేస్తున్నప్పుడు, మీరు విలువను తగ్గించవచ్చు ndots, చెప్పండి, 3 వరకు (మరియు 1 వరకు కూడా!). దీని కారణంగా, నోడ్‌లోని ప్రతి సందేశం పూర్తి డొమైన్‌ను చేర్చవలసి ఉంటుంది. మీరు పనితీరు మరియు పోర్టబిలిటీ మధ్య ఎంచుకోవలసి వచ్చినప్పుడు ఇది క్లాసిక్ ట్రేడ్-ఆఫ్‌లలో ఒకటి. DNS ఫలితాలు కూడా అంతర్గతంగా కాష్ చేయబడినందున, మీ అప్లికేషన్‌కు అల్ట్రా-తక్కువ జాప్యం చాలా ముఖ్యమైనది అయితే మాత్రమే మీరు దీని గురించి ఆందోళన చెందాలని నాకు అనిపిస్తోంది.

సూచనలు

నేను మొదట ఈ ఫీచర్ గురించి తెలుసుకున్నాను K8s-మీటప్, జనవరి 25న జరిగింది. ఇతర విషయాలతోపాటు ఈ సమస్యపై చర్చ జరిగింది.

తదుపరి అన్వేషణ కోసం ఇక్కడ కొన్ని లింక్‌లు ఉన్నాయి:

• వివరణ, ఎందుకు ndots=5 Kubernetes లో;
• గొప్ప విషయం ndotలను మార్చడం అప్లికేషన్ పనితీరును ఎలా ప్రభావితం చేస్తుంది;
• వ్యత్యాసాలు musl మరియు glibc పరిష్కారాల మధ్య.

గమనిక: నేను ఉపయోగించకూడదని ఎంచుకున్నాను dig ఈ వ్యాసంలో. dig స్వయంచాలకంగా డాట్ (రూట్ జోన్ ఐడెంటిఫైయర్) జోడిస్తుంది, డొమైన్‌ను "పూర్తి అర్హత" (FQDN) చేస్తుంది కాదు దీన్ని మొదట శోధన జాబితా ద్వారా అమలు చేయడం ద్వారా. లో దీని గురించి రాశారు మునుపటి ప్రచురణలలో ఒకటి. అయినప్పటికీ, సాధారణంగా, ప్రామాణిక ప్రవర్తనకు ప్రత్యేక జెండాను పేర్కొనడం చాలా ఆశ్చర్యకరమైనది.

హ్యాపీ DNSing! తర్వాత కలుద్దాం!

అనువాదకుని నుండి PS

మా బ్లాగులో కూడా చదవండి:

• «కుబెర్నెట్స్‌లో నెట్‌వర్కింగ్ కోసం కాలికో: పరిచయం మరియు కొద్దిగా అనుభవం";
• «CoreDNS - క్లౌడ్ స్థానిక ప్రపంచం కోసం DNS సర్వర్ మరియు కుబెర్నెట్స్ కోసం సర్వీస్ డిస్కవరీ";
• "కుబెర్నెట్స్‌లో నెట్‌వర్కింగ్‌కు ఇలస్ట్రేటెడ్ గైడ్": భాగాలు 1 మరియు 2 (నెట్‌వర్క్ మోడల్, ఓవర్‌లే నెట్‌వర్క్‌లు), పార్ట్ 3 (సేవలు మరియు ట్రాఫిక్ ప్రాసెసింగ్).

మూలం: www.habr.com