🥇CPU limits និងការគម្រាមកំហែងយ៉ាងខ្លាំងក្លានៅក្នុង Kubernetes

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

តើអ្នកធ្លាប់មានកម្មវិធីជាប់គាំង ឈប់ឆ្លើយតបនឹងការពិនិត្យសុខភាព ហើយមិនអាចដឹងថាហេតុអ្វីបានជា? ការពន្យល់មួយដែលអាចធ្វើទៅបានគឺទាក់ទងទៅនឹងដែនកំណត់កូតាធនធាន CPU ។ នេះគឺជាអ្វីដែលយើងនឹងនិយាយអំពីនៅក្នុងអត្ថបទនេះ។

TL; កុង:
យើងសូមណែនាំយ៉ាងមុតមាំឱ្យបិទដែនកំណត់ CPU នៅក្នុង Kubernetes (ឬបិទកូតា CFS នៅក្នុង Kubelet) ប្រសិនបើអ្នកកំពុងប្រើកំណែខឺណែល។ Linux ជាមួយនឹងកំហុសកូតា CFS។ នៅក្នុងខឺណែល គឺអាចប្រើបាន ធ្ងន់ធ្ងរនិង ល្បី កំហុសដែលនាំទៅដល់ការបិទបើកហួសហេតុ និងការពន្យារពេល.

នៅ Omio ហេដ្ឋារចនាសម្ព័ន្ធទាំងមូលត្រូវបានគ្រប់គ្រងដោយ Kubernetes. បន្ទុកការងារគ្មានរដ្ឋ និងគ្មានរដ្ឋរបស់យើងទាំងអស់ដំណើរការទាំងស្រុងលើ Kubernetes (យើងប្រើ Google Kubernetes Engine)។ ក្នុងរយៈពេលប្រាំមួយខែចុងក្រោយនេះ យើងបានចាប់ផ្តើមសង្កេតឃើញការថយចុះដោយចៃដន្យ។ កម្មវិធីបង្កក ឬឈប់ឆ្លើយតបនឹងការពិនិត្យសុខភាព បាត់បង់ការតភ្ជាប់ទៅបណ្តាញ។ល។ អាកប្បកិរិយានេះបានធ្វើឱ្យយើងងឿងឆ្ងល់ជាយូរណាស់មកហើយ ហើយទីបំផុតយើងបានសម្រេចចិត្តយកបញ្ហានេះយ៉ាងធ្ងន់ធ្ងរ។

សេចក្តីសង្ខេបនៃអត្ថបទ៖

ពាក្យពីរបីអំពីធុង និង Kubernetes;
របៀបដែលសំណើ និងដែនកំណត់របស់ស៊ីភីយូត្រូវបានអនុវត្ត;
របៀបដែលដែនកំណត់ស៊ីភីយូដំណើរការនៅក្នុងបរិស្ថានពហុស្នូល;
របៀបតាមដានការបិទ CPU;
ដំណោះស្រាយបញ្ហានិង nuances ។

ពាក្យពីរបីអំពីកុងតឺន័រ និង Kubernetes

Kubernetes គឺជាស្តង់ដារទំនើបដ៏សំខាន់នៅក្នុងពិភពហេដ្ឋារចនាសម្ព័ន្ធ។ ភារកិច្ចចម្បងរបស់វាគឺការរៀបចំកុងតឺន័រ។

.онтейнеры

កាលពីមុន យើងត្រូវបង្កើតវត្ថុបុរាណដូចជា Java JARs/WARs Python Eggs ឬអាចប្រតិបត្តិបាន ដើម្បីដំណើរការលើម៉ាស៊ីនមេ។ ទោះយ៉ាងណាក៏ដោយ ដើម្បីធ្វើឱ្យពួកវាមានមុខងារ ការងារបន្ថែមត្រូវធ្វើ៖ ការដំឡើងបរិស្ថានពេលដំណើរការ (Java/Python) ដាក់ឯកសារចាំបាច់នៅកន្លែងដែលត្រឹមត្រូវ ធានាភាពឆបគ្នាជាមួយកំណែជាក់លាក់នៃប្រព័ន្ធប្រតិបត្តិការ។ល។ ម្យ៉ាងវិញទៀត ការយកចិត្តទុកដាក់ត្រូវយកចិត្តទុកដាក់ចំពោះការគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធ (ដែលជារឿយៗជាប្រភពនៃការឈ្លោះប្រកែកគ្នារវាងអ្នកអភិវឌ្ឍន៍ និងអ្នកគ្រប់គ្រងប្រព័ន្ធ)។

