កុងតឺន័រ​ទៅ​កុងតឺន័រ៖ CRI-O ឥឡូវ​ជា​លំនាំដើម​ក្នុង OpenShift Container Platform 4

វេទិកា វេទិការកុងតឺន័រក្រហមហាដសស្តូត ៣ អនុញ្ញាតឱ្យអ្នកសម្រួលការបង្កើត ម៉ាស៊ីនសម្រាប់ដាក់ពង្រាយកុងតឺន័ររួមទាំងនៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកផ្តល់សេវាពពក នៅលើវេទិកានិម្មិត ឬនៅក្នុងប្រព័ន្ធដែកទទេ។ ដើម្បីបង្កើតវេទិកាដែលមានមូលដ្ឋានលើពពកពិតប្រាកដ យើងត្រូវគ្រប់គ្រងយ៉ាងតឹងរឹងនូវធាតុទាំងអស់ដែលបានប្រើ ហើយដូច្នេះបង្កើនភាពជឿជាក់នៃដំណើរការស្វ័យប្រវត្តិកម្មដ៏ស្មុគស្មាញមួយ។

ដំណោះស្រាយជាក់ស្តែងគឺត្រូវប្រើ Red Hat Enterprise Linux CoreOS (បំរែបំរួលនៃ Red Hat Enterprise Linux) និង CRI-O ជាស្តង់ដារ ហើយនេះជាមូលហេតុ...

ដោយសារប្រធានបទនៃការជិះទូកក្តោងគឺជារឿងដ៏ល្អមួយសម្រាប់ការស្វែងរកភាពស្រដៀងគ្នានៅពេលពន្យល់ពីការងាររបស់ Kubernetes និងកុងតឺន័រ នោះ ចូរយើងព្យាយាមនិយាយអំពីបញ្ហាអាជីវកម្មដែល CoreOS និង CRI-O ដោះស្រាយ ដោយប្រើឧទាហរណ៍មួយ។ ការច្នៃប្រឌិតរបស់ Brunel សម្រាប់ការផលិតប្លុក rigging. នៅឆ្នាំ 1803 លោក Marc Brunel ត្រូវបានប្រគល់ភារកិច្ចឱ្យផលិតប្លុក 100 សម្រាប់តម្រូវការរបស់កងទ័ពជើងទឹកអង់គ្លេសដែលកំពុងកើនឡើង។ ប្លុក rigging គឺជាប្រភេទនៃ rigging ដែលត្រូវបានប្រើដើម្បីភ្ជាប់ខ្សែទៅនឹងក្ដោង។ រហូតមកដល់ដើមសតវត្សទី 19 ប្លុកទាំងនេះត្រូវបានផលិតដោយដៃ ប៉ុន្តែ Brunel បានគ្រប់គ្រងការផលិតដោយស្វ័យប្រវត្តិ ហើយចាប់ផ្តើមផលិតប្លុកស្តង់ដារដោយប្រើឧបករណ៍ម៉ាស៊ីន។ ស្វ័យប្រវត្តិកម្មនៃដំណើរការនេះមានន័យថាប្លុកលទ្ធផលគឺដូចគ្នាបេះបិទ អាចត្រូវបានជំនួសយ៉ាងងាយស្រួលប្រសិនបើខូច ហើយអាចផលិតបានក្នុងបរិមាណច្រើន។

