കണ്ടെയ്‌നർ ടു കൺവെയർ: CRI-O ഇപ്പോൾ OpenShift കണ്ടെയ്‌നർ പ്ലാറ്റ്‌ഫോം 4-ൽ ഡിഫോൾട്ടാണ്

പ്ലാറ്റ്ഫോം Red Hat OpenShift കണ്ടെയ്നർ പ്ലാറ്റ്ഫോം 4 സൃഷ്ടിയെ കാര്യക്ഷമമാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു കണ്ടെയ്നറുകൾ വിന്യസിക്കുന്നതിനുള്ള ഹോസ്റ്റുകൾ, ക്ലൗഡ് സേവന ദാതാക്കളുടെ ഇൻഫ്രാസ്ട്രക്ചറിൽ, വെർച്വലൈസേഷൻ പ്ലാറ്റ്‌ഫോമുകളിലോ ബെയർ-മെറ്റൽ സിസ്റ്റങ്ങളിലോ ഉൾപ്പെടെ. ഒരു യഥാർത്ഥ ക്ലൗഡ് അധിഷ്‌ഠിത പ്ലാറ്റ്‌ഫോം സൃഷ്‌ടിക്കുന്നതിന്, ഉപയോഗിച്ച എല്ലാ ഘടകങ്ങളുടെയും കർശന നിയന്ത്രണം ഞങ്ങൾ ഏറ്റെടുക്കുകയും അങ്ങനെ സങ്കീർണ്ണമായ ഒരു ഓട്ടോമേഷൻ പ്രക്രിയയുടെ വിശ്വാസ്യത വർദ്ധിപ്പിക്കുകയും വേണം.

വ്യക്തമായ പരിഹാരം Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux-ന്റെ ഒരു വകഭേദം), CRI-O എന്നിവ സ്റ്റാൻഡേർഡായി ഉപയോഗിക്കുക എന്നതായിരുന്നു, അതിനുള്ള കാരണം ഇതാണ്...

കുബർനെറ്റുകളുടെയും കണ്ടെയ്‌നറുകളുടെയും പ്രവർത്തനം വിശദീകരിക്കുമ്പോൾ സാമ്യങ്ങൾ കണ്ടെത്തുന്നതിന് കപ്പലോട്ടം എന്ന വിഷയം വളരെ നല്ല ഒന്നായതിനാൽ, ഒരു ഉദാഹരണം ഉപയോഗിച്ച് CoreOS ഉം CRI-O ഉം പരിഹരിക്കുന്ന ബിസിനസ്സ് പ്രശ്‌നങ്ങളെക്കുറിച്ച് സംസാരിക്കാൻ ശ്രമിക്കാം. റിഗ്ഗിംഗ് ബ്ലോക്കുകൾ നിർമ്മിക്കുന്നതിനുള്ള ബ്രൂണലിന്റെ കണ്ടുപിടുത്തങ്ങൾ. 1803-ൽ, വളർന്നുവരുന്ന ബ്രിട്ടീഷ് നാവികസേനയുടെ ആവശ്യങ്ങൾക്കായി 100 റിഗ്ഗിംഗ് ബ്ലോക്കുകൾ നിർമ്മിക്കാൻ മാർക്ക് ബ്രൂണലിനെ ചുമതലപ്പെടുത്തി. കപ്പലുകളിൽ കയറുകൾ ഘടിപ്പിക്കാൻ ഉപയോഗിക്കുന്ന ഒരു തരം റിഗ്ഗിംഗ് ആണ് റിഗ്ഗിംഗ് ബ്ലോക്ക്. പത്തൊൻപതാം നൂറ്റാണ്ടിന്റെ ആരംഭം വരെ, ഈ ബ്ലോക്കുകൾ കൈകൊണ്ട് നിർമ്മിച്ചവയായിരുന്നു, എന്നാൽ ബ്രൂണലിന് ഉത്പാദനം ഓട്ടോമേറ്റ് ചെയ്യാൻ കഴിഞ്ഞു, കൂടാതെ യന്ത്ര ഉപകരണങ്ങൾ ഉപയോഗിച്ച് സ്റ്റാൻഡേർഡ് ബ്ലോക്കുകൾ നിർമ്മിക്കാൻ തുടങ്ങി. ഈ പ്രക്രിയയുടെ ഓട്ടോമേഷൻ അർത്ഥമാക്കുന്നത്, തത്ഫലമായുണ്ടാകുന്ന ബ്ലോക്കുകൾ അടിസ്ഥാനപരമായി സമാനമാണ്, തകർന്നാൽ എളുപ്പത്തിൽ മാറ്റിസ്ഥാപിക്കാവുന്നതും വലിയ അളവിൽ ഉൽപ്പാദിപ്പിക്കാവുന്നതുമാണ്.

