VPN पछाडिको निजी registry बाट AKS ले इमेज तान्न सक्दैन
kubelet ले नोडको नेटवर्कबाट तान्छ, pod को VPN बाट होइन। नोड रुट, नोड DNS, तान्ने क्रमले छुने प्रत्येक endpoint, त्यसपछि TLS र पहिचानका आधारमा निर्णय गर्नुहोस्।
तपाईंको ल्यापटपले इमेज सजिलै तान्छ, तर pod ImagePullBackOff मा रहन्छ। कर्पोरेट VPN क्लाइन्ट sidecar का रूपमा चलाउने सुझावले काम गर्दैन, किनकि तान्ने काम तपाईंको कन्टेनर अघि नै हुन्छ: kubelet ले नोडको container runtime लाई इमेज ल्याउन भन्छ र runtime ले नोडको नेटवर्क namespace प्रयोग गर्छ।
कामको क्रमले तह निर्धारण गर्छ
पहिले नाम समाधान, त्यसपछि जडान, प्रमाणीकरण, तहहरूको डाउनलोड र त्यसपछि मात्र कन्टेनर सुरु हुन्छ। pod ले VPN सँग गर्ने सबै यसपछि हुन्छ, त्यसैले क्लस्टरमा चल्ने टनेल तान्ने प्रमाण होइन।
त्यसैले cache को इमेज विश्वासयोग्य झुट हो: हप्ता अघि इमेज तानेको नोडले दिइरहन्छ, deployment स्वस्थ देखिन्छ, र नयाँ नोडमा replica राख्दा मात्र त्रुटि देखिन्छ। scale-up वा नोड परिवर्तन कारण होइन, ट्रिगर हो।
तीन सर्तले सुधार निर्धारण गर्छन्
पहुँच राउटिङ, नाम समाधान र endpoint को समूहमा टिकेको हुन्छ। नोडको subnet registry नेटवर्कमा राउट गर्न सक्दैन भने कुनै credential ले सहयोग गर्दैन। नोडको 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 व्यवस्था दिँदैन, र एकतर्फी रुट काम गर्ने रुट होइन। नोडलाई VPN gateway हुँदै समर्थित बाटो चाहिन्छ र registry पक्षलाई नोडको subnet मा फर्कने रुट चाहिन्छ।
समाधान छान्नु अघि त्रुटि पढ्नुहोस्
pod का घटना र त्यो पुगेको नोडबाट सुरु गर्नुहोस्, तपाईंका वास्तविक नामसँग: kubectl describe pod app-example -n team-example र kubectl get pod app-example -n team-example -o wide। घटनाको पाठले नखुलेको hostname र timeout, certificate अस्वीकार र हराएको इमेज, र अनुमति असफलता सबैलाई छुट्याउँछ।
प्रमाणीकरण सबैभन्दा बढी अनुमान गरिएको उपाय हो। imagePullSecret ले runtime लाई registry credential दिन्छ; यसले रुट राख्दैन, resolver बदल्दैन र अविश्वसनीय certificate लाई वैध बनाउँदैन। घटनाले तान्ने अनुमति थिएन भन्यो भने पहिचानको दायरा हेर्नुहोस्; जडान timeout भयो भन्यो भने credential अप्रासंगिक छ।
Kubernetes इमेज कागजात तान्ने व्यवहार र निजी registry credential को स्रोत हो, र नेटवर्क बदल्नु अघि एक पटक पढ्न लायक छ, किनकि यसले प्रमाणीकरण र ढुवानीबीचको सीमा स्पष्ट पार्छ।
pod मुनि बाटो बनाउनुहोस्
यही क्रममा काम गर्नुहोस्। पहिले नोड नेटवर्क राउट गर्नुहोस्: subnet सँग registry नेटवर्क जाने समर्थित बाटो छ कि जाँच्नुहोस्, नोडका प्रभावकारी रुट, दुवै छेउका सुरक्षा नियम र registry पक्षको फर्कने रुट हेर्नुहोस्।
त्यसपछि नोडको सन्दर्भबाट नाम समाधान गर्नुहोस्। नोडको resolver pod को DNS सेटिङ होइन, र pod भित्रको सफलता host runtime को प्रमाण होइन। स्थायी hosts प्रविष्टिको सट्टा व्यवस्थित निजी DNS प्रयोग गर्नुहोस्; प्रविष्टि नोड बदलिएसम्म रहन्छ र त्यसपछि चुपचाप हराउँछ।
त्यसपछि प्रत्येक endpoint प्रमाणित गर्नुहोस्। registry ले ग्राहकलाई छुट्टै प्रमाणीकरण सेवा र छुट्टै blob भण्डारण दिन सक्छ। manifest पुग्नुले तहहरूबारे लगभग केही प्रमाणित गर्दैन। अन्तमा TLS र अनुमति पूरा गर्नुहोस्: registry नामका लागि वैध र समर्थित नोड कन्फिगरेसनबाट विश्वसनीय certificate, साथै त्यो repository पढ्न सीमित तान्ने पहिचान।
हातले नसुधारेको नोडमा जाँच्नुहोस्
असली परीक्षण योग्य नोडमा नयाँ तान्ने र सबै तहको पूर्ण डाउनलोड हो, सम्भव भए scale वा परिवर्तनबाट बनेको नोडमा। यसले workload राख्न सक्ने सबै pool समेट्छ, बिर्सिएकाहरू पनि। एक नोडमा हातले गरेको सुधार deployment मोडेल होइन, र अर्को autoscale घटनाले खाली ठाउँ भेट्टाउनेछ।
अर्को VNet मा क्लस्टर पुनः बनाउनुले बाटो बदल्न सक्छ, तर त्यो पहिलो निदान चरण होइन, अन्तिम उपाय हो। स्थानान्तरण सुझाउनु अघि हालको नोड नेटवर्कलाई आवश्यक निजी रुट र समर्थित AKS नेटवर्क नियन्त्रणसँग तुलना गर्नुहोस्, र सुरु भएपछिको एप कनेक्टिभिटीलाई छुट्टै जाँचका रूपमा राख्नुहोस्: pod र backend बीचको कुराकानी नोडको इमेज डाउनलोडभन्दा फरक जाँच हो।