Chwilio DNS yn Kubernetes

Nodyn. traws.: problem DNS yn Kubernetes, neu'n fwy manwl gywir, gosodiadau paramedr ndots, yn rhyfeddol o boblogaidd, ac yn barod Nid yn gyntaf flwyddyn. Mewn nodyn arall ar y pwnc hwn, mae ei awdur, peiriannydd DevOps o gwmni broceriaeth mawr yn India, yn siarad mewn modd syml a chryno iawn am yr hyn sy'n ddefnyddiol i gydweithwyr sy'n gweithredu Kubernetes ei wybod.

Un o brif fanteision defnyddio cymwysiadau ar Kubernetes yw darganfod cymwysiadau di-dor. Mae rhyngweithio o fewn clwstwr yn cael ei symleiddio'n fawr diolch i'r cysyniad gwasanaeth (Gwasanaeth), sy'n IP rhithwir sy'n cefnogi set o gyfeiriadau IP pod. Er enghraifft, os yw'r gwasanaeth vanilla dymuno cysylltu â’r gwasanaeth chocolate, gall gael mynediad uniongyrchol i'r IP rhithwir ar gyfer chocolate. Mae'r cwestiwn yn codi: i bwy yn yr achos hwn fydd yn datrys y cais DNS chocolate A Sut?

Mae datrysiad enw DNS wedi'i ffurfweddu ar glwstwr Kubernetes gan ddefnyddio CoreDNS. Mae Kubelet yn cofrestru pod gyda CoreDNS fel gweinydd enw mewn ffeiliau /etc/resolv.conf pob codennau. Os edrychwch ar y cynnwys /etc/resolv.conf unrhyw god, bydd yn edrych rhywbeth fel hyn:

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

Defnyddir y ffurfweddiad hwn gan gleientiaid DNS i anfon ceisiadau ymlaen at y gweinydd DNS. Mewn ffeil resolv.conf yn cynnwys y wybodaeth ganlynol:

