ኮንቴይነር ወደ ማጓጓዣ፡ CRI-O አሁን በOpenShift Container Platform 4 ነባሪ ሆኗል።

የመሣሪያ ስርዓት የቀይ ኮፍያ OpenShift ኮንቴይነር መድረክ 4 ፈጠራን ለማመቻቸት ይፈቅድልዎታል መያዣዎችን ለመዘርጋት አስተናጋጆች, በደመና አገልግሎት አቅራቢዎች መሠረተ ልማት ውስጥ, በምናባዊ መድረኮች ላይ ወይም በባዶ-ሜታል ስርዓቶች ውስጥ. በእውነት ደመናን መሰረት ያደረገ መድረክ ለመፍጠር፣ ጥቅም ላይ የዋሉትን ሁሉንም ንጥረ ነገሮች ጥብቅ ቁጥጥር ማድረግ እና ውስብስብ አውቶማቲክ ሂደትን አስተማማኝነት መጨመር ነበረብን።

ግልፅ የሆነው መፍትሔ የቀይ ኮፍያ ኢንተርፕራይዝ ሊኑክስ ኮርኦኤስ (የቀይ ኮፍያ ኢንተርፕራይዝ ሊኑክስ ልዩነት) እና CRI-Oን እንደ ስታንዳርድ መጠቀም ነበር እና ለምን...

የኩበርኔትስ እና ኮንቴይነሮችን ሥራ ሲያብራሩ የመርከብ ርእሶችን ለማግኘት በጣም ጥሩ ነገር ስለሆነ CoreOS እና CRI-O ስለሚፈቱት የንግድ ሥራ ችግሮች አንድ ምሳሌን በመጠቀም ለመናገር እንሞክር ። የማጭበርበሪያ ብሎኮችን ለማምረት የብሩኔል ፈጠራዎች. እ.ኤ.አ. በ 1803 ማርክ ብሩነል እያደገ ለመጣው የብሪታንያ የባህር ኃይል ፍላጎቶች 100 ሪጂንግ ብሎኮችን የማምረት ኃላፊነት ተሰጥቶት ነበር። የማጭበርበሪያ እገዳ በሸራዎች ላይ ገመዶችን ለማያያዝ የሚያገለግል የመተጣጠፍ አይነት ነው. እስከ 19ኛው መቶ ክፍለ ዘመን መጀመሪያ ድረስ እነዚህ ብሎኮች የሚሠሩት በእጅ ነው፣ ነገር ግን ብሩኔል ምርትን በራስ-ሰር በማካሄድ የማሽን መሳሪያዎችን በመጠቀም ደረጃቸውን የጠበቁ ብሎኮች ማምረት ጀመረ። የዚህ ሂደት አውቶማቲክ ማለት የተፈጠሩት ብሎኮች በመሠረቱ ተመሳሳይ ናቸው፣ ከተሰበሩ በቀላሉ ሊተኩ የሚችሉ እና በብዛት ሊመረቱ ይችላሉ።

አሁን ብሩኔል ይህንን ሥራ ለ 20 የተለያዩ የመርከብ ሞዴሎች (የኩበርኔትስ ስሪቶች) እና ለአምስት የተለያዩ ፕላኔቶች ሙሉ ለሙሉ የተለያየ የባህር ሞገድ እና ንፋስ (የደመና አቅራቢዎች) መሥራት ነበረበት ብለው ያስቡ። በተጨማሪም ሁሉም መርከቦች (OpenShift ክላስተር) ምንም ይሁን ምን አሰሳ የሚካሄድባቸው ፕላኔቶች ምንም ይሁን ምን ከካፒቴኖቹ እይታ አንፃር (የክላስተር ስራውን የሚያስተዳድሩ ኦፕሬተሮች) ተመሳሳይ ባህሪ እንዲኖራቸው ያስፈልጋል። የባህር ላይ ተመሳሳይነት ለመቀጠል የመርከብ ካፒቴኖች በመርከቦቻቸው ላይ ምን ዓይነት ማጭበርበሪያ ብሎኮች (CRI-O) ጥቅም ላይ እንደሚውሉ በጭራሽ አይጨነቁም - ለእነሱ ዋናው ነገር እነዚህ ብሎኮች ጠንካራ እና አስተማማኝ ናቸው ።

