कुबेरनेट्स नेटवर्क: इनग्रेड

आज हम कुबेरनेट्स नेटवर्किंग गाइड के तीसरे भाग का अनुवाद प्रकाशित कर रहे हैं। पहला भाग पॉड्स के बारे में था, दूसरा सेवाओं के बारे में, और आज हम इनग्रेड प्रकार के लोड संतुलन और कुबेरनेट संसाधनों के बारे में बात करेंगे।

राउटिंग लोड संतुलन नहीं है

इस श्रृंखला के पिछले लेख में, हमने एक कॉन्फ़िगरेशन को चूल्हों की एक जोड़ी और एक सेवा से युक्त माना था जिसे एक आईपी पता सौंपा गया था जिसे "क्लस्टर आईपी" कहा जाता है। चूल्हा के लिए इरादा क्वेरी इस पते पर भेजा गया था। यहां हम अपने प्रशिक्षण प्रणाली पर काम करना जारी रखेंगे, जहां से हमने पिछली बार स्नातक किया था। याद रखें कि सेवा का क्लस्टर IP पता, 10.3.241.152 , IP पते की एक श्रेणी से संबंधित है जो कि चूल्हा नेटवर्क में उपयोग किए गए और उस नेटवर्क से उपयोग किए गए नेटवर्क से अलग है जिसमें नोड स्थित हैं। मैंने इस पता स्थान "सेवा नेटवर्क" द्वारा परिभाषित नेटवर्क को बुलाया, हालांकि यह शायद ही एक विशेष नाम के योग्य है, क्योंकि कोई भी उपकरण इस नेटवर्क से जुड़े नहीं हैं, और इसके पते की जगह, वास्तव में, पूरी तरह से रूटिंग नियमों में शामिल हैं। यह पहले दिखाया गया था कि इस नेटवर्क को कुबेरनेट्स घटक के आधार पर कैसे लागू किया जाता है, जिसे क्यूब-प्रॉक्सी कहा जाता है , और आईपी ​​कर्ल को भेजे जाने वाले अवरोधन और पुनर्निर्देशन के लिए लिनक्स कर्नेल मॉड्यूल नेटफिल्टर के साथ बातचीत करता है।


नेटवर्क आरेख

अब तक, हमने "कनेक्शन" और "अनुरोध" के बारे में बात की थी और यहां तक ​​कि "ट्रैफ़िक" की कठिन-से-व्याख्या अवधारणा का उपयोग किया था, लेकिन कुबेरनेट्स इनग्रेडेशन तंत्र की विशेषताओं को समझने के लिए, हमें और अधिक सटीक शब्दों का उपयोग करने की आवश्यकता है। तो, कनेक्शन और अनुरोध ओएसआई मॉडल (टीसीपी) के 4 वें स्तर या 7 वें स्तर (http, rpc, और इसी तरह) पर काम करते हैं। नेटफिल्टर नियम रूटिंग नियम हैं, वे तीसरे स्तर पर आईपी पैकेट के साथ काम करते हैं। नेटफिल्टर सहित सभी राउटर केवल पैकेट में निहित जानकारी के आधार पर कम या ज्यादा निर्णय लेते हैं। सामान्य तौर पर, वे रुचि रखते हैं कि पैकेट कहाँ से आता है और यह कहाँ जाता है। इसलिए, OSI मॉडल के तीसरे स्तर के संदर्भ में इस व्यवहार का वर्णन करने के लिए, यह कहा जाना चाहिए कि प्रत्येक पैकेट 10.3.241.152:80 पर स्थित सेवा के लिए है, जो कि eth0 नोड के इंटरफ़ेस पर आता है, इसे नेटफिल्टर के साथ संसाधित किया जाता है, और, के अनुसार हमारी सेवा के लिए निर्धारित नियम एक कार्यशील चूल्हा के आईपी पते पर पुनर्निर्देशित किए गए हैं।

