कुबेरनेट्स नेटवर्क: पॉड्स

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

pody

क्या (फली) कुबेरनेट्स के तहत है? उप एक इकाई है जिसमें एक या अधिक कंटेनर होते हैं जो एक ही होस्ट पर होस्ट किए जाते हैं और नेटवर्क स्टैक संसाधनों और वॉल्यूम जैसे अन्य संसाधनों को साझा करने के लिए कॉन्फ़िगर किए जाते हैं। पॉड्स बुनियादी बिल्डिंग ब्लॉक हैं जो कुबेरनेट्स प्लेटफॉर्म पर चलने वाले एप्लिकेशन बनाते हैं। पॉड्स एक नेटवर्क स्टैक साझा करते हैं। व्यवहार में, इसका मतलब है कि सभी कंटेनर जो चूल्हा बनाते हैं, स्थानीयहोस्ट के माध्यम से एक दूसरे के साथ संवाद कर सकते हैं। अगर चूल्हे में एक कंटेनर होता है जो कि नग्नेक्स चलाता है, तो पोर्ट 80 पर सुन रहा है, और एक अन्य कंटेनर जो स्क्रेपिड चलाता है, यह कंटेनर http://localhost:80 पर पहले कंटेनर तक पहुंच सकता है। यह इतना मुश्किल नहीं है। अब हम अपने आप से पूछें कि यह वास्तव में कैसे काम करता है। आइए एक विशिष्ट स्थिति पर नज़र डालें, जब स्थानीय मशीन पर डॉकर कंटेनर लॉन्च किया जाता है।


स्थानीय मशीन पर चल रहा डॉकटर कंटेनर

यदि आप इस योजना को ऊपर से नीचे तक देखते हैं, तो यह पता चलता है कि एक भौतिक नेटवर्क इंटरफ़ेस eth0 । docker0 पुल इसके docker0 , और docker0 वर्चुअल नेटवर्क इंटरफ़ेस पुल से veth0 है। ध्यान दें कि docker0 और veth0 एक ही नेटवर्क पर हैं, इस उदाहरण में यह 172.17.0.0/24 । इस नेटवर्क पर, docker0 IP पता 172.17.0.1 सौंपा गया है, यह इंटरफ़ेस veth0 लिए डिफ़ॉल्ट गेटवे है, जिसे पता 172.17.0.2 सौंपा गया है। कंटेनर को शुरू करते समय नेटवर्क नेमस्पेस सेट करने की veth0 कारण, कंटेनर के अंदर की प्रक्रिया केवल veth0 इंटरफ़ेस को docker0 और docker0 और eth0 इंटरफेस के माध्यम से बाहरी दुनिया के साथ बातचीत करती है। अब दूसरा कंटेनर चलाएं।


स्थानीय मशीन पर चलने वाले दो डॉकटर कंटेनर

जैसा कि आप ऊपर दिए गए आरेख में देख सकते हैं, नए वर्चुअल नेटवर्क इंटरफ़ेस veth1 को दूसरे कंटेनर को सौंपा गया है, जो पहले कंटेनर के समान पुल से जुड़ा हुआ है - docker0 । यह वास्तव में क्या हो रहा है, इसका संक्षिप्त विवरण है। इसके अलावा, यह ध्यान दिया जाना चाहिए कि कंटेनर और पुल के बीच संबंध स्थापित वर्चुअल ईथरनेट इंटरफेस की एक जोड़ी के लिए धन्यवाद है, जिनमें से एक कंटेनर नेमस्पेस और दूसरा रूट नेटवर्क नेमस्पेस में है। इस पर विवरण यहां पाया जा सकता है ।

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


कंटेनर एक सामान्य नेटवर्क इंटरफ़ेस का उपयोग करते हैं

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

कुबेरनेट प्रत्येक चूल्हे के लिए एक विशेष कंटेनर बनाकर इस पैटर्न को लागू करता है जिसका एकमात्र उद्देश्य अन्य चूल्हा कंटेनरों के लिए एक नेटवर्क इंटरफ़ेस प्रदान करना है। यदि आप Kubernetes क्लस्टर के नोड से कनेक्ट होते हैं जो ssh द्वारा एक विशिष्ट उप असाइन किया गया है और docker docker ps रन करता है, तो आप कम से कम एक कंटेनर को pause कमांड के साथ चलाते हुए देखेंगे। यह कमांड वर्तमान प्रक्रिया को तब तक SIGTERM जब तक SIGTERM सिग्नल नहीं आ जाता है। ऐसे कंटेनर बिल्कुल कुछ नहीं करते हैं, वे "नींद" स्थिति में हैं और इस संकेत की प्रतीक्षा कर रहे हैं। इस तथ्य के बावजूद कि "निलंबित" कंटेनर कुछ भी नहीं करते हैं, इसलिए वे बोलते हैं, चूल्हा का "दिल", एक वर्चुअल नेटवर्क इंटरफ़ेस के साथ अन्य कंटेनर प्रदान करना जो वे एक दूसरे के साथ या बाहरी दुनिया के साथ बातचीत करने के लिए उपयोग कर सकते हैं। नतीजतन, यह पता चलता है कि एक काल्पनिक वातावरण के तहत जैसा दिखता है, हमारी पिछली योजना नीचे दिखाए गए की तरह दिखेगी।


हाइपोथेटिकल कंटेनर

चूल्हा नेटवर्क

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

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


एक सरल दो-नोड क्लस्टर

