Bilješka. transl.: DNS problem u Kubernetesu, tačnije, postavke parametara ndots, je iznenađujuće popularan, i već . U drugoj belešci o ovoj temi, njen autor, DevOps inženjer iz velike brokerske kompanije u Indiji, govori na veoma jednostavan i koncizan način o tome šta je korisno da znaju kolege koje koriste Kubernetes.
Jedna od glavnih prednosti postavljanja aplikacija na Kubernetes je neometano otkrivanje aplikacija. Interakcija unutar klastera uvelike je pojednostavljena zahvaljujući konceptu usluge (), što je virtuelna IP adresa koja podržava skup IP adresa pod. Na primjer, ako je usluga vanilla želi kontaktirati servis chocolate, može direktno pristupiti virtuelnoj IP adresi za chocolate. Postavlja se pitanje kome će u ovom slučaju rješavati DNS zahtjev chocolate I kako?
Rezolucija DNS imena je konfigurisana na Kubernetes klasteru koristeći . Kubelet registruje pod sa CoreDNS kao server imena u fajlovima /etc/resolv.conf sve mahune. Ako pogledate sadržaj /etc/resolv.conf bilo koji pod, 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 serveru. U fajlu resolv.conf sadrži sljedeće informacije:
- nameserver: server na koji će se slati DNS zahtjevi. U našem slučaju, ovo je adresa CoreDNS servisa;
- pretraživanje: Definira putanju pretraživanja za određenu domenu. Zanimljivo je to
google.comilimrkaran.devnisu FQDN (). Prema standardnoj konvenciji koju slijedi većina DNS razrješavača, samo oni koji završavaju tačkom ".", koja predstavlja korijensku zonu, smatraju se potpuno kvalificiranim (FDQN) domenima. Neki razrješači mogu sami dodati tačku. dakle,mrkaran.dev.je potpuno kvalificirano ime domene (FQDN), imrkaran.dev- Ne; - ndots: Najzanimljiviji parametar (ovaj članak je o tome).
ndotsspecificira granični broj tačaka u imenu zahtjeva prije nego što se smatra "potpuno kvalificiranim" imenom domene. O tome ćemo više govoriti kasnije kada analiziramo sekvencu DNS pretraživanja.
Hajde da vidimo šta se dešava 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 nivo evidentiranja na all (što ga čini prilično opširnim). Pogledajmo dnevnike 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.145091744sFuj. Dvije stvari ovdje privlače vašu pažnju:
- Zahtjev prolazi kroz sve faze pretrage dok odgovor ne sadrži kod
NOERROR(DNS klijenti to razumiju i pohranjuju kao rezultat).NXDOMAINznači da nije pronađen zapis za dato ime domene. Zbogmrkaran.devnije FQDN ime (premandots=5), resolver gleda na stazu pretraživanja i određuje redoslijed zahtjeva; - Recordings
АиААААstižu paralelno. Činjenica je da jednokratni zahtjevi u/etc/resolv.confPodrazumevano, oni su konfigurisani na način da se paralelna pretraživanja izvode pomoću IPv4 i IPv6 protokola. Ovo ponašanje možete otkazati dodavanjem opcijesingle-requestвresolv.conf.
Napomena: glibc može se konfigurirati za slanje ovih zahtjeva uzastopno, i musl - ne, tako da korisnici Alpinea trebaju uzeti u obzir.
Eksperimentisanje sa tačkama
Hajde da eksperimentišemo još malo sa ndots i da vidimo kako se ovaj parametar ponaša. Ideja je jednostavna: ndots određuje da li će DNS klijent tretirati domenu kao apsolutnu ili relativnu. Na primjer, u slučaju jednostavnog google DNS klijenta, kako on zna da li je ova domena apsolutna? Ako postavite ndots jednak 1, klijent će reći: "Oh, unutra google ne postoji ni jedna tačka; Pretpostavljam da ću proći kroz cijelu listu za pretragu.” Međutim, ako pitate google.com, lista sufiksa će biti potpuno zanemarena jer traženo ime zadovoljava prag ndots (postoji barem jedna tač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: NXDOMAINCoreDNS 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 mrkaran nema ni jedne tačke, pretraga je obavljena po cijeloj listi sufiksa.
Napomena: u praksi maksimalna vrijednost ndots ograničeno na 15; podrazumevano u Kubernetesu je 5.
Primjena u proizvodnji
Ako aplikacija upućuje mnogo eksternih mrežnih poziva, DNS može postati usko grlo u slučaju aktivnog saobraćaja, jer rezolucija imena čini mnogo nepotrebnih upita (prije nego što sistem dođe do pravog). Aplikacije obično ne dodaju korijensku zonu imenima domena, ali ovo zvuči kao hak. To jest, umjesto da pitam api.twitter.com, možete ga 'čvrsto kodirati' api.twitter.com. (sa tačkom) u aplikaciji, što će potaknuti DNS klijente da izvrše autoritativne pretrage direktno na apsolutnoj domeni.
Dodatno, 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 cijeli domen. Ovo je jedan od klasičnih kompromisa kada morate birati između performansi i prenosivosti. Čini mi se da biste trebali brinuti o ovome samo ako je ultra-nisko kašnjenje od vitalnog značaja za vašu aplikaciju, jer se DNS rezultati također interno keširaju.
reference
Prvi put sam saznao za ovu funkciju na , održan 25. januara. Između ostalog, razgovaralo se i o ovom problemu.
Evo nekoliko linkova za dalje istraživanje:
- , zašto ndots=5 u Kubernetesu;
- kako promjena dota utječe na performanse aplikacije;
- između musl i glibc rezolvera.
Napomena: Odlučio sam da ne koristim dig u ovom članku. dig automatski dodaje tačku (identifikator korijenske zone), čineći domen "potpuno kvalificiranim" (FQDN), ne tako što ćete ga prvo proći kroz listu za pretragu. Pisala o ovome u . Međutim, prilično je iznenađujuće da, općenito, posebna zastavica mora biti specificirana za standardno ponašanje.
Sretan DNSing! Vidimo se kasnije!
PS od prevodioca
Pročitajte i na našem blogu:
- «»;
- «»;
- "Ilustrovani vodič za umrežavanje u Kubernetesu": , .
izvor: www.habr.com