Kubernetes Pod VPN बनाम इग्रेस गेटवे: सुरुङ कसको?
Pod आफ्नै नेटवर्क नेमस्पेस हो, त्यसैले साँचो छनोट भनेको सुरुङ कुन तहले राख्छ भन्ने हो: प्रत्येक वर्कलोडको पहिचान वा एउटै साझा स्रोतसहित CNI-निर्देशित इग्रेस.
तपाईं vpn-gateway नामको Pod तैनाथ गर्नुहुन्छ, परीक्षण क्लाइन्टलाई त्यसको ठेगानामा पठाउनुहुन्छ र प्याकेट हराइरहेको देख्नुहुन्छ। म्यानिफेस्टमा केही पनि गलत छैन र kubelet सँग कुनै गुनासो छैन। कारण संरचनात्मक हो, कन्फिगरेसनको होइन: Kubernetes ले प्रत्येक Pod लाई आफ्नै नेटवर्क नेमस्पेस दिन्छ, त्यसैले नाम, लेबल वा साझा API नेमस्पेसले प्याकेट कहाँ जान्छ भन्नेमा केही बदल्दैन। त्यसैले VPN ट्राफिक क्लस्टरबाट कसरी बाहिरिन्छ भन्ने निर्णय मालिकत्वको प्रश्नबाट सुरु हुन्छ, कन्टेनर इमेजबाट होइन।
दुई संयन्त्रले धेरैजसो वास्तविक तैनाथीलाई समेट्छन्, र ती अदलबदल गर्न मिल्दैनन्। एउटाले सुरुङलाई वर्कलोडको आफ्नै नेटवर्क नेमस्पेसभित्र राख्छ। अर्कोले CNI लाई छनोट गरिएको ट्राफिक तोकिएको गेटवे नोडबाट मोड्न भन्छ। ती फरक तरिकाले असफल हुन्छन्, फरक तरिकाले स्केल हुन्छन् र फरक टोलीप्रति जवाफदेह हुन्छन्, त्यसैले कन्टेनरको प्रश्नले सामान्यतया कहिल्यै नटुङ्गिने बहस जन्माउँछ।
Pod को सीमा नेमस्पेस हो, जम्प होस्ट होइन
Linux नेटवर्क नेमस्पेसले आफ्ना इन्टरफेस, ठेगाना, रुट र फायरवाल नियमहरूको मालिक हुन्छ, र प्रत्येक Pod ले एउटा पाउँछ। त्यो Pod भित्रका कन्टेनरहरू त्यसमा सामेल हुन्छन्, र त्यसैले सहायक कन्टेनरले त्यस्ता रुट पुन: लेख्न सक्छ जुन एप्लिकेसनले पछि पछ्याउँछ। छेउछाउको Pod सँग देख्नमा समान तर पूर्ण रूपमा छुट्टै स्ट्याक हुन्छ। गेटवे Pod ले उत्तराधिकारमा पाउन सक्ने कुनै साझा तालिका छैन, र एउटा नेमस्पेसबाट अर्कोमा ट्राफिकको कुनै अप्रत्यक्ष हस्तान्तरण छैन।
त्यसैले गेटवे-Pod ढाँचा तब मात्र काम गर्छ जब माथिबाट केहीले साँच्चै त्यसलाई प्याकेट पठाउँछ: एउटा Service, नोडमा स्थिर रुट वा CNI मा स्टेयरिङ नीति। एउटा ठेगानाले मात्र केही आकर्षित गर्दैन।
प्रत्येक Pod को सुरुङले के दिन्छ, र के खर्च गराउँछ
वर्कलोडको नेमस्पेसमा चल्ने सुरुङले त्यो वर्कलोडलाई आफ्नै क्लाइन्ट पहिचान दिन्छ, जुन धेरै टाढा पहुँच सेवाहरूले सत्र अनुमति वा हिसाब गर्नुअघि माग्छन्। क्षतिको दायरा पनि स्थानीय रहन्छ: बिग्रिएको सुरुङले सबैले प्रयोग गर्ने साझा मार्गको सट्टा एउटा Deployment बन्द गर्छ। यो कसरी चल्छ भन्ने कार्यान्वयनमा निर्भर छ, र यहीँ मानिसहरू गलत अनुमान गर्छन्।
केवल कर्नेल अवस्था चाहिने सेटअप init कन्टेनरमा सकिएर बाहिरिन सक्छ। Pod को पूरै जीवनकाल जीवित रहनुपर्ने युजरस्पेस डेमनलाई Kubernetes 1.29 मा नेटिभ साइडकारका रूपमा प्रस्तुत पुन: सुरु गर्न मिल्ने init कन्टेनर ढाँचा चाहिन्छ, र यो भिन्नता स्वादबाट होइन, सुरुङको कार्यान्वयनबाट आउँछ। यो मोडेलको लागत प्रतिलिपि हो: प्रत्येक रेप्लिकाले प्रमाणीकरण गर्छ, आफ्नै सुरुङ ठेगाना पाउँछ र टाढाको सत्र स्लट खपत गर्छ, त्यसैले अटोस्केलिङ घटना लिङ्कको अर्को छेउमा क्षमता घटना बन्छ। एउटै प्रमाणपत्र सबै रेप्लिकामा प्रतिलिपि गर्नाले त्यो लागत हट्दैन, त्यसले अडिट ट्रेल हटाउँछ। क्षमताहरूले पनि त्यही जाँच पाउनुपर्छ, किनकि आफ्नै नेमस्पेसमा NET_ADMIN चाहने सुरुङले privileged: true उदाहरणको सम्पूर्ण होस्टको अधिकार उत्तराधिकारमा लिने कुनै कारण छैन।
जब CNI ले इग्रेस राख्छ
यदि CNI ले यसलाई समर्थन गर्छ भने, इग्रेस गेटवेले वर्कलोड र गन्तव्य दायराअनुसार ट्राफिक छनोट गर्छ, त्यसपछि एउटा अनुमानयोग्य स्रोत ठेगानाअन्तर्गत छानिएका नोडबाट पठाउँछ। Cilium को संस्करण सामान्य सन्दर्भ हो, र यसको कागजात स्पष्ट भन्छ कि यो सुविधाका लागि विशेष Cilium कन्फिगरेसन र सही इन्टरफेस तथा ठेगानासहितका गेटवे नोड चाहिन्छ। यसले Pod सिर्जना भएपछिको सुरुवाती अवधि पनि उल्लेख गर्छ जब स्टेयरिङ अझै लागू हुँदैन, जुन पादटिप्पणी होइन, डिजाइन इनपुट हो।
त्यो ढिलाइलाई आफ्नै वाचाको सामु पढ्नुहोस्। यदि नियम यो हो कि कुनै पनि ट्राफिक अर्को बाटोबाट बाहिरिन पाउँदैन भने, खाडलको समयमा पठाउने नयाँ Pod ले पहिल्यै त्यो तोडेको छ, त्यसैले सुरुवाती क्रमले आफ्नै जवाफ चाहिन्छ: नीति लागू नहुँदासम्म एप्लिकेसन रोक्नुहोस्, वा त्यो झ्याल स्वीकार गरेर कागजात गर्नुहोस्।
दाबीलाई साँघुरो राख्नुहोस्। इग्रेस गेटवेले मार्ग छान्छ र अनुवाद गर्छ। यसले VPN समाप्त गर्दैन, र पछाडि समर्थित जडान बिना क्लस्टरलाई तपाईंको टाढाको नेटवर्कको क्लाइन्ट बनाउँदैन।
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
अनुवादले टाढाको पक्षले देख्ने कुरा चुपचाप बदल्छ
गेटवेले स्रोत पुन: लेखेपछि प्रत्येक Pod को ठेगाना हराउँछ, त्यसैले पहिचानमा आधारित अनुमति सूची एउटा साझा ठेगानामा आधारित सूची बन्छ। यो दोष होइन, साटासाट हो: मर्मतका लागि कम नियम, केही गलत व्यवहार गर्दा मोटा आरोपण।
एप्लिकेसन-तह प्रमाणीकरण र अनुरोध लगिङले नेटवर्कले अब नबताउने कुरा बोक्नुपर्छ। गेटवेको क्षमता र प्रतिस्थापनलाई साझा पूर्वाधार मान्नुहोस्, किनकि एउटा नोडको रिबुटले अब त्यसको पछाडिका सबै वर्कलोड अवरुद्ध गर्छ, र फर्कने बाटो चाँडै जाँच्नुहोस्: टाढाको छेउले अनुवादित ठेगानामा कसरी पुग्ने जान्नुपर्छ, सामान्यतया म्यानिफेस्ट होइन, मानिसले मालिकत्व लिनुपर्ने रुट वा NAT मार्फत। ठेगाना योजना पनि यहीँ पर्छ, किनकि ओभरल्याप हुने क्लस्टर र टाढाका दायराले दुवै मोडेल तोड्छन् र IPv6 अपनाउनु विरोधाभासी योजनाको बहाना होइन।
मालिकत्वले निर्णय गर्नुहोस्, त्यसपछि वाचा गरिएको असफलता परीक्षण गर्नुहोस्
टाढाको सेवाले व्यक्तिगत वर्कलोड प्रमाणीकरण गर्दा, केही Deployment लाई मात्र लिङ्क चाहिँदा, र असफलता स्थानीय रहनुपर्दा प्रत्येक Pod को सुरुङ छान्नुहोस्। नेटवर्क टोलीले पहिल्यै मार्गको मालिकत्व लिँदा, धेरै वर्कलोडले एउटै गन्तव्य साझा गर्दा, र स्थिर स्रोत ठेगाना नै सम्पूर्ण अभ्यासको उद्देश्य हुँदा गेटवे छान्नुहोस्।
जसरी पनि, स्थिर अवस्था होइन, तपाईंले बेचेको गुण जाँच्नुहोस्। एउटा Pod बनाउनुहोस्, तुरुन्तै पठाउन दिनुहोस्, र सुरुङबाट केही भाग्दैन भन्ने वाचा थियो भने पहिलो केही सेकेन्ड हेर्नुहोस्। पाँच रेप्लिकासम्म स्केल गर्नुहोस् र वाचा प्रत्येक वर्कलोडको पहिचान थियो भने टाढाको छेउले रिपोर्ट गर्ने सत्र गन्नुहोस्। यी दुई जाँचले म्यानिफेस्टको समीक्षाभन्दा धेरै छिटो संयन्त्रका सीमा उजागर गर्छन्, र अर्को घटना कुन टोलीको हो भन्ने बताउँछन्।