भाग्य बताने वाला

कुबेरनेट्स ने पहले ही मेरे काम में एक महत्वपूर्ण भूमिका निभाई है, और भविष्य में यह और भी महत्वपूर्ण हो जाएगा। लेकिन 2018 एक करीबी के लिए आकर्षित कर रहा है, इसलिए विनम्रता के बारे में भूल जाओ और एक साहसिक भविष्यवाणी करें:

कुबेरनेट्स का भविष्य आभासी मशीनें हैं, न कि कंटेनर

चीनी कुंडली के अनुसार, 2018 कुत्ते का वर्ष था, लेकिन प्रौद्योगिकी में यह कुबेरनेट्स का वर्ष था। कई लोग अभी इस क्रांतिकारी तकनीक के बारे में सीख रहे हैं, और आईटी विभाग हर जगह "कुबेरनेट्स रणनीति" [1] विकसित करने की कोशिश कर रहे हैं। कुछ संगठनों ने पहले से ही बड़े वर्कलोड को कुबेरनेट्स में स्थानांतरित कर दिया है।

[१] यदि आप कुबेरनेट रणनीति बनाने की कोशिश कर रहे हैं, तो आप पहले ही असफल हो चुके हैं, लेकिन यह एक अन्य लेख का विषय है।

दूसरे शब्दों में, कुबेरनेट्स में "गार्टनर सेंसस साइकिल" के हर चरण में बहुत सारे लोग हैं। कुछ निराशा के एक खोखले में फंस गए हैं या निराशा के गड्ढे में डूब गए हैं।


जेरेमीकम्प, विकिपीडिया । क्रिएटिव कॉमन्स CC BY-SA 3.0

मैं कंटेनरों का बहुत बड़ा प्रशंसक हूं और मैंने यह नहीं कहा कि कंटेनर मर चुके हैं । 2013 में, डॉकर ने हमें लिनक्स कंटेनरों के लिए एक शेल दिया: अनुप्रयोगों के निर्माण, पैकेज, शेयर और तैनाती के लिए एक अद्भुत नया तरीका। यह सही समय पर प्रकट हुआ, क्योंकि हमने निरंतर वितरण को गंभीरता से लेना शुरू किया। उनका मॉडल वितरण श्रृंखला के लिए आदर्श बन गया और PaS प्लेटफॉर्म के उदय में योगदान दिया, और फिर CaaS।



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

जल्द ही, कुबेरनेट्स के लिए समर्थन सभी बड़े बादलों (GKE, AKS, EKS) द्वारा प्रदान किया गया। ऑन-प्रिमाइसेस सेवाओं ने जल्दी से कुबेरनेट्स (Pivotal कंटेनर सेवा, Openshift, आदि) पर आधारित प्लेटफ़ॉर्म भी बनाए।

शीतल बहु तप

एक कष्टप्रद समस्या को हल करना आवश्यक था, जिसे कंटेनरों की कमी माना जा सकता है ... यह बहु-किरायेदारी है।

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


यह इस तथ्य से जटिल है कि कुबेरनेट के अधिकांश घटकों को किरायेदारों के बारे में पता नहीं है। बेशक, आपके पास पॉड नेमस्पेस और सुरक्षा नीतियां हैं , लेकिन एपीआई में ऐसी कोई चीज नहीं है। साथ ही साथ kubelet या kube-proxy जैसे आंतरिक घटकों में। यह इस तथ्य की ओर जाता है कि कुबेरनेट्स "सॉफ्ट रेंट" (सॉफ्ट टेनेंसी) के मॉडल को लागू करता है।


कुबेरनेट्स आर्किटेक्चर

सार और आगे रिसता है। कंटेनरों के शीर्ष पर एक मंच नरम किराए के कई पहलुओं को विरासत में मिला है। मल्टी-टेनेंट वर्चुअल मशीनों के शीर्ष पर स्थित प्लेटफॉर्म इस कठिन पट्टे (VMware, Amazon Web Services, OpenStack, आदि) को विरासत में मिला है।

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

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

इससे "एक बड़े सामान्य क्लस्टर" के बजाय "कई क्लस्टर" मॉडल का उदय हुआ। अक्सर, Google के जीकेबी ग्राहकों के पास कई टीमों के लिए दर्जनों कुबेरनेट क्लस्टर होते हैं। अक्सर प्रत्येक डेवलपर को अपने स्वयं के क्लस्टर मिलते हैं। यह व्यवहार एक चौंकाने वाली संख्या (Kubesprawl) उत्पन्न करता है।

