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 हो। त्रुटि body सहित सफल जडान अनुप्रयोग हो।
ती चारमध्ये प्रत्येक फरक सुधारसँग सम्बन्धित छ, र एउटा मात्र VPN को बारेमा हो। प्रत्येक context मा तपाईंले कुन देख्नुभयो लेख्नुहोस्, र अर्को व्यक्तिले कथा होइन प्रमाणहरू उत्तराधिकारमा पाउनेछ।