VMware उपयोगकर्ताओं के लिए Kubernetes का परिचय। भाग 1. सिद्धांत

यह मेरी कुबेरनेट्स का दूसरा भाग है एंटरप्राइज श्रृंखला की पोस्ट में। जैसा कि मैंने अपनी अंतिम पोस्ट में उल्लेख किया है, "डिज़ाइन और कार्यान्वयन मार्गदर्शिकाएँ" पर चलते समय यह बहुत महत्वपूर्ण है कि हर कोई कुबेरनेट्स (K8s) की समझ के समान स्तर पर है।

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

शुरू करने से पहले महत्वपूर्ण नोट। मैं इस तुलना का उपयोग vSphere और Kubernetes के बीच किसी भी समानता या अंतर को साबित करने के लिए नहीं करता हूं। दोनों, और एक अन्य, संक्षेप में, वितरित सिस्टम हैं, और इसलिए, किसी अन्य समान प्रणाली के साथ समानताएं होनी चाहिए। इसलिए, अंत में, मैं कुबेरनेट्स के रूप में इस तरह की एक अद्भुत तकनीक को अपने उपयोगकर्ताओं के व्यापक समुदाय से परिचित कराने का प्रयास करता हूं।

थोड़ा सा इतिहास

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

दूरसंचार की दुनिया की खोज करने से पहले, मैं एक वेब डेवलपर (2003) था।

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

सबसे पहले मैंने अपने लैपटॉप पर एप्लिकेशन विकसित किया था, LAMP स्टैक जैसी किसी चीज़ का उपयोग करते हुए, जब यह मेरे लैपटॉप पर अच्छी तरह से काम करता था, तो मैंने होस्ट सर्वर पर स्रोत कोड डाउनलोड किया (सभी को रैकशेक याद है?) या ग्राहक के निजी सर्वर पर। आप कल्पना कर सकते हैं कि जैसे ही मैंने ऐसा किया, एप्लिकेशन क्रैश हो गया और इन सर्वरों पर काम नहीं किया। इसका कारण नशा है। सर्वर में लैपटॉप पर मेरे द्वारा उपयोग किए जाने वाले सॉफ़्टवेयर (Apache, PHP, MySQL, आदि) के अन्य संस्करण थे। इसलिए मुझे दूरस्थ सर्वर (बुरे विचार) पर सॉफ़्टवेयर संस्करणों को अपडेट करने का तरीका खोजने की आवश्यकता थी या दूरस्थ सर्वर (सबसे खराब विचार) पर संस्करणों से मिलान करने के लिए अपने लैपटॉप पर कोड को फिर से लिखना। यह एक बुरा सपना था, कभी-कभी मैं खुद से नफरत करता था और सोचता था कि यह ऐसा क्यों है कि मैं कैसे एक जीवित करता हूं।

10 साल बीत चुके हैं, कंपनी डॉकर दिखाई दी। व्यावसायिक सेवाओं (2013) में एक VMware सलाहकार के रूप में, मैंने डॉकर के बारे में सुना, और मुझे यह कहने दिया कि मैं उन दिनों में इस तकनीक को समझ नहीं पाया था। मैंने कुछ कहना जारी रखा: यदि वर्चुअल मशीन हैं तो कंटेनर का उपयोग क्यों करें। तत्काल कंटेनर लॉन्च या हाइपरविजर ओवरहेड को खत्म करने जैसे अजीब फायदे के कारण vSphere HA, DRS या vMotion जैसी महत्वपूर्ण तकनीकें क्यों छोड़ दें। आखिरकार, हर कोई वर्चुअल मशीनों के साथ काम करता है और पूरी तरह से काम करता है। संक्षेप में, मैंने इसे बुनियादी ढांचे के संदर्भ में देखा।

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

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

लेकिन तब Google दिखाई दिया, दुनिया को कई वर्षों तक कंटेनरों के उपयोग के बारे में बता रहा था (वास्तव में, कंटेनर Google द्वारा आविष्कार किए गए थे: cgroups) और उनका उपयोग करने की सही विधि, एक मंच के माध्यम से जिसे उन्होंने कुबेरनेट्स कहा था। फिर उन्होंने कुबेरनेट्स के लिए स्रोत कोड खोला। कुबेरनेट्स समुदाय के सामने पेश किया गया। और इसने फिर से सब कुछ बदल दिया।

