DNS որոնում Kubernetes-ում

Նշում. թարգմ.DNS-ի խնդիր Kubernetes-ում, ավելի ճիշտ՝ պարամետրի կարգավորումներում ndots, զարմանալիորեն տարածված է, և արդեն Ոչ առաջինը տարի. Այս թեմայի վերաբերյալ մեկ այլ գրառման մեջ դրա հեղինակը՝ DevOps-ի ինժեներ Հնդկաստանի խոշոր բրոքերային ընկերությունից, շատ պարզ և հակիրճ կերպով խոսում է այն մասին, թե ինչն է օգտակար իմանալ Kubernetes-ի աշխատող գործընկերների համար:

Kubernetes-ում հավելվածների տեղակայման հիմնական առավելություններից մեկը հավելվածների անխափան հայտնաբերումն է: Ներկլաստերային փոխազդեցությունը զգալիորեն պարզեցված է ծառայության հայեցակարգի շնորհիվ (Ծառայությունների), որը վիրտուալ IP է, որն աջակցում է pod IP հասցեների մի շարք: Օրինակ, եթե ծառայությունը vanilla ցանկանում է կապվել ծառայության հետ chocolate, այն կարող է ուղղակիորեն մուտք գործել վիրտուալ IP-ի համար chocolate. Հարց է առաջանում՝ այս դեպքում ո՞ւմ է լուծելու DNS հարցումը chocolate Իսկ ինչպե՞ս:

DNS անվան լուծումը կազմաձևված է Kubernetes կլաստերի վրա՝ օգտագործելով CoreDNS. Kubelet-ը գրանցում է պատիճ CoreDNS-ով որպես անվանման սերվեր ֆայլերում /etc/resolv.conf բոլոր պատյանները: Եթե ​​նայեք բովանդակությանը /etc/resolv.conf ցանկացած պատիճ, այն կունենա այսպիսի տեսք.

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

Այս կոնֆիգուրացիան օգտագործվում է DNS հաճախորդների կողմից՝ հարցումները DNS սերվերին փոխանցելու համար: Ֆայլում resolv.conf պարունակում է հետևյալ տեղեկատվությունը.

• nameserver: սերվեր, որին կուղարկվեն DNS հարցումները: Մեր դեպքում սա CoreDNS ծառայության հասցեն է.
• որոնումՍահմանում է որոնման ուղին որոշակի տիրույթի համար: Հետաքրքիր է, որ google.com կամ mrkaran.dev FQDN չեն (լիովին որակավորված դոմենային անուններ) Համաձայն ստանդարտ կոնվենցիայի, որին հետևում են DNS լուծիչներից շատերը, միայն նրանք, որոնք ավարտվում են «.» կետով, որը ներկայացնում է արմատային գոտին, համարվում են լիովին որակավորված (FDQN) տիրույթներ։ Որոշ լուծողներ իրենք կարող են կետ ավելացնել: Այսպիսով, mrkaran.dev. լիովին որակավորված տիրույթի անունն է (FQDN), և mrkaran.dev - Ոչ;
• կետերԱմենահետաքրքիր պարամետրը (այս հոդվածը դրա մասին է): ndots նշում է կետերի շեմային թիվը հարցման անվանման մեջ, նախքան այն համարվել է «լիովին որակավորված» տիրույթի անուն: Այս մասին ավելի ուշ կխոսենք, երբ վերլուծենք DNS որոնման հաջորդականությունը:

Տեսնենք, թե ինչ կլինի, երբ հարցնենք mrkaran.dev պատիճում:

$ 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

Այս փորձի համար ես սահմանեցի CoreDNS գրանցման մակարդակը all (ինչն այն դարձնում է բավականին խոսուն): Եկեք նայենք պատիճների տեղեկամատյաններին 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

Ֆու Երկու բան այստեղ գրավում է ձեր ուշադրությունը.

• Հարցումն անցնում է որոնման բոլոր փուլերով, քանի դեռ պատասխանը չի պարունակում ծածկագիրը NOERROR (DNS հաճախորդները դա հասկանում են և արդյունքում պահպանում են այն): NXDOMAIN նշանակում է, որ տվյալ տիրույթի անվան համար գրառում չի գտնվել: Քանի որ mrkaran.dev FQDN անուն չէ (ըստ ndots=5), լուծիչը նայում է որոնման ուղուն և որոշում է հարցումների կարգը.
• Գրառումներ А и АААА ժամանել զուգահեռ. Փաստն այն է, որ մեկանգամյա հարցումները ներս /etc/resolv.conf Լռելյայնորեն, դրանք կազմաձևված են այնպես, որ զուգահեռ որոնումները կատարվեն IPv4 և IPv6 արձանագրությունների միջոցով: Դուք կարող եք չեղարկել այս պահվածքը՝ ավելացնելով տարբերակը single-request в resolv.conf.

Նշում: glibc կարող է կազմաձևվել այս հարցումները հաջորդաբար ուղարկելու համար և musl - ոչ, այնպես որ Alpine օգտվողները պետք է ուշադրություն դարձնեն:

