DNS pretraživanje u Kubernetesu

Bilješka. prev.: DNS problem u Kubernetesu, točnije, postavke parametara ndots, iznenađujuće je popularan i već Ne prvi godina. U drugoj bilješci o ovoj temi, njezin autor, DevOps inženjer iz velike brokerske tvrtke u Indiji, na vrlo jednostavan i koncizan način govori o tome što je korisno znati kolegama koji upravljaju Kubernetesom.

Jedna od glavnih prednosti postavljanja aplikacija na Kubernetes je besprijekorno otkrivanje aplikacija. Interakcija unutar klastera uvelike je pojednostavljena zahvaljujući konceptu usluge (Servis), što je virtualni IP koji podržava skup IP adresa modula. Na primjer, ako usluga vanilla želi kontaktirati službu chocolate, može izravno pristupiti virtualnom IP-u za chocolate. Postavlja se pitanje kome će u ovom slučaju riješiti DNS zahtjev chocolate I kako?

DNS rezolucija naziva konfigurirana je na Kubernetes klasteru pomoću CoreDNS. Kubelet registrira pod s CoreDNS-om kao poslužitelj imena u datotekama /etc/resolv.conf sve mahune. Ako pogledate sadržaj /etc/resolv.conf bilo koje mahune, izgledat će otprilike ovako:

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

Ovu konfiguraciju koriste DNS klijenti za prosljeđivanje zahtjeva DNS poslužitelju. U datoteci resolv.conf sadrži sljedeće podatke:

• poslužitelj imena: poslužitelj na koji će se slati DNS zahtjevi. U našem slučaju, ovo je adresa CoreDNS usluge;
• traži: Definira put pretraživanja za određenu domenu. Zanimljivo je da google.com ili mrkaran.dev nisu FQDN (potpuno kvalificirani nazivi domena). Prema standardnoj konvenciji koju slijedi većina DNS rezolvera, samo oni koji završavaju s točkom ".", što predstavlja korijensku zonu, smatraju se potpuno kvalificiranim (FDQN) domenama. Neki razrješivači mogu sami dodati točku. Tako, mrkaran.dev. je potpuno kvalificirani naziv domene (FQDN) i mrkaran.dev - Ne;
• ndots: Najzanimljiviji parametar (ovaj članak govori o tome). ndots određuje granični broj točaka u imenu zahtjeva prije nego što se smatra "potpuno kvalificiranim" nazivom domene. O ovome ćemo više govoriti kasnije kada budemo analizirali sekvencu pretraživanja DNS-a.

Da vidimo što će se dogoditi kada pitamo mrkaran.dev u mahuni:

$ 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

Za ovaj eksperiment postavio sam CoreDNS razinu zapisivanja na all (što ga čini prilično opširnim). Pogledajmo zapisnike mahune 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

Fuj. Ovdje vam pozornost privlače dvije stvari:

• Zahtjev prolazi kroz sve faze pretraživanja dok odgovor ne sadrži kod NOERROR (DNS klijenti to razumiju i pohranjuju kao rezultat). NXDOMAIN znači da nije pronađen nijedan zapis za dati naziv domene. Jer mrkaran.dev nije FQDN ime (prema ndots=5), rezolver gleda put pretraživanja i određuje redoslijed zahtjeva;
• Prijave А и АААА stići paralelno. Činjenica je da jednokratni zahtjevi u /etc/resolv.conf Prema zadanim postavkama, oni su konfigurirani na takav način da se paralelna pretraživanja izvode korištenjem IPv4 i IPv6 protokola. Ovo ponašanje možete poništiti dodavanjem opcije single-request в resolv.conf.

Napomena: glibc može se konfigurirati za slanje ovih zahtjeva uzastopno, i musl - ne, pa bi Alpine korisnici trebali uzeti u obzir.

Eksperimentiranje s ndotovima

Eksperimentirajmo još malo s ndots i da vidimo kako se ovaj parametar ponaša. Ideja je jednostavna: ndots određuje hoće li DNS klijent tretirati domenu kao apsolutnu ili relativnu. Na primjer, u slučaju jednostavnog google DNS klijenta, kako zna je li ta domena apsolutna? Ako postavite ndots jednako 1, klijent će reći: "Oh, unutra google nema niti jedne točke; Pretpostavljam da ću proći kroz cijeli popis pretraživanja.” Međutim, ako pitate google.com, popis sufiksa bit će potpuno zanemaren jer traženo ime zadovoljava prag ndots (postoji barem jedna točka).

Uvjerimo se u ovo:

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

[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

Od godine u mrkaran nema niti jedne točke, pretraživanje je provedeno po cijelom popisu sufiksa.

Napomena: u praksi najveća vrijednost ndots ograničeno na 15; prema zadanim postavkama u Kubernetesu je 5.

Primjena u proizvodnji

Ako aplikacija upućuje puno vanjskih mrežnih poziva, DNS može postati usko grlo u slučaju aktivnog prometa, budući da razrješenje imena stvara mnogo nepotrebnih upita (prije nego što sustav dođe do pravog). Aplikacije obično ne dodaju korijensku zonu nazivima domena, ali ovo zvuči kao hakiranje. Odnosno umjesto da traži api.twitter.com, možete ga 'tvrdo kodirati' api.twitter.com. (s točkom) u aplikaciji, što će potaknuti DNS klijente da izvrše autoritativna pretraživanja izravno na apsolutnoj domeni.

Osim toga, počevši od Kubernetes verzije 1.14, proširenja dnsConfig и dnsPolicy dobio stabilan status. Stoga, kada postavljate pod, možete smanjiti vrijednost ndots, recimo, do 3 (pa čak i do 1!). Zbog toga će svaka poruka unutar čvora morati uključivati ​​punu domenu. Ovo je jedan od klasičnih kompromisa kada morate birati između performansi i prenosivosti. Čini mi se da biste o tome trebali brinuti samo ako je ultraniska latencija vitalna za vašu aplikaciju, budući da se rezultati DNS-a također interno spremaju u predmemoriju.

reference

Prvi put sam saznao za ovu značajku na K8s-susret, održanom 25. siječnja. Između ostalog, raspravljalo se i o ovom problemu.

Evo nekoliko veza za daljnje istraživanje:

• objašnjenje, zašto ndots=5 u Kubernetesu;
• Super stvar kako promjena ndot-ova utječe na rad aplikacije;
• razlike između musl i glibc resolvera.

Napomena: odlučio sam ne koristiti dig u ovom članku. dig automatski dodaje točku (identifikator korijenske zone), čineći domenu "potpuno kvalificiranom" (FQDN), ne tako što ćete ga prvo provući kroz popis za pretraživanje. Pisao o ovome u jedna od prethodnih publikacija. Međutim, prilično je iznenađujuće da se općenito mora specificirati zasebna zastavica za standardno ponašanje.

Sretno DNS! Vidimo se kasnije!

PS od prevoditelja

Pročitajte i na našem blogu:

• «Calico za umrežavanje u Kubernetesu: uvod i malo iskustva»;
• «CoreDNS - DNS poslužitelj za izvorni svijet oblaka i otkrivanje usluga za Kubernetes»;
• "Ilustrirani vodič za umrežavanje u Kubernetesu": dijelovi 1 i 2 (mrežni model, preklapanje mreža), dio 3 (usluge i obrada prometa).

Izvor: www.habr.com