സ്വകാര്യ GKE നോഡുകൾ kubectl ഏത് API ഉപയോഗിക്കുന്നു എന്ന് തീരുമാനിക്കുന്നില്ല

നോഡുകൾ സ്വകാര്യമാണ്, VPN അവയിലെത്തുന്നു, എന്നിട്ടും kubectl-ന് ക്ലസ്റ്ററുമായി സംസാരിക്കാനാകുന്നില്ല. ഈ രണ്ട് വസ്തുതകൾക്കും പരസ്പരം ബന്ധമില്ല. kubectl ഉപയോഗിക്കുന്ന വിലാസം ക്രെഡൻഷ്യലുകൾ എടുത്തപ്പോൾ kubeconfig-ൽ സൂക്ഷിച്ച സെർവർ URL-ൽ നിന്നാണ് വരുന്നത്, നിങ്ങൾ ചേർക്കുന്ന ഏത് റൂട്ടും അത് മാറ്റുന്നില്ല. അതേസമയം, kubectl എത്താൻ ശ്രമിക്കുന്നത് നോഡുകളല്ല.

അഞ്ച് പരിശോധനകൾ, പ്രധാനമായ ഏക മൂല്യത്തിൽ നിന്ന് തുടങ്ങുന്നു.

പരിശോധന 1: kubeconfig-ലെ സെർവർ URL വായിക്കുക

ക്രെഡൻഷ്യലുകൾ വീഴ്ത്താതെ എൻഡ്പോയിന്റ് പ്രിന്റ് ചെയ്യുക: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". ആ ഒരു സ്ട്രിംഗ് കൈലന്റ് ഒരു IP വിലാസത്തിലേക്കോ DNS നാമത്തിലേക്കോ നിങ്ങൾ ഉദ്ദേശിക്കാത്ത ബാഹ്യ വിലാസത്തിലേക്കോ ചൂണ്ടുന്നുണ്ടോ എന്ന് പറയുന്നു. ഈ അന്വേഷണത്തിലെ മറ്റെല്ലാം അതിൽ നിന്നാണ് ഉരുത്തിരിയുന്നത്.

URL നിങ്ങൾ കോൺഫിഗർ ചെയ്തെന്ന് കരുതിയ എൻഡ്പോയിന്റ് അല്ലെങ്കിൽ, ബാക്കി രോഗനിർണയം ശ്രദ്ധ തിരിക്കലാണ്.

പരിശോധന 2: URL-നെ എൻഡ്പോയിന്റ് തരവുമായി ചേർത്തുനിർത്തുക

നിലവിലെ GKE IP അടിസ്ഥാനമാക്കിയതും DNS അടിസ്ഥാനമാക്കിയതുമായ കൺട്രോൾ പ്ലെയിൻ ആക്സസ് പിന്തുണയ്ക്കുന്നു, നിങ്ങൾ എടുക്കുന്ന ക്രെഡൻഷ്യലുകൾ അവയിലൊന്ന് തിരഞ്ഞെടുക്കുന്നു. gcloud container clusters get-credentials NAME --location REGION --internal-ip ആന്തരിക IP എൻഡ്പോയിന്റ് എഴുതുന്നു, --dns-endpoint DNS അടിസ്ഥാനമാക്കിയ ആക്സസ് തിരഞ്ഞെടുക്കുന്നു. ഒരു ഫ്ലാഗും നെറ്റ്വർക്ക് പാത നൽകുന്നില്ല, ഇത് എടുക്കൽ കണക്റ്റിവിറ്റി ശരിയാക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നവരെ അമ്പരപ്പിക്കുന്നു. ബോധപൂർവം വീണ്ടും ഫെച്ച് ചെയ്തതിന് ശേഷം URL വീണ്ടും വായിക്കുക.

URL വീണ്ടും വായിക്കാതെ ഫ്ലാഗുകൾ മാറ്റുന്നതാണ് ലാപ്ടോപ്പ് രണ്ട് ക്ലസ്റ്ററുകളുടെ ക്രെഡൻഷ്യലുകളും ഒരു ആശയക്കുഴപ്പമുള്ള പിശകും പേറി അവസാനിക്കുന്ന വഴി.

അനുവദനീയ മെഷീൻ എൻട്രി ബാഹ്യ എൻഡ്പോയിന്റിലേക്ക് ആർക്ക് എത്താമെന്ന് നിർണ്ണയിക്കുന്നു, ആന്തരിക എൻഡ്പോയിന്റിന് ബാധകമല്ല. സ്വകാര്യ പാത പരീക്ഷിക്കാൻ അത് വിശാലമാക്കുന്നത് നിങ്ങളുടെ രോഗനിർണയമല്ല, എക്സ്പോഷർ മാറ്റുന്നു.