កុងតឺន័របានផ្លាស់ប្តូរអ្វីៗទាំងអស់។ ឥឡូវនេះវត្ថុបុរាណគឺជារូបភាពធុង។ វាអាចត្រូវបានតំណាងជាប្រភេទឯកសារដែលអាចប្រតិបត្តិបានបន្ថែមដែលមានមិនត្រឹមតែកម្មវិធីប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានបរិយាកាសប្រតិបត្តិពេញលេញផងដែរ (Java/Python/...) ក៏ដូចជាឯកសារ/កញ្ចប់ចាំបាច់ ដំឡើងជាមុន និងត្រៀមខ្លួនជាស្រេចដើម្បី រត់។ កុងតឺន័រអាចត្រូវបានដាក់ពង្រាយ និងដំណើរការលើម៉ាស៊ីនមេផ្សេងគ្នាដោយមិនចាំបាច់មានជំហានបន្ថែមទៀតទេ។

លើសពីនេះ កុងតឺន័រដំណើរការនៅក្នុងបរិស្ថាន sandbox ផ្ទាល់ខ្លួន។ ពួកវាមានអាដាប់ទ័របណ្តាញនិម្មិតផ្ទាល់ខ្លួន ប្រព័ន្ធឯកសារផ្ទាល់ខ្លួនដែលមានការចូលប្រើមានកម្រិត ឋានានុក្រមដំណើរការផ្ទាល់ខ្លួន ដែនកំណត់ CPU និងអង្គចងចាំផ្ទាល់ខ្លួន និងអ្វីៗផ្សេងទៀត។ ទាំងអស់នេះត្រូវបានអនុវត្តដោយសារប្រព័ន្ធរងខឺណែលពិសេសមួយ។ Linux - ចន្លោះឈ្មោះ។

Kubernetes

ដូចដែលបានបញ្ជាក់ពីមុន Kubernetes គឺជាអ្នករៀបចំកុងតឺន័រ។ វាដំណើរការដូចនេះ៖ អ្នកផ្តល់ឱ្យវានូវម៉ាស៊ីនមួយ ហើយបន្ទាប់មកនិយាយថា៖ "Hey, Kubernetes, តោះបើកដំណើរការដប់ដងនៃកុងតឺន័ររបស់ខ្ញុំជាមួយនឹងខួរក្បាល 2 និងអង្គចងចាំ 3 GB នីមួយៗ ហើយបន្តឱ្យពួកវាដំណើរការ!" Kubernetes នឹងថែរក្សាកន្លែងដែលនៅសល់។ វានឹងរកឃើញសមត្ថភាពឥតគិតថ្លៃ បើកដំណើរការកុងតឺន័រ និងចាប់ផ្ដើមពួកវាឡើងវិញប្រសិនបើចាំបាច់ បញ្ចេញការអាប់ដេតនៅពេលផ្លាស់ប្ដូរកំណែ។ល។ សំខាន់ Kubernetes អនុញ្ញាតឱ្យអ្នកដកសមាសធាតុផ្នែករឹង និងបង្កើតប្រព័ន្ធជាច្រើនដែលសមរម្យសម្រាប់ដាក់ពង្រាយ និងដំណើរការកម្មវិធី។

Kubernetes ពីទស្សនៈរបស់ឧបាសក

តើអ្វីទៅជាសំណើ និងដែនកំណត់នៅក្នុង Kubernetes

មិនអីទេ យើងបានគ្របដណ្តប់ធុង និង Kubernetes ។ យើងក៏ដឹងដែរថា ធុងច្រើនអាចស្ថិតនៅលើម៉ាស៊ីនតែមួយ។

ភាពស្រដៀងគ្នាអាចត្រូវបានគូរជាមួយផ្ទះល្វែងរួម។ ទីធ្លាធំទូលាយ (ម៉ាស៊ីន/គ្រឿង) ត្រូវបានយក និងជួលទៅឱ្យអ្នកជួលជាច្រើន (កុងតឺន័រ)។ Kubernetes ដើរតួជាអ្នកអចលនទ្រព្យ។ សំណួរកើតឡើងតើធ្វើដូចម្តេចដើម្បីកុំឱ្យអ្នកជួលផ្ទះមានជម្លោះជាមួយគ្នា? ចុះបើម្នាក់ក្នុងចំណោមពួកគេនិយាយថា សម្រេចចិត្តខ្ចីបន្ទប់ទឹកកន្លះថ្ងៃ?

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

