عقد GKE الخاصة لا تحدد واجهة API التي يستخدمها kubectl

العقد خاصة، والـ VPN يصل إليها، ومع ذلك لا يزال kubectl عاجزًا عن التحدث إلى العنقود. هاتان الحقيقتان غير مترابطتين. العنوان الذي يستخدمه kubectl يأتي من عنوان URL للخادم المخزَّن في kubeconfig عند جلب بيانات الاعتماد، ولا يغيّره أي مسار تضيفه. وفي الوقت نفسه، ليست العقد هي ما يحاول kubectl الوصول إليه أصلًا.

خمسة فحوص، نبدأ بالقيمة الوحيدة المهمة.

الفحص 1: اقرأ عنوان URL للخادم في kubeconfig

اطبع نقطة النهاية دون إفراغ بيانات الاعتماد: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". تلك السلسلة الواحدة تخبرك ما إذا كان العميل يشير إلى عنوان IP أو اسم DNS أو عنوان خارجي لم تقصده. وكل ما تبقّى في هذا التحقيق يتبع منها.

إذا لم يكن عنوان URL هو نقطة النهاية التي ظننت أنك ضبطتها، فبقية التشخيص مجرد تشتيت.

الفحص 2: طابِق عنوان URL مع نوع نقطة النهاية

يدعم GKE الحالي الوصول إلى مستوى التحكم عبر IP وعبر DNS، وبيانات الاعتماد التي تجلبها تختار أحدهما. يكتب gcloud container clusters get-credentials NAME --location REGION --internal-ip نقطة نهاية IP الداخلية، بينما يختار --dns-endpoint الوصول القائم على DNS. ولا يوفر أي من العلمين مسار شبكة، وهو ما يفاجئ من يتوقعون أن يصلح الجلب الاتصال. أعد الجلب عمدًا ثم اقرأ عنوان URL مرة أخرى بعده.

تغيير الأعلام دون إعادة قراءة عنوان URL هو الطريق الذي ينتهي به الحاسوب المحمول حاملًا بيانات اعتماد عنقودين وخطأ واحدًا محيّرًا.

يحدد إدخال الشبكة المصرح بها من يجوز له الوصول إلى نقطة نهاية خارجية، ولا ينطبق على النقطة الداخلية. وتوسيعه لاختبار مسار خاص يغيّر تعرّضك لا تشخيصك.

الفحص 3: أثبت المسار إلى نقطة النهاية تلك

إذا كان عنوان URL عنوان IP داخليًا، فتحقق من المسار من الشبكة التي يجلس عليها العميل فعليًا، ومن نطاق المصدر المسموح، ومن إعداد الوصول الإقليمي أو العالمي للعنقود. نطاق مستوى التحكم وشبكة العقد الفرعية ليسا الوجهة نفسها، لذا لا يثبت مسار عامل إلى العقد شيئًا عن نقطة النهاية. أما الوصول القائم على DNS فمساره هو اتصال Google API بترتيب Private Google Access الموثق، وليس مسارًا إلى شبكة العمال الفرعية. اختبر نقطة النهاية باتصال TCP عادي قبل لوم kubectl.

المهلة الزمنية مشكلة مسار. ورمز 403 مشكلة سياسة. وليس لهما إصلاح مشترك.

الفحص 4: افصل السجلات وexec عن استدعاءات API

إذا نجحت طلبات API العادية وفشل kubectl logs أو kubectl exec، فأنت قد تجاوزت اختيار نقطة النهاية بالفعل. تحتاج تلك العمليات إلى أذونات Kubernetes المقابلة وتعتمد على تواصل مستوى التحكم مع العقد، وقد يكون الفشل استجابة Forbidden بدلًا من مهلة. والوصول عبر SSH إلى عقدة يختبر خدمة أخرى بالكامل ولا يثبتها.

اقرأ صنف الخطأ قبل إعادة فتح تذكرة VPN، لأن الصنفين يعيشان في مكانين مختلفين.

الفحص 5: احتفظ بثلاث ملاحظات للشخص التالي

سجّل عنوان URL المختار لواجهة API، وما إذا كان طلب API واحد مصرح به يعمل، وأي عملية لاحقة تفشل بالضبط، مع نص الخطأ. تلك الأسطر الثلاثة تفصل اختيار نقطة النهاية عن الوصول إلى العقد، وتمنع لوم مسار VPN سليم تمامًا على طلب لم يحمله قط.

سيسأل المهندس التالي ما إذا كان النفق معطلًا. يجب أن تجيب ملاحظتك عن ذلك سلفًا.