यह काफी स्पष्ट प्रतीत होता है कि कोई भी तंत्र जिसका उपयोग हम बाहरी ग्राहकों को पॉड्स तक पहुंचने की अनुमति देने के लिए करते हैं, को उसी रूटिंग इन्फ्रास्ट्रक्चर का उपयोग करना चाहिए। नतीजतन, ये बाहरी क्लाइंट आईपी पते और क्लस्टर के बंदरगाह तक पहुंच प्राप्त करेंगे, क्योंकि वे उन सभी तंत्रों के लिए "पहुंच बिंदु" हैं, जिनके बारे में हमने अब तक बात की है। वे हमें इस बारे में चिंता करने की अनुमति नहीं देते हैं कि समय में एक निश्चित बिंदु पर इसे कहाँ निष्पादित किया जाता है। हालाँकि, यह बिल्कुल स्पष्ट नहीं है कि यह सब कैसे काम करता है।

क्लस्टर IP सेवा केवल नोड के ईथरनेट इंटरफ़ेस के साथ उपलब्ध है। क्लस्टर के बाहर कुछ भी नहीं पता है कि उस पते के साथ क्या करना है जिससे यह पता चलता है। मैं सार्वजनिक IP पते से ट्रैफ़िक को पुनर्निर्देशित कैसे कर सकता हूं, यह पता लगाने के लिए है कि पैकेट केवल होस्ट पर पहले से ही उपलब्ध है?

यदि हम इस समस्या का हल खोजने का प्रयास करते हैं, तो समाधान खोजने की प्रक्रिया में जो कुछ भी किया जा सकता है, वह iptables उपयोगिता का उपयोग करके नेटफिल्टर के नियमों का अध्ययन होगा। यदि आप ऐसा करते हैं, तो आप कुछ ऐसा खोज सकते हैं, जो पहली नज़र में असामान्य लग सकता है: सेवा के लिए नियम किसी विशिष्ट स्रोत नेटवर्क तक सीमित नहीं हैं। इसका मतलब यह है कि नोड के ईथरनेट इंटरफेस पर आने वाले और कहीं भी उत्पन्न 10 पैकेट का कोई पता 10.3.241.152:80 है, जो नियम के अनुरूप होगा और उप के लिए पुनर्निर्देशित किया जाएगा। क्या हम ग्राहकों को सिर्फ एक आईपी क्लस्टर दे सकते हैं, शायद इसे एक उपयुक्त डोमेन नाम से बांध कर, और फिर एक मार्ग सेट करें जो हमें इन पैकेटों के वितरण को नोड्स में से एक में व्यवस्थित करने की अनुमति देता है?


बाहरी ग्राहक और क्लस्टर

यदि सब कुछ इस तरह से सेट किया गया है, तो ऐसा डिज़ाइन काम करने वाला साबित होगा। ग्राहक क्लस्टर आईपी तक पहुंचते हैं, पैकेट मेजबान की ओर जाने वाले मार्ग का अनुसरण करते हैं, और फिर वे नीचे तक पहुंच जाते हैं। इस समय, यह आपको लग सकता है कि ऐसा समाधान सीमित हो सकता है, लेकिन यह कुछ गंभीर समस्याओं से ग्रस्त है। पहला यह है कि नोड्स, वास्तव में, पंचांग की अवधारणा, वे विशेष रूप से इस संबंध में चूल्हा से अलग नहीं हैं। वे, बेशक, फली की तुलना में भौतिक दुनिया के थोड़ा करीब हैं, लेकिन वे नई आभासी मशीनों की ओर पलायन कर सकते हैं, क्लस्टर ऊपर या नीचे, और इसी तरह से बढ़ सकते हैं। राउटर ओएसआई मॉडल के तीसरे स्तर पर काम करते हैं और पैकेट सामान्य रूप से काम करने वाली सेवाओं और उन लोगों के बीच अंतर नहीं कर सकते हैं जो सही तरीके से काम नहीं करते हैं। उन्हें उम्मीद है कि मार्ग में अगला संक्रमण सुलभ और स्थिर होगा। यदि नोड अनुपलब्ध है, तो मार्ग निष्क्रिय हो जाएगा और ऐसा रहेगा, ज्यादातर मामलों में, बहुत समय। यहां तक ​​कि अगर मार्ग विफलताओं के लिए प्रतिरोधी है, तो ऐसी योजना इस तथ्य को जन्म देगी कि सभी बाहरी ट्रैफ़िक एक नोड से गुजरते हैं, जो संभवतः इष्टतम है।

कोई फर्क नहीं पड़ता कि हम सिस्टम में क्लाइंट ट्रैफ़िक कैसे लाते हैं, हमें ऐसा करने की आवश्यकता है ताकि यह किसी एकल क्लस्टर नोड की स्थिति पर निर्भर न हो। और, वास्तव में, राउटर का सक्रिय रूप से प्रबंधन करने के कुछ साधनों के बिना, केवल रूटिंग का उपयोग करके ऐसा करने का कोई विश्वसनीय तरीका नहीं है। तथ्य की बात के रूप में, यह ठीक है कि यह भूमिका, नियंत्रण प्रणाली की भूमिका है, कि क्यूब-प्रॉक्सी नेटफिल्टर के संबंध में खेलता है। बाह्य राउटर के प्रबंधन के लिए कुबेरनेट्स की जिम्मेदारी का विस्तार करना सिस्टम आर्किटेक्ट के लिए बहुत मायने नहीं रखता है, खासकर जब से हमारे पास पहले से ही कई सर्वरों पर क्लाइंट ट्रैफ़िक को वितरित करने के लिए सिद्ध उपकरण हैं। उन्हें लोड बैलेंसर्स कहा जाता है, और यह आश्चर्य की बात नहीं है कि वे कुबेरनेट्स इनग्रेड के लिए वास्तव में विश्वसनीय समाधान हैं। वास्तव में यह कैसे होता है, यह समझने के लिए, हमें ओएसआई के तीसरे स्तर से उठने और फिर से कनेक्शन के बारे में बात करने की आवश्यकता है।

क्लस्टर नोड्स के बीच क्लाइंट ट्रैफ़िक को वितरित करने के लिए लोड बैलेंसर का उपयोग करने के लिए, हमें एक सार्वजनिक आईपी पते की आवश्यकता होती है जिससे ग्राहक जुड़ सकते हैं, और हमें स्वयं नोड्स के पते की भी आवश्यकता होती है, जिसमें लोड बैलेंसर अनुरोधों को पुनर्निर्देशित कर सकते हैं। उपरोक्त कारणों से, हम केवल सेवा-आधारित नेटवर्क (आईपी क्लस्टर) का उपयोग करके गेटवे राउटर और नोड्स के बीच एक स्थिर स्थिर मार्ग नहीं बना सकते हैं।

जिन अन्य पतों के साथ आप काम कर सकते हैं, उनमें से आप केवल उन नेटवर्क के पतों को चिन्हित कर सकते हैं जिनसे नोड के ईथरनेट इंटरफेस जुड़े हुए हैं, 10.100.0.0/24 , इस उदाहरण में, 10.100.0.0/24 । राउटर को पहले से ही पता है कि इन इंटरफेस को पैकेट कैसे फॉरवर्ड करना है, और लोड बैलेंसर से राउटर को भेजे गए कनेक्शन कहां जाएंगे, उन्हें कहां जाना चाहिए। लेकिन अगर ग्राहक पोर्ट 80 पर हमारी सेवा से जुड़ना चाहता है, तो हम नोड्स के नेटवर्क इंटरफेस पर इस पोर्ट को केवल पैकेट नहीं भेज सकते।


लोड बैलेंसर, होस्ट नेटवर्क इंटरफ़ेस के पोर्ट 80 तक पहुंचने का असफल प्रयास

ऐसा क्यों किया जा सकता है इसका कारण पूरी तरह से स्पष्ट है। अर्थात्, हम इस तथ्य के बारे में बात कर रहे हैं कि 10.100.0.3:80 पर कनेक्शन की प्रतीक्षा करने की कोई प्रक्रिया नहीं है (और अगर वहाँ है, तो यह निश्चित रूप से एक ही प्रक्रिया नहीं है), और नेटफिल्टर के नियम, जो हमें उम्मीद थी, अनुरोध और अवरोधन करेंगे वे उसे नहीं भेजेंगे, उन्होंने उस गंतव्य पते पर काम नहीं किया। वे केवल 10.3.241.152:80 पते पर सेवाओं के आधार पर क्लस्टर आईपी नेटवर्क पर प्रतिक्रिया 10.3.241.152:80 । परिणामस्वरूप, ये पैकेट, उनके आगमन पर, गंतव्य पते पर वितरित नहीं किए जा सकते हैं, और कर्नेल एक ECONNREFUSED प्रतिक्रिया जारी करेगा। यह हमें भ्रामक स्थिति में रखता है: पैकेट पुनर्निर्देशन के लिए नेटवर्क के साथ काम करना आसान नहीं है, जिसमें नेटफ़िल्टर को कॉन्फ़िगर किया जाता है जब गेटवे से नोड्स तक डेटा को रीडायरेक्ट किया जाता है, और जिस नेटवर्क के लिए रूटिंग को कॉन्फ़िगर करना आसान होता है वह नेटवर्क नहीं है जिससे नेटफ़िल्टर पैकेट को रीडायरेक्ट करता है। इस समस्या को हल करने के लिए, आप इन नेटवर्क के बीच एक पुल बना सकते हैं। यह ठीक वैसा ही है जैसे कुबेरनेट्स नॉडपॉर्ट जैसी सेवा का उपयोग करता है।