20 വ്യത്യസ്ത കപ്പൽ മോഡലുകൾക്കും (കുബർനെറ്റസ് പതിപ്പുകൾ) തികച്ചും വ്യത്യസ്തമായ കടൽ പ്രവാഹങ്ങളും കാറ്റും ഉള്ള അഞ്ച് വ്യത്യസ്ത ഗ്രഹങ്ങൾക്കും (ക്ലൗഡ് പ്രൊവൈഡർമാർ) ബ്രൂണൽ ഈ ജോലി ചെയ്യേണ്ടി വന്നിട്ടുണ്ടോ എന്ന് ഇപ്പോൾ സങ്കൽപ്പിക്കുക. കൂടാതെ, എല്ലാ കപ്പലുകളും (ഓപ്പൺഷിഫ്റ്റ് ക്ലസ്റ്ററുകൾ), നാവിഗേഷൻ നടത്തുന്ന ഗ്രഹങ്ങൾ പരിഗണിക്കാതെ തന്നെ, ക്യാപ്റ്റൻമാരുടെ (ക്ലസ്റ്ററുകളുടെ പ്രവർത്തനം നിയന്ത്രിക്കുന്ന ഓപ്പറേറ്റർമാർ) വീക്ഷണകോണിൽ നിന്ന് ഒരേപോലെ പെരുമാറേണ്ടത് ആവശ്യമാണ്. സമുദ്ര സാമ്യം തുടരുന്നതിന്, കപ്പൽ ക്യാപ്റ്റൻമാർ അവരുടെ കപ്പലുകളിൽ ഏത് തരത്തിലുള്ള റിഗ്ഗിംഗ് ബ്ലോക്കുകൾ (സിആർഐ-ഒ) ഉപയോഗിക്കുന്നു എന്നത് ഒട്ടും ശ്രദ്ധിക്കുന്നില്ല - ഈ ബ്ലോക്കുകൾ ശക്തവും വിശ്വസനീയവുമാണ് എന്നതാണ് അവർക്ക് പ്രധാന കാര്യം.

OpenShift 4, ഒരു ക്ലൗഡ് പ്ലാറ്റ്‌ഫോം എന്ന നിലയിൽ, സമാനമായ ഒരു ബിസിനസ്സ് വെല്ലുവിളിയെ അഭിമുഖീകരിക്കുന്നു. ക്ലസ്റ്റർ സൃഷ്‌ടിക്കുമ്പോൾ, ഒരു നോഡിൽ പരാജയം സംഭവിച്ചാൽ, അല്ലെങ്കിൽ ക്ലസ്റ്റർ സ്കെയിൽ ചെയ്യുമ്പോൾ പുതിയ നോഡുകൾ സൃഷ്‌ടിക്കണം. ഒരു പുതിയ നോഡ് സൃഷ്ടിക്കുകയും ആരംഭിക്കുകയും ചെയ്യുമ്പോൾ, CRI-O ഉൾപ്പെടെയുള്ള നിർണായക ഹോസ്റ്റ് ഘടകങ്ങൾ അതിനനുസരിച്ച് കോൺഫിഗർ ചെയ്യണം. മറ്റേതൊരു ഉൽപാദനത്തിലെയും പോലെ, "അസംസ്കൃത വസ്തുക്കൾ" തുടക്കത്തിൽ തന്നെ നൽകണം. കപ്പലുകളുടെ കാര്യത്തിൽ, അസംസ്കൃത വസ്തുക്കൾ ലോഹവും മരവുമാണ്. എന്നിരുന്നാലും, OpenShift 4 ക്ലസ്റ്ററിൽ കണ്ടെയ്‌നറുകൾ വിന്യസിക്കുന്നതിന് ഒരു ഹോസ്റ്റ് സൃഷ്‌ടിക്കുമ്പോൾ, നിങ്ങൾക്ക് ഇൻപുട്ടായി കോൺഫിഗറേഷൻ ഫയലുകളും API-നൽകിയ സെർവറുകളും ഉണ്ടായിരിക്കണം. ഓപ്പൺഷിഫ്റ്റ് മുഴുവൻ ജീവിത ചക്രത്തിലുടനീളം ആവശ്യമായ ഓട്ടോമേഷൻ നൽകും, അന്തിമ ഉപയോക്താക്കൾക്ക് ആവശ്യമായ ഉൽപ്പന്ന പിന്തുണ വാഗ്ദാനം ചെയ്യുകയും പ്ലാറ്റ്‌ഫോമിലെ നിക്ഷേപം തിരിച്ചുപിടിക്കുകയും ചെയ്യും.

എല്ലാ പ്രധാന ക്ലൗഡ് കമ്പ്യൂട്ടിംഗ് ദാതാക്കൾ, വിർച്ച്വലൈസേഷൻ പ്ലാറ്റ്‌ഫോമുകൾ, ബെയർ മെറ്റൽ സിസ്റ്റങ്ങൾ എന്നിവയ്‌ക്കും പ്ലാറ്റ്‌ഫോമിന്റെ മുഴുവൻ ജീവിത ചക്രത്തിലും (4.X പതിപ്പുകൾക്കായി) സിസ്റ്റം സൗകര്യപ്രദമായി അപ്‌ഡേറ്റ് ചെയ്യാനുള്ള കഴിവ് പ്രദാനം ചെയ്യുന്ന തരത്തിലാണ് OpenShift 4 സൃഷ്‌ടിച്ചത്. ഇത് ചെയ്യുന്നതിന്, പരസ്പരം മാറ്റാവുന്ന മൂലകങ്ങളുടെ അടിസ്ഥാനത്തിൽ നോഡുകൾ സൃഷ്ടിക്കണം. ഒരു ക്ലസ്റ്ററിന് Kubernetes-ന്റെ ഒരു പുതിയ പതിപ്പ് ആവശ്യമായി വരുമ്പോൾ, CoreOS-ൽ CRI-O-യുടെ അനുബന്ധ പതിപ്പും അത് സ്വീകരിക്കുന്നു. CRI-O പതിപ്പ് നേരിട്ട് കുബർനെറ്റസുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നതിനാൽ, ഇത് പരിശോധനയ്‌ക്കോ ട്രബിൾഷൂട്ടിംഗിനോ പിന്തുണയ്‌ക്കാനോ ഉള്ള ഏത് ക്രമമാറ്റങ്ങളെയും വളരെ ലളിതമാക്കുന്നു. കൂടാതെ, ഈ സമീപനം അന്തിമ ഉപയോക്താക്കൾക്കും Red Hat-നും ചെലവ് കുറയ്ക്കുന്നു.

ഇത് കുബെർനെറ്റസ് ക്ലസ്റ്ററുകളെക്കുറിച്ച് ചിന്തിക്കുന്നതിനുള്ള അടിസ്ഥാനപരമായി ഒരു പുതിയ മാർഗമാണ് കൂടാതെ വളരെ ഉപയോഗപ്രദവും ആകർഷകവുമായ ചില പുതിയ സവിശേഷതകൾ ആസൂത്രണം ചെയ്യുന്നതിനുള്ള അടിത്തറയിടുന്നു. CRI-O (കണ്ടെയ്‌നർ റൺടൈം ഇന്റർഫേസ് - ഓപ്പൺ കണ്ടെയ്‌നർ ഇനിഷ്യേറ്റീവ്, ചുരുക്കത്തിൽ CRI-OCI) ഓപ്പൺഷിഫ്റ്റിനൊപ്പം പ്രവർത്തിക്കാൻ ആവശ്യമായ നോഡുകൾ വൻതോതിൽ സൃഷ്ടിക്കുന്നതിനുള്ള ഏറ്റവും വിജയകരമായ തിരഞ്ഞെടുപ്പായി മാറി. CRI-O ഓപ്പൺഷിഫ്റ്റ് ഉപയോക്താക്കൾ വാഗ്ദാനം ചെയ്യുന്ന മുമ്പ് ഉപയോഗിച്ച ഡോക്കർ എഞ്ചിൻ മാറ്റിസ്ഥാപിക്കും സാമ്പത്തികവും സുസ്ഥിരവും ലളിതവും വിരസവുമാണ് - അതെ, നിങ്ങൾ കേട്ടത് ശരിയാണ് - കുബർനെറ്റസുമായി പ്രവർത്തിക്കാൻ പ്രത്യേകം സൃഷ്ടിച്ച ഒരു ബോറടിപ്പിക്കുന്ന കണ്ടെയ്നർ എഞ്ചിൻ.

തുറന്ന പാത്രങ്ങളുടെ ലോകം

ലോകം വളരെക്കാലമായി തുറന്ന പാത്രങ്ങളിലേക്കാണ് നീങ്ങുന്നത്. കുബെർനെറ്റിലായാലും താഴ്ന്ന നിലയിലായാലും, കണ്ടെയ്നർ മാനദണ്ഡങ്ങളുടെ വികസനം എല്ലാ തലത്തിലും നവീകരണത്തിന്റെ ഒരു ആവാസവ്യവസ്ഥയിൽ കലാശിക്കുന്നു.

ഓപ്പൺ കണ്ടെയ്‌നേഴ്‌സ് ഇനിഷ്യേറ്റീവിന്റെ സൃഷ്ടിയോടെയാണ് ഇതെല്ലാം ആരംഭിച്ചത് 2015 ജൂണിൽ. ജോലിയുടെ ഈ പ്രാരംഭ ഘട്ടത്തിൽ, കണ്ടെയ്നർ സവിശേഷതകൾ രൂപീകരിച്ചു ചിത്രം и റൺടൈം പരിസ്ഥിതി. ഉപകരണങ്ങൾക്ക് ഒരൊറ്റ സ്റ്റാൻഡേർഡ് ഉപയോഗിക്കാനാകുമെന്ന് ഇത് ഉറപ്പാക്കി കണ്ടെയ്നർ ചിത്രങ്ങൾ അവരോടൊപ്പം പ്രവർത്തിക്കുന്നതിനുള്ള ഏകീകൃത ഫോർമാറ്റും. സ്പെസിഫിക്കേഷനുകൾ പിന്നീട് ചേർത്തു വിതരണ, എളുപ്പത്തിൽ പങ്കിടാൻ ഉപയോക്താക്കളെ അനുവദിക്കുന്നു കണ്ടെയ്നർ ചിത്രങ്ങൾ.

കുബർനെറ്റസ് കമ്മ്യൂണിറ്റി പിന്നീട് പ്ലഗ്ഗബിൾ ഇന്റർഫേസിനായി ഒരൊറ്റ സ്റ്റാൻഡേർഡ് വികസിപ്പിച്ചെടുത്തു കണ്ടെയ്നർ റൺടൈം ഇന്റർഫേസ് (CRI). ഇതിന് നന്ദി, കുബെർനെറ്റസ് ഉപയോക്താക്കൾക്ക് ഡോക്കറിന് പുറമേ കണ്ടെയ്‌നറുകളുമായി പ്രവർത്തിക്കാൻ വിവിധ എഞ്ചിനുകൾ ബന്ധിപ്പിക്കാൻ കഴിഞ്ഞു.

CRI പ്രോട്ടോക്കോളിലൂടെ കുബെലെറ്റ് അഭ്യർത്ഥനകൾ സ്വീകരിക്കാൻ കഴിയുന്ന ഒരു കണ്ടെയ്‌നർ എഞ്ചിന്റെ വിപണി ആവശ്യകത Red Hat-ലെയും Google-ലെയും എഞ്ചിനീയർമാർ കാണുകയും മുകളിൽ സൂചിപ്പിച്ച OCI സ്പെസിഫിക്കേഷനുകൾക്ക് അനുയോജ്യമായ കണ്ടെയ്‌നറുകൾ അവതരിപ്പിക്കുകയും ചെയ്തു. അങ്ങനെ OCID പ്രത്യക്ഷപ്പെട്ടു. എന്നാൽ ക്ഷമിക്കണം, ഈ മെറ്റീരിയൽ CRI-O യ്ക്ക് സമർപ്പിക്കുമെന്ന് ഞങ്ങൾ പറഞ്ഞില്ലേ? യഥാർത്ഥത്തിൽ അത്, റിലീസിനൊപ്പം മാത്രം പതിപ്പ് 1.0 പദ്ധതിയുടെ പേര് CRI-O എന്ന് പുനർനാമകരണം ചെയ്തു.

ചിത്രം. 1.

CRI-O, CoreOS എന്നിവയ്‌ക്കൊപ്പം ഇന്നൊവേഷൻ

ഓപ്പൺഷിഫ്റ്റ് 4 പ്ലാറ്റ്‌ഫോമിന്റെ സമാരംഭത്തോടെ, അത് മാറ്റി കണ്ടെയ്നർ എഞ്ചിൻ, പ്ലാറ്റ്‌ഫോമിൽ ഡിഫോൾട്ടായി ഉപയോഗിക്കുന്നു, കൂടാതെ ഡോക്കറിന് പകരം CRI-O നൽകി, കുബർനെറ്റസിന് സമാന്തരമായി വികസിക്കുന്ന ഒരു കണ്ടെയ്‌നർ പ്രവർത്തിപ്പിക്കുന്നതിന് ചെലവ് കുറഞ്ഞതും സുസ്ഥിരവും ലളിതവും വിരസവുമായ അന്തരീക്ഷം വാഗ്ദാനം ചെയ്യുന്നു. ഇത് ക്ലസ്റ്റർ പിന്തുണയും കോൺഫിഗറേഷനും വളരെ ലളിതമാക്കുന്നു. കണ്ടെയ്നർ എഞ്ചിന്റെയും ഹോസ്റ്റിന്റെയും കോൺഫിഗറേഷനും അവയുടെ മാനേജ്മെന്റും ഓപ്പൺഷിഫ്റ്റ് 4-നുള്ളിൽ യാന്ത്രികമായി മാറുന്നു.

കാത്തിരിക്കൂ, ഇത് എങ്ങനെ?

അത് ശരിയാണ്, ഓപ്പൺഷിഫ്റ്റ് 4-ന്റെ വരവോടെ, വ്യക്തിഗത ഹോസ്റ്റുകളിലേക്ക് കണക്റ്റുചെയ്‌ത് ഒരു കണ്ടെയ്‌നർ എഞ്ചിൻ ഇൻസ്റ്റാൾ ചെയ്യേണ്ടതില്ല, സ്റ്റോറേജ് കോൺഫിഗർ ചെയ്യുക, തിരയൽ സെർവറുകൾ കോൺഫിഗർ ചെയ്യുക അല്ലെങ്കിൽ ഒരു നെറ്റ്‌വർക്ക് കോൺഫിഗർ ചെയ്യുക. ഓപ്പൺഷിഫ്റ്റ് 4 പ്ലാറ്റ്ഫോം ഉപയോഗിക്കുന്നതിനായി പൂർണ്ണമായും പുനർരൂപകൽപ്പന ചെയ്തിട്ടുണ്ട് ഓപ്പറേറ്റർ ഫ്രെയിംവർക്ക് അന്തിമ ഉപയോക്തൃ ആപ്ലിക്കേഷനുകളുടെ കാര്യത്തിൽ മാത്രമല്ല, ഇമേജുകൾ വിന്യസിക്കുക, സിസ്റ്റം കോൺഫിഗർ ചെയ്യുക, അല്ലെങ്കിൽ അപ്ഡേറ്റുകൾ ഇൻസ്റ്റാൾ ചെയ്യുക തുടങ്ങിയ അടിസ്ഥാന പ്ലാറ്റ്ഫോം-ലെവൽ പ്രവർത്തനങ്ങളുടെ കാര്യത്തിലും.

ആവശ്യമുള്ള അവസ്ഥ നിർവചിച്ചും ഉപയോഗിച്ചും ആപ്ലിക്കേഷനുകൾ നിയന്ത്രിക്കാൻ Kubernetes എല്ലായ്‌പ്പോഴും ഉപയോക്താക്കളെ അനുവദിച്ചിട്ടുണ്ട് കൺട്രോളറുകൾ, യഥാർത്ഥ അവസ്ഥ ടാർഗെറ്റ് അവസ്ഥയുമായി കഴിയുന്നത്ര അടുത്ത് പൊരുത്തപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കാൻ. ഈ ടാർഗെറ്റ് സ്റ്റേറ്റ്, യഥാർത്ഥ സ്റ്റേറ്റ് സമീപനം വികസനത്തിന്റെയും പ്രവർത്തനത്തിന്റെയും വീക്ഷണകോണിൽ നിന്ന് മികച്ച അവസരങ്ങൾ തുറക്കുന്നു. ഡെവലപ്പർമാർക്ക് ആവശ്യമായ അവസ്ഥ നിർവ്വചിക്കാൻ കഴിയും കൈമാറുക ഒരു YAML അല്ലെങ്കിൽ JSON ഫയലിന്റെ രൂപത്തിൽ ഓപ്പറേറ്റർക്ക്, തുടർന്ന് പ്രൊഡക്ഷൻ എൻവയോൺമെന്റിൽ ഓപ്പറേറ്റർക്ക് ആവശ്യമായ ആപ്ലിക്കേഷൻ ഉദാഹരണം സൃഷ്ടിക്കാൻ കഴിയും, കൂടാതെ ഈ സംഭവത്തിന്റെ പ്രവർത്തന നില പൂർണ്ണമായും നിർദ്ദിഷ്ട ഒന്നുമായി പൊരുത്തപ്പെടും.

പ്ലാറ്റ്‌ഫോമിൽ ഓപ്പറേറ്റർമാരെ ഉപയോഗിക്കുന്നതിലൂടെ, ഓപ്പൺഷിഫ്റ്റ് 4 ഈ പുതിയ മാതൃക (സെറ്റ്, യഥാർത്ഥ അവസ്ഥ എന്ന ആശയം ഉപയോഗിച്ച്) RHEL CoreOS, CRI-O എന്നിവയുടെ മാനേജ്മെന്റിലേക്ക് കൊണ്ടുവരുന്നു. ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെയും കണ്ടെയ്നർ എഞ്ചിന്റെയും പതിപ്പുകൾ ക്രമീകരിക്കുന്നതിനും നിയന്ത്രിക്കുന്നതിനുമുള്ള ചുമതലകൾ എന്ന് വിളിക്കപ്പെടുന്നവ ഉപയോഗിച്ച് ഓട്ടോമേറ്റ് ചെയ്യുന്നു മെഷീൻ കോൺഫിഗറേഷൻ ഓപ്പറേറ്റർ (MCO). MCO ക്ലസ്റ്റർ അഡ്മിനിസ്ട്രേറ്ററുടെ പ്രവർത്തനത്തെ വളരെയധികം ലളിതമാക്കുന്നു, അടിസ്ഥാനപരമായി ഇൻസ്റ്റലേഷന്റെ അവസാന ഘട്ടങ്ങളും തുടർന്നുള്ള ഇൻസ്റ്റലേഷൻ പ്രവർത്തനങ്ങളും (രണ്ടാം ദിവസത്തെ പ്രവർത്തനങ്ങൾ) ഓട്ടോമേറ്റ് ചെയ്യുന്നു. ഇതെല്ലാം OpenShift 4-നെ ഒരു യഥാർത്ഥ ക്ലൗഡ് പ്ലാറ്റ്‌ഫോം ആക്കുന്നു. കുറച്ച് കഴിഞ്ഞ് ഞങ്ങൾ ഇതിലേക്ക് കടക്കും.

പ്രവർത്തിക്കുന്ന കണ്ടെയ്നറുകൾ

ടെക് പ്രിവ്യൂ സ്റ്റാറ്റസിലെ പതിപ്പ് 3.7 മുതൽ ഓപ്പൺഷിഫ്റ്റ് പ്ലാറ്റ്‌ഫോമിൽ CRI-O എഞ്ചിൻ ഉപയോഗിക്കാനുള്ള അവസരം ഉപയോക്താക്കൾക്ക് ലഭിച്ചു, പൊതുവായി ലഭ്യമായ സ്റ്റാറ്റസ് (നിലവിൽ പിന്തുണയ്ക്കുന്നു) പതിപ്പ് 3.9 മുതൽ. കൂടാതെ, Red Hat വൻതോതിൽ ഉപയോഗിക്കുന്നു പ്രൊഡക്ഷൻ വർക്ക്ലോഡുകൾ പ്രവർത്തിപ്പിക്കുന്നതിന് CRI-O പതിപ്പ് 3.10 മുതൽ OpenShift ഓൺലൈനിൽ. ഇതെല്ലാം CRI-O-യിൽ പ്രവർത്തിക്കുന്ന ടീമിനെ വലിയ കുബർനെറ്റസ് ക്ലസ്റ്ററുകളിൽ വൻതോതിൽ വിക്ഷേപിക്കുന്ന കണ്ടെയ്‌നറുകളിൽ വിപുലമായ അനുഭവം നേടാൻ അനുവദിച്ചു. കുബെർനെറ്റസ് എങ്ങനെ CRI-O ഉപയോഗിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള അടിസ്ഥാന ധാരണ ലഭിക്കുന്നതിന്, വാസ്തുവിദ്യ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കാണിക്കുന്ന ഇനിപ്പറയുന്ന ചിത്രീകരണം നോക്കാം.

അരി. 2. ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിൽ കണ്ടെയ്‌നറുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു

പുതിയ നോഡുകൾ ആരംഭിക്കുമ്പോഴും ഓപ്പൺഷിഫ്റ്റ് പ്ലാറ്റ്‌ഫോമിന്റെ പുതിയ പതിപ്പുകൾ പുറത്തിറക്കുമ്പോഴും ടോപ്പ് ലെവൽ മുഴുവനായും സമന്വയിപ്പിച്ച് പുതിയ കണ്ടെയ്‌നർ ഹോസ്റ്റുകൾ സൃഷ്ടിക്കുന്നത് CRI-O ലളിതമാക്കുന്നു. മുഴുവൻ പ്ലാറ്റ്‌ഫോമിന്റെയും പുനരവലോകനം ഇടപാട് അപ്‌ഡേറ്റുകൾ/റോൾബാക്കുകൾ അനുവദിക്കുന്നു, കൂടാതെ കണ്ടെയ്‌നർ ടെയിൽ കോർ, കണ്ടെയ്‌നർ എഞ്ചിൻ, നോഡുകൾ (കുബെലെറ്റ്‌സ്), കുബെർനെറ്റസ് മാസ്റ്റർ നോഡ് എന്നിവയ്‌ക്കിടയിലുള്ള ഡിപൻഡൻസികളിലെ ഡെഡ്‌ലോക്ക് തടയുകയും ചെയ്യുന്നു. നിയന്ത്രണവും പതിപ്പും ഉപയോഗിച്ച് എല്ലാ പ്ലാറ്റ്‌ഫോം ഘടകങ്ങളും കേന്ദ്രീകൃതമായി കൈകാര്യം ചെയ്യുന്നതിലൂടെ, എയിൽ നിന്ന് സംസ്ഥാന ബിയിലേക്ക് എല്ലായ്പ്പോഴും വ്യക്തമായ പാതയുണ്ട്. ഇത് അപ്‌ഡേറ്റ് പ്രക്രിയ ലളിതമാക്കുന്നു, സുരക്ഷ മെച്ചപ്പെടുത്തുന്നു, പ്രകടന റിപ്പോർട്ടിംഗ് മെച്ചപ്പെടുത്തുന്നു, കൂടാതെ പുതിയ പതിപ്പുകളുടെ അപ്‌ഡേറ്റുകളുടെയും ഇൻസ്റ്റാളേഷനുകളുടെയും ചെലവ് കുറയ്ക്കാൻ സഹായിക്കുന്നു. .