OpenShift 4፣ እንደ ደመና መድረክ፣ በጣም ተመሳሳይ የሆነ የንግድ ፈተና ገጥሞታል። ክላስተር በሚፈጠርበት ጊዜ፣ በአንደኛው መስቀለኛ መንገድ ብልሽት ሲከሰት ወይም ክላስተር በሚለካበት ጊዜ አዲስ አንጓዎች መፈጠር አለባቸው። አዲስ መስቀለኛ መንገድ ሲፈጠር እና ሲጀመር CRI-Oን ጨምሮ ወሳኝ የአስተናጋጅ ክፍሎች በዚህ መሰረት መዋቀር አለባቸው። እንደሌሎች ምርቶች ሁሉ "ጥሬ እቃዎች" መጀመሪያ ላይ መቅረብ አለባቸው. በመርከቦች ውስጥ, ጥሬ እቃዎች ብረት እና እንጨት ናቸው. ነገር ግን፣ በOpenShift 4 cluster ውስጥ ኮንቴይነሮችን ለማሰማራት አስተናጋጅ ለመፍጠር፣ እንደ ግብአት የማዋቀር ፋይሎች እና በኤፒአይ የቀረቡ አገልጋዮች ሊኖሩዎት ይገባል። OpenShift በጠቅላላው የህይወት ዑደቱ ውስጥ የሚፈለገውን የአውቶሜትሽን ደረጃ ያቀርባል፣ ይህም አስፈላጊውን የምርት ድጋፍ ለዋና ተጠቃሚዎች በማቅረብ እና በመድረክ ላይ ያለውን ኢንቬስትመንት ይመልሳል።

OpenShift 4 የተፈጠረው በመድረኩ ሙሉ የህይወት ዑደት ውስጥ ስርዓቱን (ለ4.X ስሪቶች) ለዋና ዋና የደመና ማስላት አገልግሎት ሰጭዎች፣ የቨርቹዋል መድረኮች እና ሌላው ቀርቶ ባዶ የብረት ስርዓቶችን በተመጣጣኝ ሁኔታ የማዘመን ችሎታን ለማቅረብ በሚያስችል መንገድ ነው። ይህንን ለማድረግ, በሚለዋወጡ ንጥረ ነገሮች ላይ በመመስረት አንጓዎች መፈጠር አለባቸው. ክላስተር አዲስ የ Kubernetes ስሪት ሲፈልግ፣ እንዲሁም በCoreOS ላይ ያለውን ተዛማጅ የCRI-O ስሪት ይቀበላል። የCRI-O ሥሪት በቀጥታ ከኩበርኔትስ ጋር የተቆራኘ ስለሆነ፣ ይህ ለሙከራ፣ መላ ፍለጋ ወይም የድጋፍ ዓላማ ማናቸውንም ለውጦችን በእጅጉ ያቃልላል። በተጨማሪም, ይህ አቀራረብ ለዋና ተጠቃሚዎች እና ቀይ ኮፍያ ወጪዎችን ይቀንሳል.

ይህ በመሠረቱ ስለ ኩበርኔትስ ስብስቦች አዲስ የአስተሳሰብ መንገድ ነው እና አንዳንድ በጣም ጠቃሚ እና አሳማኝ አዲስ ባህሪያትን ለማቀድ መሰረት ይጥላል። CRI-O (የኮንቴይነር የሩጫ ጊዜ በይነገጽ - ክፍት ኮንቴይነር ተነሳሽነት ፣ በምህፃረ CRI-OCI) ከ OpenShift ጋር ለመስራት አስፈላጊ የሆኑትን አንጓዎች በብዛት ለመፍጠር በጣም የተሳካ ምርጫ ሆኖ ተገኝቷል። CRI-O ቀደም ሲል ጥቅም ላይ የዋለውን Docker ሞተር ይተካዋል, ይህም የ OpenShift ተጠቃሚዎችን ያቀርባል ኢኮኖሚያዊ, የተረጋጋ, ቀላል እና አሰልቺ - አዎ በትክክል ሰምተሃል - በተለይ ከኩበርኔትስ ጋር ለመስራት የተፈጠረ አሰልቺ የሆነ የእቃ መጫኛ ሞተር።

ክፍት መያዣዎች ዓለም

ዓለም ለረጅም ጊዜ ወደ ክፍት ኮንቴይነሮች እየተንቀሳቀሰ ነው. በኩበርኔትስም ሆነ በዝቅተኛ ደረጃዎች፣ የመያዣ ደረጃዎች እድገት በየደረጃው የፈጠራ ስነ-ምህዳርን ያስከትላል።

ይህ ሁሉ የተጀመረው የክፍት ኮንቴይነሮች ተነሳሽነት በመፍጠር ነው። በሰኔ ወር 2015 ዓ.ም. በዚህ የመጀመሪያ የሥራ ደረጃ ላይ የእቃ መጫኛ ዝርዝሮች ተፈጥረዋል ምስል и Runtime አካባቢ. ይህ መሳሪያዎቹ አንድ ነጠላ መስፈርት መጠቀም እንደሚችሉ አረጋግጧል የመያዣ ምስሎች እና ከእነሱ ጋር አብሮ ለመስራት የተዋሃደ ቅርጸት. በኋላ ላይ መግለጫዎች ተጨምረዋል። ስርጭት, ተጠቃሚዎች በቀላሉ እንዲያጋሩ በመፍቀድ የመያዣ ምስሎች.

የኩበርኔትስ ማህበረሰብ ከዚያ ለሚሰካ በይነገጽ አንድ ነጠላ መስፈርት ፈጠረ የኮንቴይነር የስራ ጊዜ በይነገጽ (ሲአርአይ). ለዚህም ምስጋና ይግባውና የኩበርኔትስ ተጠቃሚዎች ከዶከር በተጨማሪ ከኮንቴይነሮች ጋር ለመስራት የተለያዩ ሞተሮችን ማገናኘት ችለዋል።

በ Red Hat እና Google ላይ ያሉ መሐንዲሶች በ CRI ፕሮቶኮል ላይ የኩቤሌት ጥያቄዎችን መቀበል የሚችል የእቃ መጫኛ ሞተር የገበያ ፍላጎት አይተዋል እና ከላይ ከተጠቀሱት የ OCI ዝርዝሮች ጋር የሚጣጣሙ ኮንቴይነሮችን አስተዋውቀዋል። ስለዚህ OCID ታየ. ግን ይቅርታ አድርግልኝ፣ ይህ ቁሳቁስ ለ CRI-O ይሰጣል አላልንም? በእውነቱ እሱ ነው ፣ በመለቀቁ ብቻ ስሪት 1.0 ፕሮጀክቱ CRI-O ተብሎ ተሰየመ።

ምስል አስራ አምስት.

በCRI-O እና CoreOS ፈጠራ

የOpenShift 4 መድረክ ሲጀመር ተለወጠ መያዣ ሞተር, በመድረክ ውስጥ በነባሪነት ጥቅም ላይ የዋለ, እና ዶከር በ CRI-O ተተካ, ወጪ ቆጣቢ, የተረጋጋ, ቀላል እና አሰልቺ አካባቢን በማቅረብ ከኩበርኔትስ ጋር በትይዩ የሚያድግ መያዣ. ይህ የክላስተር ድጋፍን እና ውቅርን በእጅጉ ያቃልላል። የኮንቴይነር ኢንጂን እና አስተናጋጅ ውቅር እንዲሁም አስተዳደራቸው በOpenShift 4 ውስጥ አውቶማቲክ ይሆናል።

ቆይ ይሄ እንዴት ነው?

ልክ ነው፣ ከ OpenShift 4 መምጣት ጋር፣ ከተናጥል አስተናጋጆች ጋር መገናኘት እና የእቃ መጫኛ ሞተር መጫን፣ ማከማቻ ማዋቀር፣ የፍለጋ አገልጋዮችን ማዋቀር ወይም አውታረ መረብ ማዋቀር አያስፈልግም። የ OpenShift 4 መድረክ ሙሉ ለሙሉ ተዘጋጅቷል ለመጠቀም ኦፕሬተር ማዕቀፍ ከዋና ተጠቃሚ አፕሊኬሽኖች አንፃር ብቻ ሳይሆን በመሠረታዊ የመድረክ-ደረጃ ስራዎች ለምሳሌ ምስሎችን መዘርጋት, ስርዓቱን ማዋቀር ወይም ዝመናዎችን መጫን.

ኩበርኔትስ ሁል ጊዜ ተጠቃሚዎች የሚፈለገውን ሁኔታ በመግለጽ እና በመጠቀም መተግበሪያዎችን እንዲያስተዳድሩ ፈቅዷል ተቆጣጣሪዎች, ትክክለኛው ሁኔታ በተቻለ መጠን ከተፈለገው ሁኔታ ጋር እንደሚመሳሰል ለማረጋገጥ. ይህ የታለመው ሁኔታ እና ትክክለኛው የስቴት አቀራረብ ከልማት እና ከኦፕሬሽን እይታ አንጻር ትልቅ እድሎችን ይከፍታል። ገንቢዎች የሚፈለገውን ሁኔታ በ አስተላልፈው ለኦፕሬተሩ በ YAML ወይም JSON ፋይል መልክ ፣ እና ከዚያ ኦፕሬተሩ አስፈላጊውን የመተግበሪያ ምሳሌ በምርት አካባቢ ውስጥ መፍጠር ይችላል ፣ እና የዚህ ምሳሌ የስራ ሁኔታ ከተጠቀሰው ጋር ሙሉ በሙሉ ይዛመዳል።

ኦፕሬተሮችን በመድረክ ውስጥ በመጠቀም፣ OpenShift 4 ይህንን አዲስ ፓራዳይም (የሴቲንግ እና ትክክለኛው ሁኔታ ጽንሰ-ሀሳብ በመጠቀም) ወደ RHEL CoreOS እና CRI-O አስተዳደር ያመጣል። የስርዓተ ክወና ስሪቶችን እና የመያዣ ሞተርን የማዋቀር እና የማስተዳደር ተግባራት የሚባሉትን በመጠቀም በራስ-ሰር የሚሰሩ ናቸው የማሽን ኮንፊግ ኦፕሬተር (ኤም.ሲ.ኦ). MCO የክላስተር አስተዳዳሪን ስራ በእጅጉ ያቃልላል፣ በመሠረቱ የመጫኛውን የመጨረሻ ደረጃዎችን እንዲሁም ተከታይ የመጫን ስራዎችን (የቀን ሁለት ስራዎችን) በራስ ሰር ያደርጋል። ይህ ሁሉ OpenShift 4ን እውነተኛ የደመና መድረክ ያደርገዋል። ወደዚህ ጉዳይ ትንሽ ቆይተን እንገባለን።

የሩጫ መያዣዎች