यदि प्रश्न में क्लस्टर GCP या AWS जैसे क्लाउड वातावरण में चल रहा है, तो यह योजना व्यक्तिगत परियोजनाओं के लिए डिफ़ॉल्ट नेटवर्क आर्किटेक्चर के सार को सटीक रूप से बताती है। प्रदर्शन उद्देश्यों के लिए, इस उदाहरण में निजी नेटवर्क 10.100.0.0/24 उपयोग किया 10.100.0.0/24 । नतीजतन, पते 10.100.0.1 सौंपा गया है, और 10.100.0.2 और 10.100.0.3 पते दो नोड्स 10.100.0.3 । इस आर्किटेक्चर का उपयोग करते हुए, प्रत्येक नोड अपने eth0 नेटवर्क इंटरफ़ेस का उपयोग करके अन्य के साथ बातचीत कर सकता है। अब याद करते हैं कि अंडर, होस्ट पर चल रहा है, इस निजी नेटवर्क पर नहीं है। यह पूरी तरह से अलग नेटवर्क में पुल से जुड़ा है। यह एक वर्चुअल नेटवर्क है जो केवल एक विशिष्ट नोड के भीतर ही मौजूद है। इसे स्पष्ट करने के लिए, आइए पिछली योजना को फिर से परिभाषित करें, इसे जोड़कर हमने ऊपर एक काल्पनिक चूल्हा कहा।


फली और नोड्स

इस आरेख के बाईं ओर स्थित होस्ट में eht0 पते के साथ एक eht0 इंटरफ़ेस है, जिसके लिए डिफ़ॉल्ट गेटवे 10.100.0.1 पते के साथ राउटर है। docker0 पते के साथ docker0 ब्रिज इस इंटरफेस 172.17.0.1 जुड़ा है, और इसके लिए, veth0 साथ वर्चुअल इंटरफ़ेस veth0 माध्यम से जुड़ा हुआ है, जिसे हम यहाँ चूल्हा कहते हैं। एक निलंबित कंटेनर में veth0 इंटरफ़ेस बनाया गया था। यह साझा नेटवर्क स्टैक के माध्यम से सभी तीन कंटेनरों में दिखाई देता है। इस तथ्य के कारण कि पुल बनाते समय स्थानीय रूटिंग नियम कॉन्फ़िगर किए गए हैं, कोई भी पैकेट eth0 पर पहुंचने और गंतव्य का पता 172.17.0.2 होने पर पुल पर पुनर्निर्देशित किया जाएगा, जो इसे veth0 वर्चुअल इंटरफ़ेस के लिए अग्रेषित करेगा। जबकि यह सब बहुत अच्छा लग रहा है। यदि यह ज्ञात है कि जिस होस्ट की हम चर्चा कर रहे हैं, 172.17.0.2 पता 172.17.0.2 , तो हम राउटर सेटिंग्स में एक नियम जोड़ सकते हैं, जो बताता है कि इस पते के लिए अगला संक्रमण 10.100.0.2 , जिसके बाद वहां से पैकेटों को veth0 पुनर्निर्देशित किया जाना चाहिए। बहुत बढ़िया। अब एक और मेजबान पर एक नज़र डालते हैं।

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

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


चूल्हा नेटवर्क

यह तुरंत आंख को पकड़ लेता है कि पुल के नाम docker0 से docker0 बदल दिए जाते हैं। कुबेरनेट्स मानक डॉकर पुलों का उपयोग नहीं करते हैं। जिसे हम cbr कहते हैं, वह "कस्टम ब्रिज" का संक्षिप्त नाम है, यानी हम कुछ विशेष पुलों के बारे में बात कर रहे हैं। मैं डॉक कंटेनर को पॉड में लॉन्च करने और उन्हें साधारण कंप्यूटर पर चलाने के बीच के अंतरों की पूरी सूची देने के लिए तैयार नहीं हूं, लेकिन हम यहां जो बात कर रहे हैं, वह महत्वपूर्ण समान अंतरों में से एक है। इसके अलावा, आपको इस तथ्य पर ध्यान देने की आवश्यकता है कि इस उदाहरण में पुलों को दिया गया पता स्थान 10.0.0.0/14 । यह पता हमारे मंचन समूहों में से एक से लिया गया है, जो Google क्लाउड प्लेटफ़ॉर्म पर तैनात हैं, इसलिए ऊपर एक चूल्हा नेटवर्क का एक बहुत ही वास्तविक उदाहरण है। आपके क्लस्टर को पते की पूरी तरह से भिन्न श्रेणी सौंपी जा सकती है। दुर्भाग्य से, फिलहाल kubectl उपयोगिता का उपयोग करके इन पतों के बारे में जानकारी प्राप्त करने का कोई तरीका नहीं है, लेकिन, उदाहरण के लिए, यदि आप जीसीपी का उपयोग करते हैं, तो आप gcloud container clusters describe <cluster> तरह एक कमांड चला सकते हैं gcloud container clusters describe <cluster> और gcloud container clusters describe <cluster> में देखें clusterIpv4Cidr गुण।

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

परिणाम

आज हमने कुबेरनेट्स पॉड्स और उनके नेटवर्किंग की विशेषताओं के बारे में बात की। हमें उम्मीद है कि यह सामग्री आपको कुबेरनेट नेटवर्क पर जटिल चूल्हा बातचीत परिदृश्यों को लागू करने की दिशा में सही कदम उठाने में मदद करेगी।

प्रिय पाठकों! यह लेख कुबेरनेट नेटवर्क की एक श्रृंखला में पहला है। इस चक्र का दूसरा भाग पहले ही अनुवादित हो चुका है। हम इस बारे में सोच रहे हैं कि तीसरे भाग का अनुवाद करना है या नहीं। हम आपको टिप्पणियों में इस पर टिप्पणी करने के लिए कहते हैं।