Փորձարկում կետերի հետ

Եկեք մի փոքր ավելի փորձարկենք ndots և տեսնենք, թե ինչպես է իրեն պահում այս պարամետրը: Գաղափարը պարզ է. ndots որոշում է, արդյոք DNS հաճախորդը կվերաբերվի տիրույթին որպես բացարձակ կամ հարաբերական: Օրինակ, պարզ google DNS հաճախորդի դեպքում ինչպե՞ս է դա իմանում, արդյոք այս տիրույթը բացարձակ է: Եթե ​​դուք սահմանել ndots հավասար է 1-ի, հաճախորդը կասի google չկա մեկ կետ; Կարծում եմ, ես կանցնեմ ամբողջ որոնման ցուցակը»: Այնուամենայնիվ, եթե հարցնեք google.com, վերջածանցների ցանկն ամբողջությամբ անտեսվելու է, քանի որ պահանջվող անունը համապատասխանում է շեմին ndots (կա առնվազն մեկ կետ):

Եկեք համոզվենք սա.

$ 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 տեղեկամատյաններ.

[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 ոչ մի կետ չկա, որոնումն իրականացվել է վերջածանցների ամբողջ ցանկով։

Նշում. գործնականում առավելագույն արժեքը ndots սահմանափակվում է 15-ով; լռելյայն Kubernetes-ում դա 5 է:

Կիրառում արտադրության մեջ

Եթե ​​հավելվածը շատ արտաքին ցանցային զանգեր է կատարում, ապա DNS-ը կարող է խցանման խնդիր դառնալ ակտիվ տրաֆիկի դեպքում, քանի որ անվան լուծումը շատ անհարկի հարցումներ է անում (մինչև համակարգը ճիշտը չի հասնում): Հավելվածները սովորաբար չեն ավելացնում արմատային գոտի դոմենների անուններին, բայց սա կարծես հաքերային է: Այսինքն՝ հարցնելու փոխարեն api.twitter.com, դուք կարող եք «կոշտ կոդավորել» այն api.twitter.com. (կետով) հավելվածում, որը DNS հաճախորդներին կհուշի կատարել հեղինակավոր որոնումներ անմիջապես բացարձակ տիրույթում:

Բացի այդ, սկսած Kubernetes տարբերակից 1.14, ընդարձակումներ dnsConfig и dnsPolicy ստացել է կայուն կարգավիճակ։ Այսպիսով, պատիճ տեղադրելիս կարող եք նվազեցնել արժեքը ndots, ասենք, մինչև 3 (և նույնիսկ մինչև 1): Դրա պատճառով հանգույցի ներսում յուրաքանչյուր հաղորդագրություն պետք է ներառի ամբողջ տիրույթը: Սա դասական փոխզիջումներից մեկն է, երբ դուք պետք է ընտրություն կատարեք կատարողականության և շարժունակության միջև: Ինձ թվում է, որ դուք պետք է անհանգստանաք միայն այն դեպքում, եթե ծայրահեղ ցածր հետաձգումը կենսական նշանակություն ունի ձեր հավելվածի համար, քանի որ DNS-ի արդյունքները նույնպես պահվում են ներսում:

Սայլակ

Ես առաջին անգամ իմացա այս հատկության մասին K8s-հանդիպումհունվարի 25-ին տեղի ունեցած. Այնտեղ նրանք, ի թիվս այլ հարցերի, քննարկել են այս խնդիրը։

Ահա մի քանի հղումներ հետագա ուսումնասիրության համար.

• Բացատրություն, ինչու ndots=5 Kubernetes-ում;
• Հիանալի իրեր ինչպես է կետերի փոփոխությունն ազդում հավելվածի աշխատանքի վրա.
• Անհամապատասխանություններ musl և glibc լուծիչների միջև:

Նշում. Ես որոշեցի չօգտագործել dig սույն հոդվածի. dig ավտոմատ կերպով ավելացնում է կետ (արմատային գոտու նույնացուցիչ)՝ դարձնելով տիրույթը «լիովին որակավորված» (FQDN), ոչ սկզբում այն ​​գործարկելով որոնման ցանկում: Այս մասին գրել է նախորդ հրապարակումներից մեկը. Այնուամենայնիվ, բավականին զարմանալի է, որ, ընդհանուր առմամբ, ստանդարտ վարքագծի համար պետք է նշել առանձին դրոշ:

Շնորհավոր DNS: Կտեսնվենք!

PS թարգմանչից

Կարդացեք նաև մեր բլոգում.

• «Կալիկո Kubernetes-ում ցանցերի համար. ներածություն և մի փոքր փորձ";
• «CoreDNS - DNS սերվեր՝ ամպային հայրենի աշխարհի համար և ծառայության հայտնաբերում Kubernetes-ի համար";
• «Կուբերնետեսում ցանցային կապի պատկերազարդ ուղեցույց». մասեր 1 և 2 (ցանցային մոդել, ծածկույթի ցանցեր), մաս 3 (ծառայություններ և երթևեկության մշակում).

Source: www.habr.com