🥇Kërkimi DNS në Kubernetes

Shën. përkth.: Problemi i DNS në Kubernetes, përkatësisht - konfigurimi i parametrave ndots, - për habi, është mjaft popullor, madje nuk është hera e parë vit. Në një shënim tjetër mbi këtë temë, autori i saj - inxhinier DevOps nga një kompani e madhe bursiere në Indi - flet në një mënyrë shumë të thjeshtë dhe të qartë për atë që është e rëndësishme të dinë kolegët që shfrytëzojnë Kubernetes.

Një nga avantazhet kryesore të shpërndarjes së aplikacioneve në Kubernetes është zbulimi pa probleme i aplikacioneve. Ndërveprimi brenda klasterit thjeshtohet ndjeshëm falë konceptit të shërbimit (Shërbimi), i cili përfaqëson një IP virtuale që mbështet një set IP adreshë pod-ësh. Për shembull, nëse shërbimi vanilla dëshiron të lidhet me shërbimin chocolate, ai mund të drejtohet drejtpërdrejt tek IP virtuale për chocolate. Kjo ngre pyetjen: kush do të zgjidhë kërkesën DNS në këtë rast dhe si? chocolate Zgjidhja e emrave DNS konfigurrohet në klasterin Kubernetes me anë të

CoreDNS . Kubelet regjistron pod-in me CoreDNS si server emri në skedarëttë të gjitha pod-eve. Nëse shikoni përmbajtjen e /etc/resolv.conf çdo pod-i, ajo do të duket më ose më pak si më poshtë: /etc/resolv.conf 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 tek serveri DNS. Në skedarin

resolv.conf ndodhet informacioni i mëposhtëm: nameserver

