Pod, नोड या क्लस्टर: VPN sidecar असल में क्या रीरूट करता है

Kubernetes Pod में VPN sidecar होस्ट-स्तरीय VPN जैसा दिखता है, बस बेहतर तरीकों के साथ, और समानता namespace की सीमा पर खत्म हो जाती है। एक Pod के कंटेनर नेटवर्क namespace साझा करते हैं, जिसमें पता और पोर्ट की जगह भी शामिल है, इसलिए रूट और नीति स्थापित करने वाला sidecar वास्तव में बदल देता है कि ऐप के पैकेट कहाँ जाते हैं। नोड पर दूसरे Pod के लिए यह कुछ नहीं बदलता, और अगर आप इसे वैसा कॉन्फ़िगर न करें तो नोड के अपने स्टैक को छूता भी नहीं। इस सीमा को सही समझना तय करता है कि आप क्या तैनात कर सकते हैं और क्या परखना होगा। नीचे के खंड इसे namespace से बाहर की ओर ले जाते हैं।

साझा namespace, साझा परिणाम

एक Pod में दो कंटेनर loopback पर बात करते हैं और वही इंटरफ़ेस देखते हैं, और इसी वजह से sidecar पैटर्न काम करता है: ऐप को यह जानने की जरूरत नहीं कि कोई सुरंग मौजूद है, क्योंकि जिस रूट पर वह पहुँचता है वह उसी namespace में स्थापित हुआ था जिसका वह उपयोग करता है। यही गुण बताता है कि sidecar की गलतियाँ ऐप की गलतियाँ हैं। जो रूट बहुत ज्यादा पकड़ ले, या जो DNS बदलाव सुरंग के भीतर के रिज़ॉल्वर की ओर इशारा करे, वह उस Pod के हर प्रोसेस पर तुरंत लागू होता है। साझा namespace में कंटेनर-वार राउटिंग नहीं होती, इसलिए sidecar को एक प्रोसेस तक सीमित नहीं किया जा सकता।

समीक्षा के समय यही तंत्र याद रखना चाहिए: असर का दायरा Pod है, न नोड और न क्लस्टर।

sidecar कहाँ नहीं पहुँचता

दूसरे Pod अपने namespace और अपनी राउटिंग रखते हैं, इसलिए जिस वर्कलोड को वही एग्रेस चाहिए उसे वही sidecar चाहिए या फिर नोड-स्तरीय डिज़ाइन। नोड का ट्रैफ़िक भी Pod namespace से बाहर है, और होस्ट नेटवर्क वाले Pod जानबूझकर इस अलगाव को पूरी तरह छोड़ देते हैं। अगर आप कुछ सुविधाजनक तक पहुँचने के लिए sidecar को होस्ट नेटवर्किंग के साथ चलाते हैं, तो आपने दायरा एक Pod से पूरे नोड तक बढ़ा दिया है और यह ज़ोर से कहना चाहिए।

क्लस्टर सेवाओं का ट्रैफ़िक दूसरा आम आश्चर्य है। Pod के भीतर एक चौड़ा डिफ़ॉल्ट रूट API सर्वर या ClusterIP सेवा के लिए भेजी गई मांगों को पकड़ सकता है, और फिर वे ऐसे विफल होती हैं जैसे सुरंग टूटी हो।

रूट योजना: Pod, सेवा, नोड और VPN रेंज

चारों रेंज लिख लें और कुछ भी तैनात करने से पहले ओवरलैप जाँचें: Pod CIDR, सेवा CIDR, नोड के पते और VPN के पीछे के गंतव्य। VPN की निजी रेंज और क्लस्टर की अपनी जगह के बीच ओवरलैप असामान्य नहीं है, और डिफ़ॉल्ट रूट उसके लिए गलत उपाय है। रूट योजना उसी रिपॉज़िटरी में होनी चाहिए जिसमें मैनिफ़ेस्ट है, क्योंकि अगला क्लस्टर बिल्कुल अलग Pod और सेवा रेंज दे सकता है।

DNS योजना का हिस्सा है, अलग चिंता नहीं। जो sidecar रिज़ॉल्वर कॉन्फ़िगरेशन फिर से लिखता है, वह क्लस्टर के भीतर सेवा खोज तोड़ सकता है, जबकि बाहरी खोज बिल्कुल ठीक चलती रहती है।

शुरुआत और विफलता स्पष्ट अवस्थाएँ हैं

चलती sidecar प्रोसेस एग्रेस नीति नहीं है। तय करें कि सुरंग तैयार होने से पहले कौन-सा ट्रैफ़िक बह सकता है और बाद में वह मरे तो क्या होगा, फिर उस फैसले को लागू करें: ऐप कंटेनर को गेट करने वाली प्रोब, डिफ़ॉल्ट से मना करने वाली नेटवर्क नीति, या दोनों। इनमें से एक के बिना ऐप शुरू होता है, नाम हल करता है और ट्रैफ़िक नोड के सामान्य रास्ते से बाहर भेजता है, जबकि सुरंग अभी जुड़ रही होती है।

यह अंतराल स्वस्थ क्लस्टर में छोटा और टूटे क्लस्टर में स्थायी होता है, और ठीक यही गुण हमलावर या आकस्मिक डेटा लीक को पसंद है।

क्रम को विफलता परीक्षण से जोड़ें। sidecar को मार डालें और पुष्टि करें कि ऐप चुपचाप पीछे हटने के बजाय अपना इच्छित एग्रेस खो देता है।

क्षमताएँ, नीतियाँ और ऐप कंटेनर से परीक्षण

इंटरफ़ेस बनाने और रूट बदलने के लिए जरूरी क्षमताएँ देना विशेषाधिकार का फैसला है, और अलग-थलग Pod के लिए उपयुक्त विशेषाधिकार अपने आप नोड स्टैक पर उपयुक्त नहीं होता। क्लस्टर द्वारा समर्थित नेटवर्क और सुरक्षा नीति के तंत्र इस्तेमाल करें, और यह न मानें कि हर CNI या नीति कार्यान्वयन VPN इंटरफ़ेस को एक जैसा मानता है; अंतर ठीक उन्हीं विफलता स्थितियों में दिखते हैं जो आपके लिए मायने रखती हैं।

असली ऐप कंटेनर से परखें, निजी गंतव्य, क्लस्टर सेवा और सार्वजनिक इंटरनेट पर नई मांगों के साथ। sidecar से किया परीक्षण साबित करता है कि सुरंग चलती है, यह नहीं कि ऐप वहाँ पहुँचता है जहाँ उसे पहुँचना है।

VPN कॉन्फ़िगरेशन के बगल में क्लस्टर की नेटवर्क मान्यताओं का दस्तावेज़ीकरण करें। फिर वर्कलोड को दूसरे क्लस्टर में ले जाना चुपचाप काम करना बंद कर देने वाले इमेज बदलाव के बजाय रूट योजना जाँचने का अभ्यास बन जाता है।