المستوى: متوسط — يفترض إنك تعرف أساسيات 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 لحد ما ييجي دور الاسم الحقيقي في الآخر.
مثال يقرّب الفكرة قبل الشرح العلمي
تخيّل موظف بريد عنده قاعدة إنه يلحق العنوان الناقص بأسماء 4 مدن ويجرّب واحدة واحدة، لحد ما يوصل للصح في المحاولة الخامسة. أربع محاولات ضاعت قبل الصح. ده بالظبط اللي بيعمله الـ resolver مع كل اسم دوماته أقل من قيمة ndots.
علميًا: ndots هو الحد الأدنى لعدد النقاط اللي بعده يعتبر الاسم مطلقًا (FQDN) فيُستعلم عنه مباشرة. أقل من كده بيمرّ على قائمة search بالترتيب أول. Kubernetes بيحطّ ndots:5 عشان الأسماء القصيرة بين الخدمات تشتغل من غير الاسم الكامل. الثمن المخفي: أي اسم خارجي أو مؤهّل جزئيًا بياخد جولة استعلامات فاشلة قبل ما ينجح.
اللي بيحصل فعلاً جوّه الـ Pod
افتح أي Pod وشوف الملف بنفسك:
# اطبع 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 جوّه الكلاستر وقارن اسم عادي باسم بنقطة نهائية: