منذ وقت ليس ببعيد ، أطلقنا Kubernetes 1.9 على AWS باستخدام Kops. بالأمس ، أثناء نشر حركة مرور جديدة بسلاسة إلى أكبر مجموعات Kubernetes الخاصة بنا ، بدأت لاحظت وجود أخطاء غير عادية في تحليل اسم DNS تم تسجيلها من خلال تطبيقنا.
تحدث جيثب عن هذا لفترة من الوقت ، لذلك قررت أيضا معرفة ذلك. في النهاية ، أدركت أنه في حالتنا هذا يرجع إلى زيادة الحمل على kube-dns و dnsmasq . كان الأكثر إثارة للاهتمام والجديد بالنسبة لي هو السبب وراء الزيادة الكبيرة في حركة مرور استعلامات DNS. حول هذا وماذا تفعل به ، منصبي.
يتم تحديد دقة DNS داخل الحاوية - كما هو الحال مع أي نظام Linux - من خلال ملف التكوين /etc/resolv.conf . بشكل افتراضي ، Kubernetes dnsPolicy هو ClusterFirst ، مما يعني أنه سيتم إعادة توجيه أي استعلام DNS إلى dnsmasq تشغيله في kube-dns داخل الكتلة ، والذي بدوره سيعيد توجيه الاستعلام إلى تطبيق kube-dns إذا انتهى الاسم kube-dns مجموعة ، أو خلاف ذلك ، إلى خادم DNS أعلى مستوى.
/etc/resolv.conf الملف /etc/resolv.conf داخل كل حاوية كهذا افتراضيًا:
nameserver 100.64.0.10 search namespace.svc.cluster.local svc.cluster.local cluster.local eu-west-1.compute.internal options ndots:5
كما ترون ، هناك ثلاثة توجيهات:
- خادم الاسم هو خدمة IP لـ
kube-dns - تم تحديد 4 مجالات بحث محلية
- هناك خيار
ndots:5
جزء مثير للاهتمام من هذا التكوين هو كيف ndots:5 مجالات البحث المحلية و ndots:5 إعدادات. لفهم هذا ، تحتاج إلى فهم كيفية عمل تحليل DNS للأسماء الجزئية.
ما هو الاسم الكامل؟
الاسم المؤهل بالكامل هو اسم لن يتم إجراء بحث محلي له ، وسيعتبر الاسم مطلقًا أثناء تحليل الاسم. وفقًا للاتفاقية ، يعتبر برنامج DNS أن الاسم مؤهل تمامًا إذا انتهى بفترة (.) ، ولم يتم تعريفه بالكامل على خلاف ذلك. هذا هو google.com. محددة بالكامل ، ولكن google.com لا.
كيف يتم معالجة اسم غير مكتمل؟
عندما يتصل تطبيق ما بالمضيف البعيد المحدد في الاسم ، يتم عادةً تحليل اسم DNS باستخدام مكالمة نظام ، على سبيل المثال ، getaddrinfo() . ولكن إذا كان الاسم غير مكتمل (لا ينتهي بـ.) ، أتساءل عما إذا كانت مكالمة النظام ستحاول حل الاسم على أنه مطلق أولاً أم أنها ستخضع إلى مجالات البحث المحلية أولاً؟ ذلك يعتمد على خيار ndots .
من دليل على resolv.conf :
ndots:n , , . n 1, , - , , - .
هذا يعني أنه إذا تم تعيين ndots على 5 وكان الاسم يحتوي على أقل من 5 نقاط ، فسيحاول مكالمة النظام حلها بالتسلسل ، أولاً عن طريق المرور بجميع مجالات البحث المحلية ، وإذا لم تنجح ، فسيحلها في النهاية كاسم مطلق.
لماذا يمكن أن ndots:5 تؤثر سلبا على أداء التطبيق؟
كما تعلمون ، إذا كان التطبيق الخاص بك يستخدم الكثير من حركة المرور الخارجية ، لكل اتصال TCP تم إنشاؤه (أو بشكل أكثر دقة لكل اسم تم حله) ، فسيصدر 5 استعلامات DNS قبل أن يتم حل الاسم بشكل صحيح ، لأنه سيستمر حتى 4 أولاً مجال البحث المحلي ، وفي النهاية سيصدر طلب تحليل الاسم المطلق.
يُظهر الرسم البياني التالي إجمالي عدد الزيارات على وحدات 3 kube-dns الخاصة بنا قبل وبعد أن قمنا بتحويل العديد من أسماء المضيفين التي تم تكوينها في تطبيقنا إلى أسماء محددة بالكامل.
يوضح الرسم البياني التالي تأخر التطبيق قبل وبعد أن قمنا بتحويل العديد من أسماء المضيفين التي تم تكوينها في طلبنا بالكامل (الخط الأزرق العمودي هو النشر):
الحل رقم 1 - استخدام الأسماء المؤهلة بالكامل
إذا كان لديك عدد قليل من الأسماء الخارجية الثابتة (أي المعرّفة في تكوين التطبيق) التي تنشئها عددًا كبيرًا من الاتصالات ، فربما يكون الحل الأبسط هو تحويلها إلى أسماء محددة بالكامل عن طريق إضافتها ببساطة. في النهاية
هذا ليس قرارًا نهائيًا ، لكنه يساعد على تحسين الوضع ، وإن لم يكن نظيفًا. لقد طبقنا هذا التصحيح لحل مشكلتنا ، وقد تم عرض نتائجها في لقطات الشاشة أعلاه.
الحل # 2 - تخصيص ndots في dnsConfig
في Kubernetes 1.9 ، ظهرت ميزة في وضع ألفا (الإصدار التجريبي v1.10) ، والذي يسمح بتحكم أفضل في معلمات DNS من خلال خاصية pod في dnsConfig . من بين أشياء أخرى ، يسمح لك بضبط قيمة ndots معين ، على سبيل المثال
apiVersion: v1 kind: Pod metadata: namespace: default name: dns-example spec: containers: - name: test image: nginx dnsConfig: options: - name: ndots value: "1"
مصادر
اقرأ أيضًا مقالات أخرى على مدونتنا: