निजी 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 मार्गलाई यसले कहिल्यै बोकेको नभएको अनुरोधको दोष लाग्नबाट रोक्छन्।

अर्को इन्जिनियरले सुरुङ बिग्रिएको छ कि भनेर सोध्नेछ। तपाईंको टिप्पणीले त्यसको उत्तर पहिल्यै दिइसकेको हुनुपर्छ।