Kubernetes बनाम vSphere को समझना

तो कुबेरनेट क्या है? सीधे शब्दों में कहें, कंटेनर के लिए कुबेरनेट्स एक आधुनिक डेटा सेंटर में वर्चुअल मशीनों के लिए vSphere के समान है। यदि आपने 2000 के दशक की शुरुआत में VMware वर्कस्टेशन का उपयोग किया था, तो आप जानते हैं कि इस समाधान को डेटा केंद्रों के समाधान के रूप में गंभीरता से माना गया था। जब vCenter और ESXi होस्ट के साथ VI / vSphere दिखाई दिया, तो आभासी मशीनों की दुनिया नाटकीय रूप से बदल गई। कुबेरनेट्स आज कंटेनरों की दुनिया के साथ वही काम कर रहे हैं, जो उत्पादन में कंटेनरों को लॉन्च करने और प्रबंधित करने की क्षमता ला रहे हैं। और यही कारण है कि हम अपने वितरित कार्यों और प्रौद्योगिकियों को समझने के लिए इस वितरित प्रणाली के विवरण की व्याख्या करने के लिए कुबेरनेट्स के साथ कंधे से कंधा मिलाकर तुलना करना शुरू कर देंगे।

सिस्टम अवलोकन

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


आप देख सकते हैं कि K8s का एक महत्वपूर्ण-मूल्य संग्रह है, जिसे "etcd" कहा जाता है। यह संग्रहण vCenter डेटाबेस के समान है, जहाँ आप इच्छित क्लस्टर कॉन्फ़िगरेशन को सहेजते हैं जिसका आप पालन करना चाहते हैं।

अंतर के रूप में: मास्टर K8s पर आप वर्कलोड भी चला सकते हैं, लेकिन vCenter पर आप नहीं कर सकते। vCenter केवल प्रबंधन के लिए समर्पित एक आभासी उपकरण है। K8s के मामले में, मास्टर को कंप्यूटिंग संसाधन माना जाता है, लेकिन इस पर एंटरप्राइज एप्लिकेशन चलाना एक अच्छा विचार नहीं है।

तो यह वास्तविकता में कैसे दिखेगा? आप मुख्य रूप से कुबेरनेट्स के साथ बातचीत करने के लिए सीएलआई का उपयोग करेंगे (लेकिन जीयूआई अभी भी एक बहुत ही व्यवहार्य विकल्प है)। नीचे दिए गए स्क्रीनशॉट से पता चलता है कि मैं कमांड लाइन के माध्यम से अपने कुबेरनेट्स क्लस्टर से कनेक्ट करने के लिए एक विंडोज मशीन का उपयोग कर रहा हूं (यदि आप रुचि रखते हैं तो मैं cmder का उपयोग करता हूं)। स्क्रीनशॉट में मेरे पास एक मास्टर नोड और 4 नोड्स है। वे K8s v1.6.5 चला रहे हैं, और Ubuntu 16.04 नोड्स पर स्थापित है। इस पोस्ट को लिखने के समय, हम मुख्य रूप से लिनक्स दुनिया में रहते हैं, जहां मास्टर और नोड हमेशा लिनक्स वितरण चला रहे हैं।


CL8 और GUI के माध्यम से K8s क्लस्टर प्रबंधन।

वर्कलोड फॉर्म फैक्टर

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

VSphere में, अनुप्रयोग OS के अंदर चलते हैं, और Kubernetes में, अनुप्रयोग कंटेनर के अंदर चलते हैं। एक वर्चुअल मशीन एक समय में केवल एक ओएस के साथ काम कर सकती है, और एक पॉड कई कंटेनरों को चला सकता है।


