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 अपनाना टकरावपूर्ण योजना का बहाना नहीं है।
मालिकाना देखकर तय करें, फिर वह विफलता जाँचें जिसका वादा किया था
प्रति-Pod सुरंग तब चुनें जब रिमोट सेवा अलग-अलग वर्कलोड प्रमाणित करती है, जब केवल कुछ Deployment को लिंक चाहिए, और जब विफलता स्थानीय रहनी चाहिए। गेटवे तब चुनें जब नेटवर्क टीम के पास पहले से रास्ता है, जब कई वर्कलोड एक गंतव्य साझा करते हैं, और जब स्थिर स्रोत पता ही पूरे अभ्यास का उद्देश्य है।
किसी भी तरह, स्थिर स्थिति नहीं, वह गुण जाँचें जो आपने बेचा था। एक Pod बनाएँ, उसे तुरंत भेजने दें, और अगर वादा था कि सुरंग से कुछ नहीं बचता तो पहले कुछ सेकंड देखें। पाँच रेप्लिकाओं तक स्केल करें और दूर वाला सिरा जिन सत्रों की रिपोर्ट करता है उन्हें गिनें यदि वादा प्रति-वर्कलोड पहचान था। ये दो जाँचें मैनिफ़ेस्ट की समीक्षा से कहीं तेज़ी से तंत्र की सीमाएँ उजागर करती हैं, और बताती हैं कि अगली घटना किस टीम की है।