Kubernetes | တွင် 🥇DNS ရှာဖွေခြင်း။ ProHoster

မှတ်ချက်။ ဘာသာပြန်: Kubernetes ရှိ DNS ပြဿနာ၊ သို့မဟုတ် ပိုမိုတိကျစွာ၊ ကန့်သတ်ဆက်တင်များ ndotsအံ့သြစရာကောင်းလောက်အောင် နာမည်ကြီးနေပြီး၊ ပထမတော့ မဟုတ်ဘူး။ ခုနှစ်. ဤအကြောင်းအရာနှင့်စပ်လျဉ်းသည့် အခြားမှတ်စုတွင်၊ အိန္ဒိယရှိ ပွဲစားကုမ္ပဏီကြီးတစ်ခုမှ DevOps အင်ဂျင်နီယာတစ်ဦးဖြစ်သော ၎င်း၏စာရေးသူသည် Kubernetes လည်ပတ်နေသော လုပ်ဖော်ကိုင်ဖက်များအတွက် အသုံးဝင်သောအရာများအကြောင်း အလွန်ရိုးရှင်းပြီး တိုတိုတုတ်တုတ်ဖြင့် ပြောဆိုထားသည်။

Kubernetes တွင် အပလီကေးရှင်းများ ဖြန့်ကျက်အသုံးပြုခြင်း၏ အဓိကအကျိုးကျေးဇူးများထဲမှတစ်ခုမှာ ချောမွေ့မှုမရှိသော အပလီကေးရှင်းရှာဖွေတွေ့ရှိခြင်းဖြစ်သည်။ ဝန်ဆောင်မှုသဘောတရားကြောင့် အစုအဝေးအတွင်း အပြန်အလှန်ဆက်သွယ်မှုကို အလွန်ရိုးရှင်းစေသည် (ဝန်ဆောင်မှု) သည် pod IP လိပ်စာအစုံကို ပံ့ပိုးပေးသော virtual IP တစ်ခုဖြစ်သည်။ ဥပမာပေးရရင် ဝန်ဆောင်မှုပေးတယ်။ vanilla ဝန်ဆောင်မှုကို ဆက်သွယ်လိုပါသည်။ chocolate၎င်းသည် virtual IP ကို တိုက်ရိုက်ဝင်ရောက်နိုင်သည်။ chocolate. မေးခွန်းပေါ်လာသည်- ဤကိစ္စတွင် မည်သူက DNS တောင်းဆိုမှုကို ဖြေရှင်းမည်နည်း။ chocolate ပြီးတော့ ဘယ်လိုလဲ?

DNS အမည် ကြည်လင်ပြတ်သားမှုကို Kubernetes အစုအဝေးတွင် အသုံးပြု၍ ပြင်ဆင်သတ်မှတ်ထားသည်။ CoreDNS. Kubelet သည် ဖိုင်များတွင် nameserver အဖြစ် CoreDNS ဖြင့် pod တစ်ခုကို မှတ်ပုံတင်သည်။ /etc/resolv.conf pods အားလုံး အကြောင်းအရာကို လေ့လာကြည့်ရင် /etc/resolv.conf မည်သည့် pod မဆို၊ ၎င်းသည်ဤကဲ့သို့သောပုံရသည်-

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

တောင်းဆိုချက်များကို DNS ဆာဗာသို့ ပေးပို့ရန် ဤဖွဲ့စည်းပုံကို DNS client များက အသုံးပြုပါသည်။ ဖိုင်ထဲမှာ resolv.conf အောက်ပါအချက်အလက်များပါရှိသည်-

nameserver: DNS တောင်းဆိုမှုများကို ပေးပို့မည့် ဆာဗာ။ ကျွန်ုပ်တို့၏ကိစ္စတွင်၊ ဤသည်မှာ CoreDNS ဝန်ဆောင်မှု၏လိပ်စာဖြစ်သည်။
ရှာဖှေ: သီးခြားဒိုမိန်းတစ်ခုအတွက် ရှာဖွေမှုလမ်းကြောင်းကို သတ်မှတ်သည်။ စိတ်ဝင်စားဖို့ကောင်းတယ်။ google.com သို့မဟုတ် mrkaran.dev FQDN မဟုတ်ပါဘူး (အရည်အချင်းပြည့်မီသော ဒိုမိန်းအမည်များ) DNS ဖြေရှင်းသူအများစုလိုက်နာသည့်စံနှုန်းအရ၊ အမြစ်ဇုန်ကိုကိုယ်စားပြုသည့် dot "." နှင့်အဆုံးသတ်သောသူများကိုသာ အရည်အချင်းပြည့်မီသော (FDQN) ဒိုမိန်းများအဖြစ် သတ်မှတ်သည်။ အချို့ဖြေရှင်းသူများသည် ၎င်းတို့ကိုယ်တိုင် အမှတ်ထည့်နိုင်သည်။ ထို့ကြောင့်, mrkaran.dev. အရည်အချင်းပြည့်မီသော ဒိုမိန်းအမည် (FQDN) နှင့် mrkaran.dev - မဟုတ်ဘူး;
ndots: စိတ်ဝင်စားစရာအကောင်းဆုံး ကန့်သတ်ချက် (ဤဆောင်းပါးသည် ၎င်းအကြောင်းဖြစ်သည်)။ ndots ၎င်းကို "အရည်အချင်းပြည့်မီသော" ဒိုမိန်းအမည်ဟု မယူဆမီ တောင်းဆိုမှုအမည်တစ်ခုရှိ အစက်များ၏ တံခါးခုံနံပါတ်ကို သတ်မှတ်ပေးသည်။ DNS ရှာဖွေမှု အစီအစဥ်ကို ခွဲခြမ်းစိတ်ဖြာသောအခါတွင် ၎င်းအကြောင်း နောက်ထပ်ပြောပါမည်။

