AKS VPN کے پیچھے نجی registry سے image نہیں کھینچ سکتا
kubelet node کے نیٹ ورک سے کھینچتا ہے، pod کے VPN سے نہیں۔ node کے راستے، node DNS، کھینچنے کا ہر endpoint، پھر TLS اور شناخت کی بنیاد پر فیصلہ کریں۔
آپ کا لیپ ٹاپ image بغیر کسی مسئلے کے کھینچ لیتا ہے، لیکن pod ImagePullBackOff میں رکا رہتا ہے۔ کارپوریٹ VPN کلائنٹ کو sidecar کے طور پر چلانے کی تجویز کام نہیں آئے گی، کیونکہ کھینچنا آپ کے container سے پہلے ہوتا ہے: kubelet node پر موجود container runtime سے image لانے کو کہتا ہے اور runtime node کا نیٹ ورک namespace استعمال کرتا ہے۔
اعمال کی ترتیب ہی طبقہ طے کرتی ہے
پہلے نام کا حل، پھر رابطہ، تصدیق، تہوں کی ڈاؤن لوڈ اور پھر container شروع ہوتا ہے۔ pod کا VPN سے ہر کام اس کے بعد ہوتا ہے، اس لیے کلستر میں چلنے والی ٹنل کھینچنے کا ثبوت نہیں۔
اسی لیے cache میں موجود image ایک بہت قائل جھوٹ ہے: ہفتے پہلے image کھینچنے والا node اسے دیتا رہتا ہے، deployment صحت مند دکھتا ہے، اور خرابی صرف اس وقت ظاہر ہوتی ہے جب scheduler نئے node پر replica رکھتا ہے۔ scale-up یا node کی تبدیلی سبب نہیں، محرک ہے۔
تین شرطیں مرمت کا تعین کرتی ہیں
رسائی routing، نام کے حل اور endpoint کے مجموعے پر منحصر ہے۔ اگر node کا subnet registry نیٹ ورک تک route نہیں کر سکتا تو کوئی credential مدد نہیں کرے گا۔ اگر نام node DNS کے ذریعے حل نہ ہو تو رابطہ شروع نہیں ہوگا۔ اگر صرف manifest ملے اور blob نہ ملے تو کھینچنا درمیان میں ناکام ہو جائے گا۔
| Condition | Typical symptom | Where to look |
|---|---|---|
| Node subnet has no route to the registry network | Timeout, no connection | Effective routes on the node NIC, gateway transit, return path on-premises |
| Node resolver cannot see the private zone | Name resolution failure in events | VNet DNS settings and the resolver the node actually uses |
| Only the manifest endpoint is reachable | Auth succeeds, layer download fails | Every hostname the registry hands out during the pull |
| TLS or identity is wrong | Certificate error, 401 or 403 | Server certificate name and trust, scoped pull identity |
صرف VNet peering ہر gateway transit ترتیب نہیں دیتی، اور ایک طرف کا راستہ کام کرنے والا راستہ نہیں۔ node کو VPN gateway کے ذریعے معاون راستہ چاہیے اور registry کی طرف node کے subnet تک واپسی کا راستہ۔
مرمت چننے سے پہلے خرابی پڑھیں
pod کے واقعات اور جس node پر وہ اترا وہاں سے شروع کریں، اپنے اصل ناموں کے ساتھ: kubectl describe pod app-example -n team-example اور kubectl get pod app-example -n team-example -o wide۔ واقعہ کا متن حل نہ ہونے والے hostname کو timeout سے، certificate کی نامنظوری کو غائب image سے، اور اجازت کی ناکامی کو ان سب سے الگ کرتا ہے۔
تصدیق سب سے زیادہ بڑھا چڑھا کر دیکھا گیا ذریعہ ہے۔ imagePullSecret runtime کو registry کے credentials دیتا ہے؛ یہ راستہ نہیں بناتا، resolver نہیں بدلتا اور غیر معتبر certificate کو درست نہیں کرتا۔ اگر واقعہ کہے کہ کھینچنے کی اجازت نہیں تھی تو شناخت کا دائرہ دیکھیں؛ اگر کہے کہ رابطہ timeout ہو گیا تو credentials بے معنی ہیں۔
Kubernetes کی image دستاویز کھینچنے کے رویے اور نجی registry کے credentials کا حوالہ ہے، اور نیٹ ورک بدلنے سے پہلے ایک بار پڑھنا مناسب ہے، کیونکہ یہ تصدیق اور نقل و حمل کے درمیان حد واضح کرتی ہے۔
pod کے نیچے راستہ بنائیں
اسی ترتیب سے کام کریں۔ پہلے node کا نیٹ ورک route کریں: یقینی بنائیں کہ subnet کے پاس registry نیٹ ورک تک معاون راستہ ہے، node پر مؤثر راستے، دونوں سروں کے سیکیورٹی قواعد اور registry کی طرف واپسی کا راستہ دیکھیں۔
پھر node کے سیاق سے نام حل کریں۔ node کا resolver pod کی DNS ترتیب نہیں، اور pod کے اندر کامیابی host runtime کا ثبوت نہیں۔ مستقل hosts اندراج کی بجائے منظم نجی DNS استعمال کریں؛ اندراج node بدلنے تک رہتا ہے اور پھر خاموشی سے غائب ہو جاتا ہے۔
پھر ہر endpoint ثابت کریں۔ registry گاہک کو الگ تصدیقی خدمت اور الگ blob ذخیرہ دے سکتا ہے۔ manifest تک پہنچنا تہوں کے بارے میں تقریباً کچھ ثابت نہیں کرتا۔ آخر میں TLS اور اجازت مکمل کریں: registry کے نام کے لیے درست اور معاون node ترتیب سے قابل اعتماد certificate، نیز اس repository کو پڑھنے تک محدود کھینچنے کی شناخت۔
اس node پر جانچیں جسے ہاتھ سے ٹھیک نہیں کیا
اصل امتحان موزوں node پر نئی کھینچ اور تمام تہوں کی مکمل ڈاؤن لوڈ ہے، بہتر ہو کہ scale یا تبدیلی سے بنایا گیا node ہو۔ یہ ان تمام pool کو ڈھانپتا ہے جو workload رکھ سکتے ہیں، بھولے ہوئے بھی۔ ایک node پر ہاتھ کی مرمت deployment ماڈل نہیں، اور اگلا autoscale واقعہ خلا ڈھونڈ لے گا۔
کلستر کو دوسرے VNet میں دوبارہ بنانا راستہ بدل سکتا ہے، لیکن یہ پہلا تشخیصی قدم نہیں، آخری تدبیر ہے۔ منتقلی تجویز کرنے سے پہلے موجودہ node نیٹ ورک کا موازنہ مطلوبہ نجی راستے اور معاون AKS نیٹ ورک کنٹرول سے کریں، اور آغاز کے بعد application کنیکٹیویٹی کو الگ جانچ رکھیں: pod کا backend سے بات کرنا node کے image ڈاؤن لوڈ سے مختلف جانچ ہے۔