របៀបដែលសំណើ និងដែនកំណត់ត្រូវបានអនុវត្តនៅក្នុង Kubernetes

Kubernetes ប្រើយន្តការបិទបើក (រំលងវដ្តនាឡិកា) ដែលបង្កើតឡើងនៅក្នុងខឺណែល ដើម្បីអនុវត្តដែនកំណត់ស៊ីភីយូ។ ប្រសិនបើកម្មវិធីលើសពីដែនកំណត់នោះ ការបិទបើកត្រូវបានបើក (ឧ. វាទទួលបានវដ្តស៊ីភីយូតិចជាងមុន)។ សំណើ និងដែនកំណត់សម្រាប់អង្គចងចាំត្រូវបានរៀបចំខុសៗគ្នា ដូច្នេះពួកគេងាយរកឃើញ។ ដើម្បីធ្វើដូចនេះគ្រាន់តែពិនិត្យមើលស្ថានភាពចាប់ផ្តើមឡើងវិញចុងក្រោយនៃផតៈថាតើវាជា "OOMKilled" ដែរឬទេ។ ការបិទដំណើរការស៊ីភីយូមិនសាមញ្ញប៉ុន្មានទេ ដោយសារ K8s ធ្វើឱ្យមានត្រឹមតែម៉ែត្រដោយការប្រើប្រាស់ប៉ុណ្ណោះ មិនមែនដោយក្រុម cgroups ទេ។

សំណើ CPU

របៀបដែលសំណើ CPU ត្រូវបានអនុវត្ត

សម្រាប់ភាពសាមញ្ញ សូមក្រឡេកមើលដំណើរការដោយប្រើម៉ាស៊ីនដែលមាន CPU 4-core ជាឧទាហរណ៍។