မေးတဲ့အခါ ဘာဖြစ်သွားလဲ ကြည့်ရအောင် mrkaran.dev 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

ဤစမ်းသပ်ချက်အတွက်၊ ကျွန်ုပ်သည် 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 ပရိုတိုကောများကို အသုံးပြု၍ အပြိုင်ရှာဖွေမှုများကို လုပ်ဆောင်သည့်ပုံစံဖြင့် ၎င်းတို့ကို configure လုပ်ထားသည်။ ရွေးချယ်ခွင့်ကို ထည့်သွင်းခြင်းဖြင့် သင်သည် ဤအပြုအမူကို ပယ်ဖျက်နိုင်သည်။ single-request в resolv.conf.

မှတ်ချက်: glibc ဤတောင်းဆိုချက်များကို ဆက်တိုက်ပေးပို့ရန်၊ နှင့် musl - မဟုတ်ပါ၊ ထို့ကြောင့် Alpine အသုံးပြုသူများ သတိပြုသင့်သည်။

ndots များဖြင့် စမ်းသပ်နေသည်။

နည်းနည်းထပ်ပြီး စမ်းသပ်ကြည့်ရအောင် ndots ပြီးတော့ ဒီ parameter က ဘယ်လို ပြုမူနေလဲ ကြည့်ရအောင်။ စိတ်ကူးက ရိုးရှင်းပါတယ် 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 ဖောက်သည်များအား absolute domain တွင် တရားဝင်ရှာဖွေမှုများကို တိုက်ရိုက်လုပ်ဆောင်ရန် လှုံ့ဆော်ပေးမည်ဖြစ်သည်။

ထို့အပြင် Kubernetes ဗားရှင်း 1.14 မှစတင်၍ တိုးချဲ့မှုများ dnsConfig и dnsPolicy တည်ငြိမ်သော အနေအထားကို ရရှိခဲ့သည်။ ထို့ကြောင့် pod ကိုအသုံးပြုသောအခါ၊ သင်သည်တန်ဖိုးကိုလျှော့ချနိုင်သည်။ ndots3 အထိ (နှင့် 1 အထိပင်!) ။ ထို့အတွက်ကြောင့် node တစ်ခုအတွင်းရှိ မက်ဆေ့ဂျ်တိုင်းတွင် domain အပြည့်အစုံပါဝင်ရပါမည်။ စွမ်းဆောင်ရည်နှင့် သယ်ဆောင်ရလွယ်ကူခြင်းကြားတွင် ရွေးချယ်ရသည့်အခါ ၎င်းသည် ဂန္ထဝင်အပေးအယူများထဲမှ တစ်ခုဖြစ်သည်။ DNS ရလဒ်များကို အတွင်းပိုင်း၌ သိမ်းဆည်းထားသောကြောင့် သင့်အပလီကေးရှင်းအတွက် အလွန်နိမ့်သော latency သည် အရေးကြီးပါက ၎င်းအတွက်သာ စိတ်ပူသင့်သည်ဟု ကျွန်ုပ်ထင်ပါသည်။

ကိုးကား

ဒီ Feature အကြောင်းကို စစချင်း သိလာရတယ်။ K8s-တွေ့ဆုံပွဲဇန်နဝါရီ ၂၅ ရက်က ကျင်းပခဲ့သည်။ ဒီပြဿနာနဲ့ ပတ်သက်ပြီး ဆွေးနွေးမှုတွေလည်း ရှိခဲ့ပါတယ်။

ဤသည်မှာ နောက်ထပ်ရှာဖွေရန် လင့်ခ်အချို့ဖြစ်သည်။

ရှင်းလင်းချက်Kubernetes တွင် အဘယ်ကြောင့် ndots=5 ၊
ကြီးမြတ်သောအရာ ndots များပြောင်းလဲခြင်းသည် အက်ပ်လီကေးရှင်းစွမ်းဆောင်ရည်အပေါ် မည်ကဲ့သို့အကျိုးသက်ရောက်သည်၊
မတူကွဲပြားမှုများ musl နှင့် glibc ဖြေရှင်းသူများအကြား။

မှတ်ချက်- ကျွန်တော် အသုံးမပြုရန် ရွေးချယ်ခဲ့သည်။ dig ဤဆောင်းပါးတွင်ပါ။ dig ဒိုမိန်းကို "အပြည့်အဝအရည်အချင်းပြည့်မီသော" (FQDN) ဖြစ်အောင် အစက် (root zone identifier) အလိုအလျောက်ထည့်သည်၊ မဟုတ် ရှာဖွေမှုစာရင်းမှတဆင့် ၎င်းကို ဦးစွာလုပ်ဆောင်ပါ။ ဒီအကြောင်းကို ရေးထားပါတယ်။ ယခင်စာအုပ်များထဲမှတစ်ခု. သို့သော်၊ ယေဘုယျအားဖြင့် စံအပြုအမူအတွက် သီးခြားအလံကို သတ်မှတ်ပေးရသည်မှာ အံ့သြစရာကောင်းသည်။

ပျော်ရွှင်စွာ DNSing လုပ်ပါ။ နောက်မှတွေ့မယ်!