कंटेनर-टू-पाइपलाइन: CRI-O अब OpenShift कंटेनर प्लेटफ़ॉर्म 4 में डिफ़ॉल्ट है

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



स्पष्ट समाधान Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux का एक रूपांतर) और CRI-O को मानक के रूप में उपयोग करना था, और यहाँ क्यों ...

चूंकि नेविगेशन का विषय कुबेरनेट्स और कंटेनरों के संचालन को समझाने में उपमाओं को खोजने के लिए बहुत सफल है, इसलिए उन व्यावसायिक समस्याओं के बारे में बात करने की कोशिश करें जो कोर और CRI-O हल करते हैं, धांधली ब्लॉकों के उत्पादन के लिए ब्रुनेल के आविष्कार का उदाहरण देते हैं। 1803 में, मार्क ब्रुनेल को बढ़ती ब्रिटिश नौसेना की जरूरतों के लिए 100,000 हेराफेरी ब्लॉकों के निर्माण का काम सौंपा गया था। एक उठाने वाला ब्लॉक एक प्रकार का रिग है जो रस्सियों को रस्सियों से जोड़ने के लिए उपयोग किया जाता है। 19 वीं शताब्दी की शुरुआत तक, इन ब्लॉकों को हाथ से बनाया गया था, लेकिन ब्रुनेल उत्पादन को स्वचालित करने में सक्षम था और मशीनों का उपयोग करके मानकीकृत ब्लॉकों का उत्पादन करना शुरू कर दिया। इस प्रक्रिया के स्वचालन का मतलब था कि परिणामस्वरूप, सभी ब्लॉक लगभग समान थे, आसानी से टूटने की स्थिति में प्रतिस्थापित किया जा सकता है, और बड़ी मात्रा में बनाया जा सकता है।

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

OpenShift 4, क्लाउड प्लेटफॉर्म के रूप में, एक समान व्यवसाय चुनौती का सामना करता है। क्लस्टर के निर्माण के समय, नोड्स में से एक में विफलता की स्थिति में या क्लस्टर बनाते समय नए नोड बनाए जाने चाहिए। नए नोड को बनाते और आरंभ करते समय, CRI-O सहित महत्वपूर्ण होस्ट घटक, तदनुसार कॉन्फ़िगर किए जाने चाहिए। किसी भी अन्य उत्पादन की तरह, शुरुआत में "कच्चे माल" की आपूर्ति की जानी चाहिए। जहाजों, धातु और लकड़ी के मामले में कच्चे माल के रूप में कार्य करते हैं। हालाँकि, यदि आप OpenShift 4 क्लस्टर में कंटेनरों को तैनात करने के लिए एक होस्ट बनाते हैं, तो आपके पास इनपुट पर उपलब्ध कराई गई कॉन्फ़िगरेशन फ़ाइलें और API सर्वर होना चाहिए। उसके बाद, ओपनशिफ्ट पूरे जीवन चक्र में स्वचालन का आवश्यक स्तर प्रदान करेगा, जो अंत उपयोगकर्ताओं के लिए आवश्यक उत्पाद सहायता प्रदान करेगा और इस तरह मंच में निवेश का भुगतान करेगा।

ओपनशिफ्ट 4 इस तरह से बनाया गया था ताकि क्लाउड कंप्यूटिंग, वर्चुअलाइजेशन प्लेटफार्मों और यहां तक ​​कि नंगे धातु प्रणालियों के सभी प्रमुख आपूर्तिकर्ताओं के लिए प्लेटफॉर्म (संस्करणों 4.X) के जीवन चक्र के दौरान सिस्टम को आसानी से अपडेट करने की क्षमता प्रदान की जा सके। इसके लिए, विनिमेय तत्वों के आधार पर नोड्स बनाए जाने चाहिए। जब क्लस्टर को कुबेरनेट्स के नए संस्करण की आवश्यकता होती है, तो यह कोरओएस पर संबंधित सीआरआई-ओ संस्करण भी प्राप्त करता है। चूंकि CRI-O संस्करण सीधे Kubernetes से बंधा है, इसलिए यह सब परीक्षण, समस्या निवारण या समर्थन के लिए किसी भी क्रमपरिवर्तन को सरल करता है। इसके अलावा, यह दृष्टिकोण अंतिम उपयोगकर्ताओं और Red Hat के लिए लागत को कम करता है।

