ndots:5: ليه نداء DNS واحد في Kubernetes بيتحوّل لـ 5 استعلامات

على كلاستر تحت ضغط، النتيجة زمن ذيل (tail latency) بيقفز. سيناريو واقعي: خدمة بتعمل حوالي 2000 نداء خارجي في الثانية، النقلة من 5 استعلامات لاستعلام واحد بتنزّل حِمل الاستعلامات على CoreDNS بحوالي 80%. والأخطر: مع سباق معروف في conntrack عند ترجمة عناوين UDP، ممكن حزمة DNS تتفقد وتستنى الـ timeout الافتراضي (5 ثواني) قبل إعادة المحاولة، فتشوف نداء عادي فجأة بياخد 5 ثواني كاملة.

الحل: خطوات قابلة للنسخ

أفضل طريقة هي إنك تقلّل عدد الاستعلامات لكل اسم خارجي. عندك ثلاث روافع، مرتبة بالأولوية:

1. اضبط ndots للـ workload اللي بيكلّم برّه. حط ndots:2 في dnsConfig على مستوى الـ Pod. ده بيلغي جولات الـ search domains لمعظم أسماء الـ APIs الخارجية مع الحفاظ على اكتشاف الخدمات الداخلية بالأسماء القصيرة المعتادة.
2. استخدم FQDN بنقطة نهائية. لو الاسم في كودك أو إعداداتك مكتوب api.stripe.com. بنقطة في الآخر، الـ resolver بيعتبره اسمًا مطلقًا ويسأل عليه مرة واحدة مباشرة، من غير ما تلمس أي إعداد كلاستر.
3. شغّل NodeLocal DNSCache. كاش DNS على كل node بيقصّر مسار الاستعلام ويقلّل ضربات conntrack، ومفيد على الكلاسترات الكبيرة تحت ضغط عالي.

ده الباتش المباشر على الـ Deployment:

للتحقق إنه اشتغل، قيس زمن الـ resolution جوّه الـ Pod قبل وبعد:

لو time_namelookup نزل من حدود 0.2 ثانية لحدود 0.02 ثانية، يبقى القاعدة خلاص مش بتضربك.

الـ trade-offs

لا يوجد حل مجاني. لو نزّلت ndots لـ 1 أو 2 على مستوى الكلاستر كله، الأسماء الداخلية اللي بتعتمد على أكتر من search domain (زي نداء خدمة في namespace تاني بالاسم القصير) ممكن تفشل. المكسب: استعلامات أقل وزمن أقل. الخسارة: لازم تكتب أسماء الخدمات الداخلية بشكل أكمل (مثلًا svc.namespace بدل svc). عشان كده الأأمن هو ضبط ndots على مستوى الـ Pod للـ workloads اللي بتكلّم الخارج بس، مش على مستوى الكلاستر.

أما NodeLocal DNSCache فبيكسّبك استقرارًا كبيرًا، مقابل مكوّن إضافي (DaemonSet) لازم تراقبه وتحدّثه.

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

لو خدمتك بتعمل reuse كويس للاتصالات (connection pooling / keep-alive) وبتنادي عدد صغير من الأسماء الخارجية، الـ resolution بيحصل مرات قليلة جدًا والكاش بيغطّيها، فالمكسب هيبقى مهمَل ومش مستاهل تعقيد. كمان لو كلاسترك صغير وترافيك الـ DNS تحته بعيد عن أي سقف، سيبها زي ما هي. ركّز جهدك على reuse الاتصالات الأول، لأنه بيحل جذر المشكلة قبل أي ضبط لـ ndots.

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

افتح traces خدمة واحدة بتكلّم API خارجي، ودوّر على time_namelookup أو أي وقت resolution متكرر. لو لقيته أكبر من زمن النقل نفسه، ضيف باتش dnsConfig بـ ndots:2 على الـ Deployment بتاعها بس، وقارن الأرقام قبل وبعد بأمر الـ curl فوق. لو الفرق واضح، عمّمه على باقي الخدمات اللي بتكلّم الخارج.

المصادر

• Kubernetes Docs — DNS for Services and Pods (dnsConfig و ndots)
• Marco Pracucci — Kubernetes pods /etc/resolv.conf ndots:5 option and why it may negatively affect performance
• Kubernetes Docs — Using NodeLocal DNSCache
• kubernetes/kubernetes #56903 — DNS intermittent delays (conntrack UDP race)