ឥឡូវស្រមៃមើលថាតើ Brunel ត្រូវធ្វើការងារនេះសម្រាប់គំរូកប៉ាល់ចំនួន 20 ផ្សេងគ្នា (កំណែ Kubernetes) និងសម្រាប់ភពប្រាំផ្សេងគ្នាដែលមានចរន្តសមុទ្រ និងខ្យល់ខុសគ្នាទាំងស្រុង (អ្នកផ្តល់ពពក)។ លើសពីនេះទៀតវាត្រូវបានតម្រូវឱ្យនាវាទាំងអស់ (ចង្កោម OpenShift) ដោយមិនគិតពីភពដែលការរុករកត្រូវបានអនុវត្តតាមទស្សនៈរបស់ប្រធានក្រុម (ប្រតិបត្តិករដែលគ្រប់គ្រងប្រតិបត្តិការនៃចង្កោម) មានឥរិយាបទដូចគ្នា។ ដើម្បីបន្តភាពស្រដៀងគ្នានៃដែនសមុទ្រ មេក្រុមកប៉ាល់មិនខ្វល់អ្វីទាំងអស់អំពីប្រភេទប្លុករ៉ឺម៉ក (CRI-O) ដែលត្រូវបានប្រើនៅលើកប៉ាល់របស់ពួកគេ - រឿងសំខាន់សម្រាប់ពួកគេគឺថាប្លុកទាំងនេះរឹងមាំនិងអាចទុកចិត្តបាន។

OpenShift 4 ជាវេទិកាពពក ប្រឈមមុខនឹងបញ្ហាអាជីវកម្មស្រដៀងគ្នា។ ថ្នាំងថ្មីត្រូវតែត្រូវបានបង្កើតនៅពេលបង្កើតចង្កោម ក្នុងករណីមានការបរាជ័យនៅក្នុងថ្នាំងណាមួយ ឬនៅពេលធ្វើមាត្រដ្ឋានចង្កោម។ នៅពេលដែលថ្នាំងថ្មីត្រូវបានបង្កើត និងចាប់ផ្តើម សមាសធាតុម៉ាស៊ីនសំខាន់ៗ រួមទាំង CRI-O ត្រូវតែកំណត់រចនាសម្ព័ន្ធស្របតាម។ ដូចនៅក្នុងផលិតកម្មផ្សេងទៀត "វត្ថុធាតុដើម" ត្រូវតែផ្គត់ផ្គង់នៅដើមដំបូង។ នៅក្នុងករណីនៃកប៉ាល់វត្ថុធាតុដើមគឺលោហៈនិងឈើ។ ទោះយ៉ាងណាក៏ដោយ ក្នុងករណីបង្កើតម៉ាស៊ីនសម្រាប់ដាក់ពង្រាយកុងតឺន័រនៅក្នុងចង្កោម OpenShift 4 អ្នកត្រូវមានឯកសារកំណត់រចនាសម្ព័ន្ធ និងម៉ាស៊ីនមេដែលផ្តល់ដោយ API ជាការបញ្ចូល។ បន្ទាប់មក OpenShift នឹងផ្តល់នូវកម្រិតស្វ័យប្រវត្តិកម្មដែលត្រូវការពេញមួយវដ្ដជីវិតទាំងមូល ដោយផ្តល់នូវការគាំទ្រផលិតផលចាំបាច់ដល់អ្នកប្រើប្រាស់ចុងក្រោយ ហើយដូច្នេះប្រមូលមកវិញនូវការវិនិយោគនៅក្នុងវេទិកានេះ។

OpenShift 4 ត្រូវ​បាន​បង្កើត​ឡើង​ក្នុង​របៀប​មួយ​ដើម្បី​ផ្តល់​លទ្ធភាព​ក្នុង​ការ​ធ្វើ​បច្ចុប្បន្នភាព​ប្រព័ន្ធ​យ៉ាង​ងាយស្រួល​ពេញ​មួយ​វដ្ត​ជីវិត​ទាំងមូល​នៃ​វេទិកា (សម្រាប់​កំណែ 4.X) សម្រាប់​អ្នក​ផ្តល់​សេវា​កុំព្យូទ័រ​ពពក​ធំៗ វេទិកា​និម្មិត និង​សូម្បី​តែ​ប្រព័ន្ធ​ដែក​ទទេ។ ដើម្បីធ្វើដូចនេះថ្នាំងត្រូវតែត្រូវបានបង្កើតនៅលើមូលដ្ឋាននៃធាតុដែលអាចផ្លាស់ប្តូរបាន។ នៅពេលដែលចង្កោមតម្រូវឱ្យមានកំណែថ្មីរបស់ Kubernetes វាក៏ទទួលបានកំណែដែលត្រូវគ្នានៃ CRI-O នៅលើ CoreOS ផងដែរ។ ដោយសារកំណែ CRI-O ត្រូវបានភ្ជាប់ដោយផ្ទាល់ជាមួយ Kubernetes នេះជួយសម្រួលយ៉ាងខ្លាំងនូវការអនុញ្ញាតសម្រាប់ការធ្វើតេស្ត ការដោះស្រាយបញ្ហា ឬគោលបំណងជំនួយ។ លើសពីនេះទៀត វិធីសាស្រ្តនេះកាត់បន្ថយការចំណាយសម្រាប់អ្នកប្រើប្រាស់ចុងក្រោយ និង Red Hat ។

