minikube نجی API تک نہیں پہنچ رہا؟ پہلے ڈرائیور چیک کریں
ہوسٹ، نوڈ اور Pod میں سے ہر ایک کے اپنے روٹس اور اپنا resolver ہے۔ ڈرائیور کا نام لیں، وہی endpoint تینوں سے آزمائیں، پھر وہ context ٹھیک کریں جو ناکام ہوا۔
ایک نجی API آپ کے لیپ ٹاپ سے جواب دیتا ہے اور minikube میں موجود Pod اس تک نہیں پہنچ سکتا۔ ہوسٹ پر کچھ بھی تبدیل کرنے سے پہلے فعال پروفائل کے پیچھے موجود ڈرائیور کا نام لیں، کیونکہ یہی ایک حقیقت طے کرتی ہے کہ درخواست دراصل کس نیٹ ورک سے نکلتی ہے۔ پھر وہی endpoint ہوسٹ سے، نوڈ سے اور Pod سے آزمائیں۔ ان تینوں میں سے صرف ایک وہی ہے جو ناکام ہوا، اور غلط اندازہ ایک دوپہر ضائع کر دیتا ہے۔
مرحلہ 0: ڈرائیور اور ماخذ کا نام لیں
minikube سے پوچھیں کہ کون سا پروفائل فعال ہے اور یہ کیسے چل رہا ہے۔ کنٹینر ڈرائیور نوڈ کو آپ کی مشین پر ایک کنٹینر میں رکھتا ہے، VM ڈرائیور اسے ورچوئل مشین میں رکھتا ہے، اور ریموٹ ڈرائیور اسے کہیں اور بالکل مختلف جگہ رکھتا ہے۔
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نوڈ کی طرف سے کامیاب image pull نجی ہوسٹ کے لیے ناموں کے حل کے بارے میں کچھ ثابت نہیں کرتا۔ کامیاب عوامی درخواست اس سے بھی کم ثابت کرتی ہے۔ نتائج کو context کے حساب سے الگ رکھیں، کیونکہ تین قطاروں میں نظر آنے والا نمونہ تشخیص ہے اور واحد ناکامی اشارہ۔
اگر ہوسٹ کی قطار بھی ناکام ہو تو رک جائیں۔ آپ کو ہوسٹ کا نیٹ ورک مسئلہ ہے اور کلسٹر توجہ ہٹانے والی چیز ہے۔
مرحلہ 2: ہوسٹ کا کلسٹر تک راستہ برقرار رکھیں
ایک دوسری سمت ہے جو لوگ بھول جاتے ہیں: ہوسٹ کو کلسٹر کے اپنے API اور سروسز تک پہنچتے رہنا چاہیے۔ VPN کلائنٹ ایسے روٹس نصب کر سکتا ہے جو ان prefixes سے مقابلہ کریں جو minikube اپنے نوڈ نیٹ ورک، سروس رینج اور pod رینج کے لیے استعمال کرتا ہے۔
جب ایسا ہوتا ہے تو علامت الجھن میں ڈالتی ہے، کیونکہ ٹنل کام کرتا ہے اور kubectl جواب دینا چھوڑ دیتا ہے یا NodePort کنکشنز سے انکار کر دیتا ہے۔ یہ کلسٹر کی خرابی لگتی ہے اور لیپ ٹاپ کی روٹنگ کی خرابی ہوتی ہے۔
ٹنل کو کسی اور چیز کا ذمہ دار ٹھہرانے سے پہلے ہوسٹ کی روٹنگ ٹیبل کا minikube کی رینجز سے موازنہ کریں۔ اوورلیپ عام طور پر ایک زیادہ مخصوص روٹ کی صورت میں نظر آتا ہے جو اس prefix کے لیے ٹنل انٹرفیس کی طرف اشارہ کرتا ہے جسے کلسٹر اپنا سمجھتا ہے۔
مرحلہ 3: VPN بند کیے بغیر اوورلیپ حل کریں
minikube کی اپنی VPN اور proxy ہینڈ بک ان تنازعات پر بحث کرتی ہے اور اپنی مثال والی رینجز کو دیکھنے کی چیزوں کے طور پر لیتی ہے، نہ کہ عالمی فہرست کے طور پر۔ اسے اس پروفائل کے ساتھ پڑھیں جو آپ کے پاس واقعی ہے۔
جہاں حقیقی اوورلیپ موجود ہو، معاون جواب ایک غیر متصل رینج یا VPN کے مالک کی منظور کردہ دانستہ مقامی رسائی پالیسی ہے۔ سروس رینج تبدیل کرنا pod رینج تبدیل کرنے کے برابر نہیں، اور ان میں سے کوئی بھی نوڈ نیٹ ورک تبدیل کرنے کے برابر نہیں۔
مقامی کلسٹر کے چلنے کے لیے کارپوریٹ ٹنل بند کرنا کوئی شارٹ کٹ نہیں؛ یہ پالیسی کا فیصلہ ہے جو کسی اور کو کرنا ہے۔ سب کے گھر جانے کے بعد خاموشی سے کرنے کے بجائے اسے اسی شخص تک لے جائیں۔ اگر آپ پہلے ہی کر چکے ہیں تو پوچھنے سے پہلے واپس رکھیں۔
مرحلہ 4: proxy، DNS اور ناکامی کی چار شکلیں الگ کریں
اگر proxy درکار ہو تو پہچانیں کہ کس context کو اس کی ضرورت ہے۔ ہوسٹ پر براؤزر کی سیٹنگ نوڈ کے اندر کسی عمل کو کنفیگر نہیں کرتی، اور Pod کو ماحولی متغیرات یا کلسٹر سطح کی proxy کنفیگریشن درکار ہوتی ہے۔
پھر ناکامی کو بیان کرنے کے بجائے درجہ بند کریں۔ وہ نام جو حل نہ ہو DNS ہے۔ وہ نام جو حل ہو اور کنکشن سے انکار کرے روٹنگ یا listener ہے۔ وہ کنکشن جو قائم ہو اور شناخت پر ناکام ہو TLS ہے۔ خرابی کے باڈی کے ساتھ کامیاب کنکشن ایپلیکیشن ہے۔
ان چاروں میں سے ہر ایک مختلف اصلاح سے تعلق رکھتا ہے، اور صرف ایک VPN کے بارے میں ہے۔ لکھیں کہ آپ نے ہر context میں کون سا دیکھا، اور اگلا شخص کہانی کے بجائے ثبوت ورثے میں پائے گا۔