VPN પાછળની ખાનગી registry માંથી AKS ઇમેજ ખેંચી શકતું નથી
kubelet નોડ નેટવર્ક દ્વારા ખેંચે છે, pod ના VPN દ્વારા નહીં. નોડ રૂટ, નોડ DNS, ખેંચાણ સ્પર્શે છે તે દરેક endpoint, પછી TLS અને ઓળખ દ્વારા નક્કી કરો.
તમારો લેપટોપ ઇમેજ સરળતાથી ખેંચે છે, પણ pod ImagePullBackOff માં રહે છે, અને કોઈ કોર્પોરેટ VPN ક્લાયન્ટને sidecar તરીકે ચલાવવાનું સૂચવે છે. તે કામ નહીં આવે, કારણ કે ખેંચાણ તમારા કન્ટેનર પહેલાં થાય છે: kubelet નોડ પરના container runtime ને ઇમેજ લાવવા કહે છે, અને runtime નોડનું નેટવર્ક namespace વાપરે છે. workload ની અંદરનું VPN તે માર્ગ માટે કોઈ રૂટ આપી શકતું નથી, અને તેની પોતાની સહાયક ઇમેજ પણ પહેલાં ખેંચવી પડે.
ક્રિયાઓનો ક્રમ સ્તર નક્કી કરે છે
પહેલાં ઇમેજનું નામ ઉકેલાય છે. kubelet runtime દ્વારા registry નું નામ ઉકેલે છે, જોડાય છે, પ્રમાણિત કરે છે, સ્તરો ડાઉનલોડ કરે છે અને પછી જ કન્ટેનર શરૂ કરે છે. pod VPN સાથે જે કંઈ કરે છે તે આ ક્રમ પછી થાય છે, તેથી ક્લસ્ટરમાં ચાલતું ટનલ ખેંચાણનો પુરાવો નથી.
તેથી cache કરેલી ઇમેજ એટલી વિશ્વાસપાત્ર જૂઠ છે. અઠવાડિયા પહેલાં ઇમેજ ખેંચેલો નોડ તેને આપવાનું ચાલુ રાખે છે, deployment સ્વસ્થ દેખાય છે, અને નિષ્ફળતા ત્યારે જ દેખાય છે જ્યારે scheduler નવા નોડ પર replica મૂકે છે. જો ઘટનાઓની સમયરેખામાં scale-up, નોડ બદલી કે pool અપગ્રેડ હોય, તો તેમને કારણ નહીં પણ ટ્રિગર ગણો.
ત્રણ શરતો સુધારો નક્કી કરે છે
મેનેજ્ડ node pool થી ખાનગી registry સુધીની પહોંચ રૂટિંગ, નામ ઉકેલવા અને endpoint ના સમૂહ પર આવે છે. જો નોડનું subnet registry નેટવર્ક તરફ રૂટ કરી શકતું ન હોય, તો કોઈ credential મદદ કરશે નહીં. જો રૂટ કરે પણ નોડના DNS માર્ગે registry નું નામ ઉકેલી ન શકે, તો જોડાણ ક્યારેય શરૂ નહીં થાય. જો બંને manifest endpoint માટે કામ કરે પણ registry જે blob endpoint તરફ મોકલે તેના માટે નહીં, તો ખેંચાણ અડધે નિષ્ફળ જાય.
| 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 ના credentials આપે છે; તે રૂટ સ્થાપિત કરતું નથી, નોડનું resolver બદલતું નથી અને અવિશ્વસનીય certificate ને માન્ય બનાવતું નથી. જો ઘટના કહે કે ખેંચાણ અધિકૃત ન હતું, તો ઓળખનું વ્યાપ જુઓ. જો કહે કે જોડાણ સમાપ્ત થયું, તો credentials અસંબંધિત છે.
Kubernetes ઇમેજ દસ્તાવેજીકરણ એ ખેંચાણના વર્તન અને ખાનગી registry ના credentials માટેનો સંદર્ભ છે, અને નેટવર્ક બદલતા પહેલાં એક વાર વાંચવું યોગ્ય છે, કારણ કે તે પ્રમાણીકરણ અને પરિવહન વચ્ચેની સીમા સ્પષ્ટ કરે છે.
pod ની નીચે માર્ગ બનાવો
આ ક્રમમાં કામ કરો, કારણ કે અગાઉનું ન ટકે ત્યાં સુધી દરેક પગલું અર્થહીન છે. પહેલાં નોડનું નેટવર્ક રૂટ કરો: ખાતરી કરો કે નોડના subnet પાસે registry નેટવર્ક તરફ સમર્થિત માર્ગ છે, નોડ પરના અસરકારક રૂટ, બંને છેડાના સુરક્ષા નિયમો અને registry બાજુનો પરત રૂટ તપાસો.
પછી નોડના સંદર્ભમાંથી નામ ઉકેલો. નોડનું resolver એ pod નું DNS રૂપરેખાંકન નથી, અને pod ની અંદરની સફળતા host runtime નો પુરાવો નથી. કાયમી hosts એન્ટ્રીને બદલે મેનેજ્ડ ખાનગી DNS વાપરો; એન્ટ્રી નોડ બદલાય ત્યાં સુધી રહે છે અને પછી શાંતિથી અદૃશ્ય થાય છે.
પછી દરેક endpoint સાબિત કરો. registry ક્લાયન્ટને અલગ પ્રમાણીકરણ સેવા અને અલગ blob સંગ્રહ આપી શકે છે. manifest endpoint સુધી પહોંચવું સ્તરો વિશે લગભગ કંઈ સાબિત કરતું નથી. અંતે TLS અને અધિકૃતિ પૂર્ણ કરો: registry ના નામ માટે માન્ય અને સમર્થિત નોડ રૂપરેખાંકન દ્વારા વિશ્વસનીય certificate, સાથે તે repository વાંચવા પૂરતી મર્યાદિત ખેંચાણ ઓળખ.
હાથે સુધારેલા ન હોય તેવા નોડ પર ચકાસો
જે પરીક્ષણ મહત્વનું છે તે યોગ્ય નોડ પર નવું ખેંચાણ અને બધા સ્તરોનું સંપૂર્ણ ડાઉનલોડ છે, શ્રેષ્ઠ તો scale અથવા બદલી દ્વારા બનેલો નોડ. તે બધા pool ને આવરી લે છે જે workload મૂકી શકે, ભૂલી ગયેલા પણ. એક નોડ પર હાથે કરેલો સુધારો deployment મોડેલ નથી, અને આગળની autoscale ઘટના ખાલી જગ્યા શોધી કાઢશે.
બીજા VNet માં ક્લસ્ટર ફરી બનાવવાથી માર્ગ બદલાઈ શકે, પણ તે પ્રથમ નિદાન પગલું નહીં, અંતિમ ઉપાય છે. સ્થળાંતર સૂચવતા પહેલાં હાલના નોડ નેટવર્કને જરૂરી ખાનગી રૂટ અને સમર્થિત AKS નેટવર્ક નિયંત્રણો સાથે સરખાવો, અને શરૂઆત પછીની એપ્લિકેશન કનેક્ટિવિટીને અલગ ચકાસણી તરીકે રાખો: pod નું તેના backend સાથે વાત કરવું અને નોડનું ઇમેજ ડાઉનલોડ કરવું એ બે જુદી ચકાસણી છે.