នេះគឺជាវិធីថ្មីជាមូលដ្ឋាននៃការគិតអំពីក្រុម Kubernetes និងដាក់មូលដ្ឋានគ្រឹះសម្រាប់ការរៀបចំផែនការមុខងារថ្មីៗដែលមានប្រយោជន៍ និងគួរឱ្យទាក់ទាញ។ CRI-O (Container Runtime Interface - Open Container Initiative អក្សរកាត់ CRI-OCI) បានក្លាយជាជម្រើសជោគជ័យបំផុតសម្រាប់ការបង្កើតថ្នាំងដ៏ធំដែលចាំបាច់សម្រាប់ធ្វើការជាមួយ OpenShift ។ CRI-O នឹងជំនួសម៉ាស៊ីន Docker ដែលបានប្រើពីមុនដោយផ្តល់ជូនអ្នកប្រើប្រាស់ OpenShift សន្សំសំចៃ ស្ថិរភាព សាមញ្ញ និងគួរឱ្យធុញ - បាទ អ្នកបានលឺហើយ - ម៉ាស៊ីនកុងតឺន័រដ៏គួរឱ្យធុញដែលត្រូវបានបង្កើតឡើងជាពិសេសសម្រាប់ធ្វើការជាមួយ Kubernetes ។

ពិភពនៃធុងបើកចំហ

ពិភពលោកបាននិងកំពុងឆ្ពោះទៅរកកុងតឺន័របើកចំហអស់រយៈពេលជាយូរ។ មិនថានៅក្នុង Kubernetes ឬនៅកម្រិតទាបក៏ដោយ ការអភិវឌ្ឍស្តង់ដារកុងតឺន័រ លទ្ធផលនៅក្នុងប្រព័ន្ធអេកូនៃការច្នៃប្រឌិតនៅគ្រប់កម្រិត។

វាទាំងអស់បានចាប់ផ្តើមជាមួយនឹងការបង្កើត Open Containers Initiative នៅខែមិថុនាឆ្នាំ 2015. នៅដំណាក់កាលដំបូងនៃការងារនេះ ការកំណត់កុងតឺន័រត្រូវបានបង្កើតឡើង រូបភាព и បរិស្ថានពេលដំណើរការ. នេះធានាថាឧបករណ៍អាចប្រើស្តង់ដារតែមួយ រូបភាពធុង និងទម្រង់បង្រួបបង្រួមសម្រាប់ធ្វើការជាមួយពួកគេ។ ការបញ្ជាក់ត្រូវបានបន្ថែមនៅពេលក្រោយ ការចែកចាយអនុញ្ញាតឱ្យអ្នកប្រើប្រាស់ងាយស្រួលចែករំលែក រូបភាពធុង.

បន្ទាប់មកសហគមន៍ Kubernetes បានបង្កើតស្តង់ដារតែមួយសម្រាប់ចំណុចប្រទាក់ដែលអាចដោតបាន ហៅថា ចំណុចប្រទាក់ពេលដំណើរការកុងតឺន័រ (CRI). សូមអរគុណចំពោះបញ្ហានេះ អ្នកប្រើប្រាស់ Kubernetes អាចភ្ជាប់ម៉ាស៊ីនផ្សេងៗដើម្បីធ្វើការជាមួយកុងតឺន័របន្ថែមលើ Docker ។