वैकल्पिक रूप से, ऑपरेटर अपने स्वयं के डेटा केंद्रों में अपने स्वयं के कुबेरनेट समूहों को कई समूहों को प्रबंधित करने के लिए अतिरिक्त कार्य करने के लिए उठाते हैं, या एक या दो बड़े समूहों को किराए पर देने के लिए सहमत होते हैं।

आमतौर पर, सबसे छोटा क्लस्टर चार मशीनें (या आभासी मशीनें) होती हैं। कुबेरनेट्स मास्टर के लिए एक (या एचए के लिए तीन), कुबेरनेट्स वर्कर्स के लिए तीन। बहुत सारा पैसा उन प्रणालियों पर खर्च किया जाता है जो अधिकांश भाग बेकार हैं।

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

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

बस बहुत छोटे VMs गति के लिए अनुकूलित ...

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

जेसी कामा कंटेनर जैसे वीएम कंटेनर तकनीक का उपयोग करने का सुझाव देते हैं। वे वीएम स्तर अलगाव की पेशकश करते हैं, लेकिन कंटेनरों की तरह काम करते हैं। इससे कुबेरनेट्स को प्रत्येक "किरायेदार" (हम नाम स्थान में किरायेदार मान लेते हैं) कुबेरनेट्स सिस्टम नेस्टेड वीएम कंटेनर (वर्चुअल मशीन के अंदर वीएम कंटेनर जो IaaS प्रदान करता है) में चल रहा है।


जेसी फ्रैसेल की छवि: कुबेरनेट्स में कठिन बहु-किरायेदारी

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

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

संसाधन-अनुकूलित मल्टी-टेनेंसी (लागत)

दो नामस्थान और कई चलने वाले अनुप्रयोगों के साथ एक कुबेरनेट की तैनाती कुछ इस तरह दिखाई देगी:

नोट: समान IaaS अवसंरचना पर अन्य भार हैं। चूंकि ये वीएम कंटेनर हैं, उनके पास पारंपरिक क्लाउड वीएम के समान ही अलगाव स्तर है। इसलिए, वे न्यूनतम जोखिम के साथ एक ही हाइपरविजर पर काम कर सकते हैं।

प्रारंभ में, क्लाउड में कोई बुनियादी ढांचा तैनात नहीं किया गया है, इसलिए एक सुपरयुसर के लिए लागत शून्य है।

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

सुपरयुसर दो नामस्थान foo और bar बनाता है। Kubernetes नेमस्पेस प्रबंधन के प्रत्येक स्तर (Kubernetes API और System Services) के लिए क्लाउड से दो VM कंटेनरों का अनुरोध करता है। सुपरयुसर इन नामस्थानों को कुछ उपयोगकर्ताओं तक पहुंचाता है, उनमें से प्रत्येक कुछ वर्कलोड (मॉड्यूल) लॉन्च करता है, और वीएम कंटेनर इन वर्कलोड के लिए इन कंटेनरों का अनुरोध करते हैं।

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

मैं वास्तव में कुछ भी नया नहीं कह रहा हूं ...

क्लाउड सेवा प्रदाता पहले से ही इस दिशा में काम कर रहे हैं। आप सामुदायिक घटनाओं को देखते हुए इसे सत्यापित कर सकते हैं (अमेज़ॅन ने पहले ही चुपचाप फ़रगेट के साथ ऐसा किया हो सकता है)।

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

अन्य संकेत वीएम कंटेनरीकरण के लिए नई तकनीकों की एक बड़ी संख्या हैं, जैसे पहले से ही उल्लेख किए गए काटा कंटेनर, साथ ही अमेज़ॅन के पटाखे और Google के ग्विसर ।

निष्कर्ष

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

यदि आप सार्वजनिक क्लाउड का उपयोग नहीं करते हैं, तो आपको उच्च संसाधन उपयोग का लाभ मिलता है, जो कम हार्डवेयर आवश्यकताओं के साथ भुगतान करता है।

चलो आशा करते हैं कि VMware और OpenStack ध्यान दें और हल्के VM कंटेनरों और इसी वर्चुअल क्यूबलेट कार्यान्वयन के आधार पर हाइपरविजर जारी करें।