தனிப்பட்ட 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 பாதையே அது ஒருபோதும் சுமக்காத கோரிக்கைக்காகக் குறை கூறப்படுவதைத் தடுக்கின்றன.

அடுத்த பொறியாளர் சுரங்கப்பாதை உடைந்ததா என்று கேட்பார். உங்கள் குறிப்பு அதற்கு ஏற்கனவே பதிலளித்திருக்க வேண்டும்.