Kërkimi i DNS në Kubernetes

Shënim. përkth.: Problemi DNS në Kubernetes, ose më saktë, cilësimet e parametrave ndots, është çuditërisht popullor, dhe tashmë Jo i pari vit. Në një shënim tjetër mbi këtë temë, autori i tij, një inxhinier DevOps nga një kompani e madhe brokerimi në Indi, flet në një mënyrë shumë të thjeshtë dhe koncize për atë që është e dobishme për kolegët që operojnë Kubernetes të dinë.

Një nga përfitimet kryesore të vendosjes së aplikacioneve në Kubernetes është zbulimi i pandërprerë i aplikacioneve. Ndërveprimi brenda grupit është thjeshtuar shumë falë konceptit të shërbimit (Shërbime), e cila është një IP virtuale që mbështet një grup adresash IP të pod. Për shembull, nëse shërbimi vanilla dëshiron të kontaktojë shërbimin chocolate, mund të hyjë drejtpërdrejt në IP virtuale për chocolate. Shtrohet pyetja: kujt në këtë rast do t'ia zgjidhë kërkesën DNS chocolate Dhe si?

Rezolucioni i emrit DNS është konfiguruar në një grup Kubernetes duke përdorur CoreDNS. Kubelet regjistron një pod me CoreDNS si një server emri në skedarë /etc/resolv.conf të gjitha bishtajat. Nëse shikoni përmbajtjen /etc/resolv.conf çdo pod, do të duket diçka si kjo:

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

Ky konfigurim përdoret nga klientët DNS për të përcjellë kërkesat te serveri DNS. Në dosje resolv.conf përmban informacionin e mëposhtëm:

• serveri i emrave: server në të cilin do të dërgohen kërkesat DNS. Në rastin tonë, kjo është adresa e shërbimit CoreDNS;
• kërkim: Përcakton rrugën e kërkimit për një domen specifik. Është interesante që google.com ose mrkaran.dev nuk janë FQDN (emra domenesh plotësisht të kualifikuar). Sipas konventës standarde që ndjekin shumica e zgjidhësve DNS, vetëm ato që përfundojnë me një pikë ".", që përfaqëson zonën rrënjësore, konsiderohen domene plotësisht të kualifikuara (FDQN). Disa zgjidhës mund të shtojnë një pikë vetë. Kështu, mrkaran.dev. është emri plotësisht i kualifikuar i domenit (FQDN), dhe mrkaran.dev - Jo;
• pika: Parametri më interesant (ky artikull ka të bëjë me të). ndots specifikon numrin e pragut të pikave në një emër kërkese përpara se të konsiderohet një emër domeni "plotësisht i kualifikuar". Ne do të flasim më shumë për këtë më vonë kur të analizojmë sekuencën e kërkimit të DNS.

Le të shohim se çfarë ndodh kur të pyesim mrkaran.dev në pod:

$ 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

Për këtë eksperiment, kam vendosur nivelin e regjistrimit të CoreDNS në all (që e bën atë mjaft të folur). Le të shohim regjistrat e pod 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

Phew. Dy gjëra tërheqin vëmendjen tuaj këtu:

• Kërkesa kalon nëpër të gjitha fazat e kërkimit derisa përgjigja të përmbajë kodin NOERROR (Klientët DNS e kuptojnë atë dhe e ruajnë atë si rezultat). NXDOMAIN do të thotë se nuk u gjet asnjë rekord për emrin e dhënë të domenit. Sepse mrkaran.dev nuk është një emër FQDN (sipas ndots=5), zgjidhësi shikon rrugën e kërkimit dhe përcakton rendin e kërkesave;
• regjistrimi А и АААА arrijnë paralelisht. Fakti është se kërkesat një herë në /etc/resolv.conf Si parazgjedhje, ato janë konfiguruar në atë mënyrë që kërkimet paralele të kryhen duke përdorur protokollet IPv4 dhe IPv6. Ju mund ta anuloni këtë sjellje duke shtuar opsionin single-request в resolv.conf.

Shenim: glibc mund të konfigurohet për të dërguar këto kërkesa në mënyrë sekuenciale, dhe musl - jo, kështu që përdoruesit e Alpine duhet të kenë parasysh.