कुबेरनेट्स समूहों में यह एक मौलिक रूप से नया रूप है, जो नए अत्यधिक उपयोगी और आकर्षक सुविधाओं की योजना की नींव रखता है। CRI-O (ओपन कंटेनर प्रोजेक्ट कंटेनर रनटाइम इंटरफ़ेस - ओपन कंटेनर इनिशिएटिव, संक्षिप्त CRI-OCI) नोड्स के बड़े पैमाने पर निर्माण के लिए सबसे सफल विकल्प था, जो ओपनशिफ्ट के साथ काम करने के लिए आवश्यक है। CRI-O पहले इस्तेमाल किए गए Docker इंजन को बदल देगा, OpenShift उपयोगकर्ताओं को एक किफायती, स्थिर, सरल और उबाऊ ऑफर देगा - हाँ, आपने इसे सही - बोरिंग कंटेनर इंजन को विशेष रूप से Kubernetes के साथ काम करने के लिए डिज़ाइन किया गया सुना।

खुले कंटेनरों की दुनिया

दुनिया लंबे समय से खुले कंटेनरों की ओर बढ़ रही है। कुबेरनेट्स पर, या निचले स्तरों पर, कंटेनर मानकों का विकास हर स्तर पर नवाचार के एक पारिस्थितिकी तंत्र की ओर जाता है।

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

कुबेरनेट्स समुदाय ने तब कंटेनर प्लगटाइम इंटरफ़ेस (CRI) नामक एक एकल प्लग करने योग्य इंटरफ़ेस मानक विकसित किया। इसके लिए धन्यवाद, कुबेरनेट्स उपयोगकर्ता डॉकर के अलावा कंटेनरों के साथ काम करने के लिए विभिन्न इंजनों को जोड़ने में सक्षम थे।

रेड हैट और गूगल इंजीनियरों ने एक कंटेनर इंजन की बाजार में मांग देखी, जो सीआरआई प्रोटोकॉल का उपयोग करते हुए क्यूबलेट से अनुरोध स्वीकार कर सकता है और उन कंटेनरों को पेश किया गया जो ऊपर उल्लिखित ओसीआई विनिर्देशों के साथ संगत थे। तो एक OCID था । लेकिन मुझे माफ करना, क्योंकि हमने कहा कि यह सामग्री सीआरआई-ओ को समर्पित होगी? वास्तव में, यह सिर्फ 1.0 संस्करण की रिलीज के साथ , परियोजना का नाम बदलकर CRI-O कर दिया गया।

अंजीर। 1।

CRI-O और CoreOS के साथ नवाचार

OpenShift 4 प्लेटफ़ॉर्म के लॉन्च के साथ, डिफ़ॉल्ट प्लेटफ़ॉर्म में उपयोग किए जाने वाले कंटेनर इंजन को बदल दिया गया था, और Docker को CRI-O द्वारा बदल दिया गया था, जिसने Kubetetes के समानांतर विकसित होने वाला एक किफायती, स्थिर, सरल और उबाऊ कंटेनर लॉन्च वातावरण पेश किया। यह क्लस्टर समर्थन और कॉन्फ़िगरेशन को बहुत सरल करता है। कंटेनर इंजन और होस्ट को कॉन्फ़िगर करना, साथ ही उन्हें प्रबंधित करना, ओपनशिफ्ट 4 के भीतर स्वचालित हो जाता है।

रुकिए, कैसा है?

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

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

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

कंटेनर लॉन्च

