DNS meklēšana Kubernetes

Piezīme:: DNS problēma Kubernetes, proti, parametra iestatījumi ndots, — ir pārsteidzoši populāra, turklāt jau ne pirmā gads. Šajā tēmā autors — DevOps inženieris no liela brokera Indijā — ļoti vienkāršā un kodolīgā veidā skaidro, par ko vajadzētu būt zināšanām kolēģiem, kas izmanto Kubernetes.

Viena no galvenajām priekšrocībām, izmantojot Kubernetes kā aplikāciju izvietošanas platformu, ir vienkārša aplikāciju atklāšana. Iekšklastera mijiedarbība tiek ļoti atvieglota, pateicoties servisa koncepcijai (Serviss), kas ir virtuāls IP, kas atbalsta podu IP adresu kopu. Piemēram, ja serviss vanilla. vēlas sazināties ar servisu chocolate, tas var tieši piekļūt virtuālajam IP adreses chocolate. Rodas jautājums: kurš šajā gadījumā atrisinās DNS pieprasījumu uz chocolate un kā?

DNS nosaukumu risināšana tiek konfigurēta Kubernetes klasterī, izmantojot CoreDNS. Kubelet ieraksta podu ar CoreDNS kā nosaukumu serveri visos /etc/resolv.conf podos. Ja paskatās uz kāda /etc/resolv.conf podu saturu, tas izskatīsies aptuveni šādi:

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

Šī konfigurācija tiek izmantota DNS klientiem, lai pārsūtītu pieprasījumus uz DNS serveri. Failā resolv.conf ir šāda informācija:

• nameserver: serveris, uz kuru tiks nosūtīti DNS pieprasījumi. Mūsu gadījumā tas ir CoreDNS servisa adrese;
• Ir opcija: nosaka meklēšanas ceļu konkrētam domēnam. Interesanti, ka google.com vai mrkaran.dev nav FQDN (pilnīgas domēna nosaukumi). Saskaņā ar standarta vienošanās, ko ievēro lielākā daļa DNS risinātāju, pilnīgi (FQDN) domēni tiek uzskatīti tikai tie, kas beidzas ar punktu «.», kas apzīmē saknes zonu. Daži risinātāji prot pievienot punktu paši. Tādējādi mrkaran.dev. — ir pilnīgs domēna nosaukums (FQDN), bet mrkaran.dev — nav;
• ndots: interesantākais parametrs (šī raksta tēma). ndots nosaka sliekšņa skaitu punktu pieprasījuma nosaukumā, pie kura tas tiek uzskatīts par «pilnīgu» domēna nosaukumu. Sīkāk par to runāsim vēlāk, kad analizēsim DNS meklēšanas secību.

Apskatīsim, kas notiek, kad mēs lūdzam mrkaran.dev podā:

$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53

Neautorizēta atbilde:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001

Šim eksperimentam es iestatīju CoreDNS žurnālu līmeni uz all (kas padara to diezgan apjomīgu). Apskatīsim pod'a žurnālus 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

Uff. Divas lietas šeit piesaista uzmanību:

• Pieprasījums iziet visus meklēšanas posmus, līdz atbilde satur kodu NOERROR (DNS klienti to saprot un saglabā kā rezultātu). NXDOMAIN norāda, ka šim domēna nosaukumam ieraksts nav atrasts. Tā kā mrkaran.dev nav FQDN nosaukums (saskaņā ar ndots=5), izšķirtājs skatās uz meklēšanas ceļu un nosaka pieprasījumu secību;
• Ieraksti Un un AAAA iznāk paralēli. Problēma ir tāda, ka vienreizēji pieprasījumi /etc/resolv.conf pēc noklusējuma ir iestatīti tā, lai tiktu veikta paralēla meklēšana gan IPv4, gan IPv6 protokolos. Šādu uzvedību var atcelt, pievienojot opciju single-request par resolv.conf.

Piezīme: glibc to var iestatīt uz secīgas šo pieprasījumu nosūtīšanas, bet musl – nē, tādēļ Alpine lietotājiem jāņem vērā.

Eksperimentējam ar ndots

