कंटेनर ते कन्वेयर: CRI-O आता OpenShift कंटेनर प्लॅटफॉर्म 4 मध्ये डीफॉल्ट आहे

प्लॅटफॉर्म रेड हॅट ओपनशिफ्ट कंटेनर प्लॅटफॉर्म 4 तुम्हाला निर्मिती सुव्यवस्थित करण्यास अनुमती देते कंटेनर तैनात करण्यासाठी यजमान, क्लाउड सेवा प्रदात्यांच्या पायाभूत सुविधांमध्ये, व्हर्च्युअलायझेशन प्लॅटफॉर्मवर किंवा बेअर-मेटल सिस्टममध्ये. खरोखर क्लाउड-आधारित प्लॅटफॉर्म तयार करण्यासाठी, आम्हाला वापरलेल्या सर्व घटकांवर कठोर नियंत्रण ठेवावे लागेल आणि अशा प्रकारे जटिल ऑटोमेशन प्रक्रियेची विश्वासार्हता वाढवावी लागेल.

Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux चा एक प्रकार) आणि CRI-O चा मानक म्हणून वापर करणे हा स्पष्ट उपाय होता, आणि याचे कारण येथे आहे...

कुबर्नेट्स आणि कंटेनर्सचे कार्य स्पष्ट करताना साम्य शोधण्यासाठी नौकानयन हा विषय खूप चांगला असल्याने, उदाहरण वापरून, CoreOS आणि CRI-O द्वारे सोडवलेल्या व्यावसायिक समस्यांबद्दल बोलण्याचा प्रयत्न करूया. रिगिंग ब्लॉक्सच्या उत्पादनासाठी ब्रुनेलचे शोध. 1803 मध्ये, मार्क ब्रुनेलला वाढत्या ब्रिटीश नौदलाच्या गरजांसाठी 100 रिगिंग ब्लॉक्स तयार करण्याचे काम सोपवण्यात आले. रिगिंग ब्लॉक हा एक प्रकारचा रिगिंग आहे जो पालांना दोरी जोडण्यासाठी वापरला जातो. 19व्या शतकाच्या अगदी सुरुवातीपर्यंत, हे ब्लॉक्स हाताने बनवले जात होते, परंतु ब्रुनेलने उत्पादन स्वयंचलित केले आणि मशीन टूल्स वापरून प्रमाणित ब्लॉक्स तयार करण्यास सुरुवात केली. या प्रक्रियेच्या ऑटोमेशनचा अर्थ असा होतो की परिणामी ब्लॉक मूलत: एकसारखे होते, तुटल्यास ते सहजपणे बदलले जाऊ शकतात आणि मोठ्या प्रमाणात तयार केले जाऊ शकतात.

आता कल्पना करा की ब्रुनेलला हे काम 20 वेगवेगळ्या जहाज मॉडेल्ससाठी (कुबर्नेट्स आवृत्त्या) आणि पूर्णपणे भिन्न समुद्र प्रवाह आणि वारा (क्लाउड प्रदाते) असलेल्या पाच भिन्न ग्रहांसाठी करावे लागले. याव्यतिरिक्त, सर्व जहाजे (ओपनशिफ्ट क्लस्टर्स), ज्या ग्रहांवर नेव्हिगेशन चालते त्याकडे दुर्लक्ष करून, कर्णधारांच्या दृष्टिकोनातून (क्लस्टरचे ऑपरेशन व्यवस्थापित करणारे ऑपरेटर) समान वागणे आवश्यक होते. सागरी साधर्म्य सुरू ठेवण्यासाठी, जहाज कप्तान त्यांच्या जहाजांवर कोणत्या प्रकारचे रिगिंग ब्लॉक्स (सीआरआय-ओ) वापरले जातात याची अजिबात काळजी घेत नाहीत - त्यांच्यासाठी मुख्य गोष्ट अशी आहे की हे ब्लॉक मजबूत आणि विश्वासार्ह आहेत.

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

