कन्भेयरमा कन्टेनर: CRI-O अब OpenShift कन्टेनर प्लेटफर्म 4 मा पूर्वनिर्धारित छ

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

स्पष्ट समाधान Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux को एक संस्करण) र CRI-O लाई मानकको रूपमा प्रयोग गर्नु थियो, र यहाँ किन छ...

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

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

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

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

यो Kubernetes क्लस्टरहरूको बारेमा सोच्ने मौलिक रूपमा नयाँ तरिका हो र यसले केही धेरै उपयोगी र आकर्षक नयाँ सुविधाहरूको योजना बनाउनको लागि जग राख्छ। CRI-O (कन्टेनर रनटाइम इन्टरफेस - ओपन कन्टेनर इनिसिएटिभ, संक्षिप्त CRI-OCI) ओपनशिफ्टसँग काम गर्न आवश्यक नोडहरूको ठूलो सिर्जनाको लागि सबैभन्दा सफल छनौट भयो। CRI-O ले पहिले प्रयोग गरिएको डकर इन्जिनलाई प्रतिस्थापन गर्नेछ, OpenShift प्रयोगकर्ताहरू प्रदान गर्दै आर्थिक, स्थिर, सरल र बोरिंग - हो, तपाईंले सही सुन्नुभयो - एक बोरिङ कन्टेनर इन्जिन विशेष गरी Kubernetes संग काम गर्न को लागी बनाईएको छ।

खुला कन्टेनरहरूको संसार

संसार लामो समयदेखि खुला कन्टेनरतर्फ अघि बढिरहेको छ। चाहे कुबेरनेटमा होस्, वा तल्लो तहमा, कन्टेनर मापदण्ड को विकास हरेक तहमा नवप्रवर्तनको इकोसिस्टममा परिणाम दिन्छ।

यो सबै खुला कन्टेनर पहल को निर्माण संग शुरू भयो जुन 2015 मा। कामको यो प्रारम्भिक चरणमा, कन्टेनर विनिर्देशहरू गठन गरिएको थियो छवि и रनटाइम वातावरण। यसले सुनिश्चित गर्‍यो कि उपकरणहरूले एकल मानक प्रयोग गर्न सक्छ कन्टेनर छविहरू र तिनीहरूसँग काम गर्नको लागि एक एकीकृत ढाँचा। विनिर्देशहरू पछि थपियो वितरण, प्रयोगकर्ताहरूलाई सजिलै साझेदारी गर्न अनुमति दिन्छ कन्टेनर छविहरू.

Kubernetes समुदायले त्यसपछि प्लग गर्न मिल्ने इन्टरफेसको लागि एकल मानक विकसित गर्यो, भनिन्छ कन्टेनर रनटाइम इन्टरफेस (CRI)। यसका लागि धन्यवाद, कुबेरनेट प्रयोगकर्ताहरूले डकरको अतिरिक्त कन्टेनरहरूसँग काम गर्न विभिन्न इन्जिनहरू जडान गर्न सक्षम भए।

Red Hat र Google का इन्जिनियरहरूले CRI प्रोटोकलमा कुबेलेट अनुरोधहरू स्वीकार गर्न सक्ने कन्टेनर इन्जिनको बजार आवश्यकता देखे र माथि उल्लिखित OCI विनिर्देशहरूसँग मिल्दो कन्टेनरहरू प्रस्तुत गरे। त्यसैले OCID देखा पर्‍यो। तर मलाई माफ गर्नुहोस्, के हामीले यो सामग्री CRI-O लाई समर्पित हुनेछ भनेर भनेनौं? वास्तवमा यो हो, रिलीज संग संस्करण ११ परियोजनाको नाम CRI-O राखियो।

अंजीर। १

CRI-O र CoreOS सँग नवप्रवर्तन

