kubectl VPN വഴി പ്രവർത്തിക്കുന്നതെന്തുകൊണ്ട്, എന്നാൽ AKS സ്കെയിലിംഗ് നിർത്തുന്നതെന്തുകൊണ്ട്

ഓഫീസ് VPN-ന്റെ പൊതു വിലാസം AKS API സെർവറിന്റെ അനുവദനീയ പട്ടികയിൽ ചേർക്കുന്നു, kubectl പ്രവർത്തിക്കുന്നു. ഒരാഴ്ച കഴിഞ്ഞ് ഒരു node pool ന്റെ സ്കെയിൽ-അപ്പ് പരാജയപ്പെടുന്നു, ഒരു CI ജോലിക്ക് ക്ലസ്റ്ററിൽ എത്താൻ കഴിയുന്നില്ല, പോർട്ടൽ IP ശ്രേണികളെക്കുറിച്ച് ഒന്നും പറയാത്ത ഒരു പിശക് കാണിക്കുന്നു. അനുവദനീയ പട്ടിക ആരും മാറ്റിയിട്ടില്ല. നിങ്ങൾ പ്രവർത്തനക്ഷമമാക്കിയ നിയന്ത്രണം API സെർവറിന് മുന്നിലുള്ള ഒരു പൊതു IP ഫിൽട്ടർ ആണ്, ആരാണ് വിളിക്കുന്നതെന്ന് അതിന് അറിയില്ല, വിളി ഏത് വിലാസത്തിൽ നിന്നാണ് വന്നതെന്ന് മാത്രം അറിയാം. VPN ക്ലസ്റ്ററിന് ആവശ്യമായ നിരവധി വിലാസങ്ങളിൽ ഒന്നാണ്, ആദ്യം തകരുന്നത് അതായിരിക്കുന്നത് അപൂർവമാണ്.

അനുവദനീയ പട്ടിക വിലാസവുമായി ചേരുന്നു, വ്യക്തിയുമായി അല്ല

--api-server-authorized-ip-ranges ഇത് CIDR ബ്ലോക്കുകൾ സ്വീകരിക്കുന്നു, ഉപയോക്താക്കളെയോ ഗ്രൂപ്പുകളെയോ അല്ല. ഒരു ഡെവലപ്പറുടെ അഭ്യർത്ഥന VPN സെർവർ വിട്ട് Azure-ലേക്ക് പോകുമ്പോൾ, API സെർവറിലെ സ്രോതസ്സ് വിലാസം VPN സെർവറിന്റെ പൊതു എഗ്രെസ് ആണ്. അതിനാൽ ആ VPN-ലുള്ള ഓരോ വ്യക്തിയും ഒരു എൻട്രി പങ്കിടുന്നു, VPN-ന് പുറത്തുള്ള ആരെയും ഓതന്റിക്കേഷൻ നടക്കുന്നതിന് മുമ്പുതന്നെ നിരസിക്കുന്നു.

അതിനർത്ഥം ഈ എൻട്രി നിങ്ങൾ ഉദ്ദേശിച്ചതിലും കൂടുതൽ ആളുകളെ അനുവദിക്കുന്നു എന്നാണ്. VPN ആക്സസ് ഉള്ള ഒരു കോൺട്രാക്ടർ, അതേ കൺസെൻട്രേറ്ററിലുള്ള വ്യക്തിഗത ലാപ്ടോപ്പ്, വിട്ടുപോയ ഒരു അക്കൗണ്ട് — എല്ലാം ഒരേ വിലാസത്തിൽ നിന്നാണ് വരുന്നത്. ക്ലസ്റ്റർ അംഗീകാരം മാറിയിട്ടില്ല, അതിനാൽ റോൾ അടിസ്ഥാനമാക്കിയ ആക്സസ് നിയന്ത്രണം തന്നെ വിളിക്കുന്നയാൾക്ക് എന്ത് ചെയ്യാമെന്ന് തീരുമാനിക്കുന്നു, പക്ഷേ അനുവദനീയ പട്ടിക ഒരു ഐഡന്റിറ്റി നിയന്ത്രണമല്ല, അതായി ഒരിക്കലും വിവരിക്കരുത്.

ആദ്യം തകരുന്നത് സാധാരണയായി kubectl അല്ല

അനുവദനീയ പട്ടിക API സെർവറിന്റെ പൊതു എൻഡ്പോയിന്റിന് ബാധകമാണ്, അതിനാൽ നിങ്ങളുടെ പട്ടികയിലുള്ള വിലാസങ്ങൾക്ക് പുറത്തുള്ള എല്ലാം ഉടനടി പ്രവർത്തിക്കുന്നത് നിർത്തുന്നു. വ്യക്തമായ ഇരകൾ VPN റൂട്ട് ഇല്ലാത്ത രണ്ടാമത്തെ ഓഫീസ്, ഹോസ്റ്റ് ചെയ്ത പൈപ്പ്ലൈനിലെ ഒരു CI റണ്ണർ, കണക്ട് ചെയ്യാൻ മറന്ന ഒരു ലാപ്ടോപ്പ് എന്നിവയാണ്. ഒരു മനുഷ്യൻ കാത്തിരിക്കുന്നതിനാൽ ഇവ തിരിച്ചറിയാൻ എളുപ്പമാണ്.

