DNS paieška Kubernetes

Pastaba. vert.: DNS problema Kubernetes, o tiksliau parametrų nustatymuose ndots, stebėtinai populiarus, ir jau Ne pirmas metai. Kitoje pastaboje šia tema jos autorius, „DevOps“ inžinierius iš didelės maklerio įmonės Indijoje, labai paprastai ir glaustai kalba apie tai, ką naudinga žinoti „Kubernetes“ valdantiems kolegoms.

Vienas iš pagrindinių privalumų diegiant programas Kubernetes yra sklandus programų aptikimas. Sąveika klasterio viduje yra labai supaprastinta dėl paslaugų koncepcijos (tarnyba), kuris yra virtualus IP, palaikantis pod IP adresų rinkinį. Pavyzdžiui, jei paslauga vanilla nori susisiekti su tarnyba chocolate, jis gali tiesiogiai pasiekti virtualų IP chocolate. Kyla klausimas: kam tokiu atveju išspręs DNS užklausą chocolate Ir kaip?

DNS vardo skyra sukonfigūruojama Kubernetes klasteryje naudojant CoreDNS. „Kubelet“ registruoja „Pod“ su „CoreDNS“ kaip vardų serverį failuose /etc/resolv.conf visos ankštys. Jei pažvelgsite į turinį /etc/resolv.conf bet kokiame lizde jis atrodys maždaug taip:

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

Šią konfigūraciją naudoja DNS klientai, norėdami persiųsti užklausas į DNS serverį. Byloje resolv.conf yra ši informacija:

• vardų serveris: serveris, į kurį bus siunčiamos DNS užklausos. Mūsų atveju tai yra CoreDNS paslaugos adresas;
• search: apibrėžia konkretaus domeno paieškos kelią. Įdomu tai google.com arba mrkaran.dev nėra FQDN (visiškai kvalifikuoti domenų vardai). Pagal standartinę konvenciją, kurios laikosi dauguma DNS sprendinių, tik tie, kurie baigiasi tašku „.“, reiškiančiu šaknies zoną, yra laikomi visiškai kvalifikuotais (FDQN) domenais. Kai kurie sprendėjai gali patys pridėti tašką. Taigi, mrkaran.dev. yra visiškai kvalifikuotas domeno vardas (FQDN) ir mrkaran.dev - Ne;
• ndots: Įdomiausias parametras (šiame straipsnyje apie tai). ndots nurodo slenkstinį taškų skaičių užklausos pavadinime, kad jis būtų laikomas „visiškai kvalifikuotu“ domeno pavadinimu. Daugiau apie tai pakalbėsime vėliau, kai analizuosime DNS paieškos seką.

Pažiūrėkime, kas atsitiks, kai paklausime mrkaran.dev ankštyje:

$ 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

Šiam eksperimentui nustačiau CoreDNS registravimo lygį all (dėl to jis gana daugžodis). Pažvelkime į ankšties rąstus 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

pfu. Čia jūsų dėmesį patraukia du dalykai:

• Užklausa pereina visus paieškos etapus, kol atsakyme yra kodas NOERROR (DNS klientai tai supranta ir išsaugo kaip rezultatą). NXDOMAIN reiškia, kad duotam domeno vardo įrašas nerastas. Nes mrkaran.dev nėra FQDN pavadinimas (pagal ndots=5), sprendiklis žiūri į paieškos kelią ir nustato užklausų tvarką;
• Записи А и АААА atvykti lygiagrečiai. Faktas yra tas, kad pateikiami vienkartiniai prašymai /etc/resolv.conf Pagal numatytuosius nustatymus jie sukonfigūruoti taip, kad lygiagrečios paieškos būtų atliekamos naudojant IPv4 ir IPv6 protokolus. Galite atšaukti šį elgesį pridėję parinktį single-request в resolv.conf.

Pastaba: glibc gali būti sukonfigūruotas siųsti šias užklausas nuosekliai ir musl - ne, todėl Alpių naudotojai turėtų įsidėmėti.

