ستاسو لپ ټاپ image پرته له ستونزې راوړي، خو pod په ImagePullBackOff کې پاتې کیږي. د کارپوریټ VPN کلاینټ د sidecar په توګه د چلولو وړاندیز به مرسته ونه کړي، ځکه راوړنه ستاسو له کانټینر مخکې پیښیږي: kubelet د node له container runtime څخه غواړي image راوړي، او runtime د node د شبکې namespace کاروي.

د کارونو ترتیب طبقه ټاکي

لومړی د نوم حل، بیا اړیکه، تصدیق، د طبقو ډاونلوډ، او بیا کانټینر پیل کیږي. هر هغه څه چې pod د VPN سره کوي له دې وروسته پیښیږي، نو په کلسټر کې روان تونل د راوړنې ثبوت نه دی.

نو په cache کې image یو باوري درواغ دی: هغه node چې اونۍ مخکې image راوړی وي هغه ته دوام ورکوي، deployment روغ ښکاري، او تېروتنه یوازې هغه وخت ښکاري چې scheduler په نوي node replica کېږدي. scale-up یا د node بدلون لامل نه دی، هڅوونکی دی.

درې شرطونه سمون ټاکي

لاسرسی په routing، د نومونو حل او د endpoint په ټولګه ولاړ دی. که د node subnet نشي کولی د registry شبکې ته route وکړي، هیڅ credential به مرسته ونه کړي. که نوم د node DNS له لارې نه حل شي، اړیکه نه پیل کیږي. که یوازې manifest ورسي او blob نه، راوړنه په مینځ کې ناکامه کیږي.

ConditionTypical symptomWhere to look
Node subnet has no route to the registry networkTimeout, no connectionEffective routes on the node NIC, gateway transit, return path on-premises
Node resolver cannot see the private zoneName resolution failure in eventsVNet DNS settings and the resolver the node actually uses
Only the manifest endpoint is reachableAuth succeeds, layer download failsEvery hostname the registry hands out during the pull
TLS or identity is wrongCertificate error, 401 or 403Server 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 credential ورکوي؛ دا لاره نه نصبوي، resolver نه بدلوي او نا باوري certificate نه اعتبار کوي. که پیښه وایي راوړنه اجازه نه درلوده، د هویت حد وګورئ؛ که وایي اړیکه پای ته ورسیده، credential اړوند نه دی.

د Kubernetes د imageونو اسناد د راوړنې چلند او د خصوصي registry د credential سرچینه ده، او د شبکې د بدلون مخکې یو ځل لوستل ګټور دي، ځکه چې د تصدیق او انتقال تر منځ پوله روښانه کوي.

د 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 یا بدلون له مخې جوړ شوی وي. دا ټول هغه pool پوښي چې workload کېدای شي ځای پرځای کړي، هیر شوي هم. په یو node لاسي سمون د خپرولو ماډل نه دی، او بل autoscale پیښه به تشه پیدا کړي.

په بل VNet کې د کلسټر بیا جوړول لاره بدلولی شي، خو دا لومړی تشخیصي ګام نه دی، وروستی چاره ده. د لېږد وړاندیز مخکې اوسنی node شبکه د اړین خصوصي لارې او د AKS د ملاتړ شوو شبکې کنټرولونو سره پرتله کړئ، او له پیل وروسته د اپلیکیشن اړیکه جلا کتنه وساتئ: د pod خبرې له backend سره د node د image ډاونلوډ څخه بېله کتنه ده.

اړوندې مقالې