OpenShift 4 प्लेटफर्मको सुरुवात संग, यो परिवर्तन भयो कन्टेनर इन्जिन, प्लेटफर्ममा पूर्वनिर्धारित रूपमा प्रयोग गरिन्छ, र डकरलाई CRI-O द्वारा प्रतिस्थापित गरिएको थियो, जसले Kubernetes सँग समानान्तर रूपमा विकास हुने कन्टेनर चलाउनको लागि लागत-प्रभावी, स्थिर, सरल र बोरिंग वातावरण प्रदान गर्दछ। यसले क्लस्टर समर्थन र कन्फिगरेसनलाई धेरै सरल बनाउँछ। कन्टेनर इन्जिन र होस्टको कन्फिगरेसन, साथै तिनीहरूको व्यवस्थापन, OpenShift 4 भित्र स्वचालित हुन्छ।

पर्खनुहोस्, यो कस्तो छ?

यो ठीक छ, OpenShift 4 को आगमन संग, त्यहाँ अब व्यक्तिगत होस्टहरूमा जडान गर्न र कन्टेनर इन्जिन स्थापना गर्न, भण्डारण कन्फिगर गर्न, खोज सर्भरहरू कन्फिगर गर्न वा नेटवर्क कन्फिगर गर्न आवश्यक छैन। OpenShift 4 प्लेटफर्म पूर्ण रूपमा प्रयोग गर्न पुन: डिजाइन गरिएको छ अपरेटर फ्रेमवर्क अन्तिम-प्रयोगकर्ता अनुप्रयोगहरूको सर्तमा मात्र होइन, तर छविहरू डिप्लोइ गर्ने, प्रणाली कन्फिगर गर्ने, वा अद्यावधिकहरू स्थापना गर्ने जस्ता आधारभूत प्लेटफर्म-स्तर सञ्चालनहरूको सन्दर्भमा पनि।

Kubernetes ले सधैं प्रयोगकर्ताहरूलाई इच्छित अवस्था परिभाषित गरेर र प्रयोग गरेर अनुप्रयोगहरू व्यवस्थापन गर्न अनुमति दिएको छ नियन्त्रकहरू, वास्तविक राज्य लक्ष्य राज्यसँग सम्भव भएसम्म मिल्छ भन्ने कुरा सुनिश्चित गर्न। यो लक्ष्य राज्य र वास्तविक राज्य दृष्टिकोण दुबै विकास र सञ्चालन परिप्रेक्ष्यबाट ठूलो अवसरहरू खोल्छ। विकासकर्ताहरूले आवश्यक राज्य द्वारा परिभाषित गर्न सक्छन् यसलाई पास गर्नुहोस् YAML वा JSON फाइलको रूपमा अपरेटरलाई, र त्यसपछि अपरेटरले उत्पादन वातावरणमा आवश्यक अनुप्रयोग उदाहरण सिर्जना गर्न सक्छ, र यस उदाहरणको अपरेटिङ अवस्था पूर्ण रूपमा निर्दिष्ट गरिएकोसँग मेल खान्छ।

प्लेटफर्ममा अपरेटरहरू प्रयोग गरेर, OpenShift 4 ले RHEL CoreOS र CRI-O को व्यवस्थापनमा यो नयाँ प्रतिमान (सेट र वास्तविक अवस्थाको अवधारणा प्रयोग गरेर) ल्याउँछ। अपरेटिङ सिस्टम र कन्टेनर इन्जिनको संस्करणहरू कन्फिगर गर्ने र प्रबन्ध गर्ने कार्यहरू तथाकथित प्रयोग गरेर स्वचालित हुन्छन्। मेसिन कन्फिग अपरेटर (MCO)। MCO ले क्लस्टर प्रशासकको कामलाई धेरै सरल बनाउँछ, अनिवार्य रूपमा स्थापनाको अन्तिम चरणहरू, साथै पछि स्थापना पछि सञ्चालनहरू (दिन दुई कार्यहरू) स्वचालित रूपमा। यी सबैले OpenShift 4 लाई साँचो क्लाउड प्लेटफर्म बनाउँछ। हामी केहि पछि यो मा प्रवेश गर्नेछौं।

चलिरहेको कन्टेनरहरू

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

चामल। 2. Kubernetes क्लस्टरमा कन्टेनरहरूले कसरी काम गर्छ

