निजी 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 रूट पर ऐसे अनुरोध का दोष नहीं लगने देतीं जिसे उसने कभी ढोया ही नहीं।

अगला इंजीनियर पूछेगा कि क्या सुरंग टूटी है। आपके नोट में उसका उत्तर पहले से होना चाहिए।