پرو هوسٽر > بلاگ > انتظاميه > Kubernetes ۾ DNS ڳولڻ

Kubernetes ۾ DNS ڳولڻ

نوٽ. ترجمو: Kubernetes ۾ DNS مسئلو، يا وڌيڪ واضح طور تي، پيٽرولر سيٽنگون ndots، حيرت انگيز طور تي مشهور آهي، ۽ اڳ ۾ ئي پهرين نه سال. هن موضوع تي هڪ ٻئي نوٽ ۾، ان جو ليکڪ، هندستان ۾ هڪ وڏي بروکرج ڪمپني مان هڪ DevOps انجنيئر، هڪ تمام سادو ۽ جامع انداز ۾ ڳالهائيندو آهي ته ڪبرنيٽس ڪم ڪندڙ ساٿين لاءِ ڄاڻڻ لاءِ ڇا مفيد آهي.

Kubernetes ۾ DNS ڳولڻ

Kubernetes تي ايپليڪيشنن کي ترتيب ڏيڻ جي مکيه فائدن مان هڪ آهي بيحد ايپليڪيشن دريافت. خدمت جي تصور (خدمت)، جيڪو هڪ مجازي IP آهي جيڪو پوڊ IP پتي جي هڪ سيٽ کي سپورٽ ڪري ٿو. مثال طور، جيڪڏهن خدمت vanilla خدمت سان رابطو ڪرڻ چاهي ٿو chocolate، اهو سڌو سنئون مجازي IP تائين رسائي ڪري سگهي ٿو chocolate. سوال پيدا ٿئي ٿو: ڪير هن معاملي ۾ DNS جي درخواست کي حل ڪندو chocolate ۽ ڪيئن؟

DNS نالي جي قرارداد ڪبرنيٽس ڪلستر استعمال ڪندي ترتيب ڏني وئي آھي CoreDNS. ڪوبيليٽ هڪ پوڊ رجسٽر ڪري ٿو 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 هيٺين معلومات تي مشتمل آهي:

  • نالو سرور: سرور جنهن ڏانهن DNS درخواستون موڪلي وينديون. اسان جي حالت ۾، هي آهي CoreDNS سروس جو پتو؛
  • ڳولا: مخصوص ڊومين لاءِ ڳولا جو رستو بيان ڪري ٿو. اها دلچسپ ڳالهه آهي google.com يا mrkaran.dev FQDN نه آهن (مڪمل طور تي قابل ڊومين جا نالا). معياري ڪنوينشن جي مطابق جيڪي اڪثر DNS حل ڪندڙ پيروي ڪندا آهن، صرف اهي جيڪي ڊٽ سان ختم ٿين ٿا "."، روٽ زون جي نمائندگي ڪن ٿا، مڪمل طور تي قابل (FDQN) ڊومينز سمجهيا وڃن ٿا. ڪجھ حل ڪندڙ پاڻ کي پوائنٽ شامل ڪري سگھن ٿا. اهڙيءَ طرح، mrkaran.dev. مڪمل طور تي قابليت وارو ڊومين نالو آهي (FQDN)، ۽ mrkaran.dev - نه؛
  • نقطا: سڀ کان وڌيڪ دلچسپ پيٽرولر (هي مضمون ان بابت آهي). ndots هڪ درخواست جي نالي ۾ ڊٽس جي حد جو تعداد بيان ڪري ٿو ان کان اڳ جو ان کي "مڪمل طور تي قابل" ڊومين نالو سمجهيو وڃي. اسان ان جي باري ۾ وڌيڪ ڳالهائينداسين بعد ۾ جڏهن اسان ڊي اين ايس ڳولڻ جي ترتيب جو تجزيو ڪنداسين.

Kubernetes ۾ 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 - نه، تنهنڪري الپائن استعمال ڪندڙن کي نوٽ وٺڻ گهرجي.

ndots سان تجربو