Eksperimentai su ndots

Eksperimentuokime dar šiek tiek ndots ir pažiūrėkime, kaip veikia šis parametras. Idėja paprasta: ndots nustato, ar DNS klientas domeną laikys absoliučiu ar santykiniu. Pavyzdžiui, paprasto Google DNS kliento atveju, kaip jis žino, ar šis domenas yra absoliutus? Jei nustatysite ndots lygus 1, klientas pasakys: „O, in google nėra vieno taško; Manau, kad peržvelgsiu visą paieškos sąrašą. Tačiau, jei paklausite google.com, priesagų sąrašas bus visiškai nepaisomas, nes prašomas vardas atitinka slenkstį ndots (yra bent vienas taškas).

Įsitikinkime tuo:

$ 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 žurnalai:

[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

Nuo tada, kai mrkaran nėra nei vieno punkto, paieška buvo atlikta visame priesagų sąraše.

Pastaba: praktiškai didžiausia vertė ndots ribotas iki 15; pagal numatytuosius nustatymus „Kubernetes“ yra 5.

Taikymas gamyboje

Jei programa atlieka daug išorinių tinklo skambučių, DNS gali tapti kliūtimi aktyvaus srauto atveju, nes vardo skyra sukelia daug nereikalingų užklausų (prieš sistema pasiekia reikiamą). Programos paprastai neprideda šakninės zonos prie domenų vardų, tačiau tai skamba kaip įsilaužimas. Tai yra, užuot klausęs api.twitter.com, galite jį „užkoduoti“. api.twitter.com. (su tašku) programoje, kuri paragins DNS klientus atlikti autoritetingas paieškas tiesiai absoliučiame domene.

Be to, pradedant nuo Kubernetes 1.14 versijos, plėtinių dnsConfig и dnsPolicy gavo stabilų statusą. Taigi, diegdami podą, galite sumažinti vertę ndots, tarkime, iki 3 (ir net iki 1!). Dėl šios priežasties kiekvienas mazgo pranešimas turės apimti visą domeną. Tai vienas iš klasikinių kompromisų, kai reikia rinktis tarp našumo ir nešiojamumo. Man atrodo, kad dėl to turėtumėte jaudintis tik tuo atveju, jei jūsų programai labai svarbus itin mažas delsos laikas, nes DNS rezultatai taip pat saugomi viduje.

Nuorodos

Pirmą kartą apie šią funkciją sužinojau K8s-susitikimas, vykusią sausio 25 d. Be kita ko, buvo diskutuojama apie šią problemą.

Čia yra keletas nuorodų, skirtų tolesniam tyrinėjimui:

• Paaiškinimas, kodėl Kubernetes ndots=5;
• Puikus daiktas kaip ndots keitimas veikia programos veikimą;
• Neatitikimai tarp musl ir glibc rezoliucijų.

Pastaba: nusprendžiau nenaudoti dig šiame straipsnyje. dig automatiškai prideda tašką (šakninės zonos identifikatorių), todėl domenas tampa „visiškai kvalifikuotu“ (FQDN), ne pirmiausia paleisdami jį per paieškos sąrašą. Apie tai rašė vienas iš ankstesnių leidinių. Tačiau gana stebėtina, kad paprastai standartiniam elgesiui turi būti nurodyta atskira vėliavėlė.

Sėkmės DNS! Pasimatysime vėliau!

PS iš vertėjo

Taip pat skaitykite mūsų tinklaraštyje:

• «Calico tinkle Kubernetes: įvadas ir šiek tiek patirties»;
• «„CoreDNS“ – DNS serveris, skirtas vietiniam debesų pasauliui ir „Kubernetes“ paslaugų atradimas»;
• „Iliustruotas „Kubernetes“ tinklo vadovas“: 1 ir 2 dalys (tinklo modelis, perdangos tinklai), 3 dalis (paslaugos ir srauto apdorojimas).

Šaltinis: www.habr.com