🥇DNS-otsing Kuberneteses

Märkus tõlke kohta.: DNS probleem Kubernetes'is, täpsemalt - parameetri seadistamine ndots, - on üllatavalt populaarne, tõsi küll, juba ei esimest aasta. Järjekordses selle teema märkuses räägib selle autori - DevOps insener suurest maaklerifirmast Indias - üsna lihtsas ja lakoonilises stiilis, millest on kasulik teada kolleegidele, kes kasutavad Kubernetes't.

Üks peamisi eeliseid rakenduste juurutamisel Kubernetes'es on probleemidevaba rakenduste avastamine. Klusterisisene suhtlemine muutub oluliselt lihtsamaks teenuse mõiste tõttu (Teenused), mis esindab virtuaalset IP-aadressi, toetades pod'ide IP-aadresside komplekti. Näiteks, kui teenus vanilla. tahab suhelda teenusega chocolate, võib ta otse pöörduda virtuaalse IP poole chocolate. Küsimus on: kes sel juhul lahendab DNS-päringu chocolate ja kuidas?

DNS nime lahendamine seadistatakse Kubernetes klastris abil CoreDNS. Kubelet määrab pod'i CoreDNS'i nime serverina failides /etc/resolv.conf kõikide pod'ide. Kui vaatame mõne pod'i sisu, näeb see välja umbes järgmine: /etc/resolv.conf search hello.svc.cluster.local svc.cluster.local cluster.local nameserver 10.152.183.10 options ndots:5

See konfiguratsioon kasutatakse DNS-klientide poolt, et suunata päringud DNS-serverisse. Failis

on järgmine teave: resolv.conf nameserver

: server, kuhu DNS-päringud suunatakse. Meie puhul on see CoreDNS teenuse aadress;: määrab teatud domeeni otsingu tee. Huvi pakub, et
searchmrkaran.dev google.com või ei ole FQDN ( täielikud domeeninimed). Üldiselt peavad enamiku DNS resolver'ite järgitud standardiliste kokkulepete kohaselt täielikud (FDQN) domeenid olema need, mis lõppevad punktiga „.”, mis tähistab juurdzooni. Mõned resolver'id oskavad punkti ise lisada. Seega,mrkaran.dev. on täielik domeeninimi (FQDN), kuid ei ole; ei ole FQDN ( : Kõige huvitavam parameeter (see artikkel on just selle kohta).
ndotsmäärab päringu nime punktide lävearvu, mille saavutamisel käsitletakse seda kui „täielikku” domeeninime. Räägime sellest üksikasjalikumalt hiljem, kui analüüsime DNS-otsingu järjestust. ndots Vaadakem, mis juhtub, kui küsime

pod'is: ei ole FQDN ( $ nslookup mrkaran.dev Server: 10.152.183.10 Address: 10.152.183.10#53Non-authoritative answer: Name: mrkaran.dev Address: 157.230.35.153 Name: mrkaran.dev Address: 2400:6180:0:d1::519:6001

Selle eksperimendi jaoks seadsin CoreDNS'i logimise taseme

ületama all (mis teeb selle üsna sõnakaks). Vaadakem pod'i logisid 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

Huhh. Kaks asja tõmbavad siin tähelepanu:

Päring läbib kõik otsingu etapid, kuni vastus sisaldab koodi NOERROR (DNS-kliendid mõistavad seda ja salvestavad tulemuseks). NXDOMAIN tähendab, et selle domeeninime jaoks ei leitud kirjet. Kuna ei ole FQDN ( ei ole FQDN-nimi (vastavalt ndots=5), resolver vaatab otsingu teed ja määrab päringute järjekorra;
Kirjed A ja AAAA tulevad paralleelselt. Probleem on selles, et ühekordsed päringud /etc/resolv.conf on vaikimisi seadistatud nii, et tõstetakse paralleelne otsing IPv4 ja IPv6 protokollide vahel. Sellist käitumist saab tühistada, kui lisada valik single-request ja resolv.conf.

Märkus: glibc saab seadistada nende päringute järkjärguliseks saatmiseks, kuid musl ei saa, nii et Alpine'i kasutajad peaksid seda silmas pidama.

Katsetame ndots’i

Tehkem veel mõned eksperimendid ndots ja vaatame, kuidas see parameeter käitub. Idee on lihtne: ndots määrab, kas DNS-kliendile tundub domeen absoluutne või suhteline. Näiteks, kuidas google DNS-kliendi puhul tunnistatakse selle domeeni absoluutseks? Kui seada ndots ühtseks 1, ütleb klient: „Oo, siin ei ole ühtegi punkti; ma vaatan kogu otsingulisti läbi“. Kuid kui küsida google , siis otsingu sufiksite nimekiri jäetakse täielikult tähelepanuta, kuna küsitud nimi vastab künnisele google.com(eksisteerib vähemalt üks punkt). ndots Veendugem selles:

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

[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

Kuna

mrkaran ei sisalda ühtegi punkte, toimus otsing kogu sufiksite nimekirja kaudu. Märkus: praktikas on maksimaalne väärtus

piiratud 15; vaikimisi Kuberneteses on see 5. ndots Kasutamine tootmises

Применение в production

Kui rakendus teeb palju väliseid võrgu küsitlusi, võib DNS aktiivse liikluse korral muutuda pudelikaelaks, kuna nime lahendamise protsessis toimub palju üleliigseid päringuid (enne kui süsteem jõuab soovitud tulemuseni). Rakendused ei lisa tavaliselt juurkontrollitud tsooni domeeninimedele, kuid see on omamoodi nipp. See tähendab, et selle asemel, et küsida api.twitter.com, võite 'hardcode'ida api.twitter.com. (punktiga) rakendusse, mis paneb DNS-kliente tegema autoriteetset otsingut kohe absoluutne domeeni.

Lisaks, alates versioonist Kubernetes 1.14 on laiendid dnsConfig ja dnsPolicy saand saanud stabiilse staatuse. Seega, kui rakendate pood’i, võib väärtust vähendada ndots, ütleme, 3-le (ja isegi 1-le!). Selle tulemusena peab igas sõnumis sõlmpunktis olema täielik domeen. See on üks klassikalisi kompromisse, kus tuleb valida jõudluse ja ülekantavuse vahel. Minu arvates tasub selle pärast muretseda ainult siis, kui üli madalad viivitused on teie rakenduse jaoks eluliselt olulised, kuna DNS-i tulemusi ka vahemälu.

Viidatud lingid

Esimest korda kuulsin sellest omadusest K8s-meetup'il, mis toimus 25. jaanuaril. Seal arutati ka seda probleemi.

Siin on mõned lingid edasiseks uurimiseks:

Selgitus, miks ndots=5 Kuberneteses;
Suurepärane materjal sellest, kuidas ndots'i muutmine mõjutab rakenduse jõudlust;
Erinevused resolver'ite musl ja glibc vahel.

Märkus: Otsustasin seda mitte kasutada dig selles artiklis. dig automaatselt lisab punkti (juurkontrollitud tsooni identifikaatori), muutes domeeni 'täielikuks' (FQDN), ei töötades seda eelnevalt otsinguloendi kaudu. Olen sellest kirjutanud ühes varasemas postituses. Siiski on üsna üllatav, et tavalise käitumise saavutamiseks peab olema eraldi lipp.

Head DNS-ingit! Nägemist!