NodePort जैसी सेवाएं

उदाहरण के लिए, पिछले लेख में बनाई गई सेवा को एक प्रकार असाइन नहीं किया गया है, इसलिए उसने डिफ़ॉल्ट प्रकार - ClusterIP अपनाया। दो और प्रकार की सेवाएं हैं जो अतिरिक्त सुविधाओं में भिन्न हैं, और एक जिसे हम अभी रुचि रखते हैं, वह है NodePort । इस प्रकार की सेवा का विवरण इस प्रकार है:

 kind: Service apiVersion: v1 metadata: name: service-test spec: type: NodePort selector:   app: service_test_pod ports: - port: 80   targetPort: http 

प्रकार NodePort की सेवाएँ एक प्रकार की ClusterIP की सेवाएँ हैं, जिनमें एक अतिरिक्त सुविधा है: उन तक पहुँच प्राप्त की जा सकती है जो होस्ट को असाइन किए गए IP पते और सेवा नेटवर्क में क्लस्टर को दिए गए पते से दोनों प्राप्त कर सकते हैं। यह एक सरल तरीके से प्राप्त किया जाता है: जब कुबेरनेट्स एक नोडपैड सेवा बनाता है, तो क्यूब-प्रॉक्सी 30000-32767 की सीमा में एक पोर्ट आवंटित करता है और प्रत्येक नोड के eth0 इंटरफ़ेस पर इस पोर्ट को खोलता है (इसलिए सेवा प्रकार का नाम - NodePort )। इस पोर्ट से किए गए कनेक्शन (हम ऐसे NodePort पोर्ट्स NodePort ) को सेवा के क्लस्टर IP पर पुनर्निर्देशित किया गया है। यदि हम ऊपर वर्णित सेवा बनाते हैं और kubectl get svc service-test आदेश प्राप्त करते हैं, तो हम इसे असाइन किए गए पोर्ट को देख सकते हैं।

 $ kubectl get svc service-test NAME           CLUSTER-IP EXTERNAL-IP   PORT(S) AGE service-test   10.3.241.152 <none>        80:32213/TCP 1m 

इस स्थिति में, सेवा को NodePort 32213 असाइन किया गया है। इसका अर्थ है कि अब हम अपने प्रायोगिक क्लस्टर में 10.100.0.2:32213 या 10.100.0.2:32213 पर किसी भी नोड के माध्यम से सेवा से जुड़ सकते हैं। इस स्थिति में, ट्रैफ़िक को सेवा पर पुनर्निर्देशित किया जाएगा।

इसके बाद सिस्टम के हिस्से ने अपनी जगह ले ली है, हमारे पास क्लस्टर के सभी नोड्स के लिए क्लाइंट अनुरोधों द्वारा बनाए गए लोड को संतुलित करने के लिए पाइपलाइन के सभी टुकड़े हैं।


NodePort सेवा

पिछले आंकड़े में, क्लाइंट एक सार्वजनिक आईपी पते के माध्यम से लोड बैलेंसर से कनेक्ट होता है, लोड बैलेंसर नोड का चयन करता है और इसे 10.100.0.3:32213 पर जोड़ता है, क्यूब-प्रॉक्सी इस कनेक्शन को स्वीकार करता है और इसे क्लस्टर आईपी 10.3.241.152:80 माध्यम से सेवा के लिए सुलभ 10.3.241.152:80 । यहां, अनुरोध को नेटफिल्टर द्वारा निर्धारित नियमों के अनुसार सफलतापूर्वक संसाधित किया गया है, और इसे 10.0.2.2:8080 पते पर सर्वर पॉड पर पुनर्निर्देशित किया गया है। शायद यह सब थोड़ा जटिल लग सकता है, और कुछ हद तक यह है, लेकिन यह एक सरल समाधान के साथ आना आसान नहीं है जो सभी महान विशेषताओं का समर्थन करता है जो हमें पॉड्स और सेवा-आधारित नेटवर्क देते हैं।

