1.14 पछि GKE पोडहरूले VPN पहुँच गुमाए: स्रोत सुधार्ने दुई तरिका

1.14 पछि पोडहरू आफ्नै ठेगानासहित VPN मा पुग्छन्, त्यसैले पीयरहरू जवाफहरू खारेज गर्छन्। स्रोत सम्झौता छान्नुहोस्, त्यसपछि nonMasqueradeCIDRs त्यसैअनुसार सेट गर्नुहोस्।

एउटा अपग्रेड आउँछ, र सुरुङको अर्को छेउका प्रणालीहरूले अघिल्लो हप्ता काम गरेको पोड ट्राफिक अस्वीकार गर्न थाल्छन्। सुरुङ खुला छ, फायरवाल नियमहरू अछुत छन्, र कसैले पीयर नीति सम्पादन गरेन। के बदलियो भन्ने क्लस्टर लगमा अदृश्य छ: ती प्रणालीहरूले अहिले देख्ने स्रोत ठेगाना। यो अन्तरले नेटवर्क अवरोधजस्तो देखिने र अनुमति समस्याजस्तो व्यवहार गर्ने विफलता व्याख्या गर्छ।

दुई वैध उत्तर छन्, र तिनीहरू तपाईंलाई फरक ठाउँमा लैजान्छन्। ConfigMap सम्पादन गर्नु अघि स्रोत सम्झौता छान्नुहोस्।

स्थापना हुन छाडेको पूर्वनिर्धारित नियम

पुराना GKE संस्करणहरूले masquerade नियम स्थापना गर्थे, जसले गन्तव्य 10.0.0.0/8 बाहिर हुँदा पोड स्रोतलाई नोड ठेगानाले प्रतिस्थापन गर्थ्यो। त्यो दायराभित्रको VPN गेटवेले पोड ठेगाना देख्थ्यो, जबकि अझ टाढाको कुरा नोडबाट आएको जस्तो देखिन्थ्यो। पीयरहरूले नोड ठेगानाका वरिपरि अनुमति सूची र फिर्ता मार्ग बनाए, किनकि उनीहरूले त्यही अवलोकन गरेका थिए।

पछिल्ला संस्करणहरूले त्यो पूर्वनिर्धारित नियम स्थापना गर्न छाडे। पोड ट्राफिक अब गन्तव्य जे भए पनि पोड ठेगानासहित गेटवेमा पुग्छ। केवल नोड ठेगाना रुट गर्ने पीयरले जवाफहरू खारेज गर्छ, र कुनै पक्षले उपयोगी लग प्रविष्टि लेख्दैन। अनुरोध टाढाको छेउमा सफल पनि हुन सक्छ, र यसैले यो विफलता पछ्याउन भ्रमित पार्छ।

मृत घटकको अर्थमा केही पनि बिग्रिएको छैन। दुई पक्ष कुन स्रोत वैध हो भन्नेमा सहमत छैनन्।

पीयरले देख्नुपर्ने स्रोत छान्नुहोस्

पोड ठेगाना राख्नु बढी सटीक सम्झौता हो। टाढाको पक्षले ट्राफिक उत्पन्न गर्ने कार्यभार देख्छ, लग इमानदार रहन्छ, र प्रति-पोड नीति सम्भव हुन्छ। मूल्य यो हो कि पीयरले पोड प्रिफिक्स बोक्नुपर्छ।

नोड ठेगाना राख्नु सस्तो सम्झौता हो। त्यो गन्तव्यका लागि masquerade फेरि खोल्नुहोस्, र पीयरले पहिले नै विश्वास गर्ने ठेगाना देखिरहन्छ।

एउटा प्रश्नले तिनीहरूबीच निर्णय गर्छ: पीयरले स्रोतसँग के गर्छ? यदि उसले लग लेख्छ, प्रति-स्रोत नीति लागू गर्छ वा साँघुरो फिर्ता रुटिङ लागू गर्छ भने पोड ठेगानाले थप कन्फिगरेसनलाई न्याय दिन्छ। यदि उसले जवाफ पठाउन मात्र पर्छ भने masquerade कम खर्चिलो छ र अर्को पक्षबाट केही माग्दैन। दुवै टोलीले लेखेर राखेसम्म जुनसुकै विकल्प तर्कसंगत छ।