វិស្វករនៅ Red Hat និង Google បានឃើញតម្រូវការទីផ្សារសម្រាប់ម៉ាស៊ីនកុងតឺន័រដែលអាចទទួលយកសំណើ Kubelet លើពិធីការ CRI និងបានណែនាំធុងដែលត្រូវគ្នានឹងលក្ខណៈបច្ចេកទេស OCI ដែលបានរៀបរាប់ខាងលើ។ ដូច្នេះ OCID បានបង្ហាញខ្លួន. ប៉ុន្តែសូមអភ័យទោស តើយើងមិនបាននិយាយថាសម្ភារៈនេះនឹងត្រូវបានឧទ្ទិសដល់ CRI-O ទេ? តាមពិតវាគឺគ្រាន់តែជាមួយនឹងការចេញផ្សាយ កំណែ 1.0 គម្រោងនេះត្រូវបានប្តូរឈ្មោះទៅជា CRI-O ។

រូប។ 1 ។

ការច្នៃប្រឌិតជាមួយ CRI-O និង CoreOS

ជាមួយនឹងការចាប់ផ្តើមនៃវេទិកា OpenShift 4 វាត្រូវបានផ្លាស់ប្តូរ ម៉ាស៊ីនកុងតឺន័រប្រើតាមលំនាំដើមនៅក្នុងវេទិកា ហើយ Docker ត្រូវបានជំនួសដោយ CRI-O ដែលផ្តល់នូវបរិយាកាសសន្សំសំចៃ ស្ថិរភាព សាមញ្ញ និងគួរឱ្យធុញសម្រាប់ការដំណើរការកុងតឺន័រដែលអភិវឌ្ឍស្របជាមួយ Kubernetes ។ នេះជួយសម្រួលដល់ការគាំទ្រចង្កោម និងការកំណត់រចនាសម្ព័ន្ធយ៉ាងច្រើន។ ការកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនកុងតឺន័រ និងម៉ាស៊ីន ក៏ដូចជាការគ្រប់គ្រងរបស់ពួកគេ ក្លាយជាស្វ័យប្រវត្តិនៅក្នុង OpenShift 4 ។

ចាំមើល តើនេះយ៉ាងម៉េច?

ត្រឹមត្រូវហើយ ជាមួយនឹងការមកដល់នៃ OpenShift 4 មិនចាំបាច់ភ្ជាប់ទៅម៉ាស៊ីននីមួយៗ និងដំឡើងម៉ាស៊ីនកុងតឺន័រ កំណត់រចនាសម្ព័ន្ធការផ្ទុក កំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេស្វែងរក ឬកំណត់រចនាសម្ព័ន្ធបណ្តាញទៀតទេ។ វេទិកា OpenShift 4 ត្រូវបានរៀបចំឡើងវិញទាំងស្រុងដើម្បីប្រើ ក្របខ័ណ្ឌប្រតិបត្តិករ មិនត្រឹមតែនៅក្នុងលក្ខខណ្ឌនៃកម្មវិធីអ្នកប្រើប្រាស់ចុងក្រោយប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងនៅក្នុងលក្ខខណ្ឌនៃប្រតិបត្តិការកម្រិតមូលដ្ឋានដូចជា ការដាក់ពង្រាយរូបភាព កំណត់រចនាសម្ព័ន្ធប្រព័ន្ធ ឬការដំឡើងបច្ចុប្បន្នភាព។

Kubernetes តែងតែអនុញ្ញាតឱ្យអ្នកប្រើប្រាស់គ្រប់គ្រងកម្មវិធីដោយកំណត់ស្ថានភាពដែលចង់បាន និងប្រើប្រាស់ ឧបករណ៍បញ្ជាដើម្បីធានាថារដ្ឋពិតប្រាកដត្រូវគ្នានឹងរដ្ឋគោលដៅឱ្យបានជិតបំផុតតាមដែលអាចធ្វើទៅបាន។ នេះ។ រដ្ឋគោលដៅ និងវិធីសាស្រ្តរដ្ឋជាក់ស្តែង បើកឱកាសដ៏អស្ចារ្យទាំងពីទិដ្ឋភាពនៃការអភិវឌ្ឍន៍ និងប្រតិបត្តិការ។ អ្នកអភិវឌ្ឍន៍អាចកំណត់ស្ថានភាពដែលត្រូវការដោយ ឆ្លងកាត់វា។ ទៅកាន់ប្រតិបត្តិករក្នុងទម្រង់ជាឯកសារ YAML ឬ JSON ហើយបន្ទាប់មកប្រតិបត្តិករអាចបង្កើតឧទាហរណ៍កម្មវិធីដែលត្រូវការនៅក្នុងបរិយាកាសផលិតកម្ម ហើយស្ថានភាពប្រតិបត្តិការនៃវត្ថុនេះនឹងឆ្លើយតបយ៉ាងពេញលេញទៅនឹងអ្វីដែលបានបញ្ជាក់។

ដោយប្រើប្រតិបត្តិករនៅក្នុងវេទិកា OpenShift 4 នាំមកនូវគំរូថ្មីនេះ (ដោយប្រើគំនិតនៃការកំណត់ និងស្ថានភាពជាក់ស្តែង) ដល់ការគ្រប់គ្រងរបស់ RHEL CoreOS និង CRI-O ។ ភារកិច្ចនៃការកំណត់រចនាសម្ព័ន្ធ និងគ្រប់គ្រងកំណែនៃប្រព័ន្ធប្រតិបត្តិការ និងម៉ាស៊ីនកុងតឺន័រគឺស្វ័យប្រវត្តិដោយប្រើអ្វីដែលគេហៅថា ប្រតិបត្តិករកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីន (MCO). MCO ជួយសម្រួលដល់ការងាររបស់អ្នកគ្រប់គ្រងចង្កោម យ៉ាងសំខាន់ ស្វ័យប្រវត្តិកម្មដំណាក់កាលចុងក្រោយនៃការដំឡើង ក៏ដូចជាប្រតិបត្តិការក្រោយការដំឡើងជាបន្តបន្ទាប់ (ប្រតិបត្តិការថ្ងៃទីពីរ)។ ទាំងអស់នេះធ្វើឱ្យ OpenShift 4 ក្លាយជាវេទិកាពពកពិត។ យើងនឹងចូលទៅក្នុងរឿងនេះបន្តិចក្រោយមក។

កំពុងដំណើរការធុង

អ្នកប្រើប្រាស់មានឱកាសប្រើប្រាស់ម៉ាស៊ីន CRI-O នៅក្នុងវេទិកា OpenShift ចាប់តាំងពីកំណែ 3.7 នៅក្នុងស្ថានភាព Tech Preview និងពីកំណែ 3.9 នៅក្នុងស្ថានភាពដែលអាចប្រើបានជាទូទៅ (បច្ចុប្បន្នត្រូវបានគាំទ្រ)។ លើសពីនេះទៀត Red Hat ប្រើប្រាស់យ៉ាងច្រើន CRI-O សម្រាប់ដំណើរការបន្ទុកផលិតកម្ម នៅក្នុង OpenShift Online ចាប់តាំងពីកំណែ 3.10 ។ ទាំងអស់នេះបានអនុញ្ញាតឱ្យក្រុមការងារដែលធ្វើការលើ CRI-O ទទួលបានបទពិសោធន៍យ៉ាងទូលំទូលាយក្នុងការបើកដំណើរការធុងធំនៅលើចង្កោម Kubernetes ដ៏ធំ។ ដើម្បីទទួលបានការយល់ដឹងជាមូលដ្ឋានអំពីរបៀបដែល Kubernetes ប្រើ CRI-O សូមមើលរូបភាពខាងក្រោម ដែលបង្ហាញពីរបៀបដែលស្ថាបត្យកម្មដំណើរការ។

អង្ករ។ 2. របៀបកុងតឺន័រដំណើរការនៅក្នុងចង្កោម Kubernetes