: serveri në të cilin do të drejtohen 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. Është interesante qëmrkaran.dev google.com ose nuk janë FQDN ( emra të plotë domaini). Sipas marrëveshjes standarte, të cilën e ndjekin shumica e resolverëve DNS, domainet e plota (FDQN) janë ato që përfundojnë me një pikë “.”, që përfaqëson zonën rrënjësore. Disa resolverë dinë ta shtojnë pikën vetë. Pra,mrkaran.dev. është një emër i plotë domaini (FQDN), ndërsa nuk është; nuk janë FQDN ( : Parametri më interesant (ky artikull është pikërisht për të).
ndotspërcakton numrin prag të pikave në emrin e kërkesës, kur arrihet, konsiderohet si një emër domaini "i plotë". Më shumë për këtë do të flasim më vonë, kur të analizojmë sekuencën e kërkimit DNS. ndots Le të shohim se çfarë ndodh kur kërkojmë

në pod: nuk janë FQDN ( $ nslookup mrkaran.dev Server: 10.152.183.10 Address: 10.152.183.10#53Non-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, vendosa nivelin e regjistrimit të CoreDNS në

Për këtë eksperiment, unë vendosa nivelin e regjistrimit CoreDNS në të gjitha (çfarë e bën atë shumë të fjalosur). Le të shikojmë logjët 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

Fuu. Dy gjëra këtu janë tërheqëse:

Kërkesa kalon të gjitha fazat e kërkimit derisa përgjigjja të mos përmbajë kodin NOERROR (klientët DNS e kuptojnë dhe e ruajnë atë si rezultat). NXDOMAIN do të thotë se për këtë emër domeni nuk është gjetur ndonjë regjistrim. Pasi nuk janë FQDN ( nuk është emër FQDN (sipas ndots=5), zgjidhësi e shqyrton rrugën e kërkimit dhe përcakton rendin e kërkesave;
Regjistrimet A dhe AAAA vijnë paralelisht. E vërteta është se kërkesat e veçanta në /etc/resolv.conf janë parazgjedhur për të kryer kërkimin paralel në protokollet IPv4 dhe IPv6. Të gjitha këto mund të anulohen duke shtuar opsionin single-request në ndodhet informacioni i mëposhtëm:.

Vërejtje: glibc mund të konfigurohet për të dërguar këto kërkesa radhazi, ndërsa musl —jo, kështu që përdoruesit e Alpine duhet ta kenë parasysh këtë.

Eksperimentojmë me ndots

Le të eksperimentojmë pak më shumë me ndots dhe të shohim si sillet ky parametër. Ideja është e thjeshtë: ndots përcakton nëse klienti DNS do ta konsiderojë domenin absolut ose relativ. Për shembull, si në rastin e thjeshtë, si e di klienti DNS që ky domen është absolut? Nëse vendosim ndots të jetë 1, klienti do të thotë: "O, në google nuk ka asnjë pikë; ndoshta do të kaloj në të gjithë listën e kërkimit". Megjithatë, nëse kërkohet google.com, lista e sufixeve 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

Log-et 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 u zhvillua në të gjithë listën e sufixeve.

Vërejtje: në praktikë, vlera maksimale ndots është e limituar në 15; në Kubernetes është e parazgjedhur në 5.

Aplikimi në production

Nëse një aplikacion bën shumë thirrje në rrjetin e jashtëm, DNS mund të bëhet një vendngusht në rastin e trafikut të lartë, pasi gjatë zgjidhjes së emrit kryhen shumë kërkesa të tepruara (para se sistemi të arrijë te vendi i duhur). Aplikacionet zakonisht nuk i shtojnë zonat e rrënjës në emrat e domain-eve, megjithatë, kjo është një mënyrë tepër e mençur. Kështu që në vend të kërkeseve për api.twitter.com, mund të ‘hardcode’ api.twitter.com. (me pika) në aplikacion, e cila do t'i inkurajojë klientët DNS të kryejnë kërkime autoritative menjëherë në domenin absolut.

Për më tepër, që nga versioni 1.14 i Kubernetes, zgjerimet dnsConfig dhe dnsPolicy kanë marrë statusin stabil. Pra, gjatë dislokimit të një pod-i, mund të zvogëloni vlerën ndots, le të themi, deri në 3 (madje edhe deri në 1!). Për shkak të kësaj, çdo mesazh brenda nodit do të duhet të përmbajë domenin e plotë. Ky është një nga kompromiset klasike kur duhet të zgjidhni midis.performancës dhe portabilitetit. Më duket se duhet të shqetësoheni për këtë vetëm në rast se vonesat e ulëta janë jetike për aplikacionin tuaj, pasi rezultatet e DNS gjithashtu cache-ohen brenda.

Linket

Për herë të parë për këtë veçori mora vesh në K8s-meetup, që u mbajt më 25 janar. Aty u diskutua, midis të tjera, edhe për këtë problem.

Ja disa lidhje për studim të mëtejshëm:

Shpjegimi, pse ndots=5 në Kubernetes;
Një material i shkëlqyer rreth si ndikon ndryshimi i ndots në performancën e aplikacionit;
Mospajtime mes resolver-eve musl dhe glibc.

Shënim: Preferova të mos përdor dig në këtë artikull. dig automaikisht shton pikën (identifikuesin e zonës rrënjës), duke e bërë domenin ‘të plotë’ (FQDN), jo duke e kaluar atë paraprakisht përmes listës së kërkimeve. Kam shkruar për këtë në një nga publikimet e mia të mëparshme. Megjithatë, është mjaft befasuese se, në përgjithësi, për sjelljen standarde duhet të vendosni një flamur të veçantë.

Gëzuar DNS-ing! Shihemi së shpejti!

P.S. nga përkthyesi

Lexoni gjithashtu në blogun tonë:

«Calico për rrjetin në Kubernetes: njohja dhe pak nga përvoja»;
«CoreDNS — server DNS për botën cloud native dhe Zbulimin e Shërbimeve për Kubernetes»;
“Udhëzuesi i Ilustruar për Strukturën e Rrjeteve në Kubernetes”: pjesët 1 dhe 2 (modeli rrjetor, rrjetet overlay), pjesa 3 (shërbimet dhe menaxhimi i trafik).

Burimi: habr.com