ProHoster > وبلاگ > اداره > جستجوی DNS در Kubernetes

جستجوی DNS در Kubernetes

توجه داشته باشید. ترجمه: مشکل DNS در Kubernetes یا به طور دقیق تر تنظیمات پارامتر ndots، به طرز شگفت آوری محبوب است و در حال حاضر نه اول سال. در یادداشت دیگری در مورد این موضوع، نویسنده آن، یک مهندس DevOps از یک شرکت کارگزاری بزرگ در هند، به شیوه ای بسیار ساده و مختصر در مورد آنچه برای همکارانی که در Kubernetes کار می کنند مفید است، صحبت می کند.

جستجوی DNS در Kubernetes

یکی از مزایای اصلی استقرار برنامه ها در Kubernetes، کشف یکپارچه برنامه است. تعامل درون خوشه ای به لطف مفهوم سرویس بسیار ساده شده است (محصولات) که یک IP مجازی است که مجموعه ای از آدرس های IP را پشتیبانی می کند. به عنوان مثال، اگر خدمات vanilla مایل به تماس با خدمات است chocolate، می تواند مستقیماً به IP مجازی دسترسی پیدا کند chocolate. این سوال مطرح می شود: در این مورد چه کسی درخواست DNS را حل می کند chocolate و چطور؟

وضوح نام DNS با استفاده از یک خوشه Kubernetes پیکربندی شده است CoreDNS. Kubelet یک pod را با 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 تعداد آستانه نقطه‌ها را در نام درخواست قبل از اینکه یک نام دامنه «کاملاً واجد شرایط» در نظر گرفته شود، مشخص می‌کند. بعداً وقتی دنباله جستجوی DNS را تجزیه و تحلیل می کنیم بیشتر در مورد این صحبت خواهیم کرد.

جستجوی DNS در Kubernetes

ببینیم وقتی می پرسیم چه اتفاقی می افتد 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 وضعیت پایدار دریافت کرد. بنابراین، هنگام استقرار یک pod، می توانید مقدار را کاهش دهید ndotsمثلاً تا 3 (و حتی تا 1!). به همین دلیل، هر پیامی در یک گره باید شامل دامنه کامل باشد. این یکی از معاوضه های کلاسیک است که باید بین عملکرد و قابلیت حمل یکی را انتخاب کنید. به نظر من فقط در صورتی باید نگران این موضوع باشید که تأخیر بسیار کم برای برنامه شما حیاتی باشد، زیرا نتایج DNS نیز به صورت داخلی ذخیره می شوند.

مراجع

من برای اولین بار با این ویژگی آشنا شدم K8s-Meetup، در 25 ژانویه برگزار شد. از جمله در مورد این مشکل بحث شد.

در اینجا چند لینک برای کاوش بیشتر وجود دارد:

  • توضیح، چرا ndots=5 در Kubernetes;
  • مواد عالی چگونه تغییر نقاط بر عملکرد برنامه تاثیر می گذارد.
  • اختلافات بین حل کننده های musl و glibc.

توجه: من استفاده نکردم dig در این مقاله. dig به طور خودکار یک نقطه (شناسه منطقه ریشه) اضافه می کند، و دامنه را "کاملا واجد شرایط" می کند (FQDN)، هیچ ابتدا آن را در لیست جستجو اجرا کنید. در این مورد نوشت یکی از انتشارات قبلی. با این حال، کاملاً تعجب آور است که، به طور کلی، یک پرچم جداگانه برای رفتار استاندارد باید مشخص شود.

DNS مبارک! بعدا میبینمت!

PS از مترجم

در وبلاگ ما نیز بخوانید:

منبع: www.habr.com

اضافه کردن نظر