കുറച്ചുകൂടി അവ്യക്തമായ കേസ് Azure അല്ലെങ്കിൽ നിങ്ങളുടെ സ്വന്തം ടൂളുകൾ നയിക്കുന്ന ഓട്ടോമേഷൻ ആണ്. പ്ലാറ്റ്ഫോം ആരംഭിക്കുന്ന ചില പ്രവർത്തനങ്ങൾ നിങ്ങളുടെ VPN അല്ലാത്ത വിലാസങ്ങളിൽ നിന്ന് API സെർവറിൽ എത്തുന്നു, പട്ടിക കർശനമാക്കിയതിന് തൊട്ടുപിന്നാലെ അവയിലൊന്ന് പരാജയപ്പെടാൻ തുടങ്ങിയാൽ സമയമാണ് സൂചന. സംവേദനാത്മക ആക്സസ് പ്രവർത്തിക്കുന്നതിനാൽ പട്ടിക പൂർണമാണെന്ന് കരുതരുത്; ക്ലസ്റ്റർ കേടായി എന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് നിങ്ങളുടെ പ്രദേശത്തിനും സബ്സ്ക്രിപ്ഷനുകൾക്കും ഫീച്ചർ എന്താണ് ആവശ്യപ്പെടുന്നതെന്ന് പരിശോധിക്കുക.

പരാജയത്തിന്റെ അടയാളം സഹായിക്കുന്നു. അഭ്യർത്ഥന ഒരിക്കലും ഓതന്റിക്കേഷനിൽ എത്തുന്നില്ലെങ്കിൽ അത് ഫിൽട്ടറാണ്. അത് ഓതന്റിക്കേറ്റ് ചെയ്ത് പിന്നീട് അനുമതി പിശക് ലഭിച്ചാൽ ഫിൽട്ടർ തന്റെ ജോലി ചെയ്തു, പ്രശ്നം റോൾ അടിസ്ഥാനമാക്കിയ ആക്സസ് നിയന്ത്രണത്തിലാണ്, അതിൽ അനുവദനീയ പട്ടിക ഒരിക്കലും തൊടുന്നില്ല.

മുഴുവൻ പട്ടികയും ഒരൊറ്റ കമാൻഡിൽ നിർമ്മിക്കുക

അപ്ഡേറ്റ് പരാമീറ്റർ എൻട്രി ചേർക്കുന്നതിന് പകരം മുഴുവൻ പട്ടികയും മാറ്റിസ്ഥാപിക്കുന്നു, അതിനാൽ VPN വിലാസം മാത്രം വഹിക്കുന്ന ഒരു കമാൻഡ് അവിടെ ഉണ്ടായിരുന്നതെല്ലാം നിശബ്ദമായി ഒഴിവാക്കുന്നു. ആദ്യം നിലവിലെ മൂല്യം വായിക്കുക, അത് സൂക്ഷിക്കുക, യൂണിയൻ അയക്കുക:

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

ഇതിനെ ആശ്രയിക്കുന്നതിന് മുമ്പ് VPN സെർവറിനായി റിസർവ് ചെയ്ത പൊതു IP ഉപയോഗിക്കുക. ഡൈനാമിക് വിലാസം വീണ്ടും കണക്ട് ചെയ്യുമ്പോൾ മാറുന്നു, ഓരോ മാറ്റവും ഇപ്പോഴും അനുവദനീയമായ ഒരു നെറ്റ്വർക്കിൽ നിന്ന് ആരെങ്കിലും പട്ടിക അപ്ഡേറ്റ് ചെയ്യുന്നതുവരെ ടീമിനെ ക്ലസ്റ്ററിന് പുറത്ത് നിശബ്ദമായി പൂട്ടുന്നു. റിഡണ്ടൻസിക്കായി രണ്ട് VPN എഗ്രെസ് പോയിന്റുകൾ ഉണ്ടെങ്കിൽ രണ്ടും ലിസ്റ്റ് ചെയ്യുക, കാരണം ഫിൽട്ടറിന് മുൻഗണനാ പാത എന്ന ആശയമില്ല.

ആദ്യത്തെ അനുവദനീയ ശ്രമം തന്നെ പരീക്ഷണവുമാകുന്ന വിധത്തിൽ മാറ്റം ക്രമീകരിക്കുക. പുതിയ പട്ടിക പ്രഖ്യാപിക്കുക, പ്രയോഗിക്കുക, ഉടൻ VPN-ൽ നിന്ന് കണക്ട് ചെയ്യുക; വിപരീത ക്രമത്തിൽ ചെയ്താൽ CIDR ബ്ലോക്കിലെ ഒരു ടൈപ്പോ ശരിയാക്കാൻ ആർക്കും API സെർവറിൽ എത്താൻ കഴിയാത്ത ഒരു വിൻഡോ അവശേഷിക്കുന്നു.