• gweinydd enw: gweinydd yr anfonir ceisiadau DNS ato. Yn ein hachos ni, dyma gyfeiriad y gwasanaeth CoreDNS;
• chwilio: Yn diffinio'r llwybr chwilio ar gyfer parth penodol. Mae'n ddiddorol bod google.com neu mrkaran.dev ddim yn FQDN (enwau parth cwbl gymwys). Yn ôl y confensiwn safonol y mae'r rhan fwyaf o ddatryswyr DNS yn ei ddilyn, dim ond y rhai sy'n gorffen â dot “.”, sy'n cynrychioli'r parth gwraidd, sy'n cael eu hystyried yn barthau cwbl gymwys (FDQN). Gall rhai datryswyr ychwanegu pwynt eu hunain. Felly, mrkaran.dev. yw'r enw parth cwbl gymwys (FQDN), a mrkaran.dev - Nac ydw;
• ndots: Y paramedr mwyaf diddorol (mae'r erthygl hon amdano). ndots yn pennu nifer y dotiau trothwy mewn enw cais cyn iddo gael ei ystyried yn enw parth “cymhwyster llawn”. Byddwn yn siarad mwy am hyn yn nes ymlaen pan fyddwn yn dadansoddi'r dilyniant chwilio DNS.

Gawn ni weld beth sy'n digwydd pan fyddwn ni'n gofyn mrkaran.dev mewn 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

Ar gyfer yr arbrawf hwn, gosodais lefel logio CoreDNS i all (sy'n ei wneud yn reit verbose). Gadewch i ni edrych ar foncyffion y 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. Mae dau beth yn dal eich sylw yma:

• Mae'r cais yn mynd trwy bob cam o'r chwiliad nes bod yr ymateb yn cynnwys y cod NOERROR (Mae cleientiaid DNS yn ei ddeall ac yn ei storio o ganlyniad). NXDOMAIN yn golygu na chanfuwyd unrhyw gofnod ar gyfer yr enw parth a roddwyd. Gan fod y mrkaran.dev nad yw'n enw FQDN (yn ôl ndots=5), datryswr yn edrych ar y llwybr chwilio ac yn pennu trefn y ceisiadau;
• Swyddi А и АААА cyrraedd yn gyfochrog. Y ffaith yw bod ceisiadau un-amser i mewn /etc/resolv.conf Yn ddiofyn, maent wedi'u ffurfweddu yn y fath fodd fel bod chwiliadau cyfochrog yn cael eu perfformio gan ddefnyddio'r protocolau IPv4 a IPv6. Gallwch ganslo'r ymddygiad hwn trwy ychwanegu'r opsiwn single-request в resolv.conf.

Nodyn: glibc gellir ei ffurfweddu i anfon y ceisiadau hyn yn olynol, a musl - na, felly dylai defnyddwyr Alpaidd gymryd sylw.

Arbrofi gyda ndots

Gadewch i ni arbrofi ychydig mwy gyda ndots a gadewch i ni weld sut mae'r paramedr hwn yn ymddwyn. Mae'r syniad yn syml: ndots yn penderfynu a fydd y cleient DNS yn trin y parth fel un absoliwt neu gymharol. Er enghraifft, yn achos cleient DNS google syml, sut mae'n gwybod a yw'r parth hwn yn absoliwt? Os ydych yn gosod ndots cyfartal i 1, bydd y cleient yn dweud: "O, yn google nid oes un pwynt; Mae'n debyg yr af trwy'r rhestr chwilio gyfan. ” Fodd bynnag, os gofynnwch google.com, bydd y rhestr o ôl-ddodiaid yn cael ei hanwybyddu'n llwyr oherwydd bod yr enw y gofynnwyd amdano yn cwrdd â'r trothwy ndots (mae o leiaf un pwynt).

Gadewch i ni wneud yn siŵr o hyn:

$ 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

Logiau 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

Ers yn mrkaran nid oes un pwynt, cynhaliwyd y chwiliad ar draws y rhestr gyfan o ôl-ddodiaid.

Sylwch: yn ymarferol y gwerth mwyaf ndots gyfyngedig i 15; yn ddiofyn yn Kubernetes mae'n 5.

Cais wrth gynhyrchu

Os yw cais yn gwneud llawer o alwadau rhwydwaith allanol, gall DNS ddod yn dagfa yn achos traffig gweithredol, gan fod datrysiad enw yn gwneud llawer o ymholiadau diangen (cyn i'r system gyrraedd yr un iawn). Fel arfer nid yw cymwysiadau yn ychwanegu parth gwraidd at enwau parth, ond mae hyn yn swnio fel darnia. Hynny yw, yn lle gofyn api.twitter.com, gallwch chi god caled api.twitter.com. (gyda dot) yn y cais, a fydd yn annog cleientiaid DNS i berfformio chwiliadau awdurdodol yn uniongyrchol ar y parth absoliwt.

Yn ogystal, gan ddechrau gyda fersiwn Kubernetes 1.14, estyniadau dnsConfig и dnsPolicy wedi derbyn statws sefydlog. Felly, wrth ddefnyddio pod, gallwch leihau'r gwerth ndots, dyweder, hyd at 3 (a hyd yn oed hyd at 1!). Oherwydd hyn, bydd yn rhaid i bob neges o fewn nod gynnwys y parth llawn. Mae hwn yn un o'r cyfaddawdau clasurol pan fydd yn rhaid i chi ddewis rhwng perfformiad a hygludedd. Mae'n ymddangos i mi mai dim ond os yw hwyrni hynod isel yn hanfodol i'ch cais y dylech chi boeni am hyn, gan fod canlyniadau DNS hefyd yn cael eu storio'n fewnol.

cyfeiriadau

Dysgais am y nodwedd hon gyntaf ymlaen K8s-cyfarfod, a gynhaliwyd ar Ionawr 25. Cafwyd trafodaeth am y broblem hon, ymhlith pethau eraill.

Dyma rai dolenni i'w harchwilio ymhellach:

• Esboniad, pam ndots=5 yn Kubernetes;
• Stwff gwych sut mae newid ndots yn effeithio ar berfformiad ceisiadau;
• Anghysonderau rhwng datryswyr musl a glibc.

Nodyn: Dewisais beidio â defnyddio dig yn yr erthygl hon. dig yn ychwanegu dot yn awtomatig (dynodwr parth gwraidd), gan wneud y parth yn "gwbl gymwys" (FQDN), dim trwy ei redeg trwy'r rhestr chwilio yn gyntaf. Ysgrifennodd am hyn yn un o'r cyhoeddiadau blaenorol. Fodd bynnag, mae'n syndod, yn gyffredinol, bod yn rhaid nodi baner ar wahân ar gyfer yr ymddygiad safonol.

DNSing Hapus! Wela'i di wedyn!

PS gan y cyfieithydd

Darllenwch hefyd ar ein blog:

• «Calico ar gyfer rhwydweithio yn Kubernetes: cyflwyniad ac ychydig o brofiad";
• «CoreDNS - Gweinydd DNS ar gyfer byd brodorol y cwmwl a Darganfod Gwasanaeth ar gyfer Kubernetes";
• "Arweinlyfr Darluniadol i Rwydweithio yn Kubernetes": rhannau 1 a 2 (model rhwydwaith, rhwydweithiau troshaenu), rhan 3 (gwasanaethau a phrosesu traffig).

Ffynhonnell: hab.com