ProHoster > Blog > Administrim > Kërkimi DNS në Kubernetes

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.

Kërkimi DNS në 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

Kërkimi DNS në Kubernetes

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:

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ë:

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster