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. பிழை உடலுடன் வெற்றிகரமான இணைப்பு பயன்பாடு.
அந்த நான்கில் ஒவ்வொன்றும் வெவ்வேறு திருத்தத்தைச் சேர்ந்தது, ஒன்று மட்டுமே VPN பற்றியது. ஒவ்வொரு context-இலும் எதைக் கவனித்தீர்கள் என்பதை எழுதுங்கள், அடுத்த நபர் கதைக்குப் பதிலாக ஆதாரங்களைப் பெறுவார்.