🥇DNS کوبرنیٹس میں تلاش کریں

نوٹ. ترجمہ: Kubernetes میں DNS مسئلہ، یا زیادہ واضح طور پر، پیرامیٹر کی ترتیبات ndots، حیرت انگیز طور پر مقبول ہے، اور پہلے ہی پہلے نہیں۔ سال. اس موضوع پر ایک اور نوٹ میں، اس کے مصنف، ہندوستان کی ایک بڑی بروکریج کمپنی سے ڈی او اوپس انجینئر، بہت سادہ اور مختصر انداز میں اس بارے میں بات کرتے ہیں کہ کبرنیٹس کو چلانے والے ساتھیوں کے لیے یہ جاننے کے لیے کیا مفید ہے۔

Kubernetes پر ایپلی کیشنز کی تعیناتی کے اہم فوائد میں سے ایک ہموار ایپلی کیشن کی دریافت ہے۔ سروس کے تصور کی بدولت انٹرا کلسٹر تعامل کو بہت آسان بنایا گیا ہے (سروس)، جو ایک ورچوئل IP ہے جو پوڈ IP پتوں کے سیٹ کو سپورٹ کرتا ہے۔ مثال کے طور پر، اگر سروس vanilla سروس سے رابطہ کرنا چاہتے ہیں۔ chocolate، یہ براہ راست ورچوئل IP تک رسائی حاصل کرسکتا ہے۔ chocolate. سوال یہ پیدا ہوتا ہے: اس معاملے میں ڈی این ایس کی درخواست کو کون حل کرے گا۔ chocolate اور کیسے؟

ڈی این ایس نام کی ریزولوشن کوبرنیٹس کلسٹر پر کنفیگر کیا گیا ہے۔ کور ڈی این ایس. 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 مندرجہ ذیل معلومات پر مشتمل ہے:

نام سرور: سرور جس پر DNS درخواستیں بھیجی جائیں گی۔ ہمارے معاملے میں، یہ CoreDNS سروس کا پتہ ہے۔
اشتہار ڈھونڈیں: کسی مخصوص ڈومین کے لیے تلاش کے راستے کی وضاحت کرتا ہے۔ یہ دلچسپ ہے کہ google.com یا mrkaran.dev FQDN نہیں ہیں (مکمل طور پر اہل ڈومین نام)۔ معیاری کنونشن کے مطابق جس کی زیادہ تر DNS حل کرنے والے پیروی کرتے ہیں، صرف مکمل طور پر اہل (FDQN) ڈومینز کو ہی سمجھا جاتا ہے جو ایک نقطے کے ساتھ ختم ہوتے ہیں "."، روٹ زون کی نمائندگی کرتے ہیں۔ کچھ حل کرنے والے خود ایک نقطہ شامل کرسکتے ہیں۔ اس طرح، mrkaran.dev. مکمل طور پر اہل ڈومین نام (FQDN) ہے، اور mrkaran.dev - نہیں؛
ndots: سب سے دلچسپ پیرامیٹر (یہ مضمون اس کے بارے میں ہے)۔ 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 - نہیں، لہذا الپائن صارفین کو نوٹ کرنا چاہیے۔

ndots کے ساتھ تجربہ کرنا

آئیے اس کے ساتھ تھوڑا اور تجربہ کریں۔ ndots اور آئیے دیکھتے ہیں کہ یہ پیرامیٹر کیسا برتاؤ کرتا ہے۔ خیال سادہ ہے: ndots اس بات کا تعین کرتا ہے کہ آیا 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 میں؛
بہترین چیز ndots کو تبدیل کرنا درخواست کی کارکردگی کو کیسے متاثر کرتا ہے۔
تضادات musl اور glibc حل کرنے والوں کے درمیان۔

نوٹ: میں نے استعمال نہ کرنے کا انتخاب کیا۔ dig اس مضمون میں dig ڈومین کو "مکمل طور پر اہل" (FQDN) بناتے ہوئے، خود بخود ایک ڈاٹ (روٹ زون شناخت کنندہ) شامل کرتا ہے، کوئی پہلے اسے تلاش کی فہرست کے ذریعے چلا کر۔ میں اس بارے میں لکھا پچھلی اشاعتوں میں سے ایک. تاہم، یہ کافی حیران کن ہے کہ، عام طور پر، معیاری طرز عمل کے لیے ایک الگ جھنڈا متعین کرنا پڑتا ہے۔

DNSing مبارک ہو! بعد میں ملتے ہیں!

مترجم سے PS

ہمارے بلاگ پر بھی پڑھیں:

«کبرنیٹس میں نیٹ ورکنگ کے لیے کیلیکو: ایک تعارف اور تھوڑا سا تجربہ؛ "
«CoreDNS - کلاؤڈ مقامی دنیا کے لیے DNS سرور اور Kubernetes کے لیے سروس ڈسکوری؛ "
"کوبرنیٹس میں نیٹ ورکنگ کے لیے ایک مصوری گائیڈ": حصے 1 اور 2 (نیٹ ورک ماڈل، اوورلے نیٹ ورکس), حصہ 3 (سروسز اور ٹریفک پروسیسنگ).

ماخذ: www.habr.com

Kubernetes میں DNS تلاش

ndots کے ساتھ تجربہ کرنا

پیداوار میں درخواست

حوالہ جات

مترجم سے PS

نیا تبصرہ شامل کریں جواب منسوخ کریں