यह तंत्र, हालांकि, अपनी समस्याओं के बिना नहीं है। NodePort जैसी सेवाओं का उपयोग करना ग्राहकों को एक गैर-मानक पोर्ट का उपयोग करके सेवाओं तक पहुंच प्रदान करता है। अक्सर यह कोई समस्या नहीं है, क्योंकि लोड बैलेंसर उन्हें एक नियमित पोर्ट प्रदान कर सकता है और एंड यूजर्स से NodePort छिपा NodePort है। लेकिन कुछ परिदृश्यों में, उदाहरण के लिए, एक बाहरी Google क्लाउड प्लेटफ़ॉर्म लोड बैलेंसर का उपयोग करते समय, क्लाइंट NodePort परिनियोजित करना आवश्यक हो सकता है। यह ध्यान दिया जाना चाहिए कि ऐसे बंदरगाह, इसके अलावा, सीमित संसाधनों का प्रतिनिधित्व करते हैं, हालांकि 2768 बंदरगाह संभवतः सबसे बड़े समूहों के लिए भी पर्याप्त हैं। ज्यादातर मामलों में, आप कुबेरनेट्स को पोर्ट संख्याओं को यादृच्छिक रूप से चुनने दे सकते हैं, लेकिन यदि आवश्यक हो तो आप उन्हें स्वयं सेट कर सकते हैं। अनुरोध में स्रोत IP पतों के भंडारण के संबंध में एक और समस्या कुछ सीमाएँ हैं। इन समस्याओं को हल करने का तरीका जानने के लिए, आप इस सामग्री को कुबेरनेट्स प्रलेखन से संदर्भित कर सकते हैं।

पोर्ट्स NodePorts मूलभूत तंत्र है जिसके द्वारा सभी बाहरी ट्रैफ़िक Kubernetes क्लस्टर में प्रवेश करते हैं। हालांकि, वे खुद हमें तैयार समाधान के साथ पेश नहीं करते हैं। उपरोक्त कारणों से, क्लस्टर से पहले, चाहे ग्राहक आंतरिक हो या बाहरी सार्वजनिक क्षेत्र में स्थित इकाइयाँ हों, हमेशा किसी प्रकार के लोड बैलेंसर की आवश्यकता होती है।

प्लेटफ़ॉर्म आर्किटेक्ट्स ने इसे महसूस करते हुए कुबेरनेट्स प्लेटफॉर्म से लोड बैलेंसर को कॉन्फ़िगर करने के दो तरीके प्रदान किए। आइए इस पर चर्चा करें।

लोडबैंसर और इनग्रेड प्रकार के संसाधन जैसी सेवाएं

LoadBalancer जैसी सेवाएं और LoadBalancer प्रकार के संसाधन कुछ सबसे जटिल कुबेरनेट तंत्र हैं। हालांकि, हम उन पर बहुत अधिक समय नहीं बिताएंगे, क्योंकि उनके उपयोग से हर उस चीज में मूलभूत परिवर्तन नहीं होता है जिसके बारे में हमने अब तक बात की है। सभी बाहरी ट्रैफ़िक, पहले की तरह, NodePort माध्यम से क्लस्टर में प्रवेश करते हैं।

आर्किटेक्ट यहां रुक सकते थे, जो केवल सार्वजनिक आईपी पते और लोड बैलेंसरों की देखभाल करने के लिए क्लस्टर बनाने वालों को अनुमति देते थे। वास्तव में, कुछ स्थितियों में, जैसे कि नियमित सर्वर पर या घर पर क्लस्टर शुरू करना, ठीक यही वे करते हैं। लेकिन ऐसे वातावरण में जो एपीआई-नियंत्रित नेटवर्क संसाधन कॉन्फ़िगरेशन का समर्थन करते हैं, कुबेरनेट आपको एक जगह पर अपनी ज़रूरत की सभी चीज़ों को कॉन्फ़िगर करने की अनुमति देता है।

