VPN వెనుక ఉన్న ప్రైవేట్ registry నుండి AKS 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తో చేసేదంతా దీని తర్వాతే, కాబట్టి clusterలో పనిచేసే tunnel లాగడానికి సాక్ష్యం కాదు.
అందుకే cacheలోని image చాలా నమ్మదగిన అబద్ధం: వారాల క్రితం image లాగిన node దాన్ని ఇస్తూనే ఉంటుంది, deployment ఆరోగ్యంగా కనిపిస్తుంది, కొత్త nodeపై replica పెట్టినప్పుడే వైఫల్యం కనిపిస్తుంది. scale-up లేదా node మార్పు కారణం కాదు, ట్రిగ్గర్.
మూడు షరతులు మరమ్మతును నిర్ణయిస్తాయి
ప్రాప్యత రూటింగ్, పేరు పరిష్కారం, endpoint సమితిపై ఆధారపడి ఉంటుంది. node subnet registry నెట్‌వర్క్‌కు రూట్ చేయలేకపోతే ఏ 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 credential ఇస్తుంది; అది రూట్ పెట్టదు, resolver మార్చదు, నమ్మదగని certificateను చెల్లుబాటు చేయదు. ఈవెంట్ లాగడం అనుమతి లేదని చెబితే గుర్తింపు పరిధిని చూడండి; కనెక్షన్ timeout అయిందని చెబితే credential పనికిరాదు.
Kubernetes image డాక్యుమెంటేషన్ లాగడం ప్రవర్తన మరియు ప్రైవేట్ registry credentialలకు మూలం, నెట్‌వర్క్ మార్చే ముందు ఒకసారి చదవడం విలువైనది, ఎందుకంటే ఇది ధృవీకరణ మరియు రవాణా మధ్య సరిహద్దును స్పష్టం చేస్తుంది.
pod కింద మార్గం నిర్మించండి
ఈ క్రమంలో పని చేయండి. మొదట node నెట్‌వర్క్ రూట్ చేయండి: 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 అయితే మంచిది. ఇది workload ఉంచగల అన్ని poolలను కవర్ చేస్తుంది, మరచినవి సహా. ఒక nodeపై చేతి మరమ్మతు deployment నమూనా కాదు, తదుపరి autoscale సంఘటన ఖాళీని కనుగొంటుంది.
మరో VNetలో clusterను తిరిగి సృష్టించడం మార్గాన్ని మార్చవచ్చు, కానీ అది మొదటి నిర్ధారణ దశ కాదు, చివరి మార్గం. స్థానభ్రంశం ప్రతిపాదించే ముందు ప్రస్తుత node నెట్‌వర్క్‌ను అవసరమైన ప్రైవేట్ మార్గం మరియు మద్దతు ఉన్న AKS నెట్‌వర్క్ నియంత్రణలతో పోల్చండి, ప్రారంభం తర్వాత application కనెక్టివిటీని వేరు నిర్ధారణగా ఉంచండి: pod మరియు backend సంభాషణ node image డౌన్‌లోడ్ కంటే వేరు పరీక్ష.