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 दायरा सम्बन्धी कागजात ले समर्थित प्यारामिटर र एउटै सूचीमा पर्ने प्लेटफर्मका आवश्यकता सूचीबद्ध गर्छ, र अधिकांश टिकट विवरणले छोड्ने भाग यही हो।