minikube സ്വകാര്യ API-യിൽ എത്തുന്നില്ലേ? ആദ്യം ഡ്രൈവർ പരിശോധിക്കുക
ഹോസ്റ്റ്, നോഡ്, Pod എന്നിവയ്ക്ക് ഓരോന്നിനും സ്വന്തം റൂട്ടുകളും സ്വന്തം resolver-ഉം ഉണ്ട്. ഡ്രൈവർ പേരിടുക, അതേ endpoint മൂന്നിൽ നിന്നും പരിശോധിക്കുക, തുടർന്ന് പരാജയപ്പെട്ട context ശരിയാക്കുക.
ഒരു സ്വകാര്യ API നിങ്ങളുടെ ലാപ്ടോപ്പിൽ നിന്ന് മറുപടി നൽകുന്നു, minikube-ലെ Pod അതിൽ എത്തുന്നില്ല. ഹോസ്റ്റിൽ എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് സജീവ പ്രൊഫൈലിന് പിന്നിലുള്ള ഡ്രൈവർ പേരിടുക, കാരണം ഈ ഒരു വസ്തുത മാത്രമാണ് അഭ്യർത്ഥന യഥാർത്ഥത്തിൽ ഏത് നെറ്റ്വർക്കിൽ നിന്ന് പുറത്തുപോകുന്നു എന്നത് തീരുമാനിക്കുന്നത്. തുടർന്ന് അതേ endpoint ഹോസ്റ്റിൽ നിന്നും, നോഡിൽ നിന്നും, Pod-ൽ നിന്നും പരിശോധിക്കുക. ആ മൂന്നിൽ ഒന്ന് മാത്രമാണ് പരാജയപ്പെട്ട കാര്യം, തെറ്റായ ഊഹം ഒരു ഉച്ചയ്ക്ക് ശേഷം പാഴാക്കും.
ഘട്ടം 0: ഡ്രൈവറും ഉറവിടവും പേരിടുക
ഏത് പ്രൊഫൈലാണ് സജീവം, അത് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് minikube-നോട് ചോദിക്കുക. കണ്ടെയ്നർ ഡ്രൈവർ നോഡിനെ നിങ്ങളുടെ മെഷീനിലെ ഒരു കണ്ടെയ്നറിൽ വയ്ക്കുന്നു, VM ഡ്രൈവർ അതിനെ ഒരു വെർച്വൽ മെഷീനിൽ വയ്ക്കുന്നു, റിമോട്ട് ഡ്രൈവർ അതിനെ പൂർണ്ണമായി വേറെയെവിടെയോ വയ്ക്കുന്നു.
minikube profile list
minikube status
kubectl config current-contextഅതിൽ നിന്ന് അഭ്യർത്ഥന എവിടെ നിന്ന് വരുന്നു എന്ന് എഴുതുക. ആരുടെ resolver, ഏത് റൂട്ടുകൾ പ്രധാനമാണ് എന്നത് മറുപടി തീരുമാനിക്കുന്നു, അത് എപ്പോഴും ഹോസ്റ്റിന്റേതല്ല. ഒരേ ലാപ്ടോപ്പിലെ രണ്ട് പ്രൊഫൈലുകൾ ഒരേ URL-ന് തീർത്തും വ്യത്യസ്തമായി പ്രവർത്തിക്കാം.
| Context | What has to work |
|---|---|
| Host process | Host resolver and host route to the private destination |
| minikube node | The node's own resolver and its outbound path |
| Pod | Pod DNS through cluster services plus the cluster network path |
ഘട്ടം 1: അതേ endpoint മൂന്ന് തവണ പരിശോധിക്കുക
ഒരു നിരുപദ്രവകരമായ endpoint ഉപയോഗിക്കുക, മൂന്ന് പരീക്ഷണങ്ങളിലും ഹോസ്റ്റ്നെയിം, പോർട്ട്, വിലാസ കുടുംബം എന്നിവ ഒരേപോലെ നിലനിർത്തുക. ഇവയിലേതെങ്കിലും റണ്ണുകൾക്കിടയിൽ മാറ്റിയാൽ ഫലങ്ങൾ താരതമ്യപ്പെടുത്താനാവില്ല.
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
minikube ssh -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/healthനോഡിന്റെ വിജയകരമായ image pull സ്വകാര്യ ഹോസ്റ്റിനുള്ള പേര് നിർണ്ണയത്തെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. വിജയകരമായ പൊതു അഭ്യർത്ഥന ഇനിയും കുറച്ചേ തെളിയിക്കുന്നുള്ളൂ. ഫലങ്ങൾ context അനുസരിച്ച് വേർതിരിച്ചു വയ്ക്കുക, കാരണം മൂന്ന് വരികളിലെ മാതൃക രോഗനിർണ്ണയമാണ്, ഒറ്റ പരാജയം ഒരു സൂചനയാണ്.
ഹോസ്റ്റ് വരിയും പരാജയപ്പെട്ടാൽ നിർത്തുക. നിങ്ങൾക്ക് ഹോസ്റ്റ് നെറ്റ്വർക്ക് പ്രശ്നമുണ്ട്, ക്ലസ്റ്റർ ശ്രദ്ധ തിരിക്കുന്ന കാര്യമാണ്.
ഘട്ടം 2: ഹോസ്റ്റിന്റെ ക്ലസ്റ്റർ വഴി സംരക്ഷിക്കുക
ആളുകൾ മറക്കുന്ന രണ്ടാമത്തെ ദിശയുണ്ട്: ഹോസ്റ്റ് ക്ലസ്റ്ററിന്റെ സ്വന്തം API-യിലേക്കും സേവനങ്ങളിലേക്കും എത്തിക്കൊണ്ടിരിക്കണം. ഒരു VPN ക്ലയന്റ്, minikube തന്റെ നോഡ് നെറ്റ്വർക്ക്, സേവന ശ്രേണി, pod ശ്രേണി എന്നിവയ്ക്ക് ഉപയോഗിക്കുന്ന prefixes-മായി മത്സരിക്കുന്ന റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യാം.
അങ്ങനെ സംഭവിക്കുമ്പോൾ ലക്ഷണം ആശയക്കുഴപ്പമുള്ളതാണ്, കാരണം ടണൽ പ്രവർത്തിക്കുന്നു, kubectl പ്രതികരിക്കുന്നത് നിർത്തുന്നു അല്ലെങ്കിൽ NodePort കണക്ഷനുകൾ നിരസിക്കുന്നു. ഇത് ക്ലസ്റ്റർ തകരാറുപോലെ തോന്നുന്നു, യഥാർത്ഥത്തിൽ ലാപ്ടോപ്പിന്റെ റൂട്ടിംഗ് തകരാറാണ്.
ടണലിനെ മറ്റെന്തിനെങ്കിലും കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് ഹോസ്റ്റിന്റെ റൂട്ടിംഗ് പട്ടിക minikube-ന്റെ ശ്രേണികളുമായി താരതമ്യപ്പെടുത്തുക. ഓവർലാപ്പ് സാധാരണയായി ക്ലസ്റ്റർ സ്വന്തമെന്ന് കരുതുന്ന prefix-ന് ടണൽ ഇന്റർഫേസിലേക്ക് ചൂണ്ടുന്ന കൂടുതൽ നിർദ്ദിഷ്ട റൂട്ടായി കാണപ്പെടുന്നു.
ഘട്ടം 3: VPN ഓഫ് ചെയ്യാതെ ഓവർലാപ്പ് പരിഹരിക്കുക
minikube-ന്റെ സ്വന്തം VPN, proxy കൈപ്പുസ്തകം ഈ സംഘർഷങ്ങൾ ചർച്ച ചെയ്യുന്നു, അതിന്റെ ഉദാഹരണ ശ്രേണികളെ പരിശോധിക്കേണ്ട കാര്യങ്ങളായി കണക്കാക്കുന്നു, സാർവ്വലൗകിക പട്ടികയായി എടുക്കുന്നില്ല. അത് നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ ഉള്ള പ്രൊഫൈലിനൊപ്പം വായിക്കുക.
യഥാർത്ഥ ഓവർലാപ്പ് ഉള്ളിടത്ത്, പിന്തുണയ്ക്കുന്ന ഉത്തരം ഓവർലാപ്പില്ലാത്ത ശ്രേണിയോ VPN ഉടമ അംഗീകരിച്ച ബോധപൂർവ്വം ഉണ്ടാക്കിയ പ്രാദേശിക ആക്സസ് നയമോ ആണ്. സേവന ശ്രേണി മാറ്റുന്നത് pod ശ്രേണി മാറ്റുന്നതിന് തുല്യമല്ല, രണ്ടും നോഡ് നെറ്റ്വർക്ക് മാറ്റുന്നതിന് തുല്യമല്ല.
പ്രാദേശിക ക്ലസ്റ്റർ പ്രവർത്തിക്കാൻ കോർപ്പറേറ്റ് ടണൽ ഓഫ് ചെയ്യുന്നത് ഒരു ഷോർട്ട്കട്ടുമല്ല; അത് മറ്റാരോ എടുക്കേണ്ട നയ തീരുമാനമാണ്. ബാക്കിയുള്ളവർ വീട്ടിലേക്ക് പോയതിന് ശേഷം നിശ്ശബ്ദമായി ചെയ്യുന്നതിന് പകരം അത് ആ വ്യക്തിയുടെ അടുത്ത് കൊണ്ടുപോകുക. നിങ്ങൾ ഇത് നേരത്തെ ചെയ്തിട്ടുണ്ടെങ്കിൽ, ചോദിക്കുന്നതിന് മുമ്പ് അത് തിരികെ വയ്ക്കുക.
ഘട്ടം 4: proxy, DNS, പരാജയത്തിന്റെ നാല് രൂപങ്ങൾ വേർതിരിക്കുക
proxy ആവശ്യമാണെങ്കിൽ ഏത് context-നാണ് അത് വേണ്ടതെന്ന് കണ്ടെത്തുക. ഹോസ്റ്റിലെ ബ്രൗസർ ക്രമീകരണം നോഡിനുള്ളിലെ ഒരു പ്രക്രിയ കോൺഫിഗർ ചെയ്യുന്നില്ല, Pod-ന് പരിസ്ഥിതി ചരങ്ങൾ അല്ലെങ്കിൽ ക്ലസ്റ്റർ തലത്തിലുള്ള proxy കോൺഫിഗറേഷൻ വേണം.
തുടർന്ന് പരാജയത്തെ വിവരിക്കുന്നതിന് പകരം തരംതിരിക്കുക. പരിഹരിക്കപ്പെടാത്ത പേര് DNS. പരിഹരിക്കപ്പെട്ട് കണക്ഷൻ നിരസിക്കുന്ന പേര് റൂട്ടിംഗ് അല്ലെങ്കിൽ listener. സ്ഥാപിക്കപ്പെട്ട് ഐഡന്റിറ്റിയിൽ പരാജയപ്പെടുന്ന കണക്ഷൻ TLS. പിശക് body സഹിതം വിജയകരമായ കണക്ഷൻ ആപ്ലിക്കേഷൻ.
ആ നാലിൽ ഓരോന്നും വ്യത്യസ്ത പരിഹാരവുമായി ബന്ധപ്പെട്ടതാണ്, ഒന്ന് മാത്രമാണ് VPN-നെക്കുറിച്ച്. ഓരോ context-ലും ഏതാണ് നിരീക്ഷിച്ചതെന്ന് എഴുതുക, അടുത്ത വ്യക്തിക്ക് കഥയ്ക്ക് പകരം തെളിവുകൾ പാരമ്പര്യമായി ലഭിക്കും.