VPN साइडकार को एक शुरुआती नियम और एक विफलता नियम चाहिए

एक pod ऐप से पहले टनल कंटेनर शुरू करता है और पहले अनुरोध सफल होते हैं, और यही वह स्थिति है जो समस्या को छिपाती है। क्रम एक रेस ठीक करता है और टनल विफल होने के बाद चार घंटे बाद ऐप जो ट्रैफ़िक शुरू करता है, उसके बारे में कुछ नहीं कहता। ये दो अलग निर्णय हैं। आमतौर पर इनमें से केवल एक ही डिज़ाइन किया जाता है।

क्रम केवल पहले अनुरोध को रोकता है

Kubernetes रीस्टार्ट होने योग्य init कंटेनरों से बने साइडकार जीवनचक्र का समर्थन करता है। उस मॉडल में एक स्टार्टअप प्रोब अगले इनिशियलाइज़ेशन चरण को तब तक रोक सकता है जब तक टनल तैयार होने की सूचना न दे। यह वास्तविक सुधार है, और एंट्रीपॉइंट स्क्रिप्ट में sleep जोड़ने के बजाय इसे जानबूझकर उपयोग करना चाहिए। गेट उतना ही अच्छा है जितनी अच्छी वह शर्त है जिसका वह परीक्षण करता है।

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

बताएं कि गेट क्या देखता है: एक प्रोसेस मौजूद है, एक इंटरफ़ेस मौजूद है, एक हैंडशेक पूरा हुआ। इनमें से हर दावा “इस pod को जिन गंतव्यों की ज़रूरत है, उन तक डेटा पथ काम करता है” से कमज़ोर है।

डेटा पथ को मानने के बजाय लागू करें

प्रोब एक पल की जाँच है और फ़ायरवॉल वह गुण है जो पलों के बीच लागू रहता है। अगर आवश्यकता यह है कि ऐप का ट्रैफ़िक कभी टनल के बाहर न जाए, तो उसे साझा नेटवर्क नेमस्पेस में स्वीकार-या-छोड़ें नियम के रूप में व्यक्त करना होगा। कंटेनर शुरू करने का क्रम वह आवश्यकता नहीं उठा सकता। केवल एक नियम उठा सकता है।

एक pod के कंटेनर वह नेमस्पेस साझा करते हैं, इसलिए प्रवर्तन का बिंदु नेमस्पेस स्वयं है। आप जो भी लिखें, उसे टनल के अपने बाहरी कनेक्शन को उपलब्ध छोड़ना होगा, क्योंकि ऐप की सुरक्षा के लिए उसे ब्लॉक करना ऐप को ज़रूरी रास्ता काट देता है।

विफलता नीति स्पष्ट रूप से तय करें: जब टनल स्वस्थ न हो तो ऐप ट्रैफ़िक पूरी तरह रुकना चाहिए, या चलता रहना चाहिए और असुरक्षित के रूप में चिह्नित होना चाहिए? दोनों ही तर्कसंगत हैं, और कोई भी कंटेनरों को किसी खास क्रम में शुरू करने से नहीं मिलता।

जिस ट्रैफ़िक का आपने उल्लेख नहीं किया, उसका परीक्षण करें

नियंत्रित टनल विफलता के दौरान एक नया अनुरोध लें और देखें कि वह बाहर जाता है या नहीं। फिर उन रास्तों के लिए जाँच दोहराएं जिन्हें एग्ज़िट-एड्रेस परीक्षण कभी नहीं छूता: क्लस्टर के भीतर DNS रिज़ॉल्यूशन, IPv6 गंतव्य, और सार्वजनिक इंटरनेट के बजाय क्लस्टर-आंतरिक पतों से पहुँची जाने वाली सेवाएँ। ये वे रास्ते हैं जो टनल मरने के बाद भी चुपचाप काम करते रहते हैं।

एग्ज़िट-एड्रेस पेज सिद्ध करता है कि एक अनुरोध उस पल आपकी अपेक्षा के अनुसार कहीं गया। वह बाकी रास्तों की सूची नहीं बना सकता, और आपने जो परखा और pod जहाँ पहुँच सकता है, उसके बीच का अंतर वहीं है जहाँ दिलचस्प विफलताएँ रहती हैं।

परीक्षण केवल साफ़ शुरुआत के बाद ही नहीं, साइडकार रीस्टार्ट के बाद भी दोहराएं। रीस्टार्ट हुआ टनल कंटेनर नेमस्पेस को रूट और नीति के साथ मध्यवर्ती स्थिति में छोड़ सकता है।

डिप्लॉयमेंट रिकॉर्ड लिखें

डिप्लॉयमेंट नोट्स में तीन तथ्य आते हैं: रेडीनेस परीक्षण और वह क्या देखता है, वह परीक्षण विफल होने पर रिकवरी क्रिया, और वह प्रवर्तन नियम जो एग्रेस को नियंत्रित करता है। साइडकार कंटेनर दस्तावेज़ीकरण जीवनचक्र की यांत्रिकी बताता है और वह नीतिगत निर्णय आप पर छोड़ देता है। यह विभाजन सही है, और इसी कारण नीति आमतौर पर गायब रहती है।

सुरक्षा समझी गई हेल्थ जाँच सबसे महँगी तरह का हरा संकेतक है, क्योंकि वह लोगों को प्रश्न पूछने से रोक देती है। दस्तावेज़ीकरण में उसे सटीक नाम देना एक वाक्य का खर्च है और यह रोकता है।

अंत में, ऐप चालू होने पर रिकवरी पथ का एक बार परीक्षण करें। ऐसा डिज़ाइन जो एग्रेस बहाल करने के लिए pod को फिर से बनाने की माँग करता है, एक निर्णय है, और वह आपका लिया निर्णय होना चाहिए, आपकी खोज नहीं।