VPN साइडकारलाई सुरु नियम र असफलता नियम चाहिन्छ

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

क्रमले पहिलो अनुरोध मात्र रोक्छ

Kubernetes पुनः सुरु गर्न सकिने init कन्टेनरबाट बनेको साइडकार जीवनचक्रलाई समर्थन गर्छ। त्यो मोडेलमा स्टार्टअप प्रोबले टनेल तयार भएको जानकारी नदिएसम्म अर्को इनिसियलाइजेसन चरण रोक्न सक्छ। यो वास्तविक सुधार हो, र एन्ट्रीपोइन्ट स्क्रिप्टमा sleep थप्नुको सट्टा यसलाई जानाजान प्रयोग गर्न लायक छ। गेट आफूले परीक्षण गर्ने सर्तजत्तिकै राम्रो हुन्छ।

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

गेटले के अवलोकन गर्छ भन्नुहोस्: प्रक्रिया छ, इन्टरफेस छ, handshake पूरा भयो। तीमध्ये प्रत्येक “यो pod लाई चाहिने गन्तव्यसम्मको डेटा मार्ग काम गर्छ” भन्दा कमजोर दाबी हो।

डेटा मार्गलाई मान्नुको सट्टा लागू गर्नुहोस्

प्रोब एक क्षणको जाँच हो र firewall क्षणहरूबीच लागू हुने गुण हो। यदि एपको ट्राफिक कहिल्यै टनेलबाहिर नजाओस् भन्ने आवश्यकता हो भने, त्यो साझा नेटवर्क नेमस्पेसमा स्वीकार-वा-त्याग नियमका रूपमा व्यक्त गर्नुपर्छ। कन्टेनर सुरु गर्ने क्रमले त्यो आवश्यकता बोक्न सक्दैन। एउटा नियमले मात्र सक्छ।

एउटै pod का कन्टेनरहरूले त्यो नेमस्पेस साझा गर्छन्, त्यसैले लागू गर्ने बिन्दु नेमस्पेस आफैं हो। तपाईंले जे लेख्नुभए पनि, त्यसले टनेलको आफ्नै बाहिरी जडान उपलब्ध छोड्नुपर्छ, किनभने एपको सुरक्षाका लागि त्यसलाई ब्लक गर्दा एपलाई चाहिने बाटो काटिन्छ।

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

तपाईंले उल्लेख नगर्नुभएको ट्राफिक परीक्षण गर्नुहोस्

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

एग्जिट-ठेगाना पृष्ठले एउटा अनुरोध त्यो क्षण तपाईंले अपेक्षा गरेको ठाउँमा गएको प्रमाणित गर्छ। यसले अरू मार्गको सूची बनाउन सक्दैन, र तपाईंले परीक्षण गरेको र pod पुग्न सक्नेबीचको फरक नै रोचक असफलताहरू बस्ने ठाउँ हो।

परीक्षण केवल सफा सुरुवातपछि मात्र होइन, साइडकार रिस्टार्टपछि पनि दोहोर्याउनुहोस्। रिस्टार्ट भएको टनेल कन्टेनरले नेमस्पेसलाई मार्ग र नीतिसहित मध्यवर्ती अवस्थामा छोड्न सक्छ।

डिप्लोयमेन्ट रेकर्ड लेख्नुहोस्

डिप्लोयमेन्ट नोटमा तीन तथ्य पर्छन्: रेडिनेस परीक्षण र त्यसले के अवलोकन गर्छ, त्यो परीक्षण असफल भएपछि पुनःप्राप्ति कार्य, र इग्रेसलाई नियन्त्रण गर्ने लागू नियम। साइडकार कन्टेनरको कागजात ले जीवनचक्रको यान्त्रिकी समेट्छ र त्यो नीतिगत निर्णय तपाईंमाथि छोड्छ। त्यो विभाजन सही छ, र नीति सामान्यतया गायब हुनुको कारण पनि त्यही हो।

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

अन्तमा, एप चलिरहेको बेला पुनःप्राप्ति मार्गको एक पटक परीक्षण गर्नुहोस्। इग्रेस पुनर्स्थापित गर्न pod पुनः सिर्जना गर्नुपर्ने डिजाइन एउटा निर्णय हो, र त्यो तपाईंले लिएको निर्णय हुनुपर्छ, तपाईंले फेला पारेको कुरा होइन।