اچو ته ٿورو وڌيڪ تجربو ڪريون ndots ۽ اچو ته ڏسو ته هي پيٽرول ڪيئن ڪم ڪري ٿو. خيال سادو آهي: ndots اهو طئي ڪري ٿو ته ڇا DNS ڪلائنٽ ڊومين کي مطلق يا لاڳاپو سمجهي ٿو. مثال طور، هڪ سادي گوگل DNS ڪلائنٽ جي صورت ۾، اهو ڪيئن ڄاڻي ٿو ته هي ڊومين مطلق آهي؟ جيڪڏهن توهان مقرر ڪيو ndots 1 جي برابر، ڪلائنٽ چوندو: "او، ۾ google ھڪڙو نقطو نه آھي؛ مان سمجهان ٿو ته مان سڄي ڳولا جي فهرست ذريعي وڃان ٿو. بهرحال، جيڪڏهن توهان پڇو google.com, suffixes جي فهرست کي مڪمل طور تي نظر انداز ڪيو ويندو ڇاڪاڻ ته درخواست ڪيل نالو حد سان ملندو آهي 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 ڪلائنٽ کي سڌو سنئون مطلق ڊومين تي مستند ڏسڻ کي انجام ڏيڻ جي ترغيب ڏيندو.

اضافي طور تي، ڪبرنيٽس ورزن 1.14 سان شروع ڪندي، واڌايون dnsConfig и dnsPolicy مستحڪم حيثيت حاصل ڪئي. ان ڪري، جڏهن پوڊ کي ترتيب ڏيو، توهان قيمت گھٽائي سگهو ٿا ndots، چئو، 3 تائين (۽ اڃا تائين 1 تائين!). انهي جي ڪري، هر پيغام ۾ هڪ نوڊ اندر مڪمل ڊومين شامل ڪرڻو پوندو. هي هڪ آهي کلاسک واپاري بندن مان جڏهن توهان کي چونڊڻو پوندو ڪارڪردگي ۽ پورائيبلٽي جي وچ ۾. اهو مون کي لڳي ٿو ته توهان کي صرف ان جي باري ۾ پريشان ٿيڻ گهرجي جيڪڏهن الٽرا گهٽ ويڪرائي توهان جي ايپليڪيشن لاء اهم آهي، ڇو ته DNS نتيجا پڻ اندروني طور تي ڪيش ٿيل آهن.

حوالن

مون پهريون ڀيرو هن خصوصيت جي باري ۾ سکيو K8s-ملاقات، 25 جنوري تي منعقد. هن مسئلي تي بحث ڪيو ويو، ٻين شين جي وچ ۾.

هتي وڌيڪ ڳولها لاءِ ڪجهه لنڪ آهن:

  • وضاحت، ڇو ndots = 5 ڪبرنيٽس ۾؛
  • وڏو سامان ڪيئن تبديل ٿيندڙ ndots ايپليڪيشن ڪارڪردگي کي متاثر ڪري ٿو؛
  • تڪرار Musl ۽ glibc حل ڪندڙن جي وچ ۾.

نوٽ: مون استعمال نه ڪرڻ جو انتخاب ڪيو dig هن مضمون ۾ dig خودڪار طور تي هڪ ڊٽ شامل ڪري ٿو (روٽ زون جي سڃاڻپ ڪندڙ)، ڊومين کي "مڪمل طور تي قابل" (FQDN) ٺاهڻ، نه پهرين ان کي هلائڻ جي ڳولا جي فهرست ذريعي. ۾ ان بابت لکيو اڳوڻي اشاعتن مان هڪ. بهرحال، اها ڪافي حيرت انگيز آهي ته، عام طور تي، هڪ الڳ پرچم کي معياري رويي لاء بيان ڪيو وڃي.

خوش DNSing! بعد ۾ ملون ٿا!

پي ايس مترجم کان

اسان جي بلاگ تي پڻ پڙهو:

جو ذريعو: www.habr.com

تبصرو شامل ڪريو