खाजगी 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 मार्गावर अशा विनंतीचा दोष येऊ देत नाहीत जी त्याने कधीही वाहिली नाही।

पुढील अभियंता विचारेल की बोगदा तुटलेला आहे का। तुमच्या टिपेत त्याचे उत्तर आधीच असावे।