ProHoster > Blog > Stjórnsýsla > DNS leit í Kubernetes

DNS leit í Kubernetes

Athugið. þýð.: DNS vandamál í Kubernetes, eða nánar tiltekið, færibreytustillingar ndots, er furðu vinsælt og nú þegar Ekki fyrst ári. Í annarri athugasemd um þetta efni talar höfundur hennar, DevOps verkfræðingur frá stóru verðbréfamiðlarafyrirtæki á Indlandi, á mjög einfaldan og hnitmiðaðan hátt um hvað er gagnlegt fyrir samstarfsmenn sem starfa Kubernetes að vita.

DNS leit í Kubernetes

Einn helsti kosturinn við að dreifa forritum á Kubernetes er óaðfinnanlegur uppgötvun forrita. Samskipti innan klasa eru einfölduð til muna þökk sé þjónustuhugmyndinni (þjónusta), sem er sýndar-IP sem styður sett af pod IP-tölum. Til dæmis ef þjónustan vanilla óskar eftir að hafa samband við þjónustuna chocolate, það getur beint aðgang að sýndar-IP fyrir chocolate. Spurningin vaknar: hver í þessu tilfelli mun leysa DNS beiðnina til chocolate Og hvernig?

DNS nafnaupplausn er stillt á Kubernetes þyrping með því að nota CoreDNS. Kubelet skráir pod með CoreDNS sem nafnaþjóni í skrár /etc/resolv.conf allir beljur. Ef þú skoðar innihaldið /etc/resolv.conf hvaða belg sem er, mun það líta eitthvað svona út:

search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5

Þessi stilling er notuð af DNS viðskiptavinum til að framsenda beiðnir til DNS netþjónsins. Í skrá resolv.conf inniheldur eftirfarandi upplýsingar:

  • nafnaþjónn: þjónn sem DNS beiðnir verða sendar til. Í okkar tilviki er þetta heimilisfang CoreDNS þjónustunnar;
  • leita: Skilgreinir leitarslóðina fyrir tiltekið lén. Það er athyglisvert það google.com eða mrkaran.dev eru ekki FQDN (fullgild lén). Samkvæmt staðlaðri venju sem flestir DNS-leysarar fylgja eru aðeins þeir sem enda á punkti ".", sem táknar rótarsvæðið, talin fullgild (FDQN) lén. Sumir lausnarmenn geta bætt við punkti sjálfir. Þannig, mrkaran.dev. er fullgilt lén (FQDN), og mrkaran.dev - Nei;
  • punktar: Áhugaverðasta færibreytan (þessi grein er um það). ndots tilgreinir viðmiðunarfjölda punkta í nafni beiðni áður en það er talið „fullgilt“ lén. Við munum tala meira um þetta síðar þegar við greinum DNS uppflettingarröðina.

DNS leit í Kubernetes

Við skulum sjá hvað gerist þegar við spyrjum mrkaran.dev í pod:

$ 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

Fyrir þessa tilraun stillti ég CoreDNS skráningarstigið á all (sem gerir það nokkuð orðrétt). Við skulum skoða annála belgsins 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

Púff. Tvennt vekur athygli þína hér:

  • Beiðnin fer í gegnum öll stig leitarinnar þar til svarið inniheldur kóðann NOERROR (DNS viðskiptavinir skilja það og geyma það í kjölfarið). NXDOMAIN þýðir að engin skrá fannst fyrir uppgefið lén. Vegna þess að mrkaran.dev er ekki FQDN nafn (skv ndots=5), resolver lítur á leitarslóðina og ákvarðar röð beiðna;
  • Upptökur А и АААА koma samhliða. Staðreyndin er sú að einu sinni beiðnir inn /etc/resolv.conf Sjálfgefið er að þau séu stillt á þann hátt að samhliða leit sé gerð með IPv4 og IPv6 samskiptareglum. Þú getur hætt við þessa hegðun með því að bæta við valkostinum single-request в resolv.conf.

Ath: glibc er hægt að stilla til að senda þessar beiðnir í röð, og musl - nei, svo Alpine notendur ættu að taka eftir.

Tilraunir með punkta

Við skulum gera tilraunir aðeins meira með ndots og við skulum sjá hvernig þessi breytu hegðar sér. Hugmyndin er einföld: ndots ákvarðar hvort DNS viðskiptavinurinn mun meðhöndla lénið sem algjört eða afstætt. Til dæmis, ef um er að ræða einfaldan google DNS viðskiptavin, hvernig veit hann hvort þetta lén er algert? Ef þú stillir ndots jafnt og 1, mun viðskiptavinurinn segja: "Ó, inn google það er ekki einn punktur; Ég býst við að ég fari í gegnum allan leitarlistann.“ Hins vegar, ef þú spyrð google.com, listi yfir viðskeyti verður algjörlega hunsuð vegna þess að umbeðið nafn uppfyllir þröskuldinn ndots (það er að minnsta kosti einn punktur).

Við skulum ganga úr skugga um þetta:

$ 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 logs:

[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

Síðan í mrkaran það er ekki einn punktur, leitað var yfir allan viðskeytilistann.

Athugið: í reynd hámarksgildi ndots takmarkað við 15; sjálfgefið í Kubernetes er það 5.

Umsókn í framleiðslu

Ef forrit hringir mikið utanaðkomandi netsímtöl getur DNS orðið flöskuháls þegar um er að ræða virka umferð, þar sem nafnaupplausn gerir margar óþarfar fyrirspurnir (áður en kerfið kemst á réttan hátt). Forrit bæta venjulega ekki rótarsvæði við lén, en þetta hljómar eins og hakk. Það er að segja í stað þess að spyrja api.twitter.com, þú getur 'hardcode' það api.twitter.com. (með punkti) í forritinu, sem mun hvetja DNS-viðskiptavini til að framkvæma opinbera uppflettingu beint á algeru léninu.

Að auki, frá og með Kubernetes útgáfu 1.14, viðbætur dnsConfig и dnsPolicy fengið stöðuga stöðu. Þannig geturðu dregið úr gildinu þegar þú setur upp belg ndotstd allt að 3 (og jafnvel allt að 1!). Vegna þessa verða öll skilaboð innan hnúts að innihalda allt lénið. Þetta er ein af klassísku málamiðlunum þegar þú þarft að velja á milli frammistöðu og flytjanleika. Mér sýnist að þú ættir aðeins að hafa áhyggjur af þessu ef ofurlítil leynd er mikilvæg fyrir forritið þitt, þar sem DNS niðurstöðurnar eru einnig í skyndiminni innanhúss.

tilvísanir

Ég lærði fyrst um þennan eiginleika á K8s-fundur, haldinn 25. janúar. Rætt var meðal annars um þetta vandamál.

Hér eru nokkrir tenglar til frekari könnunar:

  • Útskýring, hvers vegna ndots=5 í Kubernetes;
  • Góðir hlutir hvernig breyting á punktum hefur áhrif á árangur forrita;
  • Misræmi milli musl og glibc resolvera.

Athugið: Ég valdi að nota ekki dig í þessari grein. dig bætir sjálfkrafa við punkti (rótarsvæðisauðkenni), sem gerir lénið „fullkomlega hæft“ (FQDN), ekki með því að keyra það fyrst í gegnum leitarlistann. Skrifaði um þetta í eitt af fyrri ritunum. Hins vegar kemur það nokkuð á óvart að almennt þurfi að tilgreina sérstakan fána fyrir staðlaða hegðun.

Til hamingju með DNSing! Sé þig seinna!

PS frá þýðanda

Lestu líka á blogginu okkar:

Heimild: www.habr.com

Bæta við athugasemd