यह है कि आप CL8 के माध्यम से kubectl टूल का उपयोग करके K8s क्लस्टर के अंदर पॉड्स को सूचीबद्ध कर सकते हैं, पॉड्स की कार्यक्षमता, उनकी आयु, आईपी पता और नोड्स की जांच कर सकते हैं जो वे वर्तमान में काम कर रहे हैं।

प्रबंध

तो, हम अपने मास्टर्स, नोड्स और पॉड्स का प्रबंधन कैसे करते हैं? VSphere में, हम अपने वर्चुअल इन्फ्रास्ट्रक्चर के घटकों (यदि सभी नहीं) का प्रबंधन करने के लिए वेब क्लाइंट का उपयोग करते हैं। कुबेरनेट्स के लिए, इसी तरह, डैशबोर्ड का उपयोग करना। यह एक अच्छा GUI- आधारित वेब पोर्टल है जिसे आप अपने ब्राउज़र के माध्यम से उसी तरह से एक्सेस कर सकते हैं जैसे vSphere वेब क्लाइंट के साथ। पिछले अनुभागों से, आप देख सकते हैं कि आप CLI से kubeclt कमांड का उपयोग करके अपने K8s क्लस्टर को प्रबंधित कर सकते हैं। यह हमेशा बहस में रहता है कि आप अपना अधिकांश समय सीएलआई में या ग्राफिकल डैशबोर्ड में कहाँ बिताएंगे। चूंकि उत्तरार्द्ध हर दिन एक तेजी से शक्तिशाली उपकरण बन रहा है (आप इस वीडियो को सुनिश्चित करने के लिए देख सकते हैं)। व्यक्तिगत रूप से, मुझे लगता है कि सीएलआई में लंबे समय तक कमांड दर्ज किए बिना, डैशबोर्ड जल्दी से स्थिति की निगरानी करने या K8 के विभिन्न घटकों के विवरण प्रदर्शित करने के लिए बहुत सुविधाजनक है। आप उनके बीच एक प्राकृतिक तरीके से संतुलन बना पाएंगे।

विन्यास

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

हमारी YAML कॉन्फ़िगरेशन फ़ाइलों पर लौटते हुए, आप उन्हें वर्चुअल मशीन के लिए .VMX फ़ाइल या वर्चुअल उपकरण के लिए .OVF डिस्क्रिप्टर के रूप में मान सकते हैं, जिसे आप vSphere पर लागू करना चाहते हैं। ये फ़ाइलें उस वर्कलोड / घटक के कॉन्फ़िगरेशन को परिभाषित करती हैं जिसे आप चलाना चाहते हैं। VMX / OVF फ़ाइलों के विपरीत, जो वर्चुअल VM / एप्लाइंसेस के लिए विशिष्ट हैं, YAML कॉन्फ़िगरेशन फ़ाइलों का उपयोग किसी K8 घटक, जैसे कि प्रतिकृति, सेवाओं, तैनाती, आदि को परिभाषित करने के लिए किया जाता है। निम्नलिखित वर्गों में इस पर विचार करें।

वर्चुअल क्लस्टर

VSphere में, हमारे पास भौतिक ESXi होस्ट हैं जो तार्किक रूप से समूहों में वर्गीकृत हैं। इन समूहों को "संसाधन पूल" नामक अन्य आभासी समूहों में विभाजित किया जा सकता है। ये "पूल" मुख्य रूप से संसाधनों को सीमित करने के लिए उपयोग किए जाते हैं। कुबेरनेट्स में, हमारे पास बहुत कुछ समान है। हम उन्हें "नेमस्पेस" कहते हैं, उनका उपयोग संसाधन सीमा प्रदान करने के लिए भी किया जा सकता है, जो अगले भाग में परिलक्षित होगा। हालाँकि, अक्सर "नेमस्पेस" का उपयोग अनुप्रयोगों (या उपयोगकर्ताओं, यदि आप सामान्य K8s क्लस्टर्स का उपयोग करते हैं) के लिए बहु-किरायेदारी उपकरण के रूप में किया जाता है। यह भी एक विकल्प है जिसके साथ आप NSX-T का उपयोग करके नेटवर्क विभाजन कर सकते हैं। निम्नलिखित प्रकाशनों में इस पर विचार करें।

