Get best of the week

بحث DNS في Kubernetes

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



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

يتم تكوين تحليل اسم DNS في كتلة Kubernetes باستخدام CoreDNS . 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 ؛
  • search: . , google.com mrkaran.dev FQDN ( ). , resolver' DNS, (FDQN) , «.», . resolver' . , 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 — , Alpine .

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 على إجراء عمليات بحث موثوقة على الفور في المجال المطلق.

وعلاوة على ذلك، بدءا من الإصدار Kubernetes 1.14 والإرشاد dnsConfigو dnsPolicyمنح وضع مستقر. وبالتالي ، عند نشر جراب ، يمكنك تقليل القيمةndotsعلى سبيل المثال ، حتى 3 (وحتى 1!). ولهذا السبب ، يجب أن تتضمن كل رسالة داخل العقدة نطاقًا كاملاً. هذا هو أحد التنازلات الكلاسيكية عندما يكون عليك الاختيار بين الأداء وقابلية النقل. يبدو لي أن القلق بشأن هذا الأمر ضروري فقط إذا كانت أوقات الاستجابة المنخفضة للغاية ضرورية لتطبيقك ، حيث يتم أيضًا تخزين نتائج DNS مؤقتًا داخليًا.

المراجع


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

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


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

DNS'ing جيد! أراك لاحقا!

ملاحظة من المترجم


اقرأ أيضا في مدونتنا:

More articles:


All Articles