VPN वापरकर्त्यांसाठी Pod IP, ClusterIP किंवा अंतर्गत लोड बॅलेंसर
Pod बदलले जाईपर्यंत Pod IP VPN वर राउट केले जाऊ शकते। थेट Pod प्रवेश, ClusterIP आणि अंतर्गत बॅलेंसर यांची तुलना करा, आणि प्रत्येकाचा खर्च काय आहे।
VPC CNI सोबत Pod VPC मधून एक पत्ता घेऊ शकतो, आणि योग्य राउट असलेला VPN वापरकर्ता त्याला थेट पोहोचू शकतो। त्यामुळे थेट Pod प्रवेश सर्वात सोपा पर्याय वाटतो, आणि Pod बदलले जाईपर्यंत तो तसाच आहे। वापरकर्त्याला आठवणारा पत्ता अॅप्लिकेशनचा असावा, प्रतिकृतीचा नाही। तिन्ही प्रवेशांची तुलना शेवटी यात येते की पत्ता कोणत्या ऑब्जेक्टचा आहे आणि वर्कलोड हलल्यावर काय चालू राहिले पाहिजे।
प्रथम जीवनचक्रानुसार निवडा, नंतर प्रवेश पोहोचण्यायोग्य करण्यासाठी नेटवर्कने काय करावे यानुसार।
तीन प्रवेश, तीन जीवनचक्र
Pod IP चा मालक Pod असतो: तो त्याच्यासोबत वाटला जातो आणि तो संपल्यावर सोडला जातो। ClusterIP चा मालक Service असतो आणि तो व्हर्च्युअल आहे, क्लस्टरचे सेवा राउटिंग जिथे आहे तिथेच त्याला अर्थ आहे। अंतर्गत लोड बॅलेंसरचा मालक क्लाउड संसाधन असते ज्याला क्लस्टरचा नियंत्रक बॅकएंडसह प्रोग्राम करतो। ही मालकी मॉडेल्स तुम्हाला मिळणारे अपयश आधीच सांगतात: जुना पत्ता, पोहोचता न येणारे नाव, किंवा जुना बॅकएंड संच।
निवडण्यापूर्वी तुलना लिहून काढा। मालक आणि अपयश यांना नाव दिल्यानंतर निवड बहुतेकदा स्वतःच होते।
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
थेट Pod प्रवेश: उपयुक्त, तात्पुरता
नियंत्रित तपासणीसाठी थेट प्रवेश खरोखर उपयुक्त आहे: एक प्रशासक, एक छोटे सत्र, एक विशिष्ट पोर्ट। पण वापरकर्त्यांसाठी हा वाईट करार आहे, कारण पत्ता हा अंमलबजावणीचा तपशील आहे जो प्रत्येक तैनातीत बदलतो। आणि तो विकीमध्ये नोंदवणे हा चालत्या सेवेचे अफवेत रूपांतर होण्याचा मार्ग आहे।
हे रुंद नियमांनाही आमंत्रण देते। एका प्रशासकाला एका Pod पर्यंत पोहोचण्याची परवानगी नोड सबनेटमधील प्रत्येक पत्त्यासाठी परवानगी नाही, आणि सहसा दुसराच लिहिला जातो।
ClusterIP: रचनेनुसार क्लस्टरपुरता मर्यादित
ClusterIP कार्य करतो कारण क्लस्टरचे डेटाप्लेन क्लस्टरच्या आत त्याच्यासाठी राउटिंग प्रोग्राम करते। VPN वरील लॅपटॉपवरून पत्त्याला काहीच अर्थ नाही, जोपर्यंत काही तो जाणूनबुजून उघड करत नाही। svc.cluster.local ने संपणारे नाव क्लस्टर DNS चे आहे, म्हणून ते दुसऱ्या रिझॉल्व्हर असलेल्या क्लायंटवर कॉपी केल्यास राउटिंग त्रुटीऐवजी अस्तित्वात नसलेले नाव मिळते।
क्लस्टरच्या आतील कॉलरसाठी, इतर वर्कलोडसह, ClusterIP हा योग्य प्रवेश राहतो। तो फक्त क्लस्टरच्या राउटिंग डोमेनबाहेरील वापरकर्त्यांसाठी प्रकाशन व्यवस्था नाही।
अंतर्गत लोड बॅलेंसर: प्रकाशित मार्ग
अंतर्गत लोड बॅलेंसर तुम्हाला स्थिर खाजगी पत्ता आणि तुमचा झोन ज्याकडे निर्देश करू शकेल असे नाव देतो, तर नियंत्रक बॅकएंड संच अद्ययावत ठेवतो, जसे EKS लोड-बॅलेंसिंग मार्गदर्शक सांगते। हाच तो प्रवेश आहे जो कोणीही दस्तऐवज संपादित न करता सामान्य Pod बदलण्यात टिकतो। त्याचा खर्च क्लाउड संसाधन, नियंत्रक संरचना आणि VPN मधून एक राउट आहे, आणि लोक याच भागांना कमी लेखतात।
क्लस्टर प्रत्यक्षात चालवत असलेले नियंत्रक मॉडेल वापरा। एका एकत्रीकरणासाठी लिहिलेल्या टीका दुसऱ्याला लागू होत नाहीत।
स्रोत पत्ता कोण आहे
सुरक्षा गट त्यांच्या सीमेवर येणारा स्रोत पाहतात, आणि VPN व लोड-बॅलेंसिंग मार्गावर अवलंबून तो जोडलेला क्लायंट किंवा भाषांतरित पत्ता असू शकतो। EC2 आधारित नोड्सवर, सामान्य VPC CNI Pod डीफॉल्टनुसार नोडचे ENI गट वारसा घेतात, तर समर्थित संरचना Pod-विशिष्ट गट जोडू शकतात। अनुमानित लॅपटॉप पत्त्यासाठी नाही, तर दस्तऐवजीकृत मार्गासाठी नियम लिहा।
अॅप्लिकेशनचे स्वतःचे श्रोता आणि प्रमाणीकरण वेगळे नियंत्रण म्हणून ठेवा। प्रवाहाला परवानगी देणारा नेटवर्क नियम हा अधिकृततेचा निर्णय नाही आणि तसा विचार करू नये।
वापरकर्त्यांना काय द्यावे
वापरकर्त्यांना पत्ता नाही, सेवेचे नाव द्या। नाव खाजगी झोनमध्ये प्रकाशित करा, ते अंतर्गत प्रवेशाकडे निर्देश करा, आणि नंतर क्लायंट तेच नाव उघडे ठेवत असताना बॅकएंड Pod बदलून तपासा। हा सराव तो गुण तपासतो जो महत्त्वाचा आहे: नियमित तैनातीनंतरही त्याच अॅप्लिकेशनपर्यंत पोहोचणे।
थेट Pod प्रवेश स्वतःच्या व्याप्तीसह दस्तऐवजीकृत कार्यात्मक अपवाद म्हणून, वापरकर्ता सूचनांपासून दूर ठेवा।