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 या आपके अपने टूल चलाते हैं। प्लेटफ़ॉर्म से शुरू होने वाले कुछ ऑपरेशन ऐसे पतों से API सर्वर तक पहुँचते हैं जो आपका VPN नहीं हैं, और जब उनमें से कोई सूची सख़्त होने के तुरंत बाद विफल होने लगे, तो समय ही सुराग है। यह न मानें कि सूची पूरी है क्योंकि इंटरैक्टिव पहुँच काम करती है; अपने क्षेत्र और सदस्यताओं के लिए सुविधा को क्या चाहिए, यह जाँचें, फिर क्लस्टर ख़राब होने का नतीजा निकालें।

विफलता का हस्ताक्षर मदद करता है। अगर अनुरोध कभी प्रमाणीकरण तक नहीं पहुँचता, तो यह फ़िल्टर है। अगर वह प्रमाणीकृत होकर फिर अनुमति त्रुटि पाता है, तो फ़िल्टर ने अपना काम किया और समस्या भूमिका-आधारित पहुँच नियंत्रण में है, जिसे अनुमत सूची कभी नहीं छूती।

पूरी सूची एक ही कमांड में बनाएँ

अपडेट पैरामीटर प्रविष्टि जोड़ने के बजाय पूरी सूची बदल देता है, इसलिए केवल 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 के ज़रिये किसी एप्लिकेशन तक पहुँचना अलग समस्या है: जिस Service के पास केवल क्लस्टर IP है, उसे लैपटॉप के खोल पाने से पहले अब भी आंतरिक लोड बैलेंसर, ingress या port-forward चाहिए। इन दो डिज़ाइनों को मिलाने से ऐसा बदलाव टिकट बनता है जो डेवलपरों को सीमित करने का दावा करता है और असल में एप्लिकेशन के बारे में कुछ भी सीमित नहीं करता।

दोनों ओर से सत्यापित करें, फिर एक वास्तविक ऑपरेशन चलाएँ

VPN पर नए क्लाइंट से और उसके बाहर के क्लाइंट से परीक्षण करें। बाहर का प्रयास नाम रिज़ॉल्यूशन पर नहीं, API सर्वर पर अस्वीकार होना चाहिए; अगर नाम हल न हो, तो आप DNS परीक्षण कर रहे हैं और फ़िल्टर के बारे में कुछ नहीं सीखा। फिर ऐसा ऑपरेशन चलाएँ जो इंटरैक्टिव kubectl कॉल न हो, जैसे node pool स्केल या अपग्रेड जाँच, और यह मानने के बजाय कि हो जाएगा, पूरा होने की पुष्टि करें।

बदलाव के पास पिछली सूची का मान दर्ज रखें, और टाइप की गई कमांड पर भरोसा करने के बजाय अपडेट के बाद प्रभावी मान फिर से पढ़ें। AKS के अधिकृत IP रेंज दस्तावेज़ समर्थित पैरामीटर और उसी सूची में आने वाली प्लेटफ़ॉर्म आवश्यकताएँ सूचीबद्ध करते हैं, और यही वह हिस्सा है जो ज़्यादातर टिकट विवरण छोड़ देते हैं।