तेस्रो विकल्प सामान्यतया गल्ती हो: सबै masquerade गर्ने र ट्राफिक श्रेय गर्ने क्षमता गुमाउने। पीयरले साँच्चै नोड ठेगाना बाहेक अरू केही रुट गर्न नसकेसम्म यसबाट बच्नुहोस्।

nonMasqueradeCIDRs लाई वास्तविक दायरातर्फ निर्देशित गर्नुहोस्

GKE ले kube-system मा ip-masq-agent चलाउँछ, र यसको ConfigMap ले masquerade छोड्ने गन्तव्यहरू सूचीबद्ध गर्छ। सुरुङतर्फ पोड स्रोत जोगाउन पोड दायरा, नोड सबनेट र स्थानीय प्रिफिक्स सबै त्यो सूचीमा पर्छन्।

नमुना मानहरूलाई आफ्नै क्लस्टरका दायराले बदल्नुहोस्। आवश्यकताभन्दा फराकिलो सूची नबनाउनुहोस्, किनकि हरेक थप प्रविष्टिले अर्को गन्तव्यले देख्ने कुरा बदल्छ। तलका तीन प्रविष्टिले पोड नेटवर्क, नोड सबनेट र सुरुङपछाडिको प्रिफिक्स जनाउँछन्:

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

0.0.0.0/0 प्रविष्टिले सबै गन्तव्यका लागि masquerade बन्द गर्छ, जसले असम्बन्धित कार्यभार बाह्य सेवाहरूलाई कस्तो देखिन्छ भन्ने बदल्छ र विरलै जानाजान गरिन्छ। एजेन्टले resyncInterval मा आफ्नो कन्फिगरेसन फेरि पढ्छ, त्यसैले पुनः सुरु गर्नु सामान्यतया आवश्यक हुँदैन। एजेन्ट पोड चलिरहेको छ कि जाँच्नुहोस्, त्यसपछि त्यसभित्र माउन्ट गरिएको फाइल खोल्नुहोस्। त्यो फाइल पढ्नुले नै परिवर्तन पुगेको प्रमाण दिन्छ।

जवाफको मार्ग अर्को आधा हो

masquerade ले अनुरोधको स्रोत मात्र बदल्छ, अरू केही होइन। पीयरले जुनसुकै स्रोत पाए पनि त्यहाँ फर्कने मार्ग अझै चाहिन्छ, र क्लस्टरलाई पीयरतर्फको मार्ग पनि अझै चाहिन्छ।

VPN गेटवेमा क्याप्चरले दुई विफलता छिटो अलग गर्छ। पोड ठेगानासहित आएर कहिल्यै जवाफ नपाउने प्याकेटको अर्थ पीयरसँग पोड प्रिफिक्सको मार्ग छैन। गेटवेमा देखिए पनि क्लस्टरसम्म कहिल्यै नपुग्ने जवाफको अर्थ स्थानीय मार्ग हराएको छ। जसरी भए पनि सम्झौता टिकटमा लेख्नुहोस्: पीयरले कुन स्रोत देख्छ, र कुन प्रिफिक्सतर्फ फर्काउँछ।

हरेक अपग्रेडपछि फेरि जाँच्नुहोस्

masquerade को पूर्वनिर्धारित व्यवहार पहिले नै एक पटक बदलिएको छ, र नोड पूल प्रतिस्थापनले क्लस्टर नेटवर्किङ रिसेट गर्न सक्छ। स्रोत सम्झौतालाई अनुमान गर्ने कुरा होइन, जाँच्ने कुरा मान्नुहोस्।

अपग्रेडपछि एउटा पोडबाट स्थानीय सेवामा एउटा अनुरोध पठाउनुहोस् र पीयरले लग गर्ने स्रोत पढ्नुहोस्। त्यो एउटै अवलोकनले सुरुङ स्थिति पृष्ठले खुसीसाथ स्वस्थ भनी रिपोर्ट गर्ने रिग्रेसन पक्रन्छ। यसलाई दोहोर्याउन एक मिनेट लाग्छ र अर्को व्यक्तिको एक साँझ बचाउँछ।

सम्बन्धित लेखहरू