VPC CNI के साथ Pod, VPC से एक पता ले सकता है, और सही रूट वाला VPN उपयोगकर्ता उस तक सीधे पहुँच सकता है। इससे सीधा Pod एक्सेस सबसे सरल विकल्प लगता है, और Pod बदले जाने तक वह है भी। उपयोगकर्ता जो पता याद रखता है वह एप्लिकेशन का होना चाहिए, किसी रेप्लिका का नहीं। तीनों प्रवेशों की तुलना इसी पर आती है कि पता किस ऑब्जेक्ट का है और वर्कलोड के हटने पर क्या चलता रहना चाहिए।

पहले जीवनचक्र के आधार पर चुनें, फिर इस आधार पर कि प्रवेश को पहुँचने योग्य बनाने के लिए नेटवर्क को क्या करना होगा।

तीन प्रवेश, तीन जीवनचक्र

Pod IP का स्वामी Pod होता है: यह उसके साथ आवंटित होता है और उसके समाप्त होने पर मुक्त हो जाता है। ClusterIP का स्वामी Service होता है और यह आभासी है, इसका अर्थ केवल वहीं है जहाँ क्लस्टर का सेवा रूटिंग मौजूद है। आंतरिक लोड बैलेंसर का स्वामी एक क्लाउड संसाधन होता है जिसे क्लस्टर का नियंत्रक बैकएंड के साथ प्रोग्राम करता है। ये स्वामित्व मॉडल पहले ही बता देते हैं कि आपको कौन-सी विफलता मिलेगी: पुराना पता, अप्राप्य नाम, या पुराना बैकएंड समूह।

चुनने से पहले तुलना लिख लें। स्वामी और विफलता का नाम आ जाने के बाद चुनाव अक्सर खुद हो जाता है।

EntryOwnerFailure when the workload moves
Pod IPThe PodAddress changes and saved links break
ClusterIPThe ServiceVirtual address with no meaning outside cluster routing
Internal balancerCloud resource plus controllerBackends 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 एक्सेस को अपने दायरे वाला दस्तावेज़ीकृत परिचालन अपवाद रखें, उपयोगकर्ता निर्देशों से दूर।

संबंधित लेख