🥇DNS-otsing Kuberneteses

Märk. tõlge.: DNS probleem Kubernetesis, täpsemalt — parameetri seadistamine ndots, — üllatavalt populaarne, ja juba ei ole esimene aasta. Järjekordses sellele teemal kirjutises räägib autor — DevOps-insener suurest maaklerifirmast Indias — väga lihtsal ja lakoonilisel viisil, millest on kasu kolleegidele, kes kasutavad Kubernetes’t.

Üks peamisi eeliseid rakenduste juurutamisel Kuberneteses on probleemivaba rakenduste avastamine. Siseriiklike suhtlemine muutub oluliselt lihtsamaks teenuse (Teenused), mis on virtuaalne IP, toetav pod’ide IP-aadresside kogumit. Näiteks, kui teenus vanilla tahab suhelda teenusega chocolate, saab ta otse pöörduda virtuaalse IP poole chocolate. Tekib küsimus: kes sel juhul lahendab DNS-päringu chocolate ja kuidas?

DNS-nimede lahendamine seadistatakse Kubernetes klastris läbi CoreDNS. Kubelet kirjutab pod’i CoreDNS nime serverina kõikide pod’ide failidesse /etc/resolv.conf . Kui vaadata mis tahes 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

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

See konfiguratsioon on DNS-kliendi jaoks, et suunata päringud DNS-serverisse. Failis resolv.conf on järgmine teave:

nameserver: server, kuhu DNS-päringud suunatakse. Meie puhul on see CoreDNS teenuse aadress;
search: määrab konkreetse domeeni otsingutee. Huvi pärast google.com või mrkaran.dev ei ole FQDN (täielikud domeeninimesid). Vastavalt enamik DNS-resolvery peetavatele standarditele loetakse täielikeks (FDQN) domeenideks vaid need, mis lõpevad punktiga „.“, mis tähistab juureala. Mõned resolver'id suudavad punkti automaatselt lisada. Seega, mrkaran.dev. — on täielik domeeninimi (FQDN), kuid mrkaran.dev — ei ole;
ndots: kõige huvitavam parameeter (see artikkel käsitleb just seda). ndots määrab äärepunktide arvu nime päringus, mille saavutamisel loetakse see „täielikuks” domeeninimeks. Räägime sellest hiljem, kui analüüsime DNS-otsingu järjekorda.

Vaadakem, mis juhtub, kui me pärime mrkaran.dev pod's:

$ 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

Käesoleva eksperimendi jaoks seadsin CoreDNS logimise taseme 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

Huh. Siin köidavad tähelepanu kaks asja:

Päring läbib kõik otsinguetapid, kuni vastus sisaldab koodi NOERROR (DNS-kliendid mõistavad seda ja säilitavad tulemuseks). NXDOMAIN tähendab, et antud domeeninime kohta pole kirjet leitud. Kuna mrkaran.dev ei ole FQDN-nimi (vastavalt ndots=5), resolver vaatab otsinguteed ja määrab päringute järjekorra;
Kirjed A ja AAAA tulevad paralleelselt. Asi on selles, et korduvad päringud on /etc/resolv.conf vaikimisi seadistatud nii, et tehakse paralleelne otsing nii IPv4 kui ka IPv6 protokollide kaudu. Seda käitumist saab tühistada, lisades valiku single-request ühes resolv.conf.

Märkus: glibc võib seada nende päringute järjestikuseks saatmiseks, musl — ei, se tähendab, et Alpine'i kasutajad peaksid seda meeles pidama.

Katsume ndotseiga

Teeme veel mõned katsetused 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 teada, kas see domeen on absoluutne? Kui seadistada ndots väärtuseks 1, ütleb klient: „Oh, siin google pole ühtki punkti; võib-olla lähen kogu otsingulisti üle.” Kui aga küsida google.com, siis suffixide nimekiri jäetakse täielikult tähelepanuta, kuna küsitud nimi rahuldab künnise ndots (kui on vähemalt üks punkt).

Kinnitage see:

$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53

** server ei suuda leida 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 pole ühtki punkti, otsing tehti kogu suffixide nimekirja põhjal.

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

Kasutamine tootmises

Kui rakendus teeb palju väliseid võrguväljakutseid, võib DNS olla kitsaskohaks suure liikluse korral, kuna nime lahendamisel tehakse mitmeid tarbetuid päringuid (enne kui süsteem leiab vajaliku). Rakendused ei lisanud tavaliselt juurezonaid domeeninimedele, kuid see on üsna toimiv lahendus. See tähendab, et selle asemel, et küsida api.twitter.com, võite 'hardcode'ida api.twitter.com. (punktiga) rakendusse, mis sunnib DNS-kliente tegema autoriteetset otsingut otse absoluutsele domeenile.

Lisaks on alates Kubernetes 1.14 versioonist laiendused dnsConfig ja dnsPolicy saanud stabiilsuse staatuse. Seega saab pod'i juurutamisel väärtust vähendada. ndots, ütleme, kuni 3 (ja isegi kuni 1!). Selle tõttu peab iga sõnum sõlmes sisaldama täielikku domeeni. See on üks klassikalisi kompromisse, millega peab valima jõudluse ja ülekantavuse vahel. Arvan, et selle üle tasub muretseda ainult juhul, kui äärmiselt madalad latentsused on teie rakenduse jaoks eluliselt olulised, kuna DNS-i tulemused ka vahemälus.

Lingid

Selle omaduse kohta sain esmakordselt teada K8s-meetupil, mis toimus 25. jaanuaril. Seal räägiti ka sellest probleemist.

Siin on mõned lingid edasiseks uurimiseks:

Selgitus, miks on ndots=5 Kuberneteses;
Suurepärane materjal kuidas ndots-i muutmine mõjutab rakenduse tõhusust;
Erinevused musl ja glibc resolver`ite vahel.

Märkus: eelistasin mitte kasutada dig selles artiklis. dig automaatne punkt (juurkonna identifikaator), muutes domeeni „täielikuks” (FQDN), ei läbi otsinguloendi. Kirjutasin sellest ühes varasemas väljaandes. Tõepoolest, on üsna üllatav, et üldise käitumise saavutamiseks tuleb seada eraldi lipuke.

Headjat DNS’ing! Kohtumiseni!

P.S. tõlkija märkused

Lugege ka meie blogist:

«Calico Kubernetes'i võrgu jaoks: sissejuhatus ja veidi kogemust»;
«CoreDNS – DNS-server pilvetoetuste ja Kubernetes'e teenuste avastamiseks.»;
„Illustreeritud juhend Kuberneteses olevate võrkude seadistamiseks“: osad 1 ja 2 (võrgumudel, overlay-võrgud), osa 3 (teenused ja liikluse töötlemine).

Allikas: habr.com