نجی GKE نوڈز یہ طے نہیں کرتے کہ kubectl کون سا API استعمال کرتا ہے

نوڈز نجی ہیں، VPN ان تک پہنچتا ہے، اور پھر بھی kubectl کلسٹر سے بات نہیں کر سکتا۔ یہ دونوں حقیقتیں آپس میں منسلک نہیں ہیں۔ kubectl جو پتہ استعمال کرتا ہے وہ kubeconfig میں محفوظ سرور URL سے آتا ہے جو اس وقت لکھا گیا جب اسناد حاصل کی گئیں، اور آپ کا شامل کردہ کوئی راستہ اسے تبدیل نہیں کرتا۔ اس دوران، نوڈز وہ چیز ہی نہیں ہیں جہاں kubectl پہنچنے کی کوشش کر رہا ہے۔

پانچ جانچیں، صرف اسی ایک قدر سے شروع کرتے ہوئے جو اہم ہے۔

جانچ 1: kubeconfig میں سرور URL پڑھیں

اسناد انڈیلے بغیر اینڈ پوائنٹ چھاپیں: 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 کی بنیاد پر رسائی کے لیے راستہ مستند Private Google Access ترتیب کے ساتھ Google API رابطہ ہے، کارکنوں کے سب نیٹ تک راستہ نہیں۔ kubectl کو الزام دینے سے پہلے سادہ TCP رابطے سے اینڈ پوائنٹ جانچیں۔

وقت کا ختم ہونا راستے کا مسئلہ ہے۔ 403 پالیسی کا مسئلہ ہے۔ ان کا مشترکہ حل نہیں۔

جانچ 4: لاگز اور exec کو API کالز سے الگ کریں

اگر عام API درخواستیں کامیاب ہوں اور kubectl logs یا kubectl exec ناکام ہو، تو آپ اینڈ پوائنٹ کے انتخاب سے گزر چکے ہیں۔ ان کارروائیوں کے لیے متعلقہ Kubernetes اجازتیں درکار ہیں اور وہ کنٹرول پلین سے نوڈز تک رابطے پر منحصر ہیں، اور ناکامی وقت ختم ہونے کے بجائے Forbidden جواب بھی ہو سکتی ہے۔ نوڈ تک SSH رسائی بالکل الگ سروس جانچتی ہے اور انہیں قائم نہیں کرتی۔

VPN ٹکٹ دوبارہ کھولنے سے پہلے غلطی کا طبقہ پڑھیں، کیونکہ دونوں طبقے مختلف جگہوں پر رہتے ہیں۔

جانچ 5: اگلے شخص کے لیے تین مشاہدے رکھیں

منتخب شدہ API URL، یہ کہ ایک مجاز API درخواست کام کرتی ہے یا نہیں، اور بالکل کون سی بعد کی کارروائی ناکام ہوتی ہے، غلطی کے متن کے ساتھ درج کریں۔ وہ تین سطریں اینڈ پوائنٹ کے انتخاب کو نوڈ رسائی سے الگ کرتی ہیں، اور کسی بالکل اچھے VPN راستے کو ایسی درخواست کا الزام لگنے سے روکتی ہیں جو اس نے کبھی اٹھائی نہیں۔

اگلا انجینئر پوچھے گا کہ کیا سرنگ ٹوٹی ہے۔ آپ کے نوٹ میں اس کا جواب پہلے سے ہونا چاہیے۔