उपयोगकर्ताओं के पास OpenShift प्लेटफ़ॉर्म में CRI-O इंजन का उपयोग करने का अवसर था, जो कि टेक प्रीव्यू की स्थिति में संस्करण 3.7 से शुरू हुआ था और सामान्य रूप से उपलब्ध (वर्तमान में समर्थित) की स्थिति में संस्करण 3.9 से था। इसके अलावा, Red Hat 3.10 संस्करण के बाद से OpenShift ऑनलाइन में उत्पादन कार्यभार को लॉन्च करने के लिए CRI-O का व्यापक उपयोग करता है। यह सब बड़े कुबेरनेट समूहों पर कंटेनरों के सामूहिक प्रक्षेपण में व्यापक अनुभव हासिल करने के लिए सीआरआई-ओ पर काम कर रही टीम को अनुमति देता है। कुबेरनेट्स सीआरआई-ओ का उपयोग कैसे करता है, इसकी एक बुनियादी समझ पाने के लिए, आइए निम्नलिखित दृष्टांत पर एक नज़र डालें, जो बताता है कि वास्तुकला कैसे काम करती है।

अंजीर। 2. कुबेरनेट क्लस्टर में कंटेनर कैसे काम करते हैं



CRI-O नए नोड्स को इनिशियलाइज़ करते समय, और OpenShift प्लेटफ़ॉर्म के नए संस्करणों को रिलीज़ करते समय पूरे टॉप लेवल को सिंक्रोनाइज़ करके नए कंटेनर होस्ट के निर्माण को सरल बनाता है। एक संपूर्ण प्लेटफ़ॉर्म ऑडिट ट्रांज़ैक्शनल अपडेट / रोलबैक के लिए अनुमति देता है, और कंटेनर टेल कर्नेल, कंटेनर इंजन, क्यूबलेट्स और कुबर्नेटेस मास्टर के बीच निर्भरता में गतिरोध को भी रोकता है। सभी प्लेटफार्म घटकों के केंद्रीकृत प्रबंधन के साथ, संस्करण नियंत्रण और प्रबंधन के साथ, आप हमेशा राज्य ए से राज्य बी तक एक स्पष्ट पथ को ट्रैक कर सकते हैं। यह अद्यतन प्रक्रिया को सरल करता है, सुरक्षा में सुधार करता है, प्रदर्शन रिपोर्टिंग में सुधार करता है और नए संस्करणों को अपडेट करने और स्थापित करने की लागत को कम करने में मदद करता है।

विनिमेय तत्वों की शक्ति का प्रदर्शन

जैसा कि पहले उल्लेख किया गया है, OpenShift 4 में कंटेनर होस्ट और कंटेनर इंजन का प्रबंधन करने के लिए मशीन कॉन्फिगर ऑपरेटर का उपयोग करके स्वचालन का एक नया स्तर प्रदान करता है जो पहले कुबेरनेट्स प्लेटफॉर्म पर संभव नहीं था। नई सुविधाओं को प्रदर्शित करने के लिए, हम दिखाते हैं कि आप कैसे crio.conf फ़ाइल में परिवर्तन कर सकते हैं। शब्दावली में भ्रमित न होने के लिए, परिणामों पर ध्यान केंद्रित करने का प्रयास करें।

सबसे पहले, कन्टेनर रनटाइम कॉन्फ़िगरेशन को कंटेनर रनटाइम कॉन्फ़िगरेशन कहा जाता है। इस Kubernetes संसाधन पर विचार करें जो CRI-O के लिए विन्यास का प्रतिनिधित्व करता है। वास्तव में, यह मशीनकॉन्फिग नामक एक विशेष संस्करण है, जो ओपनशफ्ट क्लस्टर के भीतर एक आरएचईएल कोरओएस मशीन पर तैनात किसी भी कॉन्फ़िगरेशन है।

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

पिछली दो पंक्तियों पर ध्यान दें, जिन्हें हम /etc/crio/crio.conf फ़ाइल में बदलने जा रहे हैं। ये दो पंक्तियाँ crio.conf फ़ाइल की रेखाओं के समान हैं, ये हैं:

vi ContainerRuntimeConfig.yaml 