ተጠቃሚዎች ከስሪት 3.7 ጀምሮ በቴክ ቅድመ እይታ ሁኔታ እና ከስሪት 3.9 ጀምሮ በአጠቃላይ የሚገኝ ሁኔታ (በአሁኑ ጊዜ የሚደገፍ) የ CRI-O ሞተርን በ OpenShift መድረክ ላይ የመጠቀም እድል አግኝተዋል። በተጨማሪም ቀይ ኮፍያ በብዛት ይጠቀማል CRI-O የምርት የሥራ ጫናዎችን ለማካሄድ በOpenShift Online ከስሪት 3.10 ጀምሮ። ይህ ሁሉ በ CRI-O ላይ የሚሠራው ቡድን በትላልቅ የኩበርኔትስ ስብስቦች ኮንቴይነሮችን በጅምላ የማስጀመር ልምድ እንዲያገኝ አስችሎታል። ኩበርኔትስ CRI-Oን እንዴት እንደሚጠቀም መሠረታዊ ግንዛቤ ለማግኘት፣ የሥነ ሕንፃው አሠራር እንዴት እንደሚሠራ የሚያሳየውን የሚከተለውን ምሳሌ እንመልከት።

ሩዝ. 2. መያዣዎች በኩበርኔትስ ክላስተር ውስጥ እንዴት እንደሚሠሩ

CRI-O አዲስ ኖዶችን ሲጀምር ሙሉውን ከፍተኛ ደረጃ በማመሳሰል እና የOpenShift መድረክ አዲስ ስሪቶችን በሚለቁበት ጊዜ አዲስ የኮንቴይነር አስተናጋጆችን መፍጠርን ያቃልላል። የመላው መድረክ ክለሳ የግብይት ማሻሻያ/መመለሻዎችን ይፈቅዳል፣እንዲሁም በኮንቴይነር ጅራት ኮር፣በኮንቴይነር ሞተር፣በአንጓዎች (Kubelets) እና በኩበርኔትስ ማስተር መስቀለኛ መንገድ መካከል ያሉ ጥገኞችን መገደብ ይከላከላል። ሁሉንም የመድረክ አካላትን በማእከላዊ በማስተዳደር፣ ከቁጥጥር እና ከስሪት ጋር፣ ከግዛት ሀ ወደ ግዛት B ምንጊዜም ግልጽ የሆነ መንገድ አለ። ይህ የማዘመን ሂደቱን ያቃልላል፣ ደህንነትን ያሻሽላል፣ የአፈጻጸም ሪፖርት ማድረግን ያሻሽላል እና የዝማኔዎች እና የአዳዲስ ስሪቶች ጭነት ወጪን ይቀንሳል። .

የመተኪያ አባሎችን ኃይል በማሳየት ላይ

ቀደም ሲል እንደተገለፀው በ OpenShift 4 ውስጥ የእቃ መጫኛ አስተናጋጅ እና የእቃ መያዢያ ሞተርን ለማስተዳደር የማሽን ኮንፊግ ኦፕሬተርን በመጠቀም ቀደም ሲል በኩበርኔትስ መድረክ ላይ የማይቻል አዲስ አውቶማቲክ ደረጃን ይሰጣል ። አዲሶቹን ባህሪያት ለማሳየት በcrio.conf ፋይል ላይ እንዴት ለውጦችን ማድረግ እንደሚችሉ እናሳያለን። በቃላት ግራ መጋባትን ለማስወገድ በውጤቶቹ ላይ ለማተኮር ይሞክሩ።

በመጀመሪያ ኮንቴይነር Runtime ውቅር የሚባለውን እንፍጠር - ኮንቴይነር Runtime Config. ለ CRI-O ውቅረትን የሚወክል እንደ የኩበርኔትስ ምንጭ አድርገው ያስቡ። እንደ እውነቱ ከሆነ፣ ልዩ የሆነ የማሽን ኮንፊግ የሚባል ነገር ነው፣ እሱም እንደ የOpenShift ክላስተር አካል ወደ RHEL CoreOS ማሽን የሚዘረጋ ማንኛውም ውቅር ነው።