മാറ്റിസ്ഥാപിക്കുന്ന മൂലകങ്ങളുടെ ശക്തി പ്രകടമാക്കുന്നു

നേരത്തെ സൂചിപ്പിച്ചതുപോലെ, OpenShift 4-ൽ കണ്ടെയ്‌നർ ഹോസ്റ്റും കണ്ടെയ്‌നർ എഞ്ചിനും നിയന്ത്രിക്കാൻ മെഷീൻ കോൺഫിഗ് ഓപ്പറേറ്റർ ഉപയോഗിക്കുന്നത് കുബർനെറ്റസ് പ്ലാറ്റ്‌ഫോമിൽ മുമ്പ് സാധ്യമല്ലാത്ത ഒരു പുതിയ തലത്തിലുള്ള ഓട്ടോമേഷൻ നൽകുന്നു. പുതിയ ഫീച്ചറുകൾ പ്രദർശിപ്പിക്കുന്നതിന്, crio.conf ഫയലിൽ നിങ്ങൾക്ക് എങ്ങനെ മാറ്റങ്ങൾ വരുത്താമെന്ന് ഞങ്ങൾ കാണിക്കും. ടെർമിനോളജിയിൽ ആശയക്കുഴപ്പത്തിലാകാതിരിക്കാൻ, ഫലങ്ങളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ ശ്രമിക്കുക.

ആദ്യം, നമുക്ക് കണ്ടെയ്നർ റൺടൈം കോൺഫിഗറേഷൻ എന്ന് വിളിക്കുന്നത് സൃഷ്ടിക്കാം - കണ്ടെയ്നർ റൺടൈം കോൺഫിഗറേഷൻ. CRI-O-നുള്ള കോൺഫിഗറേഷനെ പ്രതിനിധീകരിക്കുന്ന ഒരു കുബർനെറ്റസ് റിസോഴ്സായി ഇതിനെ കരുതുക. വാസ്തവത്തിൽ, ഇത് MachineConfig എന്ന് വിളിക്കപ്പെടുന്ന ഒരു പ്രത്യേക പതിപ്പാണ്, ഇത് ഒരു ഓപ്പൺഷിഫ്റ്റ് ക്ലസ്റ്ററിന്റെ ഭാഗമായി ഒരു RHEL CoreOS മെഷീനിലേക്ക് വിന്യസിച്ചിരിക്കുന്ന ഏതെങ്കിലും കോൺഫിഗറേഷനാണ്.

CRI-O കോൺഫിഗർ ചെയ്യുന്നത് ക്ലസ്റ്റർ അഡ്മിനിസ്ട്രേറ്റർമാർക്ക് എളുപ്പമാക്കുന്നതിനാണ് ContainerRuntimeConfig എന്ന് വിളിക്കപ്പെടുന്ന ഈ ഇഷ്‌ടാനുസൃത ഉറവിടം സൃഷ്ടിച്ചത്. ഈ ഉപകരണം 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