Paskatīsimies vēl nedaudz uz ndots un redzēsim, kā uzvedas šis parametrs. Ideja ir vienkārša: ndots nosaka, vai DNS klients uzskatīs domēnu par absolūtu vai relatīvu. Piemēram, kā gadījumā ar vienkāršo google DNS klients uzzina, vai šis domēns ir absolūts? Ja iestatīt ndots vienāds ar 1, klients sacīs: "Ak, nav nevienas punkta; domāju, ka paskatīšos visā meklēšanas sarakstā." Tomēr, ja pieprasīt google , meklēšanas sufiks tiek pilnībā ignorēts, jo pieprasītā nosaukuma slieksnis ir apmierināts google.com(ir vismaz viens punkts). ndots Pārliecināsimies par to:

$ 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

CoreDNS žurnāli:

[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

mrkaran

Tā kā nav nevienas punkta, meklēšana tika veikta visā sufiksu sarakstā. Piezīme: praksē maksimālā vērtība

ir ierobežota līdz 15; pēc noklusējuma Kubernetes tā ir vienāda ar 5. ndots Izmantošana ražošanā

Izmantošana produkcijā

Ja, ja aplikācija veic daudzus ārējos tīkla pieprasījumus, DNS var kļūt par šauru vietu aktīva trafika gadījumā, jo nosaukuma izšķiršanai ir nepieciešami daudzi lieki pieprasījumi (pirms sistēma nonāk līdz vajadzīgajam). Lietojumprogrammas parasti nepiešķir saknes zonu domēna nosaukumiem, tomēr tas noteikti ir veids, kā pievērst uzmanību. Tādējādi, nevis pieprasot api.twitter.com, jūs varat "hardcodēt" api.twitter.com. (ar punktu) lietojumprogrammā, kas mudinās DNS klientus veikt autoritatīvu meklēšanu tieši absolūtajā domēnā.

Turklāt, sākot ar Kubernetes versiju 1.14, paplašinājumi dnsConfig un ir ieguva stabilas statusu. Tādējādi, izvietojot podu, jums ir iespēja samazināt vērtību ndots, piemēram, līdz 3 (un pat līdz 1!). Tādējādi katram ziņojumam iekšējā mezglā būs jāiekļauj pilns domēns. Tas ir viens no klasiskajiem kompromisiem, kad nākas izvēlēties starp veiktspēju un pārnesamību. Manuprāt, par to jāuztraucas tikai tad, ja super zemas latentības ir vitāli svarīgas jūsu lietojumprogrammai, jo DNS rezultāti arī tiek kešoti iekšpusē.

Saites

Par šo iezīmi pirmo reizi uzzināju pasākumā K8s-meetupā, kas notika 25. janvārī. Tur tika runāts, tostarp, par šo problēmu.

Šeit ir daži saites tālākai izpētei:

• Skaidrojums, kāpēc ndots=5 Kubernetes;
• Lielisks materiāls par to, kā izmaiņas ndots ietekmē lietojumprogrammas veiktspēju;
• Atšķirības starp musl un glibc resolveriem.

Piezīme: Es izvēlējos neizmantot dig šajā rakstā. dig automātiski pievieno punktu (saknes zonas identifikators), padarot domēnu par "pilnu" (FQDN), nees pārvēršot to iepriekš caur meklēšanas sarakstu. Par to rakstīju vienā no iepriekšējām publikācijām. Tomēr diezgan pārsteidzoši, ka, kopumā, standartā uzvedībai ir nepieciešams atsevišķs karogs.

Labu DNS meklēšanu! Uz drīzu tikšanos!

P.S. no tulka

Lasiet arī mūsu emuāra rakstos:

• «Calico tīklam Kubernetes: iepazīšanās un mazliet no pieredzes»;
• «CoreDNS — DNS servers cloud native pasaulei un pakalpojumu atklāšanai Kubernetes vidē»;
• „Ilustrētā rokasgrāmata par tīklu struktūru Kubernetes”: daļas 1 un 2 (tīkla modelis, pārklājošie tīkli), daļa 3 (pakalpojumi un satiksmes apstrāde).

Avots: habr.com