🥇Kërkimi DNS në Kubernetes

Shën. përk.: Problemi DNS në Kubernetes, dhe saktësisht — konfigurimi i parametrave ndots, — sorprus është shumë popullor, dhe tashmë nuk është hera e parë vit. Në një shënim tjetër në këtë temë, autori — një inxhinier DevOps nga një kompani e madhe brokeri në Indi — në një mënyrë shumë të thjeshtë dhe të qartë tregon se çfarë është e rëndësishme të dinë kolegët që përdorin Kubernetes.

Një nga avantazhet kryesore të vendosjes së aplikacioneve në Kubernetes është zbulimi pa probleme i aplikacioneve. Ndërveprimi brenda klasës bëhet shumë më i thjeshtë përmes konceptit të shërbimit (Shërbimi), i cili paraqet një IP virtuale që mbështet një grup IP adresash të pod’ave. Për shembull, nëse shërbimi vanilla dëshiron të lidhet me shërbimin chocolate, ai mund të drejtohet drejtpërdrejt te IP virtuale për chocolate. Lind pyetja: kush do ta zgjidhë këtë rast DNS kërkesën për chocolate dhe si?

Zgjidhja e emrave DNS konfiguroni në klasën Kubernetes me CoreDNS. Kubelet regjistron podin me CoreDNS si server emrave në skedarët /etc/resolv.conf të të gjitha pod’ave. Nëse e shqyrtojmë përmbajtjen e /etc/resolv.conf cdo pod’i, do të duket më pak si kjo:

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

Kjo konfigurim përdoret nga klientët DNS për të drejtuar kërkesat në serverin DNS. Në skedarin resolv.conf ndodhet informacioni si më poshtë:

nameserver: serveri i cili do të drejtojë kërkesat DNS. Në rastin tonë, kjo është adresa e shërbimit CoreDNS;
search: përcakton rrugën e kërkimit për një domain të caktuar. Curiozisht, google.com ose mrkaran.dev nuk janë FQDN (emra të plotë domaini). Sipas marrëveshjes standarde, të cilën shumica e zgjidhësve DNS e ndjekin, domainet e plota (FDQN) konsiderohen vetëm ato që përfundojnë me pikën “.”, që përfaqëson zonën rrënjë. Disa zgjidhës dinë të shtojnë pikën vetë. Kështu, mrkaran.dev. — është emri i plotë i domainit (FQDN), ndërsa mrkaran.dev — nuk është;
ndots: Parametri më interesant (ky artikull është pikërisht për të). ndots vendos numrin kufitar të pikave në emrin e kërkesës, kur arrin atë, ajo konsiderohet si “emri i plotë” i domainit. Më shumë për këtë do të flasim më vonë, kur të analizojmë sekuencën e kërkimit DNS.

Le të shohim se çfarë ndodh kur kërkojmë 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, unë vendosa nivelin e logaritjes së CoreDNS në all (çka e bën atë shumë gojzi). Le të shohim loget e pod’it 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

Uf! Dy gjëra këtu tërheqin vëmendjen:

Kërkesa kalon nëpër të gjitha fazat e kërkimit deri sa përgjigjja të përmbajë kodin NOERROR (klientët DNS e kuptojnë dhe e ruajnë si rezultat). NXDOMAIN do të thotë se nuk u gjend një rekord për këtë emër domaini. Përderisa mrkaran.dev nuk është një emër FQDN (sipas ndots=5), rezolva shton për rrugën e kërkimit dhe përcakton rendin e kërkesave;
Rekordet Dhe dhe AAAA vijnë paralelisht. Çështja është se kërkesat e njëhershme në /etc/resolv.conf së bashku janë të konfiguruara në mënyrë që të ndodhi një kërkim paralel për protokollet IPv4 dhe IPv6. Mund të anulohet një sjellje e tillë, duke shtuar opsionin single-request në resolv.conf.

Shënim: glibc mund të konfigurohet për të dërguar këto kërkesa të njëpasnjëshme, dhe musl — jo, prandaj përdoruesit e Alpine duhet ta kenë parasysh këtë.