Eksperimentimi me pika

Le të eksperimentojmë pak më shumë me ndots dhe le të shohim se si sillet ky parametër. Ideja është e thjeshtë: ndots përcakton nëse klienti DNS do ta trajtojë domenin si absolut apo relativ. Për shembull, në rastin e një klienti të thjeshtë google DNS, si e di nëse ky domen është absolut? Nëse vendosni ndots e barabartë me 1, klienti do të thotë: "Oh, in google nuk ka asnjë pikë të vetme; Mendoj se do të kaloj nëpër të gjithë listën e kërkimit.” Megjithatë, nëse pyesni google.com, lista e prapashtesave do të shpërfillet plotësisht sepse emri i kërkuar plotëson pragun ndots (ka të paktën një pikë).

Le të sigurohemi për këtë:

$ 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

Regjistrat e CoreDNS:

[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

Që në mrkaran nuk ka asnjë pikë të vetme, kërkimi u krye në të gjithë listën e prapashtesave.

Shënim: në praktikë vlera maksimale ndots kufizuar në 15; si parazgjedhje në Kubernetes është 5.

Aplikimi në prodhim

Nëse një aplikacion bën shumë thirrje të rrjetit të jashtëm, DNS mund të bëhet një pengesë në rastin e trafikut aktiv, pasi zgjidhja e emrit bën shumë pyetje të panevojshme (përpara se sistemi të arrijë në atë të duhurin). Aplikacionet zakonisht nuk shtojnë një zonë rrënjësore në emrat e domeneve, por kjo tingëllon si një hak. Kjo është, në vend që të pyesni api.twitter.com, mund të kodosh api.twitter.com. (me një pikë) në aplikacion, i cili do të nxisë klientët DNS të kryejnë kërkime autoritative direkt në domenin absolut.

Për më tepër, duke filluar me versionin 1.14 të Kubernetes, shtesat dnsConfig и dnsPolicy mori status të qëndrueshëm. Kështu, kur vendosni një pod, mund ta zvogëloni vlerën ndots, të themi, deri në 3 (dhe madje deri në 1!). Për shkak të kësaj, çdo mesazh brenda një nyje do të duhet të përfshijë domenin e plotë. Ky është një nga kompensimet klasike kur duhet të zgjidhni midis performancës dhe transportueshmërisë. Më duket se duhet të shqetësoheni për këtë vetëm nëse vonesa jashtëzakonisht e ulët është jetike për aplikacionin tuaj, pasi rezultatet e DNS ruhen gjithashtu brenda në memorie të fshehtë.

Referencat

Fillimisht mësova për këtë veçori në K8s-takim, mbajtur më 25 janar. Aty u diskutua ndër të tjera për këtë problem.

Këtu janë disa lidhje për eksplorim të mëtejshëm:

• Shpjegim, pse ndots=5 në Kubernetes;
• Gjëra të shkëlqyera si ndikon ndryshimi i pikave në performancën e aplikacionit;
• Mospërputhjet ndërmjet zgjidhësve musl dhe glibc.

Shënim: Zgjodha të mos e përdor dig në këtë artikull. dig automatikisht shton një pikë (identifikuesi i zonës rrënjësore), duke e bërë domenin "plotësisht të kualifikuar" (FQDN), jo duke e drejtuar fillimisht nëpër listën e kërkimit. Shkroi për këtë në një nga publikimet e mëparshme. Megjithatë, është mjaft e habitshme që, në përgjithësi, një flamur i veçantë duhet të specifikohet për sjelljen standarde.

Gëzuar DNSing! Shihemi me vone!

PS nga përkthyesi

Lexoni edhe në blogun tonë:

• «Calico për rrjetëzimin në Kubernetes: prezantim dhe pak përvojë"?
• «CoreDNS - Server DNS për botën amtare të cloud dhe Zbulimi i Shërbimit për Kubernetes"?
• "Një udhëzues i ilustruar për rrjetëzimin në Kubernetes": pjesët 1 dhe 2 (modeli i rrjetit, rrjetet e mbivendosjes), pjesa 3 (shërbimet dhe përpunimi i trafikut).

Burimi: www.habr.com