DNS-i otsing Kubernetesis

Märge. tõlge: Kubernetese DNS-i probleem või täpsemalt parameetrite seaded ndots, on üllatavalt populaarne ja juba Mitte esimene aasta. Teises selleteemalises märkuses räägib selle autor, DevOpsi insener ühest suurest India maaklerfirmast, väga lihtsalt ja kokkuvõtlikult sellest, mida on kasulik teada Kubernetes tegutsevatel kolleegidel.

Kubernetes rakenduste juurutamise üks peamisi eeliseid on rakenduste sujuv avastamine. Klastrisisene suhtlus on tänu teenusekontseptsioonile oluliselt lihtsustatud (Teenus), mis on virtuaalne IP, mis toetab kaustade IP-aadresside komplekti. Näiteks kui teenus vanilla soovib teenindusega ühendust võtta chocolate, pääseb see otse juurde virtuaalsele IP-le chocolate. Tekib küsimus: kellele sel juhul DNS-päringu lahendab chocolate Ja kuidas?

DNS-i nime eraldusvõime on konfigureeritud Kubernetese klastris kasutades CoreDNS. Kubelet registreerib CoreDNS-iga podi failides nimeserverina /etc/resolv.conf kõik kaunad. Kui vaatate sisu /etc/resolv.conf mis tahes kausta, näeb see välja umbes selline:

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

Seda konfiguratsiooni kasutavad DNS-kliendid päringute DNS-serverisse edastamiseks. Failis resolv.conf sisaldab järgmist teavet:

• nimeserver: server, kuhu DNS-päringud saadetakse. Meie puhul on see CoreDNS-teenuse aadress;
• otsing: määrab konkreetse domeeni otsingutee. See on huvitav google.com või mrkaran.dev ei ole FQDN (täielikult kvalifitseeritud domeeninimed). Vastavalt tavapärasele kokkuleppele, mida järgib enamik DNS-i lahendajaid, loetakse täielikult kvalifitseeritud (FDQN) domeenideks ainult neid, mis lõpevad juurtsooni tähistava punktiga ".". Mõned lahendajad saavad ise punkti lisada. Seega mrkaran.dev. on täielikult kvalifitseeritud domeeninimi (FQDN) ja mrkaran.dev - Ei;
• ndots: Kõige huvitavam parameeter (see artikkel räägib sellest). ndots määrab päringu nimes olevate punktide läviväärtuse, enne kui seda loetakse "täielikult kvalifitseeritud" domeeninimeks. Räägime sellest lähemalt hiljem, kui analüüsime DNS-i otsingujärjestust.

Vaatame, mis juhtub, kui küsime mrkaran.dev kaustas:

$ 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

Selle katse jaoks määrasin CoreDNS-i logimise tasemeks all (mis teeb selle üsna paljusõnaliseks). Vaatame kauna palke 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

Pheh. Siin köidavad teie tähelepanu kaks asja:

• Päring läbib kõik otsingu etapid, kuni vastus sisaldab koodi NOERROR (DNS-kliendid mõistavad seda ja salvestavad selle tulemusel). NXDOMAIN tähendab, et antud domeeninime kohta kirjet ei leitud. Kuna mrkaran.dev ei ole FQDN-i nimi (vastavalt ndots=5), vaatab lahendaja otsinguteed ja määrab päringute järjekorra;
• Lindistused А и АААА saabuvad paralleelselt. Fakt on see, et ühekordsed taotlused on sisse lülitatud /etc/resolv.conf Vaikimisi on need konfigureeritud nii, et paralleelotsingud tehakse IPv4 ja IPv6 protokollide abil. Saate selle käitumise tühistada, lisades valiku single-request в resolv.conf.

Märkus: glibc saab konfigureerida neid päringuid järjest saatma ja musl - ei, nii et Alpine kasutajad peaksid sellega arvestama.

Katsetamine ndotsidega

Eksperimenteerime veel veidi ndots ja vaatame, kuidas see parameeter käitub. Idee on lihtne: ndots määrab, kas DNS-klient käsitleb domeeni absoluutse või suhtelisena. Kuidas ta näiteks lihtsa google DNS-kliendi puhul teab, kas see domeen on absoluutne? Kui määrate ndots võrdne 1-ga, ütleb klient: "Oh, sisse google pole ühtegi punkti; Ma arvan, et vaatan kogu otsinguloendi läbi. Kui aga küsida google.com, jäetakse järelliidete loend täielikult tähelepanuta, kuna soovitud nimi vastab läve ndots (seal on vähemalt üks punkt).

Veendume 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-i 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

Alates aastast mrkaran pole ühtki punkti, otsing viidi läbi kogu sufiksite loetelus.

Märkus: praktikas maksimaalne väärtus ndots piiratud kuni 15; vaikimisi on see Kubernetesis 5.

Kasutamine tootmises

Kui rakendus teeb palju väliseid võrgukõnesid, võib aktiivse liikluse puhul kitsaskohaks saada DNS, kuna nimede lahendamine teeb palju tarbetuid päringuid (enne kui süsteem õigesse jõuab). Tavaliselt ei lisa rakendused domeeninimedele juurtsooni, kuid see kõlab nagu häkkimine. See tähendab, et selle asemel, et küsida api.twitter.com, saate selle kõvasti kodeerida api.twitter.com. (punktiga) rakenduses, mis kutsub DNS-i kliente tegema autoriteetseid otsinguid otse absoluutses domeenis.

Lisaks, alustades Kubernetese versioonist 1.14, laiendustest dnsConfig и dnsPolicy saanud stabiilse staatuse. Seega saate podi juurutamisel väärtust vähendada ndots, ütleme, kuni 3 (ja isegi kuni 1!). Seetõttu peab iga sõlme sees olev sõnum sisaldama täielikku domeeni. See on üks klassikalisi kompromisse, kui peate valima jõudluse ja kaasaskantavuse vahel. Mulle tundub, et peaksite selle pärast muretsema ainult siis, kui ülimadal latentsusaeg on teie rakenduse jaoks ülioluline, kuna DNS-i tulemused salvestatakse ka sisemiselt vahemällu.

Viited

Esimest korda sain selle funktsiooni kohta teada K8s-kohtumine, mis toimus 25. jaanuaril. Arutleti muuhulgas ka selle probleemi üle.

Siin on mõned lingid edasiseks uurimiseks:

• Seletus, miks ndots=5 Kubernetes;
• Hea kraam kuidas ndots-i muutmine mõjutab rakenduse jõudlust;
• Lahknevused musli ja glibc lahendajate vahel.

Märkus: otsustasin mitte kasutada dig Sellest siin artiklis. dig lisab automaatselt punkti (juurtsooni identifikaator), muutes domeeni "täielikult kvalifitseerituks" (FQDN), ei käivitades selle esmalt otsinguloendist. Kirjutas sellest sisse üks varasematest väljaannetest. Üsna üllatav on aga see, et üldiselt tuleb standardkäitumiseks eraldi lipp määrata.

Head DNS-i kasutamist! Näeme hiljem!

PS tõlkijalt

Loe ka meie blogist:

• «Calico Kubernetese võrgu loomiseks: tutvustus ja väike kogemus";
• «CoreDNS – DNS-server pilvepõhise maailma jaoks ja teenuse avastamine Kubernetese jaoks";
• "Kubernetese võrgu loomise illustreeritud juhend": osad 1 ja 2 (võrgumudel, ülekattevõrgud), 3. osa (teenused ja liikluse töötlemine).

Allikas: www.habr.com