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 पहुँचलाई आफ्नै दायरा भएको कागजातीय परिचालन अपवादका रूपमा, प्रयोगकर्ता निर्देशनबाट टाढा राख्नुहोस्।