तुमचा लॅपटॉप इमेज अडचणीशिवाय खेचतो, पण pod ImagePullBackOff मध्ये राहतो. कॉर्पोरेट VPN क्लायंट sidecar म्हणून चालवण्याचा सल्ला उपयोगी नाही, कारण खेचणी तुमच्या कंटेनरपूर्वीच होते: kubelet नोडवरील container runtime ला इमेज आणायला सांगतो आणि runtime नोडचे नेटवर्क namespace वापरते.

क्रियांचा क्रम थर ठरवतो

आधी नावाचे निराकरण, नंतर जोडणी, प्रमाणीकरण, थरांचे डाउनलोड आणि मगच कंटेनर सुरू होतो. pod चे VPN वरील सर्व यानंतर घडते, म्हणून क्लस्टरमध्ये चालणारे टनेल खेचणीचा पुरावा नाही.

म्हणून cache मधील इमेज पटवणारे खोटे आहे: आठवड्यांपूर्वी इमेज खेचलेला नोड ती देत राहतो, deployment निरोगी दिसतो, आणि नवीन नोडवर replica ठेवल्यावरच अपयश दिसते. scale-up किंवा नोड बदलणे हे कारण नाही, ट्रिगर आहे.

तीन अटी दुरुस्ती ठरवतात

प्रवेशयोग्यता राउटिंग, नाव निराकरण आणि endpoint च्या संचावर अवलंबून आहे. नोडचे subnet registry नेटवर्ककडे राउट करू शकत नसेल तर कोणतेही credential उपयोगी नाही. नोडच्या 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 रचना देत नाही, आणि एका दिशेचा रूट कार्यरत रूट नसतो. नोडला 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 शी बोलणे नोडच्या इमेज डाउनलोडपेक्षा वेगळी तपासणी आहे.

संबंधित लेख