संसाधन प्रबंधन

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

कार्यभार की पहचान

यह बहुत सरल है और vSphere और Kubernetes के लिए लगभग समान है। पहले मामले में, हम समान कार्यभार को परिभाषित (या समूह) करने के लिए टैग की अवधारणाओं का उपयोग करते हैं, और दूसरे में हम "लेबल" शब्द का उपयोग करते हैं। कुबेरनेट्स के मामले में, कार्यभार की पहचान अनिवार्य है।

आरक्षण

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

लोड संतुलन

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

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

जैसा कि मैंने पहले ही उल्लेख किया है, सेवा में कई अन्य कॉन्फ़िगरेशन हैं, उदाहरण के लिए, "NodePort", जहां आप नोड स्तर पर पोर्ट असाइन करते हैं और फिर पॉड्स के लिए पोर्ट-एड्रेस-ट्रांसलेशन ट्रांसलेशन करते हैं। वहाँ एक "LoadBalancer" भी है जहाँ आप एक तृतीय-पक्ष या क्लाउड प्रदाता से लोड Balancer उदाहरण चलाते हैं।


कुबेरेंट के पास एक और बहुत महत्वपूर्ण भार संतुलन तंत्र है जिसे "इनग्रेस कंट्रोलर" कहा जाता है। आप इसे एक इन-लाइन एप्लिकेशन लोड बैलेंसर मान सकते हैं। मुख्य विचार यह है कि इनरवेयर कंट्रोलर (एक पॉड के रूप में) को बाहर से दिखाई देने वाले आईपी पते के साथ लॉन्च किया जाएगा। इस आईपी पते में वाइल्डकार्ड डीएनएस रिकॉर्ड जैसा कुछ हो सकता है। जब ट्रैफ़िक बाहरी IP पते का उपयोग करके इनग्रेड कंट्रोलर पर आता है, तो यह हेडर की जाँच करता है और उन नियमों के सेट का उपयोग करके निर्धारित करता है, जिन्हें आपने पहले सेट किया था कि यह नाम किस पॉड का है। उदाहरण के लिए: sphinx-v1.esxcloud.net को सेवा sphinx-svc-1 के लिए निर्देशित किया जाएगा, और sphinx-v2.esxcloud.net को सेवा sphinx-svc2, आदि के लिए निर्देशित किया जाएगा।

भंडारण और नेटवर्क

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

कुबेरनेट्स के पास विभिन्न नेटवर्क "प्लगइन्स" हैं जिनका उपयोग आप अपने नोड्स और पॉड्स के नेटवर्क को कॉन्फ़िगर करने के लिए कर सकते हैं। एक सामान्य प्लगइन "kubenet" है, जो वर्तमान में GCP और AWS जैसे मेगा-बादलों में उपयोग किया जाता है। यहाँ मैं संक्षेप में GCP के कार्यान्वयन के बारे में बात करूँगा, और फिर GKE में कार्यान्वयन का व्यावहारिक उदाहरण दिखाऊँगा।


पहली नज़र में, यह बहुत जटिल लग सकता है, लेकिन मुझे आशा है कि आप इस पोस्ट के अंत तक यह सब समझ सकते हैं। सबसे पहले, हम देखते हैं कि हमारे पास दो कुबेरनेट्स नोड्स हैं: नोड 1 और नोड (एम)। प्रत्येक नोड में किसी भी Linux मशीन की तरह एक eth0 इंटरफ़ेस होता है। इस इंटरफ़ेस का बाहरी दुनिया के लिए एक IP पता है, हमारे मामले में, 10.140.0.0/24 सबनेट पर। अपस्ट्रीम L3 डिवाइस हमारे ट्रैफ़िक को रूट करने के लिए डिफ़ॉल्ट गेटवे के रूप में कार्य करता है। यह आपके डेटा केंद्र में L3 स्विच या क्लाउड में VPC राउटर हो सकता है, जैसे कि GCP, जैसा कि हम बाद में देखेंगे। क्या सब ठीक चल रहा है?