इस समस्या को हल करने का पहला तरीका, सबसे सरल, लोडबेलर जैसे कुबेरनेट सेवाओं का उपयोग LoadBalancer । इस तरह की सेवाओं में NodePort जैसी सेवाओं की सभी क्षमताएं हैं, और, इसके अलावा, आने वाले ट्रैफ़िक के लिए पूर्ण पथ बनाने की क्षमता है, इस धारणा के आधार पर कि क्लस्टर GCP या AWS जैसे वातावरण में चल रहा है जो API के माध्यम से नेटवर्क के कॉन्फ़िगरेशन का समर्थन करता है।

 kind: Service apiVersion: v1 metadata: name: service-test spec: type: LoadBalancer selector:   app: service_test_pod ports: - port: 80   targetPort: http 

यदि हम Google Kubernetes इंजन में अपने उदाहरण से सेवा को हटाते हैं और फिर से बनाते हैं, तो उसके तुरंत बाद, kubectl get svc service-test का उपयोग करके kubectl get svc service-test आदेश मिलता है, हम यह सत्यापित कर सकते हैं कि बाहरी IP को असाइन किया गया है।

 $ kubectl get svc service-test NAME      CLUSTER-IP      EXTERNAL-IP PORT(S)          AGE openvpn   10.3.241.52     35.184.97.156 80:32213/TCP     5m 

ऊपर कहा गया है कि हम बाहरी आईपी पते को "जल्द ही" असाइन करने के तथ्य को सत्यापित करने में सक्षम होंगे, इस तथ्य के बावजूद कि बाहरी आईपी के असाइनमेंट में कई मिनट लग सकते हैं, जो किसी स्वस्थ राज्य में लाने के लिए आवश्यक संसाधनों की मात्रा को देखते हुए आश्चर्य की बात नहीं है। उदाहरण के लिए, GCP प्लेटफ़ॉर्म पर, सिस्टम को बाहरी IP पता, ट्रैफ़िक पुनर्निर्देशन नियम, लक्ष्य प्रॉक्सी सर्वर, बैकएंड सेवा, और संभवतः, समूह का एक उदाहरण बनाने की आवश्यकता होती है। एक बाहरी आईपी पता आवंटित करने के बाद, आप इस पते के माध्यम से सेवा से जुड़ सकते हैं, इसे एक डोमेन नाम निर्दिष्ट कर सकते हैं और ग्राहकों को सूचित कर सकते हैं। जब तक सेवा को नष्ट नहीं किया जाता है और फिर से बनाया जाता है (ऐसा करने के लिए, शायद ही कभी जब कोई अच्छा कारण होता है), तो आईपी पता नहीं बदलेगा।

LoadBalancer जैसी सेवाओं की कुछ सीमाएँ हैं। ऐसी सेवा को HTTPS ट्रैफ़िक को डिक्रिप्ट करने के लिए कॉन्फ़िगर नहीं किया जा सकता है। आप वर्चुअल होस्ट नहीं बना सकते हैं या पथ-आधारित रूटिंग को कॉन्फ़िगर नहीं कर सकते हैं, इसलिए आप व्यावहारिक कॉन्फ़िगरेशन का उपयोग करके, कई सेवाओं के साथ एकल लोड बैलेंसर का उपयोग नहीं कर सकते हैं। इन सीमाओं के कारण कुबेरनेट्स 1.1 की शुरुआत हुई। लोड बैलेंसरों को कॉन्फ़िगर करने के लिए एक विशेष संसाधन। यह इनग्रेड प्रकार का एक संसाधन है। LoadBalancer जैसी सेवाओं का उद्देश्य बाहरी ग्राहकों का समर्थन करने के लिए एकल सेवा की क्षमताओं का विस्तार करना है। इसके विपरीत, Ingress संसाधन विशेष संसाधन हैं जो आपको लचीले ढंग से लोड बैलेंसरों को कॉन्फ़िगर करने की अनुमति देते हैं। Ingress API TLS ट्रैफ़िक, वर्चुअल होस्ट और पथ-आधारित रूटिंग के डिक्रिप्शन का समर्थन करता है। इस एपीआई का उपयोग करते हुए, लोड बैलेंसर को आसानी से कई बैकएंड सेवाओं के साथ काम करने के लिए कॉन्फ़िगर किया जा सकता है।

