ProHoster > بلوق > إدارة > بحث DNS في Kubernetes

بحث DNS في Kubernetes

ملحوظة. ترجمة.: مشكلة DNS في Kubernetes، أو بشكل أكثر دقة، إعدادات المعلمة ndots، يحظى بشعبية مدهشة، وبالفعل ليس الأول سنة. وفي ملاحظة أخرى حول هذا الموضوع، يتحدث مؤلفها، وهو مهندس DevOps من شركة وساطة كبيرة في الهند، بطريقة بسيطة وموجزة للغاية حول ما هو مفيد للزملاء العاملين في Kubernetes معرفته.

بحث DNS في Kubernetes

إحدى الفوائد الرئيسية لنشر التطبيقات على Kubernetes هي الاكتشاف السلس للتطبيقات. تم تبسيط التفاعل داخل المجموعة إلى حد كبير بفضل مفهوم الخدمة (العطاء)، وهو عنوان IP افتراضي يدعم مجموعة من عناوين IP الخاصة بالبود. على سبيل المثال، إذا كانت الخدمة vanilla يرغب في الاتصال بالخدمة chocolate، يمكنه الوصول مباشرة إلى عنوان IP الظاهري لـ chocolate. السؤال الذي يطرح نفسه: من في هذه الحالة سوف يحل طلب DNS ل chocolate وكيف؟

تم تكوين تحليل اسم DNS على مجموعة Kubernetes باستخدام كور دي ان اس. يقوم 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.

بحث 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 - لا، لذا يجب على مستخدمي جبال الألب أخذ العلم بذلك.

تجربة مع 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:

[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 من Kubernetes، والملحقات dnsConfig и dnsPolicy حصل على وضع مستقر. وبالتالي، عند نشر الكبسولة، يمكنك تقليل القيمة ndots، على سبيل المثال، ما يصل إلى 3 (وحتى ما يصل إلى 1!). ولهذا السبب، يجب أن تتضمن كل رسالة داخل العقدة النطاق الكامل. هذه إحدى المقايضات الكلاسيكية عندما يتعين عليك الاختيار بين الأداء وقابلية النقل. يبدو لي أنه لا ينبغي عليك القلق بشأن هذا الأمر إلا إذا كان زمن الوصول المنخفض للغاية أمرًا حيويًا لتطبيقك، نظرًا لأن نتائج DNS يتم تخزينها مؤقتًا داخليًا أيضًا.

مراجع

لقد تعلمت لأول مرة عن هذه الميزة على لقاء K8s، المنعقدة في 25 يناير. وكان هناك نقاش حول هذه المشكلة، من بين أمور أخرى.

فيما يلي بعض الروابط لمزيد من الاستكشاف:

ملحوظة: اخترت عدم الاستخدام dig في هذه المقالة. dig يضيف تلقائيًا نقطة (معرف منطقة الجذر)، مما يجعل المجال "مؤهلًا بالكامل" (FQDN)، لا عن طريق تشغيله أولاً من خلال قائمة البحث. كتبت عن هذا في أحد المنشورات السابقة. ومع ذلك، فمن المدهش تمامًا أنه بشكل عام، يجب تحديد علامة منفصلة للسلوك القياسي.

DNSing سعيد! أراك لاحقًا!

PS من المترجم

اقرأ أيضًا على مدونتنا:

المصدر: www.habr.com

إضافة تعليق