kubectl VPN वर का काम करते पण AKS स्केलिंग का थांबवते

तुम्ही कार्यालयीन VPN चा सार्वजनिक पत्ता AKS API सर्व्हरच्या परवानगी सूचीत जोडता, आणि kubectl काम करते। आठवडाभरानंतर node pool चे स्केल-अप अयशस्वी होते, CI कार्य क्लस्टरपर्यंत पोहोचू शकत नाही, आणि पोर्टल अशी त्रुटी दाखवते ज्यात IP श्रेणींचा उल्लेखही नाही। परवानगी सूची कोणीही बदलली नाही। तुम्ही सुरू केलेला नियंत्रण API सर्व्हरसमोरचा सार्वजनिक IP फिल्टर आहे, आणि तो कोण कॉल करत आहे हे जाणत नाही, फक्त कॉल कोणत्या पत्त्यावरून आला हे जाणतो। VPN क्लस्टरला आवश्यक असलेल्या अनेक पत्त्यांपैकी एक आहे, आणि पहिल्यांदा तुटणे हेच असते असे फार कमी होते।

परवानगी सूची पत्त्याशी जुळते, व्यक्तीशी नाही

--api-server-authorized-ip-ranges ते CIDR ब्लॉक घेते, वापरकर्ते किंवा गट नाहीत। जेव्हा डेव्हलपरची विनंती VPN सर्व्हर सोडून Azure कडे जाते, तेव्हा API सर्व्हरवरील स्रोत पत्ता VPN सर्व्हरचा सार्वजनिक इग्रेस असतो। त्यामुळे त्या VPN वरील प्रत्येकजण एकच नोंद सामायिक करतो, आणि VPN बाहेरील कोणालाही प्रमाणीकरण होण्याआधीच नकारले जाते।

याचा अर्थ असाही की ही नोंद तुम्ही ठरवलेल्यापेक्षा जास्त लोकांना प्रवेश देते। VPN प्रवेश असलेला कंत्राटदार, त्याच कॉन्सेंट्रेटरवरील वैयक्तिक लॅपटॉप, आणि हॅक झालेले खाते — सर्व एकाच पत्त्यावरून येतात। क्लस्टरचे प्राधिकरण बदललेले नाही, त्यामुळे भूमिका-आधारित प्रवेश नियंत्रण अजूनही कॉल करणारा काय करू शकतो हे ठरवते, पण परवानगी सूची हे ओळख नियंत्रण नाही आणि तसे कधीही वर्णन करू नये।

पहिल्यांदा तुटणारी गोष्ट सहसा kubectl नसते

परवानगी सूची API सर्व्हरच्या सार्वजनिक एंडपॉइंटला लागू होते, त्यामुळे तुमच्या सूचीबद्ध पत्त्यांबाहेरील सर्व काही लगेच काम करणे थांबवते। स्पष्ट बळी म्हणजे VPN मार्ग नसलेले दुसरे कार्यालय, होस्टेड पाइपलाइनमधील CI रनर, आणि जोडायचे विसरलेला लॅपटॉप। हे ओळखणे सोपे आहे कारण एक माणूस वाट पाहत असतो।

कमी स्पष्ट प्रकरण म्हणजे Azure किंवा तुमच्या स्वतःच्या साधनांनी चालवलेले ऑटोमेशन। प्लॅटफॉर्मने सुरू केलेल्या काही क्रिया VPN नसलेल्या पत्त्यांवरून API सर्व्हरपर्यंत पोहोचतात, आणि सूची कडक केल्यावर लगेच त्यातील एक अयशस्वी होऊ लागली तर वेळ हाच सुगावा असतो। इंटरॅक्टिव्ह प्रवेश काम करतो म्हणून सूची पूर्ण आहे असे गृहीत धरू नका; क्लस्टर खराब आहे असा निष्कर्ष काढण्यापूर्वी तुमच्या प्रदेशासाठी आणि सदस्यतांसाठी या सुविधेला काय आवश्यक आहे ते तपासा।

अपयशाचे स्वाक्षरी मदत करते। विनंती कधीही प्रमाणीकरणापर्यंत पोहोचत नसेल, तर ते फिल्टर आहे। जर ती प्रमाणित होऊन नंतर परवानगी त्रुटी मिळाली, तर फिल्टरने आपले काम केले आहे आणि समस्या भूमिका-आधारित प्रवेश नियंत्रणात आहे, ज्याला परवानगी सूची कधीही स्पर्श करत नाही।