ContainerRuntimeConfig ተብሎ የሚጠራው ይህ ብጁ መርጃ የክላስተር አስተዳዳሪዎች 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

ContainerRuntimeConfigን ከፈጠርን በኋላ፣ ይህንን ውቅር በክላስተር ውስጥ ለተወሰኑ የማሽኖች ቡድን መተግበር እንደምንፈልግ ለኩበርኔትስ ምልክት ለመስጠት ከማሽን ኮንፊግ ገንዳዎች አንዱን ማሻሻል አለብን። በዚህ አጋጣሚ የማሽን ኮንፊግ ፑልን ለዋና አንጓዎች እንለውጣለን፡

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 የማሽን ኮንፊግ ልዩ ስሪት ነው፣ ስለዚህ በማሽን ኮንፊግ ውስጥ ያሉትን ተዛማጅ መስመሮች በመመልከት ውጤቱን ማየት እንችላለን፡

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 መርጃ ላይ ለገለፅናቸው የፒዲ እና ማረም መመሪያዎች በአዲሱ እሴቶች መዘመኑን ያያሉ። ውበት እራሱ;

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"
...

እነዚህ ሁሉ በክላስተር ላይ የተደረጉ ለውጦች ኤስኤስኤች ሳይሄዱ ተደርገዋል። ሁሉም ስራዎች የተከናወኑት የኩቤሬንቴስ ዋና መስቀለኛ መንገድን በማግኘት ነው። ያም ማለት እነዚህ አዳዲስ መመዘኛዎች የተዋቀሩት በማስተር ኖዶች ላይ ብቻ ነው. የሰራተኛው አንጓዎች አልተለወጡም, ይህም የኩበርኔትስ ዘዴ የተወሰኑ እና ትክክለኛ ግዛቶችን ከመያዣ አስተናጋጆች እና ከኮንቴይነር ሞተሮች ጋር በተለዋዋጭ ንጥረ ነገሮች ላይ ያለውን ጥቅም ያሳያል.

ከላይ ያለው ምሳሌ በትንሽ የOpenShift Container Platform 4 ክላስተር በሶስት የምርት ኖዶች ወይም 3000 ኖዶች ባለው ግዙፍ የምርት ክላስተር ላይ ለውጦችን የማድረግ ችሎታ ያሳያል። በማንኛውም ሁኔታ የሥራው መጠን ተመሳሳይ ይሆናል - እና በጣም ትንሽ - የContainerRuntimeConfig ፋይልን ብቻ ያዋቅሩ እና በ MachineConfigPool ውስጥ አንድ መለያ ይቀይሩ። እና በማንኛውም የOpenShift Container Platform 4.X ኩበርኔትስ በህይወት ዑደቱ ሁሉ ይህንን ማድረግ ይችላሉ።

ብዙውን ጊዜ የቴክኖሎጂ ኩባንያዎች በፍጥነት ይሻሻላሉ, ለምንድነው ለስር ክፍሎች አንዳንድ ቴክኖሎጂዎችን እንደመረጥን ማብራራት አንችልም. የኮንቴይነር ሞተሮች በታሪክ ተጠቃሚዎች በቀጥታ የሚገናኙበት አካል ናቸው። የመያዣዎች ተወዳጅነት በተፈጥሮ የመያዣ ሞተሮች መምጣት የጀመረ በመሆኑ ተጠቃሚዎች ብዙውን ጊዜ ለእነሱ ፍላጎት ያሳያሉ። ቀይ ኮፍያ CRI-Oን የመረጠበት ሌላ ምክንያት ይህ ነው። ኮንቴይነሮች አሁን በኦርኬስትራ ላይ ትኩረት በማድረግ እየተሻሻሉ ነው፣ እና CRI-O ከOpenShift 4 ጋር ሲሰራ ምርጡን ተሞክሮ እንደሚያቀርብ ደርሰንበታል።

ምንጭ: hab.com