പരിശോധന 3: ആ എൻഡ്പോയിന്റിലേക്കുള്ള പാത തെളിയിക്കുക

URL ആന്തരിക IP ആണെങ്കിൽ, കൈലന്റ് യഥാർത്ഥത്തിൽ ഇരിക്കുന്ന നെറ്റ്വർക്കിൽ നിന്നുള്ള റൂട്ട്, അനുവദിച്ച ഉറവിട ശ്രേണി, ക്ലസ്റ്ററിന്റെ പ്രാദേശിക അല്ലെങ്കിൽ ആഗോള ആക്സസ് ക്രമീകരണം എന്നിവ പരിശോധിക്കുക. കൺട്രോൾ പ്ലെയിൻ ശ്രേണിയും നോഡ് സബ്നെറ്റും ഒരേ ലക്ഷ്യമല്ല, അതിനാൽ നോഡുകളിലേക്ക് പ്രവർത്തിക്കുന്ന റൂട്ട് എൻഡ്പോയിന്റിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. DNS അടിസ്ഥാനമാക്കിയ ആക്സസിന് പാത രേഖപ്പെടുത്തിയ Private Google Access ക്രമീകരണത്തോടെയുള്ള Google API കണക്റ്റിവിറ്റിയാണ്, തൊഴിലാളികളുടെ സബ്നെറ്റിലേക്കുള്ള റൂട്ടല്ല. kubectl-നെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് സാധാരണ TCP കണക്ഷൻ ഉപയോഗിച്ച് എൻഡ്പോയിന്റ് പരീക്ഷിക്കുക.

ടൈംഔട്ട് പാതയുടെ പ്രശ്നമാണ്. 403 നയത്തിന്റെ പ്രശ്നമാണ്. അവയ്ക്ക് ഒരേ പരിഹാരമില്ല.

പരിശോധന 4: ലോഗുകളും exec-ഉം API വിളികളിൽ നിന്ന് വേർതിരിക്കുക

സാധാരണ API അഭ്യർത്ഥനകൾ വിജയിക്കുകയും kubectl logs അല്ലെങ്കിൽ kubectl exec പരാജയപ്പെടുകയും ചെയ്താൽ, നിങ്ങൾ ഇതിനകം എൻഡ്പോയിന്റ് തിരഞ്ഞെടുപ്പ് കടന്നിരിക്കുന്നു. ആ പ്രവർത്തനങ്ങൾക്ക് ബന്ധപ്പെട്ട Kubernetes അനുമതികൾ വേണം, അവ കൺട്രോൾ പ്ലെയിനിൽ നിന്ന് നോഡുകളിലേക്കുള്ള ആശയവിനിമയത്തെ ആശ്രയിക്കുന്നു, പരാജയം ടൈംഔട്ടിന് പകരം Forbidden പ്രതികരണവുമാകാം. നോഡിലേക്കുള്ള SSH ആക്സസ് തികച്ചും വ്യത്യസ്തമായ ഒരു സേവനം പരീക്ഷിക്കുന്നു, അവയെ സ്ഥാപിക്കുന്നില്ല.

VPN ടിക്കറ്റ് വീണ്ടും തുറക്കുന്നതിന് മുമ്പ് പിശകിന്റെ വർഗ്ഗം വായിക്കുക, കാരണം രണ്ട് വർഗ്ഗങ്ങളും വ്യത്യസ്ത സ്ഥലങ്ങളിലാണ് കഴിയുന്നത്.

പരിശോധന 5: അടുത്ത വ്യക്തിക്കായി മൂന്ന് നിരീക്ഷണങ്ങൾ സൂക്ഷിക്കുക

തിരഞ്ഞെടുത്ത API URL, ഒരു അനുവദനീയ API അഭ്യർത്ഥന പ്രവർത്തിക്കുന്നുണ്ടോ, കൃത്യമായി ഏത് തുടർന്നുള്ള പ്രവർത്തനമാണ് പരാജയപ്പെടുന്നത് എന്നിവ പിശകിന്റെ എഴുത്തിനൊപ്പം രേഖപ്പെടുത്തുക. ആ മൂന്ന് വരികൾ എൻഡ്പോയിന്റ് തിരഞ്ഞെടുപ്പിനെ നോഡ് ആക്സസിൽ നിന്ന് വേർതിരിക്കുന്നു, തികച്ചും നല്ല ഒരു VPN പാത അത് ഒരിക്കലും വഹിച്ചിട്ടില്ലാത്ത ഒരു അഭ്യർത്ഥനയുടെ കുറ്റം ഏൽക്കുന്നത് തടയുന്നു.

അടുത്ത എഞ്ചിനീയർ ടണൽ കേടാണോ എന്ന് ചോദിക്കും. നിങ്ങളുടെ കുറിപ്പ് അതിന് ഇതിനകം ഉത്തരം നൽകിയിരിക്കണം.