CRI-O សម្រួលដល់ការបង្កើតម៉ាស៊ីនកុងតឺន័រថ្មីដោយធ្វើសមកាលកម្មកម្រិតកំពូលទាំងមូលនៅពេលចាប់ផ្តើមថ្នាំងថ្មី និងនៅពេលចេញផ្សាយកំណែថ្មីនៃវេទិកា OpenShift ។ ការពិនិត្យឡើងវិញនៃវេទិកាទាំងមូលអនុញ្ញាតឱ្យមានការធ្វើបច្ចុប្បន្នភាព/ការវិលត្រឡប់មកវិញនៃប្រតិបត្តិការ ហើយក៏ការពារការជាប់គាំងនៅក្នុងភាពអាស្រ័យរវាងស្នូលកន្ទុយកុងតឺន័រ ម៉ាស៊ីនកុងតឺន័រ ថ្នាំង (Kubelets) និងថ្នាំង Kubernetes Master ។ តាមរយៈការគ្រប់គ្រងផ្នែកកណ្តាលនៃសមាសធាតុវេទិកាទាំងអស់ ជាមួយនឹងការគ្រប់គ្រង និងកំណែ វាតែងតែមានផ្លូវច្បាស់លាស់ពីរដ្ឋ A ដល់រដ្ឋ B។ វាជួយសម្រួលដល់ដំណើរការអាប់ដេត ធ្វើអោយប្រសើរឡើងនូវសុវត្ថិភាព ធ្វើអោយប្រសើរឡើងនូវរបាយការណ៍ប្រតិបត្តិការ និងជួយកាត់បន្ថយថ្លៃដើមនៃការអាប់ដេត និងការដំឡើងកំណែថ្មី .

បង្ហាញពីអំណាចនៃធាតុជំនួស

ដូចដែលបានរៀបរាប់ពីមុន ការប្រើប្រាស់ Machine Config Operator ដើម្បីគ្រប់គ្រងម៉ាស៊ីនកុងតឺន័រ និងម៉ាស៊ីនកុងតឺន័រនៅក្នុង OpenShift 4 ផ្តល់នូវកម្រិតស្វ័យប្រវត្តិកម្មថ្មីមួយដែលមិនអាចធ្វើទៅបានពីមុននៅលើវេទិកា Kubernetes ។ ដើម្បីបង្ហាញពីលក្ខណៈពិសេសថ្មី យើងនឹងបង្ហាញពីរបៀបដែលអ្នកអាចធ្វើការផ្លាស់ប្តូរឯកសារ crio.conf ។ ដើម្បីជៀសវាងការយល់ច្រឡំដោយវាក្យស័ព្ទ សូមព្យាយាមផ្តោតលើលទ្ធផល។

ជាដំបូង ចូរយើងបង្កើតអ្វីដែលគេហៅថា ការកំណត់រចនាសម្ព័ន្ធពេលដំណើរការកុងតឺន័រ - Container Runtime Config ។ គិតថាវាជាធនធាន Kubernetes ដែលតំណាងឱ្យការកំណត់រចនាសម្ព័ន្ធសម្រាប់ 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 ហើយ​ពិនិត្យ​មើល​ថា​វា​ពិត​ជា​ត្រូវ​បាន​បង្កើត​មែន​ឬ​ទេ។ សូមចំណាំថាប្រតិបត្តិការនេះគឺដូចគ្នាទៅនឹងធនធាន Kubernetes ផ្សេងទៀតដែរ៖

oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig

សេចក្តីសន្និដ្ឋាន:

NAME              AGE
set-log-and-pid   22h

នៅពេលដែលយើងបានបង្កើត ContainerRuntimeConfig យើងត្រូវកែប្រែ MachineConfigPools មួយដើម្បីផ្តល់សញ្ញាទៅ Kubernetes ថាយើងចង់អនុវត្តការកំណត់នេះទៅក្រុមជាក់លាក់នៃម៉ាស៊ីននៅក្នុងចង្កោម។ ក្នុងករណីនេះ យើងនឹងផ្លាស់ប្តូរ 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

