أحمد حايس
الرئيسيةمن أناالدوراتالمدونةسوق الأوامرالمناهج والباقاتالشركاء
أحمد حايس

دورات عربية متخصصة في التقنية والبرمجة والذكاء الاصطناعي.

المنصة مبنية على الوضوح، التطبيق، والنتيجة النافعة: شرح مرتب يساعدك تفهم الأدوات، تكتب كودًا أفضل، وتستخدم الذكاء الاصطناعي بوعي داخل العمل الحقيقي.

تعلم أسرعوصول مباشر للدورات والمسارات من الموبايل.
تنقل أوضحالروابط الأساسية والدعم في مكان واحد بدون تشتيت.

المنصة

  • الرئيسية
  • من أنا
  • الدورات
  • المناهج والباقات
  • سوق الأوامر
  • المدونة

الدعم

  • الأسئلة الشائعة
  • تواصل معنا
  • سياسة الخصوصية
  • شروط استخدام التطبيق
  • سياسة الاسترجاع
محتاج مسار سريع؟
ابدأ من الدوراتتواصل معناالأسئلة الشائعة

© 2026 أحمد حايس. جميع الحقوق محفوظة.

الرئيسيةالدوراتالمناهجالمدونةالدخول
DevOps بالعربي

مشكلة ndots في Kubernetes: ليه استعلام DNS واحد بيتحوّل لـ 5 استعلامات ويبطّئ خدمتك

متوسط٨ يوليو ٢٠٢٦4 دقائق قراءة
مشكلة ndots في Kubernetes: ليه استعلام DNS واحد بيتحوّل لـ 5 استعلامات ويبطّئ خدمتك

المستوى: متوسط — يفترض إنك تعرف أساسيات Kubernetes (Pod، Service) وتقدر تعدّل مانيفست YAML.

لو نداء بسيط بين خدمتين جوّه الكلاستر بياخد وقت أطول من المتوقّع، وCoreDNS عليه حِمل مالوش تفسير، المشكلة غالبًا مش في الشبكة ولا في السيرفر. المشكلة في سطر واحد جوّه ملف resolv.conf اسمه ndots:5. هنا هتعرف ليه استعلام DNS واحد بيتحوّل لـ 4 أو 5 استعلامات، وإزّاي تقيس ده وتصلّحه.

ndots في Kubernetes: استعلام واحد يتحوّل إلى خمسة

المشكلة باختصار

كل Pod بيتحطّله ملف /etc/resolv.conf فيه قائمة search وإعداد options ndots:5. أي اسم فيه عدد نقاط أقل من 5 بيتجرّب بنطاقات الـ search الأول قبل ما يتعامل كاسم مطلق. نداء لاسم زي api.github.com بيتجرّب أولًا كـ api.github.com.default.svc.cluster.local وبيرجّع NXDOMAIN لحد ما ييجي دور الاسم الحقيقي في الآخر.

صفوف خوادم في مركز بيانات تعكس بنية Kubernetes حيث تدير خدمة CoreDNS استعلامات DNS الداخلية بين الخدمات

مثال يقرّب الفكرة قبل الشرح العلمي

تخيّل موظف بريد عنده قاعدة إنه يلحق العنوان الناقص بأسماء 4 مدن ويجرّب واحدة واحدة، لحد ما يوصل للصح في المحاولة الخامسة. أربع محاولات ضاعت قبل الصح. ده بالظبط اللي بيعمله الـ resolver مع كل اسم دوماته أقل من قيمة ndots.

علميًا: ndots هو الحد الأدنى لعدد النقاط اللي بعده يعتبر الاسم مطلقًا (FQDN) فيُستعلم عنه مباشرة. أقل من كده بيمرّ على قائمة search بالترتيب أول. Kubernetes بيحطّ ndots:5 عشان الأسماء القصيرة بين الخدمات تشتغل من غير الاسم الكامل. الثمن المخفي: أي اسم خارجي أو مؤهّل جزئيًا بياخد جولة استعلامات فاشلة قبل ما ينجح.

اللي بيحصل فعلاً جوّه الـ Pod

افتح أي Pod وشوف الملف بنفسك:

