Tafuta DNS huko Kubernetes

Kumbuka. tafsiri.: Tatizo la DNS katika Kubernetes, au kwa usahihi zaidi, mipangilio ya vigezo ndots, ni maarufu kwa kushangaza, na tayari Sio kwanza mwaka. Katika dokezo lingine kuhusu mada hii, mwandishi wake, mhandisi wa DevOps kutoka kampuni kubwa ya udalali nchini India, anazungumza kwa njia rahisi na mafupi kuhusu kile ambacho ni muhimu kwa wenzake wanaoendesha Kubernetes kujua.

Mojawapo ya faida kuu za kupeleka programu kwenye Kubernetes ni ugunduzi wa programu bila mshono. Mwingiliano wa ndani ya nguzo hurahisisha sana shukrani kwa dhana ya huduma (huduma), ambayo ni IP pepe inayoauni seti ya anwani za IP za pod. Kwa mfano, ikiwa huduma vanilla anataka kuwasiliana na huduma chocolate, inaweza kufikia moja kwa moja IP pepe ya chocolate. Swali linatokea: ni nani katika kesi hii atasuluhisha ombi la DNS chocolate Na Jinsi gani?

Azimio la jina la DNS limesanidiwa kwenye nguzo ya Kubernetes kwa kutumia CoreDNS. Kubelet husajili ganda na CoreDNS kama seva ya majina katika faili /etc/resolv.conf maganda yote. Ukiangalia yaliyomo /etc/resolv.conf ganda lolote, litaonekana kama hii:

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

Mipangilio hii inatumiwa na wateja wa DNS kusambaza maombi kwa seva ya DNS. Katika faili resolv.conf ina taarifa zifuatazo:

• seva ya jina: seva ambayo maombi ya DNS yatatumwa. Kwa upande wetu, hii ndiyo anwani ya huduma ya CoreDNS;
• search: Inafafanua njia ya utafutaji ya kikoa maalum. Inavutia hiyo google.com au mrkaran.dev sio FQDN (majina ya kikoa yaliyohitimu kikamilifu) Kulingana na makubaliano ya kawaida ambayo visuluhishi vingi vya DNS hufuata, zile tu zinazoisha na nukta “.”, zinazowakilisha eneo la mizizi, ndizo zinazochukuliwa kuwa vikoa vilivyo na sifa kamili (FDQN). Baadhi ya wasuluhishi wanaweza kuongeza pointi wenyewe. Hivyo, mrkaran.dev. ni jina la kikoa lililohitimu kikamilifu (FQDN), na mrkaran.dev - Hapana;
• ndots: Parameter ya kuvutia zaidi (makala hii ni kuhusu hilo). ndots hubainisha idadi ya kizingiti cha nukta katika jina la ombi kabla ya kuchukuliwa kuwa jina la kikoa "lililohitimu kikamilifu". Tutazungumza zaidi kuhusu hili baadaye tutakapochambua mlolongo wa utafutaji wa DNS.

Hebu tuone nini kinatokea tunapouliza mrkaran.dev katika ganda:

$ 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

Kwa jaribio hili, niliweka kiwango cha ukataji miti cha CoreDNS all (ambayo inafanya kuwa kitenzi kabisa). Wacha tuangalie magogo ya ganda 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. Mambo mawili yanavutia umakini wako hapa:

• Ombi hupitia hatua zote za utafutaji hadi jibu liwe na msimbo NOERROR (Wateja wa DNS wanaielewa na kuihifadhi kama matokeo). NXDOMAIN inamaanisha kuwa hakuna rekodi iliyopatikana kwa jina la kikoa lililopewa. Kwa sababu ya mrkaran.dev sio jina la FQDN (kulingana na ndots=5), msuluhishi anaangalia njia ya utaftaji na huamua mpangilio wa maombi;
• Machapisho А и АААА kufika sambamba. Ukweli ni kwamba maombi ya mara moja ndani /etc/resolv.conf Kwa chaguo-msingi, husanidiwa kwa njia ambayo utafutaji sambamba unafanywa kwa kutumia itifaki za IPv4 na IPv6. Unaweza kughairi tabia hii kwa kuongeza chaguo single-request в resolv.conf.

Kumbuka: glibc inaweza kusanidiwa kutuma maombi haya kwa kufuatana, na musl - hapana, hivyo watumiaji wa Alpine wanapaswa kuzingatia.

