ProHoster > بلاګ > اداره > په Kubernetes کې د DNS لټون

په Kubernetes کې د DNS لټون

نوټ. ژباړه: په Kubernetes کې د DNS ستونزه، یا په سمه توګه، د پیرامیټ ترتیبات ndots، په حیرانتیا سره مشهور دی، او دمخه لومړی نه کال. د دې موضوع په یوه بل یادښت کې، د دې لیکوال، په هند کې د لوی بروکرج شرکت څخه د DevOps انجنیر، په خورا ساده او لنډ ډول خبرې کوي چې د همکارانو لپاره چې د Kubernetes کار کوي پوهیدل ګټور دي.

په Kubernetes کې د DNS لټون

په کبرنیټس کې د غوښتنلیکونو پلي کولو یوه له اصلي ګټو څخه د بې سیمه غوښتنلیک کشف کول دي. د انټرا کلستر تعامل خورا ساده شوی د خدماتو مفهوم څخه مننه (خدمت)، کوم چې یو مجازی IP دی چې د پوډ IP پتې سیټ ملاتړ کوي. د مثال په توګه، که خدمت vanilla غواړي له خدمت سره اړیکه ونیسي chocolate، دا کولی شي مستقیم د دې لپاره مجازی IP ته لاسرسی ومومي chocolate. پوښتنه راپورته کیږي: څوک به پدې حالت کې د DNS غوښتنه حل کړي chocolate او څنګه؟

د DNS نوم ریزولوشن د Kubernetes کلستر په کارولو سره تنظیم شوی 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 حل کونکي یې تعقیبوي، یوازې هغه څوک چې د نقطې سره پای ته رسیږي ". ځینې ​​حل کونکي کولی شي پخپله یو ټکی اضافه کړي. په دې توګه، mrkaran.dev. د بشپړ وړ ډومین نوم (FQDN) دی، او mrkaran.dev - نه؛
  • ndots: ترټولو په زړه پورې پیرامیټر (دا مقاله د دې په اړه ده). ndots مخکې له دې چې د "بشپړ وړ" ډومین نوم وګڼل شي د غوښتنې نوم کې د نقطو حد شمیره مشخصوي. موږ به وروسته د دې په اړه نور خبرې وکړو کله چې موږ د DNS لټون ترتیب تحلیل کړو.

په 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 پیرودونکي به د ډومین سره د مطلق یا اړوند په توګه چلند وکړي. د مثال په توګه، د ساده 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 logs:

[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 ترسره شو. د نورو موضوعاتو تر څنګ د دې ستونزې په اړه هم خبرې وشوې.

دلته د نورو سپړنې لپاره ځینې لینکونه دي:

یادونه: ما نه کارول غوره کړل dig پدې مقاله کې. dig په اوتومات ډول یو نقطه اضافه کوي (د روټ زون پیژندونکی)، ډومین "بشپړ وړ" (FQDN) جوړوي، نه لومړی د لټون لیست له لارې دا په چلولو سره. په دې اړه یې لیکلي یو له پخوانیو خپرونو څخه. په هرصورت، دا خورا حیرانتیا ده چې په عمومي توګه، یو جلا بیرغ باید د معیاري چلند لپاره مشخص شي.

خوشحاله DNSing! وروسته به سره ګورو!

PS د ژباړونکي څخه

زموږ په بلاګ کې هم ولولئ:

سرچینه: www.habr.com

Add a comment