DNS lookup sa Kubernetes

Tandaan. transl.: Problema sa DNS sa Kubernetes, o mas tiyak, mga setting ng parameter ndots, ay nakakagulat na sikat, at mayroon na Hindi muna taon. Sa isa pang tala sa paksang ito, ang may-akda nito, isang DevOps engineer mula sa isang malaking kumpanya ng brokerage sa India, ay nagsasalita sa napakasimple at maigsi na paraan tungkol sa kung ano ang kapaki-pakinabang para malaman ng mga kasamahan na nagpapatakbo ng Kubernetes.

Ang isa sa mga pangunahing benepisyo ng pag-deploy ng mga application sa Kubernetes ay ang tuluy-tuloy na pagtuklas ng application. Ang inter-cluster na interaksyon ay lubos na pinasimple salamat sa konsepto ng serbisyo (serbisyo), na isang virtual na IP na sumusuporta sa isang hanay ng mga pod IP address. Halimbawa, kung ang serbisyo vanilla gustong makipag-ugnayan sa serbisyo chocolate, maaari itong direktang ma-access ang virtual IP para sa chocolate. Ang tanong ay lumitaw: kanino sa kasong ito ang lutasin ang kahilingan ng DNS chocolate At kung paano?

Ang resolution ng pangalan ng DNS ay naka-configure sa isang Kubernetes cluster gamit CoreDNS. Nagrerehistro ang Kubelet ng pod sa CoreDNS bilang nameserver sa mga file /etc/resolv.conf lahat ng pods. Kung titingnan mo ang nilalaman /etc/resolv.conf anumang pod, magiging ganito ang hitsura:

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

Ang configuration na ito ay ginagamit ng mga DNS client para ipasa ang mga kahilingan sa DNS server. Nasa file resolv.conf naglalaman ng sumusunod na impormasyon:

• nameserver: server kung saan ipapadala ang mga kahilingan sa DNS. Sa aming kaso, ito ang address ng serbisyo ng CoreDNS;
• paghahanap: Tinutukoy ang landas ng paghahanap para sa isang partikular na domain. Nakakatuwa yun google.com o mrkaran.dev ay hindi FQDN (ganap na kwalipikadong mga pangalan ng domain). Ayon sa karaniwang convention na sinusunod ng karamihan sa mga DNS resolver, tanging ang mga nagtatapos sa isang tuldok na ".", na kumakatawan sa root zone, ay itinuturing na ganap na kwalipikado (FDQN) na mga domain. Ang ilang mga solver ay maaaring magdagdag ng isang punto sa kanilang sarili. kaya, mrkaran.dev. ay ang ganap na kwalipikadong pangalan ng domain (FQDN), at mrkaran.dev - Hindi;
• tuldok: Ang pinaka-kagiliw-giliw na parameter (ang artikulong ito ay tungkol dito). ndots tumutukoy sa bilang ng threshold ng mga tuldok sa isang pangalan ng kahilingan bago ito ituring na isang "ganap na kwalipikado" na domain name. Pag-uusapan pa natin ito sa ibang pagkakataon kapag pinag-aralan natin ang pagkakasunud-sunod ng paghahanap ng DNS.

Tingnan natin kung ano ang mangyayari kapag nagtanong tayo mrkaran.dev sa 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

Para sa eksperimentong ito, itinakda ko ang antas ng pag-log ng CoreDNS sa all (na ginagawang medyo verbose). Tingnan natin ang mga log ng 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. Dalawang bagay ang nakakuha ng iyong pansin dito:

• Ang kahilingan ay dumaan sa lahat ng mga yugto ng paghahanap hanggang sa ang tugon ay naglalaman ng code NOERROR (Naiintindihan ito ng mga kliyente ng DNS at iniimbak ito bilang isang resulta). NXDOMAIN nangangahulugan na walang nakitang tala para sa ibinigay na domain name. Dahil ang mrkaran.dev ay hindi isang pangalan ng FQDN (ayon sa ndots=5), ang resolver ay tumitingin sa landas ng paghahanap at tinutukoy ang pagkakasunud-sunod ng mga kahilingan;
• Entries А и АААА dumating sa parallel. Ang katotohanan ay ang isang beses na kahilingan sa /etc/resolv.conf Bilang default, ang mga ito ay isinaayos sa paraang parallel na paghahanap ay isinasagawa gamit ang IPv4 at IPv6 protocol. Maaari mong kanselahin ang gawi na ito sa pamamagitan ng pagdaragdag ng opsyon single-request в resolv.conf.

