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 कॉन्फिगरेशनच्या शेजारी क्लस्टरच्या नेटवर्क गृहीतकांची नोंद ठेवा. मग वर्कलोड दुसऱ्या क्लस्टरमध्ये हलवणे म्हणजे गपचूप कार्य बंद करणारा इमेज बदल नाही, तर रूट योजना तपासण्याचा सराव होतो.