VPN साइडकारला सुरुवातीचा नियम आणि अयशस्वीतेचा नियम आवश्यक आहे
अ‍ॅपपूर्वी टनेल सुरू करणे एका शर्यतीचे निराकरण करते. रेडीनेसपूर्वी, टनेल अयशस्वी होताना आणि रीस्टार्टनंतर अ‍ॅप काय पाठवू शकते हे वेगळे ठरवा.
एक pod अ‍ॅपपूर्वी टनेल कंटेनर सुरू करतो आणि पहिल्या विनंत्या यशस्वी होतात, आणि हीच ती परिस्थिती आहे जी समस्या लपवते. क्रम एक शर्यत सोडवतो आणि टनेल अयशस्वी झाल्यानंतर चार तासांनी अ‍ॅप जो ट्रॅफिक सुरू करतो त्याबद्दल काहीही सांगत नाही. हे दोन वेगळे निर्णय आहेत. सामान्यतः त्यापैकी एकच रचला जातो.
क्रम फक्त पहिल्या विनंतीला अडवतो
Kubernetes रीस्टार्ट करता येण्याजोग्या init कंटेनरपासून बनलेल्या साइडकार जीवनचक्राला आधार देते. त्या मॉडेलमध्ये स्टार्टअप प्रोब टनेल तयार असल्याचे कळवेपर्यंत पुढील इनिशियलायझेशन पायरी थांबवू शकतो. ही खरी सुधारणा आहे, आणि एंट्रीपॉइंट स्क्रिप्टमध्ये sleep जोडण्याऐवजी ती जाणीवपूर्वक वापरण्यासारखी आहे. गेट तो तपासत असलेल्या अटीइतकाच चांगला असतो.
त्या मॉडेलबाहेर, क्रमाची अर्थव्यवस्था तुम्ही वापरत असलेल्या रनटाइम किंवा डिपेंडन्सी सिस्टमची असते, आणि त्यांनी जुळणे आवश्यक नाही. दुसऱ्या प्लॅटफॉर्मवरून कॉपी केलेली तैनाती टनेलची वाट पाहत असल्यासारखी दिसू शकते, कारण अ‍ॅप योगायोगाने हळू सुरू होते. ती तीच हमी नाही, आणि भाराखाली ती तुटते.
गेट काय निरीक्षण करतो ते सांगा: प्रोसेस आहे, इंटरफेस आहे, handshake पूर्ण झाला. यातील प्रत्येक “या pod ला आवश्यक असलेल्या गंतव्यांपर्यंतचा डेटा मार्ग काम करतो” यापेक्षा कमकुवत दावा आहे.
डेटा मार्ग गृहीत धरण्याऐवजी लागू करा
प्रोब एका क्षणाची तपासणी आहे आणि firewall क्षणांदरम्यान लागू असलेला गुणधर्म आहे. जर अ‍ॅपचा ट्रॅफिक कधीही टनेलबाहेर जाऊ नये ही आवश्यकता असेल, तर ती सामायिक नेटवर्क नेमस्पेसमध्ये स्वीकार-किंवा-टाकून-दे नियम म्हणून व्यक्त करावी लागेल. कंटेनर सुरू करण्याचा क्रम ही आवश्यकता पेलू शकत नाही. फक्त नियम पेलू शकतो.
एका pod मधील कंटेनर तो नेमस्पेस सामायिक करतात, त्यामुळे अंमलबजावणीचा बिंदू नेमस्पेस स्वतः आहे. तुम्ही काहीही लिहा, ते टनेलचे स्वतःचे बाह्य कनेक्शन उपलब्ध ठेवले पाहिजे, कारण अ‍ॅपचे संरक्षण करण्यासाठी ते ब्लॉक केल्यास अ‍ॅपला आवश्यक असलेला मार्ग कापला जातो.
अयशस्वीतेचे धोरण स्पष्टपणे ठरवा: टनेल निरोगी नसताना अ‍ॅपचा ट्रॅफिक पूर्ण थांबावा, की सुरू राहून असुरक्षित म्हणून चिन्हांकित व्हावा? दोन्हीही समर्थनीय आहेत, आणि ठराविक क्रमाने कंटेनर सुरू करून जे मिळते ते यातील कोणतेही नाही.
तुम्ही उल्लेख न केलेल्या ट्रॅफिकची चाचणी करा
नियंत्रित टनेल अयशस्वीतेदरम्यान नवीन विनंती घ्या आणि ती बाहेर जाते का ते पहा. नंतर एक्झिट-अ‍ॅड्रेस चाचणी कधीही स्पर्श न करणाऱ्या मार्गांसाठी तपासणी पुन्हा करा: क्लस्टरमधील DNS रिसोल्युशन, IPv6 गंतव्ये, आणि सार्वजनिक इंटरनेटऐवजी क्लस्टर-अंतर्गत पत्त्यांद्वारे पोहोचणाऱ्या सेवा. टनेल मेल्यानंतरही शांतपणे काम करत राहणारे मार्ग हेच आहेत.
एक्झिट-अ‍ॅड्रेस पेज सिद्ध करते की एक विनंती त्या क्षणी तुम्ही अपेक्षित असलेल्या ठिकाणी गेली. ते इतर मार्गांची यादी करू शकत नाही, आणि तुम्ही चाचणी केलेले आणि pod पोहोचू शकणारे यातील अंतर हेच मनोरंजक अयशस्वीता राहतात ते ठिकाण.
फक्त स्वच्छ सुरुवातीनंतरच नाही, तर साइडकार रीस्टार्टनंतरही चाचणी पुन्हा करा. रीस्टार्ट झालेला टनेल कंटेनर नेमस्पेसला मार्ग आणि धोरणासह मध्यस्थ स्थितीत सोडू शकतो.
तैनाती नोंद लिहा
तैनाती नोंदींमध्ये तीन तथ्ये येतात: रेडीनेस चाचणी आणि ती काय निरीक्षण करते, ती चाचणी अयशस्वी झाल्यावर पुनर्प्राप्ती क्रिया, आणि इग्रेस नियंत्रित करणारा अंमलबजावणी नियम. साइडकार कंटेनर दस्तऐवजीकरण जीवनचक्राची यांत्रिकी समाविष्ट करते आणि तो धोरण निर्णय तुमच्यावर सोडते. ती विभागणी बरोबर आहे, आणि धोरण सामान्यतः गायब असण्याचे कारणही तेच आहे.
संरक्षण समजलेली आरोग्य तपासणी हा सर्वात महाग प्रकारचा हिरवा निर्देशक आहे, कारण ती लोकांना प्रश्न विचारण्यापासून थांबवते. दस्तऐवजीकरणात तिला अचूक नाव देण्याचा खर्च एक वाक्य आहे आणि ते ते टाळते.
शेवटी, अ‍ॅप सुरू असताना पुनर्प्राप्ती मार्गाची एकदा चाचणी करा. इग्रेस पुनर्संचयित करण्यासाठी pod पुन्हा तयार करणे आवश्यक असणारी रचना हा एक निर्णय आहे, आणि तो तुम्ही घेतलेला निर्णय असावा, तुम्ही शोधलेली गोष्ट नाही.