CRI-O ले नयाँ नोडहरू प्रारम्भ गर्दा, र OpenShift प्लेटफर्मको नयाँ संस्करणहरू जारी गर्दा सम्पूर्ण शीर्ष स्तर सिङ्क्रोनाइज गरेर नयाँ कन्टेनर होस्टहरूको सिर्जनालाई सरल बनाउँछ। सम्पूर्ण प्लेटफर्मको संशोधनले लेनदेन अद्यावधिकहरू/रोलब्याकहरूको लागि अनुमति दिन्छ, र कन्टेनर टेल कोर, कन्टेनर इन्जिन, नोडहरू (कुबेलेट्स) र कुबेरनेट मास्टर नोडहरू बीचको निर्भरतामा अवरोधहरू पनि रोक्छ। केन्द्रीय रूपमा सबै प्लेटफर्म कम्पोनेन्टहरू प्रबन्ध गरेर, नियन्त्रण र संस्करणको साथ, त्यहाँ सधैं राज्य A देखि राज्य B सम्म एक स्पष्ट मार्ग हुन्छ। यसले अद्यावधिक प्रक्रियालाई सरल बनाउँछ, सुरक्षा सुधार गर्दछ, प्रदर्शन रिपोर्टिङ सुधार गर्दछ, र नयाँ संस्करणहरूको अद्यावधिक र स्थापनाहरूको लागत घटाउन मद्दत गर्दछ। ।

प्रतिस्थापन तत्वहरूको शक्ति प्रदर्शन गर्दै

पहिले उल्लेख गरिए अनुसार, OpenShift 4 मा कन्टेनर होस्ट र कन्टेनर इन्जिन प्रबन्ध गर्न मेसिन कन्फिग अपरेटर प्रयोग गर्नाले स्वचालनको नयाँ स्तर प्रदान गर्दछ जुन पहिले Kubernetes प्लेटफर्ममा सम्भव थिएन। नयाँ सुविधाहरू देखाउनको लागि, हामी तपाईँले crio.conf फाइलमा कसरी परिवर्तन गर्न सक्नुहुन्छ भनेर देखाउने छौँ। शब्दावली द्वारा भ्रमित हुनबाट जोगिन, परिणामहरूमा ध्यान केन्द्रित गर्ने प्रयास गर्नुहोस्।

पहिले, कन्टेनर रनटाइम कन्फिगरेसन - कन्टेनर रनटाइम कन्फिगरेसन भन्ने कुरा सिर्जना गरौं। यसलाई CRI-O को कन्फिगरेसन प्रतिनिधित्व गर्ने कुबर्नेट्स स्रोतको रूपमा सोच्नुहोस्। वास्तवमा, यो MachineConfig भनिने केहिको एक विशेष संस्करण हो, जुन कुनै पनि कन्फिगरेसन हो जुन RHEL CoreOS मेसिनमा OpenShift क्लस्टरको भागको रूपमा प्रयोग गरिन्छ।

यो अनुकूलन स्रोत, जसलाई 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 सिर्जना गरिसकेपछि, हामीले Kubernetes लाई संकेत गर्नको लागि 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 फाइल सिर्जना गर्न थाल्छ। यस अवस्थामा, पूर्ण रूपमा समाप्त कन्फिगरेसन फाइल Kubernetes 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 चलाउन बिना नै बनाइएका थिए। सबै काम Kuberentes मास्टर नोड पहुँच गरेर गरिएको थियो। त्यो हो, यी नयाँ प्यारामिटरहरू मास्टर नोडहरूमा मात्र कन्फिगर गरिएको थियो। कार्यकर्ता नोडहरू परिवर्तन भएनन्, जसले कन्टेनर होस्टहरू र कन्टेनर इन्जिनहरू आदानप्रदानयोग्य तत्वहरूसँगको सन्दर्भमा निर्दिष्ट र वास्तविक अवस्थाहरू प्रयोग गर्ने कुबर्नेट्स पद्धतिका फाइदाहरू देखाउँदछ।

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

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

स्रोत: www.habr.com