निष्कर्ष:

 apiVersion: machineconfiguration.openshift.io/v1 kind: ContainerRuntimeConfig metadata: name: set-log-and-pid spec: machineConfigPoolSelector: matchLabels: debug-crio: config-log-and-pid containerRuntimeConfig: pidsLimit: 2048 logLevel: debug 

अब इस फाइल को कुबेरनेट क्लस्टर में भेजें और सत्यापित करें कि यह वास्तव में बनाई गई है। कृपया ध्यान दें कि ऑपरेशन किसी अन्य कुबेरनेट संसाधन के साथ उसी तरह से किया जाता है:

 oc create -f ContainerRuntimeConfig.yaml oc get ContainerRuntimeConfig 

निष्कर्ष:

 NAME AGE set-log-and-pid 22h 

कन्टेनरटाइमटाइमऑनफिग बनाने के बाद, हमें कुबेरनेट्स को यह समझने के लिए मशीनकोनफिगपूल में से एक को संशोधित करने की आवश्यकता है कि हम इस कॉन्फ़िगरेशन को क्लस्टर में मशीनों के एक विशिष्ट समूह पर लागू करना चाहते हैं। इस स्थिति में, हम मास्टर नोड्स के लिए MachineConfigPool को बदल देंगे:

 oc edit MachineConfigPool/master 

निष्कर्ष (स्पष्टता के लिए, मुख्य बिंदु बचा है):

 ... metadata: creationTimestamp: 2019-04-10T23:42:28Z generation: 1 labels: debug-crio: config-log-and-pid operator.machineconfiguration.openshift.io/required-for-upgrade: "" ... 

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

 oc get MachineConfigs | grep rendered 

निष्कर्ष:

 rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h 

कृपया ध्यान दें कि मास्टर नोड्स के लिए परिणामी कॉन्फ़िगरेशन फ़ाइल मूल कॉन्फ़िगरेशन की तुलना में एक नया संस्करण है। इसे देखने के लिए, निम्न कमांड चलाएँ। गुजरते समय में, हम ध्यान दें कि कुबेरनेट्स के इतिहास में यह शायद सबसे अच्छी एकल-पंक्ति स्क्रिप्ट में से एक है:

 python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid 

निष्कर्ष:

 pids_limit = 2048 

अब सुनिश्चित करें कि कॉन्फ़िगरेशन को सभी मास्टर नोड्स पर लागू किया गया है। पहले हमें क्लस्टर में नोड्स की एक सूची मिलती है:

 oc get node | grep master Output: ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1 ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1 ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1 

अब इंस्टॉल की गई फाइल को देखें। आप देखेंगे कि फ़ाइल को नए pid और डिबग निर्देशों के साथ अपडेट किया गया है, जिसे हमने कंटेनररंटटाइमकोन्फिग संसाधन में निर्दिष्ट किया है। लालित्य ही:

 oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid' 

निष्कर्ष:

 ... pids_limit = 2048 ... log_level = "debug" ... 

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

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

अक्सर, प्रौद्योगिकी कंपनियां इतनी तेजी से विकसित हो रही हैं कि हम यह समझाने में सक्षम नहीं हैं कि हम बुनियादी घटकों के लिए कुछ तकनीकों का चयन क्यों करते हैं। कंटेनर इंजन ऐतिहासिक रूप से घटक है जिसके साथ उपयोगकर्ता सीधे संपर्क करते हैं। चूंकि कंटेनरों की लोकप्रियता स्वाभाविक रूप से कंटेनर इंजनों के आगमन के साथ शुरू हुई, इसलिए उपयोगकर्ता अक्सर उनमें रुचि दिखाते हैं। यह एक और कारण है कि Red Hat ने CRI-O का विकल्प चुना। कंटेनर विकसित हो रहे हैं, आज आर्केस्ट्रा पर ध्यान केंद्रित करने के साथ, और हम इस निष्कर्ष पर पहुंचे हैं कि सीआरआई-ओ ओपनशफ्ट 4 के साथ काम करते समय सबसे अच्छा अनुभव प्रदान करता है।