OpenShift 4 ची निर्मिती सर्व प्रमुख क्लाउड कंप्युटिंग प्रदाते, व्हर्च्युअलायझेशन प्लॅटफॉर्म आणि अगदी बेअर मेटल सिस्टीमसाठी प्लॅटफॉर्मच्या संपूर्ण जीवन चक्रात (आवृत्त्या 4.X साठी) प्रणालीला सोयीस्करपणे अद्यतनित करण्याची क्षमता प्रदान करण्यासाठी अशा प्रकारे केली गेली. हे करण्यासाठी, अदलाबदल करण्यायोग्य घटकांच्या आधारे नोड्स तयार करणे आवश्यक आहे. जेव्हा क्लस्टरला Kubernetes ची नवीन आवृत्ती आवश्यक असते, तेव्हा ते CoreOS वर CRI-O ची संबंधित आवृत्ती देखील प्राप्त करते. CRI-O आवृत्ती थेट Kubernetes शी जोडलेली असल्याने, हे चाचणी, समस्यानिवारण किंवा समर्थन हेतूंसाठी कोणतेही क्रमपरिवर्तन सुलभ करते. याशिवाय, हा दृष्टिकोन अंतिम वापरकर्त्यांसाठी आणि Red Hat साठी खर्च कमी करतो.

कुबर्नेट्स क्लस्टर्सबद्दल विचार करण्याचा हा मूलभूतपणे नवीन मार्ग आहे आणि काही अतिशय उपयुक्त आणि आकर्षक नवीन वैशिष्ट्यांचे नियोजन करण्यासाठी पाया घालतो. सीआरआय-ओ (कंटेनर रनटाइम इंटरफेस - ओपन कंटेनर इनिशिएटिव्ह, संक्षिप्त सीआरआय-ओसीआय) ओपनशिफ्टसह कार्य करण्यासाठी आवश्यक असलेल्या नोड्सच्या मोठ्या प्रमाणात निर्मितीसाठी सर्वात यशस्वी निवड ठरली. CRI-O पूर्वी वापरलेले डॉकर इंजिन पुनर्स्थित करेल, OpenShift वापरकर्त्यांना ऑफर करेल आर्थिक, स्थिर, साधे आणि कंटाळवाणे – होय, तुम्ही बरोबर ऐकले आहे – एक कंटाळवाणे कंटेनर इंजिन विशेषत: कुबर्नेट्ससह काम करण्यासाठी तयार केले आहे.

उघड्या डब्यांचे जग

जग बर्याच काळापासून खुल्या कंटेनरकडे वाटचाल करत आहे. कुबर्नेट्समध्ये असो किंवा खालच्या स्तरावर असो, कंटेनर मानकांचा विकास प्रत्येक स्तरावर नावीन्यपूर्ण परिसंस्थेमध्ये परिणाम होतो.

हे सर्व ओपन कंटेनर इनिशिएटिव्हच्या निर्मितीपासून सुरू झाले जून 2015 मध्ये. कामाच्या या सुरुवातीच्या टप्प्यावर, कंटेनर तपशील तयार केले गेले प्रतिमा и रनटाइम वातावरण. यामुळे साधने एकच मानक वापरू शकतात याची खात्री झाली कंटेनर प्रतिमा आणि त्यांच्यासोबत काम करण्यासाठी एक एकीकृत स्वरूप. तपशील नंतर जोडले गेले वितरण, वापरकर्त्यांना सहज शेअर करण्याची अनुमती देते कंटेनर प्रतिमा.

कुबर्नेट्स समुदायाने नंतर प्लग करण्यायोग्य इंटरफेससाठी एकच मानक विकसित केले, ज्याला म्हणतात कंटेनर रनटाइम इंटरफेस (CRI). याबद्दल धन्यवाद, कुबर्नेट्स वापरकर्ते डॉकर व्यतिरिक्त कंटेनरसह कार्य करण्यासाठी विविध इंजिन कनेक्ट करण्यात सक्षम होते.

Red Hat आणि Google मधील अभियंत्यांनी CRI प्रोटोकॉलवर कुबेलेट विनंत्या स्वीकारू शकतील अशा कंटेनर इंजिनची बाजारपेठेची गरज पाहिली आणि वर नमूद केलेल्या OCI वैशिष्ट्यांशी सुसंगत कंटेनर सादर केले. तर OCID दिसू लागले. पण माफ करा, आम्ही असे म्हटले नाही की ही सामग्री CRI-O ला समर्पित केली जाईल? खरं तर, फक्त प्रकाशन सह आवृत्ती 1.0 प्रकल्पाचे नाव CRI-O असे ठेवण्यात आले.

अंजीर 1.

CRI-O आणि CoreOS सह नवोपक्रम

