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 क्लाइंट ऐसे रूट लगा सकता है जो उन prefixes से टकराते हैं जो minikube अपने नोड नेटवर्क, सर्विस रेंज और pod रेंज के लिए इस्तेमाल करता है।
जब ऐसा होता है तो लक्षण उलझाने वाला होता है, क्योंकि टनल काम करता है और kubectl जवाब देना बंद कर देता है या NodePort कनेक्शन अस्वीकार कर देता है। यह क्लस्टर की खराबी जैसा दिखता है और लैपटॉप की रूटिंग की खराबी होता है।
टनल को किसी और चीज़ के लिए दोष देने से पहले होस्ट की रूटिंग टेबल की minikube की रेंजों से तुलना करें। ओवरलैप आम तौर पर एक ज़्यादा विशिष्ट रूट के रूप में दिखता है जो उस prefix के लिए टनल इंटरफ़ेस की ओर इशारा करता है जिसे क्लस्टर अपना मानता है।
चरण 3: VPN बंद किए बिना ओवरलैप हल करें
minikube की अपनी VPN और proxy हैंडबुक इन टकरावों पर चर्चा करती है और अपनी उदाहरण रेंजों को देखने की चीज़ें मानती है, न कि सार्वभौमिक सूची। इसे उस प्रोफ़ाइल के साथ पढ़ें जो आपके पास वाकई है।
जहाँ सचमुच ओवरलैप है, वहाँ समर्थित जवाब एक ग़ैर-ओवरलैपिंग रेंज या VPN के मालिक द्वारा स्वीकृत जानबूझकर बनी स्थानीय पहुँच नीति है। सर्विस रेंज बदलना pod रेंज बदलने के बराबर नहीं है, और इनमें से कोई भी नोड नेटवर्क बदलने के बराबर नहीं है।
कॉर्पोरेट टनल को बंद करना ताकि स्थानीय क्लस्टर चले, कोई शॉर्टकट नहीं है; यह नीति का फ़ैसला है जो किसी और को लेना है। बाकी सब के घर जाने के बाद चुपचाप करने के बजाय इसे उसी व्यक्ति तक ले जाएँ। अगर आप पहले ही कर चुके हैं, तो पूछने से पहले वापस लगाएँ।
चरण 4: proxy, DNS और विफलता के चार रूप अलग करें
अगर proxy ज़रूरी है, तो पहचानें कि किस context को इसकी ज़रूरत है। होस्ट पर ब्राउज़र की सेटिंग नोड के अंदर किसी प्रक्रिया को कॉन्फ़िगर नहीं करती, और Pod को एनवायरनमेंट वेरिएबल या क्लस्टर-स्तर की proxy कॉन्फ़िगरेशन चाहिए।
फिर विफलता को बताने के बजाय वर्गीकृत करें। जो नाम हल न हो वह DNS है। जो नाम हल हो और कनेक्शन अस्वीकार कर दे वह रूटिंग या listener है। जो कनेक्शन बने और पहचान पर विफल हो वह TLS है। त्रुटि के body के साथ सफल कनेक्शन अनुप्रयोग है।
इन चारों में से हर एक अलग सुधार से जुड़ा है, और सिर्फ़ एक VPN के बारे में है। लिखें कि आपने हर context में कौन-सा देखा, और अगला व्यक्ति कहानी के बजाय सबूत विरासत में पाएगा।