VPN-ന് പിന്നിലുള്ള സ്വകാര്യ registry-യിൽ നിന്ന് AKS-ന് ഇമേജ് എടുക്കാനാവില്ല
kubelet node-ന്റെ നെറ്റ്വർക്കിലൂടെയാണ് എടുക്കുന്നത്, pod-ന്റെ VPN-യിലൂടെയല്ല. node റൂട്ടുകൾ, node DNS, എടുക്കൽ തൊടുന്ന ഓരോ endpoint, പിന്നീട് TLS-ഉം ഐഡന്റിറ്റിയും കൊണ്ട് തീരുമാനിക്കുക.
നിങ്ങളുടെ ലാപ്ടോപ്പ് ഇമേജ് കൃത്യമായി എടുക്കുന്നു, പക്ഷേ pod ImagePullBackOff-ൽ നിൽക്കുന്നു. കോർപ്പറേറ്റ് VPN ക്ലയന്റ് sidecar ആയി ഓടിക്കാമെന്ന നിർദ്ദേശം സഹായിക്കില്ല, കാരണം നിങ്ങളുടെ കണ്ടെയ്നർ ഉണ്ടാകുന്നതിന് മുൻപേ എടുക്കൽ നടക്കുന്നു: node-ലെ container runtime-നോട് kubelet ഇമേജ് കൊണ്ടുവരാൻ ആവശ്യപ്പെടുന്നു, runtime node-ന്റെ നെറ്റ്വർക്ക് namespace ഉപയോഗിക്കുന്നു.
പ്രവർത്തനങ്ങളുടെ ക്രമമാണ് പാളി തീരുമാനിക്കുന്നത്
ആദ്യം പേരിന്റെ പരിഹാരം, പിന്നെ കണക്ഷൻ, പ്രാമാണീകരണം, പാളികളുടെ ഡൗൺലോഡ്, അതിനുശേഷം മാത്രം കണ്ടെയ്നർ ആരംഭിക്കുന്നു. pod VPN-കൊണ്ട് ചെയ്യുന്നതെല്ലാം ഇതിനുശേഷമാണ്, അതിനാൽ ക്ലസ്റ്ററിൽ പ്രവർത്തിക്കുന്ന ടണൽ എടുക്കലിന്റെ തെളിവല്ല.
അതുകൊണ്ടാണ് cache-ലുള്ള ഇമേജ് ഇത്ര വിശ്വസനീയമായ കള്ളം: ആഴ്ചകൾക്ക് മുൻപ് ഇമേജ് എടുത്ത 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 നിരസിക്കലിനെ ഇമേജ് ഇല്ലായ്മയിൽ നിന്നും, അനുമതി പരാജയത്തെ എല്ലാറ്റിൽ നിന്നും വേർതിരിക്കുന്നു.
പ്രാമാണീകരണമാണ് ഏറ്റവും അധികം വിലയിരുത്തപ്പെടുന്ന ഉപാധി. imagePullSecret runtime-ന് registry credential നൽകുന്നു; അത് റൂട്ട് ഇടുന്നില്ല, resolver മാറ്റുന്നില്ല, വിശ്വസനീയമല്ലാത്ത certificate-നെ സാധുവാക്കുന്നുമില്ല. എടുക്കൽ അനുവദിക്കപ്പെട്ടില്ലെന്ന് ഇവന്റ് പറഞ്ഞാൽ ഐഡന്റിറ്റിയുടെ പരിധി നോക്കുക; കണക്ഷൻ സമയം കഴിഞ്ഞു എന്ന് പറഞ്ഞാൽ credential പ്രസക്തമല്ല.
Kubernetes ഇമേജ് ഡോക്യുമെന്റേഷൻ എടുക്കലിന്റെ സ്വഭാവത്തിനും സ്വകാര്യ 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-ൽ ക്ലസ്റ്റർ പുനർനിർമ്മിക്കുന്നത് വഴി മാറ്റാം, പക്ഷേ അത് ആദ്യ രോഗനിർണയ ഘട്ടമല്ല, അവസാന മാർഗമാണ്. മൈഗ്രേഷൻ നിർദ്ദേശിക്കുന്നതിന് മുൻപ് നിലവിലുള്ള node നെറ്റ്വർക്കിനെ ആവശ്യമായ സ്വകാര്യ റൂട്ടുമായും പിന്തുണയുള്ള AKS നെറ്റ്വർക്ക് നിയന്ത്രണങ്ങളുമായും താരതമ്യം ചെയ്യുക, തുടക്കത്തിനുശേഷമുള്ള ആപ്പ് കണക്ടിവിറ്റി വേറിട്ട പരിശോധനയായി നിലനിർത്തുക: pod-ന്റെ backend-മായ സംഭാഷണം node-ന്റെ ഇമേജ് ഡൗൺലോഡിൽ നിന്ന് വ്യത്യസ്ത പരിശോധനയാണ്.