OpenShift 4 प्लॅटफॉर्म लाँच झाल्यानंतर, ते बदलले गेले कंटेनर इंजिन, प्लॅटफॉर्ममध्ये डीफॉल्टनुसार वापरले जाते, आणि डॉकरची जागा CRI-O ने घेतली आहे, जे कुबर्नेट्सच्या समांतर विकसित होणारे कंटेनर चालविण्यासाठी किफायतशीर, स्थिर, साधे आणि कंटाळवाणे वातावरण देते. हे क्लस्टर समर्थन आणि कॉन्फिगरेशन मोठ्या प्रमाणात सुलभ करते. कंटेनर इंजिन आणि होस्टचे कॉन्फिगरेशन, तसेच त्यांचे व्यवस्थापन, OpenShift 4 मध्ये स्वयंचलित होते.

थांबा, हे कसे आहे?

हे खरे आहे, OpenShift 4 च्या आगमनाने, यापुढे वैयक्तिक होस्टशी कनेक्ट करण्याची आणि कंटेनर इंजिन स्थापित करण्याची, स्टोरेज कॉन्फिगर करण्याची, शोध सर्व्हर कॉन्फिगर करण्याची किंवा नेटवर्क कॉन्फिगर करण्याची आवश्यकता नाही. OpenShift 4 प्लॅटफॉर्म वापरण्यासाठी पूर्णपणे पुन्हा डिझाइन केले गेले आहे ऑपरेटर फ्रेमवर्क केवळ एंड-यूजर ऍप्लिकेशन्सच्या बाबतीतच नाही तर प्रतिमा तैनात करणे, सिस्टम कॉन्फिगर करणे किंवा अद्यतने स्थापित करणे यासारख्या मूलभूत प्लॅटफॉर्म-स्तरीय ऑपरेशन्सच्या बाबतीत देखील.

Kubernetes ने नेहमी वापरकर्त्यांना इच्छित स्थिती परिभाषित करून आणि वापरून अनुप्रयोग व्यवस्थापित करण्याची परवानगी दिली आहे नियंत्रक, वास्तविक स्थिती लक्ष्य राज्याशी शक्य तितक्या जवळून जुळते याची खात्री करण्यासाठी. या लक्ष्य राज्य आणि वास्तविक राज्य दृष्टीकोन विकास आणि ऑपरेशन या दोन्ही दृष्टीकोनातून उत्तम संधी उघडते. विकसक याद्वारे आवश्यक स्थिती परिभाषित करू शकतात पुढे पाठवा ऑपरेटरला YAML किंवा JSON फाईलच्या स्वरूपात, आणि नंतर ऑपरेटर उत्पादन वातावरणात आवश्यक अनुप्रयोग उदाहरण तयार करू शकतो आणि या उदाहरणाची ऑपरेटिंग स्थिती निर्दिष्ट केलेल्याशी पूर्णपणे अनुरूप असेल.

प्लॅटफॉर्ममध्ये ऑपरेटर्सचा वापर करून, OpenShift 4 RHEL CoreOS आणि CRI-O च्या व्यवस्थापनासाठी हा नवीन नमुना (सेट आणि वास्तविक स्थितीचा वापर करून) आणते. ऑपरेटिंग सिस्टम आणि कंटेनर इंजिनच्या आवृत्त्या कॉन्फिगर आणि व्यवस्थापित करण्याची कार्ये तथाकथित वापरून स्वयंचलित आहेत मशीन कॉन्फिग ऑपरेटर (MCO). MCO क्लस्टर अॅडमिनिस्ट्रेटरचे काम मोठ्या प्रमाणात सुलभ करते, मूलत: इंस्टॉलेशनचे शेवटचे टप्पे स्वयंचलित करते, तसेच त्यानंतरच्या पोस्ट-इंस्टॉलेशन ऑपरेशन्स (दिवस दोन ऑपरेशन्स). हे सर्व OpenShift 4 ला खरे क्लाउड प्लॅटफॉर्म बनवते. आपण थोड्या वेळाने ह्यात येऊ.

चालणारे कंटेनर