K8s ប្រើយន្តការក្រុមគ្រប់គ្រង (cgroups) ដើម្បីគ្រប់គ្រងការបែងចែកធនធាន (អង្គចងចាំ និងដំណើរការ)។ គំរូតាមឋានានុក្រមមានសម្រាប់វា៖ កុមារទទួលមរតកដែនកំណត់នៃក្រុមមេ។ ព័ត៌មានលម្អិតនៃការចែកចាយត្រូវបានរក្សាទុកក្នុងប្រព័ន្ធឯកសារនិម្មិត (/sys/fs/cgroup) នៅក្នុងករណីនៃខួរក្បាលនេះគឺ /sys/fs/cgroup/cpu,cpuacct/*.

K8s ប្រើឯកសារ cpu.share ដើម្បីបែងចែកធនធានដំណើរការ។ ក្នុងករណីរបស់យើង root cgroup ទទួលបាន 4096 ភាគហ៊ុននៃធនធាន CPU - 100% នៃថាមពលខួរក្បាលដែលមាន (1 core = 1024; នេះគឺជាតម្លៃថេរ) ។ ក្រុម root ចែកចាយធនធានតាមសមាមាត្រអាស្រ័យលើចំណែកនៃកូនចៅដែលបានចុះឈ្មោះ cpu.shareហើយពួកគេក៏ធ្វើដូចគ្នានឹងកូនចៅរបស់ពួកគេ ។ល។ នៅលើថ្នាំង Kubernetes ធម្មតា ក្រុម root cgroup មានកូនបីនាក់៖ system.slice, user.slice и kubepods. ក្រុមរងពីរដំបូងត្រូវបានប្រើដើម្បីចែកចាយធនធានរវាងការផ្ទុកប្រព័ន្ធសំខាន់ៗ និងកម្មវិធីអ្នកប្រើប្រាស់នៅខាងក្រៅ K8s ។ ចុងក្រោយ - kubepods — បង្កើតឡើងដោយ Kubernetes ដើម្បីចែកចាយធនធានរវាងផត។

ដ្យាក្រាមខាងលើបង្ហាញថាក្រុមរងទីមួយ និងទីពីរបានទទួលនីមួយៗ 1024 ភាគហ៊ុនជាមួយក្រុមរង kuberpod ត្រូវបានបែងចែក 4096 ភាគហ៊ុន តើវាអាចទៅរួចដោយរបៀបណា៖ បន្ទាប់មក ក្រុមឫសមានសិទ្ធិចូលប្រើតែប៉ុណ្ណោះ។ 4096 ភាគហ៊ុន ហើយផលបូកនៃភាគហ៊ុននៃកូនចៅរបស់នាងលើសពីចំនួននេះ (6144)? ចំណុចសំខាន់គឺថាតម្លៃមានអត្ថន័យឡូជីខល ដូច្នេះអ្នករៀបចំផែនការ Linux (CFS) ប្រើវាដើម្បីចែកចាយធនធាន CPU តាមសមាមាត្រ។ ក្នុងករណីរបស់យើង ក្រុមពីរដំបូងទទួលបាន 680 ភាគហ៊ុនពិត (16,6% នៃ 4096) ហើយ kubepod ទទួលបាននៅសល់ 2736 ភាគហ៊ុន ក្នុងករណីមានការផ្អាក ក្រុមពីរដំបូងនឹងមិនប្រើប្រាស់ធនធានដែលបានបែងចែកនោះទេ។

ជាសំណាងល្អ កម្មវិធីកំណត់ពេលមានយន្តការដើម្បីជៀសវាងការខ្ជះខ្ជាយធនធាន CPU ដែលមិនបានប្រើ។ វាផ្ទេរសមត្ថភាព "ទំនេរ" ទៅកាន់ក្រុមសកល ដែលវាត្រូវបានចែកចាយទៅក្រុមដែលត្រូវការថាមពលខួរក្បាលបន្ថែម (ការផ្ទេរកើតឡើងជាបាច់ដើម្បីជៀសវាងការបាត់បង់ជុំ)។ វិធីសាស្រ្តស្រដៀងគ្នានេះត្រូវបានអនុវត្តចំពោះកូនចៅទាំងអស់នៃកូនចៅ។

យន្តការនេះធានានូវការចែកចាយថាមពលដំណើរការដោយយុត្តិធម៌ និងធានាថាគ្មាននរណាម្នាក់ដំណើរការ "លួច" ធនធានពីអ្នកដទៃឡើយ។

ដែនកំណត់ស៊ីភីយូ

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

K8s ចូលរួម យន្តការកូតា CFS ដើម្បីអនុវត្តដែនកំណត់។ ការកំណត់របស់ពួកគេត្រូវបានបញ្ជាក់នៅក្នុងឯកសារ cfs_period_us и cfs_quota_us នៅក្នុងថត cgroup (ឯកសារក៏មានទីតាំងនៅទីនោះផងដែរ។ cpu.share).

មិនដូច cpu.share, កូតាគឺផ្អែកលើ រយៈពេលហើយមិនមែននៅលើថាមពលខួរក្បាលដែលមាននោះទេ។ cfs_period_us បញ្ជាក់រយៈពេលនៃរយៈពេល (សម័យ) - វាតែងតែ 100000 μs (100 ms) ។ មានជម្រើសដើម្បីផ្លាស់ប្តូរតម្លៃនេះនៅក្នុង K8s ប៉ុន្តែវាអាចប្រើបានតែនៅក្នុងអាល់ហ្វាសម្រាប់ពេលនេះ។ កម្មវិធីកំណត់ពេលប្រើសម័យដើម្បីចាប់ផ្តើមកូតាដែលបានប្រើឡើងវិញ។ ឯកសារទីពីរ cfs_quota_usបញ្ជាក់ពេលវេលាដែលមាន (កូតា) ក្នុងសម័យនីមួយៗ។ ចំណាំថាវាត្រូវបានបញ្ជាក់ផងដែរជាមីក្រូវិនាទី។ កូតាអាចលើសពីប្រវែងសម័យ; នៅក្នុងពាក្យផ្សេងទៀតវាអាចធំជាង 100 ms ។

សូមក្រឡេកមើលសេណារីយ៉ូពីរនៅលើម៉ាស៊ីន 16-core (ប្រភេទកុំព្យូទ័រទូទៅបំផុតដែលយើងមាននៅ Omio):

សេណារីយ៉ូ 1: 2 threads និងដែនកំណត់ 200 ms ។ គ្មានការបិទបើក

សេណារីយ៉ូ 2: 10 threads និងដែនកំណត់ 200 ms ។ ការបិទដំណើរការចាប់ផ្តើមបន្ទាប់ពី 20 ms ការចូលប្រើធនធានដំណើរការត្រូវបានបន្តបន្ទាប់ពី 80 ms ផ្សេងទៀត

ចូរនិយាយថាអ្នកកំណត់ដែនកំណត់ស៊ីភីយូទៅ 2 ខឺណែល; Kubernetes នឹងបកប្រែតម្លៃនេះទៅជា 200 ms ។ នេះមានន័យថាកុងតឺន័រអាចប្រើពេលវេលា CPU អតិបរមា 200ms ដោយមិនចាំបាច់បិទបើក។

ហើយនេះគឺជាកន្លែងដែលភាពសប្បាយរីករាយចាប់ផ្តើម។ ដូចដែលបានរៀបរាប់ខាងលើ កូតាដែលមានគឺ 200 ms ។ ប្រសិនបើអ្នកកំពុងធ្វើការស្របគ្នា។ ដប់ ខ្សែស្រឡាយនៅលើម៉ាស៊ីន 12-core (មើលរូបភាពសម្រាប់សេណារីយ៉ូទី 2) ខណៈពេលដែលផតផ្សេងទៀតទាំងអស់នៅទំនេរ កូតានឹងត្រូវអស់ក្នុងរយៈពេលត្រឹមតែ 20 ms (ចាប់តាំងពី 10 * 20 ms = 200 ms) ហើយខ្សែស្រឡាយទាំងអស់នៃផតនេះនឹងព្យួរ។ » (បិទបើក) សម្រាប់ 80 ms បន្ទាប់។ ដែលបានរៀបរាប់រួចហើយ កំហុសកម្មវិធីកំណត់ពេលដោយសារតែការបិទបើកច្រើនពេកកើតឡើង ហើយកុងតឺន័រមិនអាចសូម្បីតែបំពេញកូតាដែលមានស្រាប់។

តើធ្វើដូចម្តេចដើម្បីវាយតម្លៃ throttling នៅក្នុង pods?

គ្រាន់តែចូលទៅ pod ហើយប្រតិបត្តិ cat /sys/fs/cgroup/cpu/cpu.stat.

nr_periods - ចំនួនសរុបនៃរយៈពេលកំណត់ពេល;
nr_throttled - ចំនួននៃរយៈពេលបិទបើកក្នុងសមាសភាព nr_periods;
throttled_time - ពេលវេលាបិទបើកជា nanoseconds ។

តើមានអ្វីកើតឡើង?

ជាលទ្ធផល យើងទទួលបានការបិទបើកខ្ពស់ក្នុងគ្រប់កម្មវិធីទាំងអស់។ ពេលខ្លះគាត់ចូល មួយដងកន្លះ ខ្លាំងជាងការគណនា!

វានាំឱ្យមានកំហុសផ្សេងៗ - ការបរាជ័យក្នុងការត្រួតពិនិត្យការត្រៀមខ្លួន ការបង្កកកុងតឺន័រ ការដាច់ការតភ្ជាប់បណ្តាញ ការអស់ពេលក្នុងការហៅសេវាកម្ម។ នេះជាលទ្ធផលនៅទីបំផុតក្នុងការបង្កើនភាពយឺតយ៉ាវ និងអត្រាកំហុសកាន់តែខ្ពស់។

ការសម្រេចចិត្តនិងផលវិបាក

អ្វីគ្រប់យ៉ាងគឺសាមញ្ញនៅទីនេះ។ យើងបានបោះបង់ចោលដែនកំណត់ស៊ីភីយូ ហើយបានចាប់ផ្តើមធ្វើបច្ចុប្បន្នភាពខឺណែល OS នៅក្នុងចង្កោមទៅជាកំណែចុងក្រោយបំផុត ដែលកំហុសត្រូវបានជួសជុល។ ចំនួននៃកំហុស (HTTP 5xx) នៅក្នុងសេវាកម្មរបស់យើងភ្លាមៗបានធ្លាក់ចុះយ៉ាងខ្លាំង៖

កំហុស HTTP 5xx

កំហុស HTTP 5xx សម្រាប់សេវាកម្មសំខាន់មួយ។

ពេលវេលាឆ្លើយតប p95

ភាពយឺតយ៉ាវនៃសំណើសេវាកម្មសំខាន់, ភាគរយទី 95

ការចំណាយប្រតិបត្តិការ

ចំនួនម៉ោងឧទាហរណ៍ដែលបានចំណាយ

តើអ្វីទៅជាការចាប់?

ដូចដែលបានបញ្ជាក់នៅដើមអត្ថបទ៖

ភាពស្រដៀងគ្នាអាចត្រូវបានគូរជាមួយអាផាតមិនរួម... Kubernetes ដើរតួជាអ្នកអចលនទ្រព្យ។ ប៉ុន្តែតើធ្វើដូចម្តេចដើម្បីរក្សាអ្នកជួលពីជម្លោះជាមួយគ្នា? ចុះបើម្នាក់ក្នុងចំណោមពួកគេនិយាយថា សម្រេចចិត្តខ្ចីបន្ទប់ទឹកកន្លះថ្ងៃ?

នេះជាការចាប់។ ធុងដែលមិនចេះខ្វល់ខ្វាយមួយអាចស៊ីធនធាន CPU ដែលមាននៅលើម៉ាស៊ីន។ ប្រសិនបើអ្នកមានជង់កម្មវិធីឆ្លាតវៃ (ឧទាហរណ៍ JVM, Go, Node VM ត្រូវបានកំណត់រចនាសម្ព័ន្ធត្រឹមត្រូវ) នោះមិនមែនជាបញ្ហាទេ៖ អ្នកអាចធ្វើការក្នុងលក្ខខណ្ឌបែបនេះបានយូរ។ ប៉ុន្តែប្រសិនបើកម្មវិធីត្រូវបានធ្វើឱ្យប្រសើរខ្សោយ ឬមិនបានធ្វើឱ្យប្រសើរអ្វីទាំងអស់ (FROM java:latest) ស្ថានភាពអាចចេញពីការគ្រប់គ្រង។ នៅ Omio យើងមាន Dockerfiles មូលដ្ឋានដោយស្វ័យប្រវត្តិជាមួយនឹងការកំណត់លំនាំដើមគ្រប់គ្រាន់សម្រាប់ជង់ភាសាសំខាន់ៗ ដូច្នេះបញ្ហានេះមិនមានទេ។

យើងសូមណែនាំឱ្យត្រួតពិនិត្យម៉ែត្រ ប្រើ (ការប្រើប្រាស់ តិត្ថិភាព និងកំហុស) ការពន្យារពេល API និងអត្រាកំហុស។ ធានាថាលទ្ធផលឆ្លើយតបតាមការរំពឹងទុក។

សេចក្តីយោង

នេះជារឿងរបស់យើង។ សម្ភារៈខាងក្រោមបានជួយយ៉ាងខ្លាំងឱ្យយល់ពីអ្វីដែលកំពុងកើតឡើង៖

kernel.org → CFS Scheduler;
kernel.org → CFS Bandwidth Control;
ការយល់ដឹង Linux ការកំណត់ពេលវេលាកុងតឺន័រ;
អ្វីគ្រប់យ៉ាងដែលអ្នកត្រូវដឹងអំពី Linux កុងតឺន័រ ផ្នែកទី I៖ Linux ក្រុមត្រួតពិនិត្យ និងការដាក់ឱ្យនៅដាច់ដោយឡែកពីដំណើរការ;
រឿងរ៉ាវបរាជ័យ Kubernetes - រកមើល "ការបិទដំណើរការស៊ីភីយូ" ។

របាយការណ៍កំហុស Kubernetes៖

តើអ្នកបានជួបប្រទះបញ្ហាស្រដៀងគ្នានៅក្នុងការអនុវត្តរបស់អ្នក ឬមានបទពិសោធន៍ទាក់ទងនឹងការបិទបើកក្នុងបរិយាកាសផលិតកម្មក្នុងធុងទេ? ចែករំលែករឿងរបស់អ្នកនៅក្នុងមតិយោបល់!

PS ពីអ្នកបកប្រែ

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

ប្រភព: www.habr.com

ដែនកំណត់ស៊ីភីយូ និងការបិទបើកដ៏ខ្លាំងក្លានៅក្នុង Kubernetes