/etc/resolv.conf لـ Kubernetes pods ، الخيار ndots: 5 ، كيف يمكن أن يؤثر ذلك سلبًا على أداء التطبيق

/etc/resolv.conf لـ Kubernetes pods ، الخيار ndots: 5 ، كيف يمكن أن يؤثر ذلك سلبًا على أداء التطبيق

أطلقنا مؤخرًا Kubernetes 1.9 على AWS بمساعدة Kops. بالأمس ، أثناء طرح حركة مرور جديدة بسلاسة إلى أكبر مجموعة Kubernetes لدينا ، بدأت في ملاحظة أخطاء غير عادية في تحليل اسم DNS تم تسجيلها بواسطة تطبيقنا.

لدى GitHub القليل عن ذلك. قال، لذلك قررت أيضًا النظر في الأمر. نتيجة لذلك ، أدركت أنه في حالتنا كان السبب في ذلك هو زيادة الحمل kube-dns и dnsmasq. كان الأمر الأكثر إثارة للاهتمام والجديد بالنسبة لي هو السبب الحقيقي للزيادة الكبيرة في حركة استعلام DNS. حول هذا وماذا أفعل به ، منشوري.

يتم تحديد دقة DNS داخل الحاوية - كما هو الحال في أي نظام Linux - بواسطة ملف التكوين /etc/resolv.conf. افتراضي Kubernetes dnsPolicy هذا ClusterFirst، مما يعني أنه سيتم إعادة توجيه أي طلب DNS إلى dnsmasqيركض في جراب kube-dns داخل الكتلة ، والتي بدورها ستحيل الطلب إلى التطبيق kube-dns، إذا كان الاسم ينتهي بلاحقة مجموعة ، أو بخلاف ذلك ، إلى خادم DNS ذي مستوى أعلى.

ملف /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

كما ترى ، هناك ثلاث توجيهات:

  1. خادم الاسم هو IP الخاص بالخدمة kube-dns
  2. تم تحديد 4 مجالات بحث محلية search
  3. هناك خيار 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 الخاصة بنا قبل وبعد تبديل العديد من أسماء المضيف التي تم تكوينها في تطبيقنا إلى أسماء مضيفة مؤهلة تمامًا.

/etc/resolv.conf لـ Kubernetes pods ، الخيار ndots: 5 ، كيف يمكن أن يؤثر ذلك سلبًا على أداء التطبيق

يوضح الرسم البياني التالي زمن انتقال التطبيق قبل وبعد تبديل العديد من أسماء المضيف التي تم تكوينها في تطبيقنا إلى أسماء كاملة (الخط الأزرق العمودي هو النشر):

/etc/resolv.conf لـ Kubernetes pods ، الخيار ndots: 5 ، كيف يمكن أن يؤثر ذلك سلبًا على أداء التطبيق

الحل رقم 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"

مصادر

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

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

إضافة تعليق