वापरकर्त्यांना ओपनशिफ्ट प्लॅटफॉर्मवर टेक पूर्वावलोकन स्थितीतील आवृत्ती 3.7 पासून आणि सर्वसाधारणपणे उपलब्ध स्थितीत (सध्या समर्थित) आवृत्ती 3.9 पासून CRI-O इंजिन वापरण्याची संधी मिळाली आहे. याव्यतिरिक्त, Red Hat मोठ्या प्रमाणात वापरतो उत्पादन कार्यभार चालविण्यासाठी CRI-O आवृत्ती 3.10 पासून OpenShift ऑनलाइन मध्ये. या सर्वांमुळे CRI-O वर काम करणार्‍या टीमला मोठ्या Kubernetes क्लस्टर्सवर कंटेनर लाँच करण्याचा व्यापक अनुभव मिळू शकला. कुबर्नेट्स सीआरआय-ओ कसे वापरतात याची मूलभूत माहिती मिळविण्यासाठी, खालील चित्र पाहू या, जे आर्किटेक्चर कसे कार्य करते हे दर्शविते.

तांदूळ. 2. कुबर्नेट्स क्लस्टरमध्ये कंटेनर कसे कार्य करतात

CRI-O नवीन नोड्स सुरू करताना आणि OpenShift प्लॅटफॉर्मच्या नवीन आवृत्त्या रिलीझ करताना संपूर्ण शीर्ष स्तर समक्रमित करून नवीन कंटेनर होस्टची निर्मिती सुलभ करते. संपूर्ण प्लॅटफॉर्मचे पुनरावृत्ती व्यवहार अद्यतने/रोलबॅकसाठी अनुमती देते आणि कंटेनर टेल कोअर, कंटेनर इंजिन, नोड्स (कुबेलेट्स) आणि कुबर्नेट्स मास्टर नोड यांच्यातील अवलंबित्वांमधील गतिरोध देखील प्रतिबंधित करते. नियंत्रण आणि आवृत्तीसह सर्व प्लॅटफॉर्म घटकांचे केंद्रिय व्यवस्थापन करून, राज्य A ते राज्य B पर्यंत नेहमीच एक स्पष्ट मार्ग असतो. यामुळे अद्यतन प्रक्रिया सुलभ होते, सुरक्षा सुधारते, कार्यप्रदर्शन अहवाल सुधारते आणि नवीन आवृत्त्यांच्या अद्यतने आणि स्थापनेची किंमत कमी करण्यात मदत होते. .

बदली घटकांची शक्ती प्रदर्शित करणे

आधी सांगितल्याप्रमाणे, OpenShift 4 मध्ये कंटेनर होस्ट आणि कंटेनर इंजिन व्यवस्थापित करण्यासाठी मशीन कॉन्फिग ऑपरेटरचा वापर केल्याने ऑटोमेशनचा एक नवीन स्तर उपलब्ध होतो जो पूर्वी Kubernetes प्लॅटफॉर्मवर शक्य नव्हता. नवीन वैशिष्ट्ये प्रदर्शित करण्यासाठी, आम्ही दाखवू की तुम्ही crio.conf फाइलमध्ये कसे बदल करू शकता. पारिभाषिक शब्दांद्वारे गोंधळ होऊ नये म्हणून, परिणामांवर लक्ष केंद्रित करण्याचा प्रयत्न करा.

प्रथम, कंटेनर रनटाइम कॉन्फिगरेशन ज्याला म्हणतात ते तयार करूया - कंटेनर रनटाइम कॉन्फिगरेशन. CRI-O साठी कॉन्फिगरेशनचे प्रतिनिधित्व करणारे कुबर्नेट्स संसाधन म्हणून याचा विचार करा. प्रत्यक्षात, ही MachineConfig नावाची एक विशेष आवृत्ती आहे, जी ओपनशिफ्ट क्लस्टरचा भाग म्हणून RHEL CoreOS मशीनवर तैनात केलेली कोणतीही संरचना आहे.

हे सानुकूल संसाधन, ज्याला ContainerRuntimeConfig म्हणतात, क्लस्टर प्रशासकांना CRI-O कॉन्फिगर करणे सोपे करण्यासाठी तयार केले गेले. हे साधन पुरेसे शक्तिशाली आहे की ते फक्त MachineConfigPool सेटिंग्जवर अवलंबून विशिष्ट नोड्सवर लागू केले जाऊ शकते. समान उद्देश पूर्ण करणार्‍या मशीन्सचा समूह म्हणून याचा विचार करा.

