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 मध्ये तुम्ही कोणते पाहिले ते लिहा, आणि पुढच्या व्यक्तीला गोष्टीऐवजी पुरावे वारसा मिळतील।