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 வரம்புகள் பற்றிய ஆவணம் ஆதரிக்கப்படும் அளவுருக்களையும் அதே பட்டியலில் இடம்பெற வேண்டிய தளத் தேவைகளையும் பட்டியலிடுகிறது, பெரும்பாலான டிக்கெட் விவரணைகள் விட்டுவிடும் பகுதி இதுவே.