അനുവദനീയ പട്ടിക ഒരിക്കലും ഉൾക്കൊള്ളാത്തത്

അത് API സെർവറിനെ സ്വകാര്യമാക്കുന്നില്ല. ഒരു സ്വകാര്യ ക്ലസ്റ്റർ സ്വകാര്യ എൻഡ്പോയിന്റും സ്വകാര്യ DNS-ഉം ഉപയോഗിക്കുന്നു, അനുവദനീയ ശ്രേണികളുടെ പട്ടിക അതിനെ മാറ്റിസ്ഥാപിക്കുന്ന നിയന്ത്രണമല്ല. അകത്തേക്ക് വിട്ട ഒരു വിളിക്കുന്നയാൾക്ക് എന്ത് ചെയ്യാമെന്നും അത് മാറ്റുന്നില്ല, അതിനാൽ ചോർന്ന ഒരു അഡ്മിൻ kubeconfig ഏത് അനുവദനീയ വിലാസത്തിൽ നിന്നും ഇപ്പോഴും പ്രവർത്തിക്കുന്നു. ക്രെഡൻഷ്യലിനെ സുരക്ഷാ അതിർത്തിയായും പട്ടികയെ നെറ്റ്വർക്ക് സൗകര്യമായും കാണുക.

അതിന് വർക്ക്ലോഡുകളുമായി യാതൊരു ബന്ധവുമില്ല. പട്ടിക സജീവമായിരിക്കുമ്പോഴും Pods, Services പ്രവർത്തിക്കുന്നത് തുടരുന്നു, VPN വഴി ഒരു ആപ്ലിക്കേഷനിൽ എത്തുന്നത് വേറിട്ട ഒരു പ്രശ്നമാണ്: ക്ലസ്റ്റർ IP മാത്രമുള്ള ഒരു Service-ന് ലാപ്ടോപ്പിന് അത് തുറക്കാൻ കഴിയുന്നതിന് മുമ്പ് ഇപ്പോഴും ആന്തരിക ലോഡ് ബാലൻസർ, ingress അല്ലെങ്കിൽ port-forward ആവശ്യമാണ്. ഈ രണ്ട് ഡിസൈനുകളും കലർത്തുന്നത് ഡെവലപ്പർമാരെ നിയന്ത്രിക്കുന്നു എന്ന് അവകാശപ്പെടുകയും എന്നാൽ ആപ്ലിക്കേഷനുകളെക്കുറിച്ച് ഒന്നും നിയന്ത്രിക്കാതിരിക്കുകയും ചെയ്യുന്ന ഒരു മാറ്റ ടിക്കറ്റ് സൃഷ്ടിക്കുന്നു.

ഇരുവശത്തുനിന്നും പരിശോധിച്ച്, പിന്നീട് ഒരു യഥാർത്ഥ പ്രവർത്തനം നടത്തുക

VPN-ലുള്ള ഒരു പുതിയ ക്ലയന്റുമായും അതിന് പുറത്തുള്ള ഒരു ക്ലയന്റുമായും പരീക്ഷിക്കുക. പുറത്തുനിന്നുള്ള ശ്രമം നാമ റെസല്യൂഷനിൽ അല്ല, API സെർവറിൽ നിരസിക്കപ്പെടണം; പേര് റെസോൾവ് ചെയ്യുന്നില്ലെങ്കിൽ, നിങ്ങൾ DNS പരീക്ഷിക്കുകയാണ്, ഫിൽട്ടറിനെക്കുറിച്ച് ഒന്നും പഠിച്ചിട്ടില്ല. പിന്നീട് സംവേദനാത്മക kubectl കോൾ അല്ലാത്ത ഒരു പ്രവർത്തനം നടത്തുക, ഉദാഹരണത്തിന് node pool സ്കെയിൽ അല്ലെങ്കിൽ അപ്ഗ്രേഡ് പരിശോധന, സംഭവിക്കുമെന്ന് കരുതുന്നതിന് പകരം പൂർത്തിയായെന്ന് സ്ഥിരീകരിക്കുക.

മാറ്റത്തിന് അടുത്തായി മുമ്പത്തെ പട്ടിക മൂല്യം രേഖപ്പെടുത്തുക, ടൈപ്പ് ചെയ്ത കമാൻഡിനെ വിശ്വസിക്കുന്നതിന് പകരം അപ്ഡേറ്റിന് ശേഷം ഫലപ്രദമായ മൂല്യം വീണ്ടും വായിക്കുക. AKS-ന്റെ അനുവദനീയ IP ശ്രേണികൾ സംബന്ധിച്ച ഡോക്യുമെന്റേഷൻ പിന്തുണയ്ക്കുന്ന പരാമീറ്ററുകളും അതേ പട്ടികയിൽ വരേണ്ട പ്ലാറ്റ്ഫോം ആവശ്യകതകളും ലിസ്റ്റ് ചെയ്യുന്നു, മിക്ക ടിക്കറ്റ് വിവരണങ്ങളും ഒഴിവാക്കുന്ന ഭാഗം അതാണ്.