संपूर्ण सूची एकाच आदेशात तयार करा

अद्ययावत पॅरामीटर नोंद जोडण्याऐवजी संपूर्ण सूची बदलतो, त्यामुळे फक्त VPN पत्ता घेऊन जाणारा आदेश तिथे असलेले बाकी सर्व शांतपणे टाकून देतो। आधी सध्याचे मूल्य वाचा, ते ठेवा, आणि संघ पाठवा:

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

यावर अवलंबून राहण्यापूर्वी VPN सर्व्हरसाठी आरक्षित सार्वजनिक IP वापरा। गतिशील पत्ता पुन्हा जोडताना बदलतो, आणि प्रत्येक बदल संघाला क्लस्टरबाहेर शांतपणे बंद करतो, जोपर्यंत कोणी अजूनही परवानगी असलेल्या नेटवर्कवरून सूची अद्ययावत करत नाही। अनावश्यकतेसाठी दोन VPN इग्रेस बिंदू असतील तर दोन्ही सूचीबद्ध करा, कारण फिल्टरला पसंतीच्या मार्गाची संकल्पना नाही।

पहिला परवानगी दिलेला प्रयत्न हाच चाचणी होईल अशा क्रमाने बदल मांडा। नवीन सूची जाहीर करा, ती लागू करा, आणि लगेच VPN वरून जोडा; उलट क्रमाने केल्यास CIDR ब्लॉकमधील टायपो दुरुस्त करण्यासाठी कोणीही API सर्व्हरपर्यंत पोहोचू शकत नाही अशी खिडकी राहते।

परवानगी सूचीने कधीही काय व्यापले नाही

ते API सर्व्हरला खाजगी करत नाही। खाजगी क्लस्टर खाजगी एंडपॉइंट आणि खाजगी DNS वापरतो, आणि अधिकृत-श्रेणी सूची हे त्याची जागा घेणारे नियंत्रण नाही। आत घेतलेला कॉल करणारा काय करू शकतो हेही ते बदलत नाही, त्यामुळे गळलेला अॅडमिन kubeconfig अजूनही कोणत्याही परवानगी असलेल्या पत्त्यावरून काम करतो। क्रेडेन्शियलला सुरक्षा सीमा आणि सूचीला नेटवर्क सुविधा माना।

त्याचा वर्कलोडशी काहीही संबंध नाही। सूची सुरू असतानाही Pods आणि Services चालू राहतात, आणि VPN मधून अनुप्रयोगापर्यंत पोहोचणे ही वेगळी समस्या आहे: फक्त क्लस्टर IP असलेल्या Service ला लॅपटॉप ते उघडू शकण्यापूर्वी अजूनही अंतर्गत लोड बॅलन्सर, ingress किंवा port-forward लागतो। या दोन रचना एकत्र केल्यास डेव्हलपरना मर्यादित करण्याचा दावा करणारे पण अनुप्रयोगांबद्दल काहीही मर्यादित न करणारे बदल तिकीट तयार होते।

दोन्ही बाजूंनी पडताळणी करा, नंतर एक वास्तविक क्रिया चालवा

VPN वर नवीन क्लायंट आणि त्याबाहेरच्या क्लायंटसह चाचणी करा। बाहेरचा प्रयत्न नाव निराकरणावर नाही, API सर्व्हरवर नाकारला पाहिजे; जर नाव सोडवले जात नसेल, तर तुम्ही DNS चाचणी करत आहात आणि फिल्टरबद्दल काहीही शिकला नाही। नंतर इंटरॅक्टिव्ह kubectl कॉल नसलेली क्रिया चालवा, जसे की node pool स्केल किंवा अपग्रेड तपासणी, आणि होईल असे गृहीत धरण्याऐवजी पूर्ण झाल्याची पुष्टी करा।

बदलाच्या शेजारी मागील सूचीचे मूल्य नोंदवा, आणि टाइप केलेल्या आदेशावर विश्वास ठेवण्याऐवजी अद्ययावतानंतर प्रभावी मूल्य पुन्हा वाचा। AKS चे अधिकृत IP श्रेणी दस्तऐवज समर्थित पॅरामीटर आणि त्याच सूचीत येणाऱ्या प्लॅटफॉर्मच्या आवश्यकता सूचीबद्ध करतात, आणि बहुतेक तिकीट वर्णने जी गोष्ट वगळतात तीच ही आहे।