Tandaan: glibc maaaring i-configure upang ipadala ang mga kahilingang ito nang sunud-sunod, at musl - hindi, kaya dapat tandaan ng mga gumagamit ng Alpine.

Pag-eksperimento sa mga dot

Mag-eksperimento pa tayo ng kaunti ndots at tingnan natin kung paano kumikilos ang parameter na ito. Ang ideya ay simple: ndots tinutukoy kung ituturing ng DNS client ang domain bilang ganap o kamag-anak. Halimbawa, sa kaso ng isang simpleng google DNS client, paano nito malalaman kung ang domain na ito ay ganap? Kung itinakda mo ndots katumbas ng 1, sasabihin ng kliyente: "Oh, sa google walang isang punto; Sa palagay ko ay dadaan ako sa buong listahan ng paghahanap." Gayunpaman, kung tatanungin mo google.com, ang listahan ng mga suffix ay ganap na hindi papansinin dahil ang hiniling na pangalan ay nakakatugon sa threshold ndots (mayroong kahit isang punto).

Siguraduhin natin ito:

$ 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

Mga log ng 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

Mula noong sa mrkaran walang isang punto, ang paghahanap ay isinagawa sa buong listahan ng mga suffix.

Tandaan: sa pagsasanay ang pinakamataas na halaga ndots limitado sa 15; bilang default sa Kubernetes ito ay 5.

Aplikasyon sa produksyon

Kung ang isang application ay gumagawa ng maraming panlabas na mga tawag sa network, ang DNS ay maaaring maging isang bottleneck sa kaso ng aktibong trapiko, dahil ang paglutas ng pangalan ay gumagawa ng maraming hindi kinakailangang mga query (bago makarating ang system sa tama). Ang mga application ay karaniwang hindi nagdaragdag ng root zone sa mga domain name, ngunit ito ay parang hack. Ibig sabihin, imbes na magtanong api.twitter.com, maaari kang mag-hardcode api.twitter.com. (na may tuldok) sa application, na magpo-prompt sa mga DNS client na direktang magsagawa ng mga authoritative lookup sa absolute domain.

Bukod pa rito, simula sa bersyon 1.14 ng Kubernetes, mga extension dnsConfig и dnsPolicy nakatanggap ng matatag na katayuan. Kaya, kapag nagde-deploy ng pod, maaari mong bawasan ang halaga ndots, sabihin nating, hanggang 3 (at kahit hanggang 1!). Dahil dito, ang bawat mensahe sa loob ng isang node ay kailangang isama ang buong domain. Isa ito sa mga klasikong trade-off kapag kailangan mong pumili sa pagitan ng performance at portability. Para sa akin, dapat ka lang mag-alala tungkol dito kung ang ultra-low latency ay mahalaga sa iyong aplikasyon, dahil ang mga resulta ng DNS ay naka-cache din sa loob.

sanggunian

Una kong natutunan ang tungkol sa tampok na ito sa K8s-meetup, na ginanap noong Enero 25. Nagkaroon ng talakayan tungkol sa problemang ito, bukod sa iba pang mga bagay.

Narito ang ilang mga link para sa karagdagang paggalugad:

• Paliwanag, bakit ndots=5 sa Kubernetes;
• Mahusay na bagay kung paano nakakaapekto ang pagbabago ng mga tuldok sa pagganap ng aplikasyon;
• Mga pagkakaiba sa pagitan ng mga solver ng musl at glibc.

Tandaan: Pinili kong huwag gamitin dig sa artikulong ito. dig awtomatikong nagdaragdag ng tuldok (root zone identifier), na ginagawang "ganap na kwalipikado" (FQDN) ang domain, hindi sa pamamagitan ng unang pagpapatakbo nito sa listahan ng paghahanap. Sumulat tungkol dito sa isa sa mga naunang publikasyon. Gayunpaman, nakakagulat na, sa pangkalahatan, ang isang hiwalay na bandila ay kailangang tukuyin para sa karaniwang pag-uugali.

Maligayang DNSing! See you later!

PS mula sa tagasalin

Basahin din sa aming blog:

• «Calico para sa networking sa Kubernetes: panimula at kaunting karanasan";
• «CoreDNS - DNS server para sa cloud native na mundo at Service Discovery para sa Kubernetes";
• "Isang Illustrated na Gabay sa Networking sa Kubernetes": bahagi 1 at 2 (modelo ng network, mga overlay na network), bahagi 3 (mga serbisyo at pagproseso ng trapiko).

Pinagmulan: www.habr.com