Ingress प्रकार के संसाधन API यहां अपनी विशेषताओं पर चर्चा करने के लिए बहुत बड़ा है; यह, इसके अलावा, यह विशेष रूप से प्रभावित नहीं करता है कि नेटवर्क स्तर पर इनग्रेड संसाधन कैसे काम करते हैं। इस संसाधन का कार्यान्वयन सामान्य कुबेरनेट पैटर्न का अनुसरण करता है: इस प्रकार को नियंत्रित करने के लिए एक संसाधन प्रकार और एक नियंत्रक है। इस मामले में संसाधन Ingress संसाधन है, जो नेटवर्क संसाधनों के अनुरोधों का वर्णन करता है। यहाँ एक Ingress संसाधन का वर्णन कैसा दिख सकता है।

 apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test-ingress annotations:   kubernetes.io/ingress.class: "gce" spec: tls:   - secretName: my-ssl-secret rules: - host: testhost.com   http:     paths:     - path: /*       backend:         serviceName: service-test         servicePort: 80 

इनग्रेस कंट्रोलर अन्य संसाधनों को वांछित स्थिति में लाकर इन अनुरोधों को निष्पादित करने के लिए जिम्मेदार है। Ingress का उपयोग करते समय, NodePort जैसी सेवाएँ बनाई NodePort हैं, जिसके बाद Ingress नियंत्रक को नोड्स पर यातायात को कैसे निर्देशित किया जाए, इस पर निर्णय लेने की अनुमति दी जाती है। NCEx और haproxy जैसे लोकप्रिय प्रॉक्सी सर्वरों के लिए GWS लोड बैलेन्सर के लिए Ingress कंट्रोलर का कार्यान्वयन है। ध्यान दें कि LoadBalancer जैसे LoadBalancer संसाधनों और सेवाओं को LoadBalancer से कुछ वातावरणों में छोटी समस्याएं हो सकती हैं। वे संभालना आसान है, लेकिन, सामान्य तौर पर, सरल सेवाओं के लिए भी केवल इनग्रेड का उपयोग करना सबसे अच्छा है।

HostPort और HostNetwork

अब हम HostPort बारे में बात करने जा रहे हैं, अर्थात् HostPort और HostNetwork , को दिलचस्प दुर्लभताओं की श्रेणी के बजाय जिम्मेदार ठहराया जा सकता है, न कि उपयोगी टूल को। वास्तव में, मैं यह दावा करने का कार्य करता हूं कि 99.99% मामलों में उनके उपयोग को एक विरोधी पैटर्न माना जा सकता है, और किसी भी प्रणाली जिसमें उनका उपयोग किया जाता है उसे इसकी वास्तुकला की अनिवार्य जांच से गुजरना होगा।

मुझे लगा कि यह उनके बारे में बात करने के लायक नहीं है, लेकिन वे आने वाले यातायात को संसाधित करने के लिए इनग्रेड संसाधनों द्वारा उपयोग किए जाने वाले उपकरण की तरह हैं, इसलिए मैंने फैसला किया कि यह कम से कम संक्षेप में उनका उल्लेख करने योग्य था।

सबसे पहले बात करते हैं HostPort । यह एक कंटेनर संपत्ति ( ContainerPort संरचना में घोषित) है। जब इसमें एक निश्चित पोर्ट संख्या लिखी जाती है, तो यह इस पोर्ट को नोड पर और इसके पुनर्निर्देशन को सीधे कंटेनर में ले जाती है। कोई समीपवर्ती तंत्र नहीं हैं, और पोर्ट केवल उन नोड्स पर खुलता है जिन पर कंटेनर चल रहा है। प्लेटफॉर्म के शुरुआती दिनों में, डेमनसेट और स्टेटफुलसेट मैकेनिज्म के सामने आने के बाद, HostPort एक ट्रिक थी जिसने किसी भी नोड पर एक निश्चित प्रकार के केवल एक कंटेनर को लॉन्च करने की अनुमति दी थी। उदाहरण के लिए, मैंने एक बार HostPort को 9200 सेट करके और कई प्रतिकृतियों के रूप में निर्दिष्ट करते हुए एक Elasticsearch क्लस्टर बनाने के लिए इसका उपयोग किया था क्योंकि इसमें नोड्स थे। , Kubernetes, - HostPort .

NostNetwork , , Kubernetes , HostPort . true , - network=host docker run . , . eth0 . , . , , , Kubernetes, - .

परिणाम

Kubernetes, , Ingress. , , , Kubernetes.

प्रिय पाठकों! Ingress?