minikube لا يصل إلى API خاص؟ تحقق من برنامج التشغيل أولاً
المضيف والعقدة والـ Pod لكل منها مساراته وResolver الخاص به. سمِّ برنامج التشغيل، واختبر نفس الـ endpoint من الثلاثة، ثم أصلح السياق الذي فشل.
يستجيب API خاص من حاسوبك المحمول ولا يستطيع Pod داخل minikube الوصول إليه. قبل أن تغيّر أي شيء على المضيف، سمِّ برنامج التشغيل الموجود خلف الملف الشخصي النشط، لأن هذه الحقيقة الوحيدة تحدد الشبكة التي يخرج منها الطلب فعلاً. ثم اختبر نفس الـ endpoint من المضيف، ومن العقدة، ومن الـ Pod. واحد فقط من هؤلاء الثلاثة هو ما فشل، والتخمين الخاطئ يكلفك بعد الظهر.
الخطوة 0: سمِّ برنامج التشغيل والمصدر
اسأل minikube أي ملف شخصي نشط وكيف يعمل. برنامج تشغيل الحاويات يضع العقدة في حاوية على جهازك، وبرنامج تشغيل الآلة الافتراضية يضعها في آلة افتراضية، وبرنامج التشغيل البعيد يضعها في مكان آخر تماماً.
minikube profile list
minikube status
kubectl config current-contextمن ذلك، دوّن من أين ينشأ الطلب. تحدد الإجابة أي Resolver وأي مسارات تهم، وهو ليس دائماً خاصاً بالمضيف. ملفان شخصيان على الحاسوب نفسه قد يتصرفان بشكل مختلف تماماً لنفس الـ URL.
| Context | What has to work |
|---|---|
| Host process | Host resolver and host route to the private destination |
| minikube node | The node's own resolver and its outbound path |
| Pod | Pod DNS through cluster services plus the cluster network path |
الخطوة 1: اختبر نفس الـ endpoint ثلاث مرات
استخدم endpoint غير ضار وأبقِ اسم المضيف والمنفذ وعائلة العناوين متطابقة في الاختبارات الثلاثة. تغيير أي منها بين التشغيلات يجعل النتائج غير قابلة للمقارنة.
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
minikube ssh -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/healthسحب صورة ناجح من العقدة لا يثبت شيئاً عن تحليل الأسماء لمضيف خاص. طلب عام ناجح يثبت أقل من ذلك. أبقِ النتائج منفصلة حسب السياق، لأن نمطاً عبر ثلاثة صفوف هو تشخيص، وفشل واحد هو دليل.
إذا فشل صف المضيف أيضاً، فتوقف. لديك مشكلة شبكة على المضيف، والعنقود مجرد إلهاء.
الخطوة 2: حافظ على مسار المضيف إلى العنقود
هناك اتجاه ثانٍ ينساه الناس: يجب أن يظل المضيف يصل إلى API العنقود وخدماته. قد يثبّت عميل VPN مسارات تنافس البادئات التي يستخدمها minikube لشبكة العقد ومدى الخدمات ومدى الـ Pod.
عندما يحدث ذلك يكون العَرَض مربكاً، لأن النفق يعمل ويتوقف kubectl عن الاستجابة أو يرفض NodePort الاتصالات. يبدو كعطل في العنقود وهو عطل توجيه في الحاسوب المحمول.
تحقق من جدول التوجيه في المضيف مقابل نطاقات minikube قبل أن تلوم النفق على أي شيء آخر. يظهر التداخل عادة كمسار أكثر تحديداً يشير إلى واجهة النفق لبادئة يتوقع العنقود أنها ملكه.
الخطوة 3: حل التداخل دون تعطيل الـ VPN
دليل VPN والوكيل الخاص بـ minikube يناقش هذه التعارضات ويعامل نطاقاته المثالبة كأشياء يجب فحصها، لا كقائمة عالمية. اقرأه إلى جانب الملف الشخصي الذي لديك فعلاً.
حيث يوجد تداخل حقيقي، تكون الإجابة المدعومة نطاقاً غير متداخل أو سياسة وصول محلية متعمدة يوافق عليها مالك الـ VPN. تغيير نطاق الخدمات ليس مثل تغيير نطاق الـ Pod، ولا أي منهما مثل تغيير شبكة العقد.
تعطيل نفق الشركة لكي يعمل عنقود محلي ليس حلاً ملتوياً؛ إنه قرار سياسة يجب أن يتخذه شخص آخر. ارفعه إلى ذلك الشخص بدلاً من فعله بهدوء بعد أن يذهب الجميع إلى بيوتهم. إذا كنت قد فعلت ذلك بالفعل، فأعده قبل أن تسأل.
الخطوة 4: افصل الوكيل وDNS وأربعة أشكال للفشل
إذا كان الوكيل مطلوباً، فحدد أي سياق يحتاجه. إعداد المتصفح على المضيف لا يكوّن عملية داخل العقدة، ويحتاج الـ Pod إلى متغيرات البيئة أو إلى تكوين وكيل على مستوى العنقود.
ثم صنّف الفشل بدلاً من وصفه. اسم لا يُحلَّل هو DNS. اسم يُحلَّل ويرفض اتصالاً هو توجيه أو مستمع. اتصال يُنشأ ويفشل في الهوية هو TLS. اتصال ناجح مع جسم خطأ هو التطبيق.
كل واحد من هؤلاء الأربعة ينتمي إلى إصلاح مختلف، وواحد فقط منها يتعلق بالـ VPN. دوّن أيها لاحظت في كل سياق، وسيرث الشخص التالي أدلة بدلاً من قصة.