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