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 कन्फिगरेसनको छेउमा क्लस्टरका नेटवर्क मान्यताहरू अभिलेख गर्नुहोस्। त्यसपछि वर्कलोड अर्को क्लस्टरमा सार्नु भनेको चुपचाप काम गर्न छाड्ने इमेज परिवर्तन होइन, रुट योजना जाँच्ने अभ्यास हो।