👩‍⚕️ 🏆 🖕🏻 [इलस्ट्रेटेड] कुबेरनेट्स में नेटवर्किंग के लिए गाइड। भाग ३ 💏 👨‍👩‍👧‍👧 🕵🏾

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

क्लस्टर की गतिशीलता

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

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

कुबेरनेट्स में सेवा ऑब्जेक्ट में लेबल चयनकर्ता

इस वर्चुअल आईपी के पूरे कार्यान्वयन के पीछे iptables नियम हैं (कुबेरनेट के नवीनतम संस्करणों में भी IPVS का उपयोग करने की क्षमता है , लेकिन यह एक अन्य चर्चा का विषय है), जिसे क्यूब-प्रॉक्सी नामक कुबेरनेट्स घटक द्वारा नियंत्रित किया जाता है। हालाँकि, ऐसा नाम आज की वास्तविकताओं में भ्रामक है। Kubernetes v1.0 की रिलीज से पहले के दिनों में Kube- प्रॉक्सी का उपयोग वास्तव में प्रॉक्सी के रूप में किया गया था, लेकिन इससे कर्नेल स्पेस और यूजर स्पेस के बीच निरंतर कॉपी ऑपरेशन के कारण संसाधनों और ब्रेक की बड़ी खपत हुई। अब यह सिर्फ एक नियंत्रक है - कुबेरनेट्स में कई अन्य नियंत्रकों की तरह। यह एंडपॉइंट्स में बदलाव के लिए एपीआई सर्वर की निगरानी करता है और तदनुसार iptables नियमों को अपडेट करता है।

इन iptables नियमों के अनुसार, यदि पैकेट सेवा के आईपी पते के लिए अभिप्रेत है, तो इसके लिए एक गंतव्य नेटवर्क पता अनुवाद (DNAT) किया जाता है: इसका मतलब है कि इसका आईपी पता सेवा के आईपी से अंतिम छोर तक बदल जाएगा, अर्थात फली के आईपी पते में से एक, जो iptables बेतरतीब ढंग से चयन करता है। यह सुनिश्चित करता है कि लोड को फली के बीच समान रूप से वितरित किया गया है।

DNAT iptables में

इस तरह के DNAT के मामले में, आवश्यक जानकारी को कॉनट्रैक में संग्रहीत किया जाता है - लिनक्स में कनेक्शन लेखा तालिका (यह iptables द्वारा किए गए पांच-जोड़ी अनुवादों को संग्रहीत करता है: protocol , srcIP , srcPort , dstIP , dstPort )। सब कुछ इस तरह से व्यवस्थित किया जाता है कि जब कोई प्रतिक्रिया वापस आती है, तो रिवर्स DNAT ऑपरेशन (un-DNAT) हो सकता है, अर्थात फली आईपी से सेवा आईपी के लिए आईपी स्रोत की जगह। इस क्लाइंट के लिए धन्यवाद, पर्दे के पीछे पैकेज के साथ काम करने के लिए जानने की बिल्कुल आवश्यकता नहीं है।

पांच-जोड़ी (5-ट्यूपल) प्रविष्टियाँ तालिका में

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

संकेत : दूसरा रास्ता चुनकर, आप बहुत सारी अनावश्यक DNS कॉल्स बचाते हैं!

बाहर जाने वाला यातायात

ऊपर वर्णित कुबेरनेट सेवाएं एक क्लस्टर के भीतर काम करती हैं। व्यवहार में, अनुप्रयोगों को आमतौर पर कुछ बाहरी एपीआई / साइटों तक पहुंच की आवश्यकता होती है।

सामान्य तौर पर, होस्ट में निजी और सार्वजनिक दोनों आईपी पते हो सकते हैं। इंटरनेट तक पहुंचने के लिए, इन निजी और सार्वजनिक आईपी पते के लिए एक-पर-एक NAT प्रदान किया जाता है - यह विशेष रूप से क्लाउड वातावरण के लिए सच है।

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

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

आनेवाला यातायात

अब तक सब कुछ ठीक था। फली एक दूसरे के साथ और इंटरनेट के साथ संवाद कर सकते हैं। हालांकि, हमारे पास अभी भी मुख्य चीज की कमी है - उपयोगकर्ता यातायात की सेवा। वर्तमान में इसे लागू करने के दो तरीके हैं:

1. NodePort / क्लाउड लोड बैलेंसर (L4 स्तर: IP और पोर्ट)

NodePort को सेवा के प्रकार के रूप में सेट करना NodePort सेवा को NodePort की सीमा में असाइन करेगा। यह nodePort प्रत्येक नोड पर खुला होता है, तब भी जब नोड पर कोई पॉड नहीं चल रहा हो। इस NodePort पर आने वाले ट्रैफ़िक को NodePort से एक के लिए निर्देशित किया NodePort है (जो कि दूसरे नोड पर भी दिखाई दे सकता है!), फिर से NodePort उपयोग करते हुए।

क्लाउड वातावरण में सेवा का प्रकार LoadBalancer क्लाउड LoadBalancer बैलेंसर बनाता है (उदाहरण के लिए, ELB) सभी नोड्स के सामने, उसी NodePort साथ आगे काम करते हुए।

2. प्रवेश (L7 स्तर: HTTP / TCP)

कई अन्य कार्यान्वयन भी इसी बैकेंड के साथ HTTP होस्ट / पाथ मैपिंग करते हैं - उदाहरण के लिए, nginx, traefik, HAProxi, आदि। उनके साथ, LoadBalancer और NodePort फिर से ट्रैफ़िक के लिए प्रवेश बिंदु बन जाते हैं, लेकिन यहाँ लाभ यह है कि हमें कई NodePort / LoadBalancers के बजाय सभी सेवाओं के आने वाले ट्रैफ़िक की सेवा के लिए केवल एक Ingress की आवश्यकता है।

नेटवर्क नीतियां

नेटवर्क नीतियों को पॉड्स के लिए सुरक्षा समूह / एसीएल के रूप में सोचा जा सकता है। NetworkPolicy नियम पॉड्स के बीच ट्रैफ़िक की अनुमति / खंडन करते हैं। उनका सटीक कार्यान्वयन नेटवर्क लेयर / CNI पर निर्भर करता है, लेकिन उनमें से ज्यादातर केवल iptables का उपयोग करते हैं।

...

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

अनुवादक से पी.एस.

हमारे ब्लॉग में भी पढ़ें:

[इलस्ट्रेटेड] कुबेरनेट्स में नेटवर्किंग के लिए गाइड। भाग ३