សូមចំណាំថាឯកសារកំណត់រចនាសម្ព័ន្ធលទ្ធផលសម្រាប់ថ្នាំងមេគឺជាកំណែថ្មីជាងការកំណត់រចនាសម្ព័ន្ធដើម។ ដើម្បីមើលវា ដំណើរការពាក្យបញ្ជាខាងក្រោម។ នៅក្នុងការឆ្លងកាត់ យើងកត់សម្គាល់ថានេះប្រហែលជាខ្សែបន្ទាត់ដ៏ល្អបំផុតមួយនៅក្នុងប្រវត្តិសាស្រ្តរបស់ Kubernetes៖

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 និង​បំបាត់​កំហុស​ដែល​យើង​បាន​បញ្ជាក់​ក្នុង​ធនធាន 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 ទេ។ ការងារទាំងអស់ត្រូវបានធ្វើដោយការចូលប្រើថ្នាំងមេ Kuberentes ។ នោះគឺ ប៉ារ៉ាម៉ែត្រថ្មីទាំងនេះត្រូវបានកំណត់រចនាសម្ព័ន្ធតែលើថ្នាំងមេប៉ុណ្ណោះ។ ថ្នាំងកម្មករមិនផ្លាស់ប្តូរទេ ដែលបង្ហាញពីអត្ថប្រយោជន៍នៃវិធីសាស្រ្ត Kubernetes នៃការប្រើប្រាស់ស្ថានភាពដែលបានបញ្ជាក់ និងជាក់ស្តែងទាក់ទងនឹងម៉ាស៊ីនកុងតឺន័រ និងម៉ាស៊ីនកុងតឺន័រដែលមានធាតុដែលអាចផ្លាស់ប្តូរបាន។

ឧទាហរណ៍ខាងលើបង្ហាញពីសមត្ថភាពក្នុងការធ្វើការផ្លាស់ប្តូរចំពោះចង្កោម OpenShift Container Platform 4 តូចមួយដែលមានថ្នាំងផលិតកម្មចំនួនបី ឬចង្កោមផលិតកម្មដ៏ធំដែលមានថ្នាំង 3000 ។ ក្នុងករណីណាក៏ដោយ បរិមាណការងារនឹងដូចគ្នា - និងតូចណាស់ - គ្រាន់តែកំណត់រចនាសម្ព័ន្ធឯកសារ ContainerRuntimeConfig ហើយប្តូរស្លាកមួយនៅក្នុង MachineConfigPool ។ ហើយអ្នកអាចធ្វើដូចនេះជាមួយនឹងកំណែណាមួយនៃ OpenShift Container Platform 4.X ដែលដំណើរការ Kubernetes ពេញមួយវដ្តជីវិតរបស់វា។

ជាញឹកញយ ក្រុមហ៊ុនបច្ចេកវិទ្យាមានការវិវឌ្ឍយ៉ាងឆាប់រហ័ស ដែលយើងមិនអាចពន្យល់ពីមូលហេតុដែលយើងជ្រើសរើសបច្ចេកវិទ្យាជាក់លាក់សម្រាប់សមាសធាតុមូលដ្ឋាន។ ម៉ាស៊ីនកុងតឺន័រធ្លាប់ជាធាតុផ្សំដែលអ្នកប្រើប្រាស់ធ្វើអន្តរកម្មដោយផ្ទាល់។ ចាប់តាំងពីប្រជាប្រិយភាពនៃកុងតឺន័រចាប់ផ្តើមដោយធម្មជាតិជាមួយនឹងការមកដល់នៃម៉ាស៊ីនកុងតឺន័រ អ្នកប្រើប្រាស់តែងតែបង្ហាញចំណាប់អារម្មណ៍លើពួកគេ។ នេះជាហេតុផលមួយទៀតដែល Red Hat ជ្រើសរើស CRI-O។ កុងតឺន័រកំពុងវិវឌ្ឍដោយផ្តោតការយកចិត្តទុកដាក់លើការប្រគុំតន្រ្តី ហើយយើងបានរកឃើញថា CRI-O ផ្តល់នូវបទពិសោធន៍ដ៏ល្អបំផុតនៅពេលធ្វើការជាមួយ OpenShift 4 ។

ប្រភព: www.habr.com