Bash
# اطبع resolv.conf من داخل Pod شغّال
kubectl exec -it deploy/my-app -- cat /etc/resolv.conf

# المتوقّع تلاقي حاجة زي دي:
# nameserver 10.96.0.10
# search default.svc.cluster.local svc.cluster.local cluster.local ec2.internal
# options ndots:5

قائمة الـ search فيها 4 نطاقات. اسم خارجي بنقطتين هيتجرّب 4 مرات فاشلة + مرة صح = 5 استعلامات لكل بحث. لو خدمتك بتنده اسم خارجي آلاف المرات في الثانية، ده بيضرب حِمل CoreDNS في حوالي 5.

إزّاي تقيسها بنفسك

شغّل صورة فيها أدوات DNS جوّه الكلاستر وقارن اسم عادي باسم بنقطة نهائية:

Bash
kubectl run dnsutils --rm -it --image=registry.k8s.io/e2e-test-images/agnhost:2.39 -- bash

time getent hosts api.github.com
time getent hosts api.github.com.

على كلاستر EKS تحت حِمل حوالي 1200 نداء/ثانية بين الخدمات، الفرق النموذجي في زمن الاستجابة p99 لنداء داخلي كان حوالي 48 مللي ثانية بالإعداد الافتراضي مقابل 11 مللي ثانية بعد الضبط، نزول قرابة 77%. الأرقام تقديرية وبتفرق حسب حجم الترافيك وموقع CoreDNS، بس الاتجاه ثابت.

الحل: 3 طرق مرتّبة حسب الأولوية

1) النقطة النهائية للأسماء الخارجية (أرخص حل). بدل api.github.com اكتب api.github.com. بنقطة في الآخر، فبتتخطى قائمة search وتوفّر 4 استعلامات فورًا. 2) نزّل ndots للـ Pod عبر dnsConfig لو مش قادر تعدّل كل الأسماء في الكود:

YAML
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  dnsConfig:
    options:
      - name: ndots
        value: "2"
  containers:
    - name: app
      image: my-app:1.0

مع ndots:2، أي اسم فيه نقطتين أو أكتر بيتعامل كـ FQDN مباشرة، والأسماء القصيرة تفضل شغّالة. 3) NodeLocal DNSCache للحمل العالي بيشغّل كاش DNS على كل Node فيقلّل الرحلات لـ CoreDNS المركزي، ومفيد لما يكون عندك آلاف الـ Pods.

الـ trade-offs

النقطة النهائية بتوفّر أكتر استعلامات بس ممكن تُنسى في مكتبة أو config. ndots:2 بيصلّح المشكلة على مستوى الـ Pod، لكن لو عندك أسماء داخلية مؤهّلة جزئيًا بتعتمد على الـ search ممكن تكسر resolution ليها فاختبر قبل ما تعمّم. NodeLocal DNSCache بيدّيك أكبر مكسب على السكيل مقابل مكوّن إضافي تشغّله وتراقبه.

متى لا تستخدم هذه الطريقة

لو خدمتك بتنده أسماء داخلية قصيرة بس ونادرًا بتكلّم الخارج، فإعداد ndots:5 الافتراضي مناسب ومش محتاج تلمسه. وكمان لو حجم ترافيك الـ DNS صغير، التوفير مش هيبان. اقيس الأول وبعدين قرّر.

الخطوة التالية

افتح Pod من أكتر خدمة عندها ترافيك، شغّل cat /etc/resolv.conf، وقارن زمن الاستعلام لاسم خارجي مع نفس الاسم بنقطة نهائية. لو لقيت فرق واضح، ابدأ بأرخص حل وراقب حِمل CoreDNS قبل وبعد.

المصادر

  • Kubernetes Documentation — DNS for Services and Pods: kubernetes.io/docs/concepts/services-networking/dns-pod-service
  • Kubernetes Documentation — Using NodeLocal DNSCache: kubernetes.io/docs/tasks/administer-cluster/nodelocaldns
  • Linux manual — resolv.conf(5): man7.org/linux/man-pages/man5/resolv.conf.5.html
  • CoreDNS Documentation: coredns.io/manual

هل استفدت من المقال؟

اطّلع على المزيد من المقالات والدروس المجانية من نفس المسار المعرفي.

تصفّح المدونة