Majaribio na ndots

Hebu tujaribu kidogo zaidi na ndots na wacha tuone jinsi parameta hii inavyofanya. Wazo ni rahisi: ndots huamua kama mteja wa DNS atachukulia kikoa kama kamilifu au jamaa. Kwa mfano, katika kesi ya mteja rahisi wa google DNS, inajuaje ikiwa kikoa hiki ni kamili? Ukiweka ndots sawa na 1, mteja atasema: "Oh, ndani google hakuna nukta moja; Nadhani nitapitia orodha nzima ya utaftaji." Walakini, ukiuliza google.com, orodha ya viambishi tamati itapuuzwa kabisa kwa sababu jina lililoombwa linakidhi kizingiti ndots (kuna angalau pointi moja).

Hebu tuhakikishe hili:

$ 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

Kumbukumbu za 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

Tangu katika mrkaran hakuna nukta moja, utafutaji ulifanyika katika orodha nzima ya viambishi.

Kumbuka: katika mazoezi thamani ya juu ndots mdogo hadi 15; kwa chaguo-msingi katika Kubernetes ni 5.

Maombi katika uzalishaji

Ikiwa programu itapiga simu nyingi za mtandao wa nje, DNS inaweza kuwa kizuizi katika kesi ya trafiki inayoendelea, kwani utatuzi wa jina hufanya maswali mengi yasiyo ya lazima (kabla ya mfumo kufika kwa moja sahihi). Programu kwa kawaida haziongezi eneo la mizizi kwa majina ya vikoa, lakini hii inaonekana kama udukuzi. Yaani badala ya kuuliza api.twitter.com, unaweza hardcode api.twitter.com. (yenye nukta) katika programu, ambayo itawahimiza wateja wa DNS kufanya ukaguzi unaokubalika moja kwa moja kwenye kikoa kabisa.

Zaidi ya hayo, kuanzia na toleo la Kubernetes 1.14, viendelezi dnsConfig и dnsPolicy alipokea hali thabiti. Kwa hivyo, wakati wa kupeleka ganda, unaweza kupunguza thamani ndots, sema, hadi 3 (na hata hadi 1!). Kwa sababu hii, kila ujumbe ndani ya nodi itabidi ujumuishe kikoa kamili. Hii ni mojawapo ya ubadilishanaji wa kawaida unapolazimika kuchagua kati ya utendaji na kubebeka. Inaonekana kwangu kwamba unapaswa kuwa na wasiwasi kuhusu hili ikiwa tu muda wa kusubiri wa kiwango cha chini ni muhimu kwa programu yako, kwani matokeo ya DNS pia yamehifadhiwa ndani.

marejeo

Nilijifunza kwanza kuhusu kipengele hiki Mkutano wa K8, iliyofanyika Januari 25. Huko walijadili, pamoja na mambo mengine, shida hii.

Hapa kuna viungo vingine vya uchunguzi zaidi:

• Maelezo, kwa nini ndots=5 katika Kubernetes;
• Mambo makubwa jinsi kubadilisha ndoti kuathiri utendaji wa programu;
• Tofauti kati ya visuluhishi vya musl na glibc.

Kumbuka: Nilichagua kutotumia dig katika makala haya. dig huongeza kiotomatiki nukta (kitambulisho cha eneo la mizizi), na kufanya kikoa kuwa "kilichohitimu kikamilifu" (FQDN), hakuna kwa kuiendesha kwanza kupitia orodha ya utaftaji. Aliandika kuhusu hili katika moja ya machapisho yaliyotangulia. Walakini, inashangaza kwamba, kwa ujumla, bendera tofauti lazima ibainishwe kwa tabia ya kawaida.

Furaha ya DNSing! Tutaonana baadaye!

PS kutoka kwa mtafsiri

Soma pia kwenye blogi yetu:

• «Calico ya mtandao katika Kubernetes: utangulizi na uzoefu kidogo";
• «CoreDNS - seva ya DNS ya ulimwengu asilia wa wingu na Ugunduzi wa Huduma kwa Kubernetes";
• "Mwongozo Ulioonyeshwa kwa Mtandao katika Kubernetes": sehemu ya 1 na 2 (mfano wa mtandao, mitandao inayowekelea), Sehemu ya 3 (huduma na usindikaji wa trafiki).

Chanzo: mapenzi.com