सर्विसेज, लोड बैलेंसिंग और नेटवर्किंग

कुबेर्नेट्स नेटवर्क मॉडल

कुबेर्नेट्स नेटवर्क मॉडल कई हिस्सों से बना है:

• क्लस्टर में प्रत्येक पॉड को अपना विशिष्ट क्लस्टर-व्यापी IP एड्रेस मिलता है।

क्लस्टर में प्रत्येक पॉड को अपना विशिष्ट क्लस्टर-व्यापी IP एड्रेस मिलता है।

• एक पॉड का अपना निजी नेटवर्क नेमस्पेस होता है जिसे उस पॉड के सभी कंटेनर आपस में साझा करते हैं। एक ही पॉड में अलग-अलग कंटेनरों में चलने वाले प्रोसेस localhost के माध्यम से एक-दूसरे से बात कर सकते हैं।

• पॉड नेटवर्क (जिसे क्लस्टर नेटवर्क भी कहा जाता है) पॉड्स के बीच संचार को संभालता है। यह सुनिश्चित करता है कि (जानबूझकर नेटवर्क विभाजन को छोड़कर):

  • सभी पॉड्स सभी अन्य पॉड्स से बात कर सकते हैं, चाहे वे एक ही नोड पर हों या अलग-अलग नोड्स पर। पॉड्स सीधे एक-दूसरे से बिना किसी प्रॉक्सी या एड्रेस ट्रांसलेशन (NAT) के बात कर सकते हैं।

    Windows पर, यह नियम होस्ट-नेटवर्क पॉड्स पर लागू नहीं होता।

  • नोड पर एजेंट (जैसे सिस्टम डेमॉन या kubelet) उस नोड पर सभी पॉड्स से बात कर सकते हैं।

• सर्विस API आपको एक स्थायी IP एड्रेस या होस्टनेम प्रदान करता है जो एक या अधिक बैकएंड पॉड्स द्वारा चलाई जा रही सर्विस के लिए होता है। सर्विस बनाने वाले पॉड्स समय के साथ बदल सकते हैं।

  • कुबेर्नेट्स अपने आप एंडपॉइंटस्लाइस ऑब्जेक्ट्स को मैनेज करता है ताकि सर्विस के वर्तमान पॉड्स की जानकारी उपलब्ध रहे।

  • एक सर्विस प्रॉक्सी इम्प्लीमेंटेशन Service और EndpointSlice ऑब्जेक्ट्स के सेट की निगरानी करता है और डेटा प्लेन को प्रोग्राम करता है ताकि सर्विस ट्रैफिक को उसके बैकएंड्स तक रूट किया जा सके। यह ऑपरेटिंग सिस्टम या क्लाउड प्रोवाइडर के API का उपयोग करके पैकेट्स को इंटरसेप्ट या रीराइट करता है।

• गेटवे API (या इसका पहले का वर्जन, इंग्रेस) आपको क्लस्टर के बाहर के क्लाइंट्स के लिए सर्विसेज को एक्सेस करने की सुविधा देता है।

  • क्लस्टर में बाहर से एक्सेस के लिए एक सरल, लेकिन कम कॉन्फ़िगर करने योग्य तरीका सर्विस API के type: LoadBalancer के माध्यम से उपलब्ध है, जब एक सपोर्टेड क्लाउड प्रदाता (Cloud Provider) का उपयोग किया जाता है।

• नेटवर्क पॉलिसी एक बिल्ट-इन Kubernetes API है जो आपको पॉड्स के बीच या पॉड्स और बाहरी दुनिया के बीच ट्रैफ़िक को नियंत्रित करने की अनुमति देता है।

पुराने कंटेनर सिस्टम में, विभिन्न होस्ट्स पर कंटेनरों के बीच स्वचालित कनेक्टिविटी नहीं होती थी, इसलिए कंटेनरों के बीच स्पष्ट लिंक बनाना या अन्य होस्ट्स पर कंटेनरों द्वारा उन्हें सुलभ बनाने के लिए कंटेनर पोर्ट्स को होस्ट पोर्ट्स पर मैप करना अक्सर आवश्यक होता था। Kubernetes में यह आवश्यक नहीं है; Kubernetes का मॉडल है कि पॉड्स को VMs या भौतिक होस्ट्स की तरह माना जा सकता है, पोर्ट आवंटन, नामकरण, सर्विस डिस्कवरी, लोड बैलेंसिंग, एप्लिकेशन कॉन्फ़िगरेशन और माइग्रेशन के दृष्टिकोण से।

इस मॉडल के केवल कुछ हिस्से ही Kubernetes द्वारा स्वयं लागू किए जाते हैं। अन्य भागों के लिए, Kubernetes API को परिभाषित करता है, लेकिन संबंधित कार्यक्षमता बाहरी घटकों द्वारा प्रदान की जाती है, जिनमें से कुछ वैकल्पिक हैं:

• पॉड नेटवर्क नेमस्पेस सेटअप कंटेनर रनटाइम इंटरफ़ेस को लागू करने वाले सिस्टम-स्तरीय सॉफ़्टवेयर द्वारा संभाला जाता है।

• पॉड नेटवर्क का प्रबंधन एक पॉड नेटवर्क कार्यान्वयन द्वारा किया जाता है। Linux पर, अधिकांश कंटेनर रनटाइम्स पॉड नेटवर्क कार्यान्वयन के साथ इंटरैक्ट करने के लिए कंटेनर नेटवर्किंग इंटरफ़ेस (CNI) का उपयोग करते हैं, इसलिए इन कार्यान्वयनों को अक्सर CNI प्लगइन्स कहा जाता है।

• Kubernetes सर्विस प्रॉक्सींग का एक डिफ़ॉल्ट कार्यान्वयन प्रदान करता है, जिसे kube-proxy कहा जाता है, लेकिन कुछ पॉड नेटवर्क कार्यान्वयन इसके बजाय अपने स्वयं के सर्विस प्रॉक्सी का उपयोग करते हैं जो शेष कार्यान्वयन के साथ अधिक दृढ़ता से एकीकृत होता है।

• NetworkPolicy आमतौर पर पॉड नेटवर्क कार्यान्वयन द्वारा भी लागू की जाती है। (कुछ सरल पॉड नेटवर्क कार्यान्वयन NetworkPolicy को लागू नहीं करते हैं, या एक व्यवस्थापक पॉड नेटवर्क को NetworkPolicy समर्थन के बिना कॉन्फ़िगर करना चुन सकता है। इन मामलों में, API अभी भी मौजूद होगा, लेकिन उसका कोई प्रभाव नहीं होगा।)

• गेटवे API के कई कार्यान्वयन हैं, जिनमें से कुछ विशेष क्लाउड ए

आगे क्या है

सर्विसेज के साथ अनुप्रयोगों को कनेक्ट करना ट्यूटोरियल आपको एक व्यावहारिक उदाहरण के साथ सर्विसेज और Kubernetes नेटवर्किंग के बारे में सीखने में मदद करता है।

क्लस्टर नेटवर्किंग बताता है कि अपने क्लस्टर के लिए नेटवर्किंग कैसे सेटअप करें, और शामिल प्रौद्योगिकियों का एक समीक्षा भी प्रदान करता है।