शेवटच्या दोन ओळींकडे लक्ष द्या जे आपण /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

आता ही फाईल Kubernetes क्लस्टरवर ढकलू आणि ती प्रत्यक्षात तयार झाली आहे का ते तपासू. कृपया लक्षात घ्या की ऑपरेशन इतर कोणत्याही कुबर्नेट्स संसाधनाप्रमाणेच आहे:

oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig

निष्कर्ष:

NAME              AGE
set-log-and-pid   22h

एकदा आम्‍ही ContainerRuntimeConfig तयार केल्‍यावर, आम्‍हाला हे कॉन्फिगरेशन क्‍लस्‍टरमध्‍ये मशीनच्‍या एका विशिष्‍ट गटावर लागू करण्‍याचे आहे हे कुबेर्नेट्सला सिग्‍नल करण्‍यासाठी आम्‍हाला MachineConfigPools पैकी एक सुधारित करण्‍याची आवश्‍यकता आहे. या प्रकरणात आम्ही मास्टर नोड्ससाठी 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 फाइल तयार करण्यास सुरुवात करते. या प्रकरणात, कुबर्नेट्स API वापरून पूर्णतः पूर्ण झालेली कॉन्फिगरेशन फाइल पाहिली जाऊ शकते. लक्षात ठेवा, ContainerRuntimeConfig ही MachineConfig ची फक्त एक विशेष आवृत्ती आहे, त्यामुळे आम्ही MachineConfigs मधील संबंधित ओळी पाहून परिणाम पाहू शकतो:

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

आता इन्स्टॉल केलेली फाईल पाहू. तुम्हाला दिसेल की आम्ही ContainerRuntimeConfig संसाधनामध्ये निर्दिष्ट केलेल्या 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"
...

क्लस्टरमधील हे सर्व बदल SSH न चालवताही केले गेले. कुबेरेन्टेस मास्टर नोडमध्ये प्रवेश करून सर्व कार्य केले गेले. म्हणजेच, हे नवीन पॅरामीटर्स केवळ मास्टर नोड्सवर कॉन्फिगर केले गेले होते. वर्कर नोड्स बदलले नाहीत, जे अदलाबदल करण्यायोग्य घटकांसह कंटेनर होस्ट आणि कंटेनर इंजिनच्या संबंधात निर्दिष्ट आणि वास्तविक स्थिती वापरण्याच्या कुबर्नेट्स पद्धतीचे फायदे दर्शविते.

वरील उदाहरण तीन प्रोडक्शन नोड्ससह लहान OpenShift कंटेनर प्लॅटफॉर्म 4 क्लस्टरमध्ये किंवा 3000 नोड्ससह मोठ्या उत्पादन क्लस्टरमध्ये बदल करण्याची क्षमता दर्शवते. कोणत्याही परिस्थितीत, कामाचे प्रमाण समान असेल - आणि अगदी लहान - फक्त ContainerRuntimeConfig फाइल कॉन्फिगर करा आणि MachineConfigPool मध्ये एक लेबल बदला. आणि तुम्ही हे OpenShift कंटेनर प्लॅटफॉर्म 4.X च्या कोणत्याही आवृत्तीसह करू शकता जे कुबेरनेट्सचे संपूर्ण आयुष्यभर चालते.

बर्‍याचदा तंत्रज्ञान कंपन्या इतक्या लवकर विकसित होतात की आम्ही अंतर्निहित घटकांसाठी विशिष्ट तंत्रज्ञान का निवडतो हे स्पष्ट करण्यात आम्ही अक्षम आहोत. कंटेनर इंजिन हे ऐतिहासिकदृष्ट्या घटक आहेत जे वापरकर्ते थेट संवाद साधतात. कंटेनरची लोकप्रियता नैसर्गिकरित्या कंटेनर इंजिनच्या आगमनाने सुरू झाल्यामुळे, वापरकर्ते सहसा त्यांच्यामध्ये स्वारस्य दाखवतात. Red Hat ने CRI-O निवडण्याचे हे दुसरे कारण आहे. आता ऑर्केस्ट्रेशनवर लक्ष केंद्रित करून कंटेनर विकसित होत आहेत आणि आम्हाला आढळले आहे की ओपनशिफ्ट 4 सह काम करताना CRI-O सर्वोत्तम अनुभव प्रदान करतो.

स्त्रोत: www.habr.com