इसके अलावा हम देखते हैं कि हमारे पास नोड के अंदर ब्रिज इंटरफेस cbr0 है। यह इंटरफ़ेस Node 1. के मामले में IP सबनेट 10.40.1.0/24 के लिए डिफ़ॉल्ट गेटवे है। इस सबनेट को Kubernetes द्वारा प्रत्येक नोड को सौंपा जाता है। नोड्स को आमतौर पर / 24 सबनेट मिलता है, लेकिन आप इसे NSX-T का उपयोग करके बदल सकते हैं (हम निम्नलिखित पोस्ट में इसे कवर करेंगे)। फिलहाल, यह सबनेट वह है जिसमें से हम पॉड्स के लिए आईपी पते जारी करेंगे। इस तरह, नोड 1 के अंदर किसी भी पॉड को इस सबनेट से आईपी एड्रेस मिलेगा। हमारे मामले में, पॉड 1 का 10.40.1.10 का आईपी पता है। हालाँकि, आप ध्यान दें कि इस पॉड में दो नेस्टेड कंटेनर हैं। हमने पहले ही कहा है कि एक पॉड के भीतर एक या कई कंटेनरों को लॉन्च किया जा सकता है, जो कार्यक्षमता के संदर्भ में एक-दूसरे से निकटता से संबंधित हैं। यह हम आंकड़ा में देखते हैं। कंटेनर 1 बंदरगाह 80 पर सुनता है, और कंटेनर 2 बंदरगाह 90 पर सुनता है। दोनों कंटेनरों का समान आईपी पता 10.40.1.10 है, लेकिन उनके पास नेटवर्किंग नाम स्थान नहीं है। ठीक है, तो इस नेटवर्क स्टैक का मालिक कौन है? असल में एक विशेष कंटेनर है जिसे "पॉज कंटेनर" कहा जाता है। आरेख से पता चलता है कि उसका आईपी पता बाहरी दुनिया के साथ संचार के लिए पोड का आईपी पता है। इस प्रकार, पॉज कंटेनर इस नेटवर्क स्टैक का मालिक है, जिसमें आईपी एड्रेस 10.40.1.10 भी शामिल है, और निश्चित रूप से, यह कंटेनर 1 से पोर्ट 80 तक ट्रैफिक को रीडायरेक्ट करता है, और कंटेनर 2 से पोर्ट 90 पर ट्रैफिक को भी रीडायरेक्ट करता है।

अब आपको यह पूछना है कि बाहरी दुनिया में ट्रैफ़िक को कैसे पुनर्निर्देशित किया जाता है? हमारे पास मानक Linux IP अग्रेषण है जो cbr0 से eth0 तक ट्रैफ़िक को अग्रेषित करने में सक्षम है। यह बहुत अच्छा है, लेकिन फिर यह स्पष्ट नहीं है कि एल 3 डिवाइस कैसे सीख सकता है कि अपने गंतव्य के लिए ट्रैफ़िक कैसे अग्रेषित करें? इस विशिष्ट उदाहरण में, हमारे पास इस नेटवर्क की घोषणा के लिए गतिशील मार्ग नहीं है। इसलिए, हमारे पास L3 डिवाइस पर कुछ प्रकार के स्थिर मार्ग होने चाहिए। 10.40.1.0/24 सबनेट तक पहुंचने के लिए, आपको ट्रैफ़िक को नोड 1 आईपी पते (10.140.0.11) पर भेजने की आवश्यकता है और 10.40.2.0/24 सबनेट को अगली आशा तक पहुँचने के लिए - आईपी कोड 10.140.0.12 के साथ नोड (एम)।

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

याद रखें कि हमने kubenet प्लगइन को देखा था, न कि CNI। कुबनेट प्लगइन Google कंटेनर इंजन (GKE) का उपयोग करता है, और जिस तरह से वे करते हैं वह बहुत मजेदार है क्योंकि यह पूरी तरह से सॉफ्टवेयर परिभाषित है और अपने क्लाउड में स्वचालित है। , GCP. .

आगे क्या है?

Kuberentes. , .

दूसरा भाग।

. .
.