Po eksperimentojmë me ndots

Le të eksperimentojmë edhe pak me ndots dhe të shohim si sillet ky parametrin. Ideja është e thjeshtë: ndots përcakton nëse klienti DNS do ta konsiderojë domenin si absolut ose relativ. Për shembull, siç është rasti me Google të thjeshtë, klienti DNS si e kupton nëse ky domain është absolut? Nëse caktohet ndots të jetë 1, klienti do të thotë: "Oh, në google nuk ka asnjë pikë; ndoshta do të kaloj në gjithë listën e kërkimit". Megjithatë, nëse kërkohet google.com, lista e sufikseve do të injorohet plotësisht, pasi emri i kërkuar përmbush 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

Loget 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

Pasi në mrkaran nuk ka asnjë pikë, kërkimi është bërë në gjithë listën e sufikseve.

Shënim: në praktikë, vlera maksimale ndots e kufizuar 15; në Kubernetes, vlera e paracaktuar është 5.

Përdorimi në produksion

Nëse aplikacioni kryen shumë thirrje të jashtme në rrjet, DNS mund të bëhet një ngushticë në rast të trafik të lartë, pasi në zgjidhjen e emrit bëhen shumë kërkesa të panevojshme (para se sistemi të arrijë në të nevojshmen). Aplikacionet zakonisht nuk shtojnë zonën rrënjësore në emrat e domeneve, megjithatë kjo është përgjithësisht një hile. Pra, në vend që të kërkoni api.twitter.com, mund të ‘hardcode’ api.twitter.com. (me pikë) në aplikacion, gjë që do të inkurajojë klientët DNS të kryejnë kërkimin autoritativ menjëherë në domenin absolut.

Për më tepër, që nga versioni Kubernetes 1.14, shtesat dnsConfig dhe dnsPolicy kanë marrë statusin e stabilizuar. Kështu, gjatë desplejimit të pod-it, mund të zvogëloni vlerën ndots, le të themi, deri në 3 (madje deri në 1!). Për këtë arsye, çdo mesazh brenda nodit duhet të përmbajë emrin e plotë të domain-it. Kjo është një nga kompromisët klasike kur duhet të zgjidhni mes performancës dhe portabilitetit. Më duket se ka vlere të shqetësohesh për këtë vetëm nëse vonesat e tepërta janë jetike për aplikacionin tuaj, pasi rezultatet e DNS gjithashtu ruhen në cache.

Linke

Herën e parë që mësova për këtë veçori ishte në K8s-meetup-in, që u mbajt më 25 janar. Aty u diskutua, përfshirë edhe këtë problem.

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

Shpjegimi, pse ndots=5 në Kubernetes;
Material i shkëlqyer për mënyrën si ndryshimi i ndots ndikon në performancën e aplikacionit;
Konsistencat ndërmjet resolver-ave musl dhe glibc.

Shënim: Preferova të mos përdor dig në këtë artikull. dig automatikisht shton pikën (identifikuesin e zonës së rrënjës), duke bërë që domeni të jetë “i plotë” (FQDN), nuk duke e kaluar paraprakisht përmes listës së kërkimeve. E kam shkruar për këtë në një nga publikimet e mia të mëparshme. Megjithatë, është mjaft e çuditshme që, në përgjithësi, për sjelljen standarde duhet të vendosni një flamur të veçantë.

Gëzoje DNS-in! Shihemi shpejt!

P.S. nga përkthyesi

Lexoni gjithashtu në blogun tonë:

«Calico për rrjetin në Kubernetes: njohje dhe pak nga përvoja»;
«CoreDNS — serveri DNS për botën cloud native dhe Service Discovery për Kubernetes»;
«Udhëzuesi ilustruar për ndërtimin e rrjetit në Kubernetes»: pjesët 1 dhe 2 (modeli rrjetor, rrjetet e mbështjelljes), pjesa 3 (shërbimet dhe procesimi i trafikut).

Burimi: habr.com