ഇനി നമുക്ക് ഈ ഫയൽ കുബർനെറ്റസ് ക്ലസ്റ്ററിലേക്ക് തള്ളുകയും അത് യഥാർത്ഥത്തിൽ സൃഷ്ടിച്ചതാണോ എന്ന് പരിശോധിക്കുകയും ചെയ്യാം. മറ്റേതൊരു കുബെർനെറ്റസ് റിസോഴ്‌സിനും സമാനമായ പ്രവർത്തനമാണ് ഈ പ്രവർത്തനം എന്നത് ശ്രദ്ധിക്കുക:

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 റിസോഴ്‌സിൽ ഞങ്ങൾ വ്യക്തമാക്കിയ പിഡ്, ഡീബഗ് നിർദ്ദേശങ്ങൾക്കായുള്ള പുതിയ മൂല്യങ്ങൾ ഉപയോഗിച്ച് ഫയൽ അപ്‌ഡേറ്റ് ചെയ്‌തതായി നിങ്ങൾ കാണും. ചാരുത തന്നെ:

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 പോലും പ്രവർത്തിപ്പിക്കാതെയാണ് ക്ലസ്റ്ററിലെ ഈ മാറ്റങ്ങളെല്ലാം വരുത്തിയത്. കുബെറെന്റസ് മാസ്റ്റർ നോഡിലേക്ക് പ്രവേശിച്ച് എല്ലാ ജോലികളും ചെയ്തു. അതായത്, ഈ പുതിയ പാരാമീറ്ററുകൾ മാസ്റ്റർ നോഡുകളിൽ മാത്രമാണ് ക്രമീകരിച്ചിരിക്കുന്നത്. വർക്കർ നോഡുകൾ മാറിയില്ല, ഇത് പരസ്പരം മാറ്റാവുന്ന ഘടകങ്ങളുള്ള കണ്ടെയ്‌നർ ഹോസ്റ്റുകളുമായും കണ്ടെയ്‌നർ എഞ്ചിനുകളുമായും ബന്ധപ്പെട്ട് നിർദ്ദിഷ്ടവും യഥാർത്ഥവുമായ അവസ്ഥകൾ ഉപയോഗിക്കുന്നതിനുള്ള കുബർനെറ്റസ് മെത്തഡോളജിയുടെ പ്രയോജനങ്ങൾ പ്രകടമാക്കുന്നു.

മൂന്ന് പ്രൊഡക്ഷൻ നോഡുകളുള്ള ഒരു ചെറിയ ഓപ്പൺഷിഫ്റ്റ് കണ്ടെയ്നർ പ്ലാറ്റ്ഫോം 4 ക്ലസ്റ്ററിലോ 3000 നോഡുകളുള്ള ഒരു വലിയ പ്രൊഡക്ഷൻ ക്ലസ്റ്ററിലോ മാറ്റങ്ങൾ വരുത്താനുള്ള കഴിവ് മുകളിലെ ഉദാഹരണം കാണിക്കുന്നു. ഏത് സാഹചര്യത്തിലും, ജോലിയുടെ അളവ് സമാനമായിരിക്കും - വളരെ ചെറുതായിരിക്കും - ContainerRuntimeConfig ഫയൽ കോൺഫിഗർ ചെയ്യുക, കൂടാതെ MachineConfigPool-ൽ ഒരു ലേബൽ മാറ്റുക. ഓപ്പൺഷിഫ്റ്റ് കണ്ടെയ്‌നർ പ്ലാറ്റ്‌ഫോം 4.X-ന്റെ ജീവിതചക്രത്തിലുടനീളം പ്രവർത്തിക്കുന്ന Kubernetes-ന്റെ ഏത് പതിപ്പിലും നിങ്ങൾക്ക് ഇത് ചെയ്യാൻ കഴിയും.

പലപ്പോഴും സാങ്കേതിക കമ്പനികൾ വളരെ വേഗത്തിൽ വികസിച്ചുവരുന്നു, എന്തുകൊണ്ടാണ് ഞങ്ങൾ അടിസ്ഥാന ഘടകങ്ങൾക്കായി ചില സാങ്കേതികവിദ്യകൾ തിരഞ്ഞെടുക്കുന്നതെന്ന് വിശദീകരിക്കാൻ കഴിയില്ല. കണ്ടെയ്നർ എഞ്ചിനുകൾ ചരിത്രപരമായി ഉപയോക്താക്കൾക്ക് നേരിട്ട് ഇടപഴകുന്ന ഘടകമാണ്. കണ്ടെയ്‌നറുകളുടെ ജനപ്രീതി സ്വാഭാവികമായും കണ്ടെയ്‌നർ എഞ്ചിനുകളുടെ വരവോടെ ആരംഭിച്ചതിനാൽ, ഉപയോക്താക്കൾ പലപ്പോഴും അവയിൽ താൽപ്പര്യം കാണിക്കുന്നു. Red Hat CRI-O തിരഞ്ഞെടുക്കാനുള്ള മറ്റൊരു കാരണം ഇതാണ്. ഇപ്പോൾ ഓർക്കസ്‌ട്രേഷനിൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ച് കണ്ടെയ്‌നറുകൾ വികസിച്ചുകൊണ്ടിരിക്കുന്നു, ഓപ്പൺഷിഫ്റ്റ് 4-ൽ പ്രവർത്തിക്കുമ്പോൾ CRI-O മികച്ച അനുഭവം നൽകുന്നുവെന്ന് ഞങ്ങൾ കണ്ടെത്തി.

അവലംബം: www.habr.com