របៀបពិនិត្យមើលថាសជាមួយ fio សម្រាប់ដំណើរការគ្រប់គ្រាន់សម្រាប់ ល។

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

សេចក្តីសង្ខេបខ្លីៗនៃអត្ថបទទាំងមូល៖ ហ្វីអូ និង ល

ដំណើរការនៃចង្កោម etcd គឺពឹងផ្អែកយ៉ាងខ្លាំងទៅលើល្បឿននៃការផ្ទុកមូលដ្ឋាន។ etcd នាំចេញម៉ែត្រ Prometheus ផ្សេងៗ ដើម្បីតាមដានដំណើរការ។ មួយក្នុងចំណោមពួកគេគឺ wal_fsync_duration_seconds. នៅក្នុងឯកសារសម្រាប់ ល។ វា​និយាយការផ្ទុកអាចត្រូវបានគេចាត់ទុកថាលឿនគ្រប់គ្រាន់ ប្រសិនបើភាគរយទី 99 នៃម៉ែត្រនេះមិនលើសពី 10 ms…

ប្រសិនបើអ្នកកំពុងពិចារណាលើការដំឡើង etcd cluster នៅលើម៉ាស៊ីនលីនុច ហើយចង់ពិនិត្យមើលថាតើ drives (ដូចជា SSDs) មានល្បឿនលឿនគ្រប់គ្រាន់ដែរឬទេ យើងសូមណែនាំឱ្យប្រើ I/O tester ដ៏ពេញនិយមដែលហៅថា fio. វាគ្រប់គ្រាន់ដើម្បីដំណើរការពាក្យបញ្ជាខាងក្រោម (ថត test-data ត្រូវតែមានទីតាំងនៅក្នុងភាគថាសដែលបានម៉ោននៃដ្រាយដែលបានសាកល្បង)៖

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

វានៅសល់តែដើម្បីមើលលទ្ធផល និងពិនិត្យមើលថាតើភាគរយទី 99 សម fdatasync ក្នុង 10 ms ។ បើដូច្នេះមែន នោះដ្រាយរបស់អ្នកដំណើរការលឿនល្មម។ នេះជាឧទាហរណ៍លទ្ធផល៖

fsync/fdatasync/sync_file_range:
  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

កំណត់ចំណាំមួយចំនួន៖

1. ក្នុងឧទាហរណ៍ខាងលើយើងបានកែតម្រូវប៉ារ៉ាម៉ែត្រ --size и --bs សម្រាប់ករណីជាក់លាក់មួយ។ ដើម្បីទទួលបានលទ្ធផលដ៏មានអត្ថន័យពី fio, បញ្ជាក់តម្លៃដែលសមរម្យសម្រាប់ករណីប្រើប្រាស់របស់អ្នក។ របៀបជ្រើសរើសពួកវានឹងត្រូវបានពិភាក្សាខាងក្រោម។
2. ក្នុងអំឡុងពេលធ្វើតេស្តតែប៉ុណ្ណោះ fio ផ្ទុកប្រព័ន្ធរងរបស់ឌីស។ នៅក្នុងជីវិតពិត វាទំនងជាថាដំណើរការផ្សេងទៀតនឹងសរសេរទៅថាស (ក្រៅពីវាទាក់ទងនឹង wal_fsync_duration_seconds) បន្ទុកបន្ថែមនេះអាចកើនឡើង wal_fsync_duration_seconds. នៅក្នុងពាក្យផ្សេងទៀតប្រសិនបើភាគរយទី 99 ពីការធ្វើតេស្តជាមួយ fioតិចជាង 10 ms បន្តិច មានឱកាសល្អដែលដំណើរការផ្ទុកមិនគ្រប់គ្រាន់។
3. សម្រាប់ការធ្វើតេស្តអ្នកនឹងត្រូវការកំណែ fio មិនតិចជាង ៨០ដោយសារតែកំណែចាស់មិនសរុបលទ្ធផល fdatasync ក្នុងទម្រង់ជាភាគរយ។
4. ការ​សន្និដ្ឋាន​ខាង​លើ​នេះ​គ្រាន់​តែ​ជា​ការ​ដក​ស្រង់​បន្តិចបន្តួច​ពី​ការ​សន្និដ្ឋាន​ទូទៅ​ប៉ុណ្ណោះ។ fio.

បន្ថែមទៀតអំពី fio និង ល។

ពាក្យពីរបីអំពី WALs ។ល។

ជាទូទៅ មូលដ្ឋានទិន្នន័យប្រើប្រាស់ ការកត់ត្រាសកម្ម (ការកត់ត្រាទុកមុន WAL) ។ etcd ក៏រងផលប៉ះពាល់ផងដែរ។ ការពិភាក្សាអំពី WAL គឺហួសពីវិសាលភាពនៃអត្ថបទនេះ ប៉ុន្តែសម្រាប់គោលបំណងរបស់យើង អ្វីដែលអ្នកត្រូវដឹងគឺថា សមាជិកនៃក្រុម etcd នីមួយៗរក្សាទុក WAL នៅក្នុងការផ្ទុកជាប់លាប់។ etcd សរសេរប្រតិបត្តិការផ្ទុកតម្លៃគន្លឹះមួយចំនួន (ដូចជាការអាប់ដេត) ទៅ WAL មុនពេលប្រតិបត្តិពួកវា។ ប្រសិនបើថ្នាំងគាំង និងចាប់ផ្តើមឡើងវិញរវាងការថតរូប ល.ល អាចស្តារប្រតិបត្តិការឡើងវិញចាប់តាំងពីរូបថតមុនដោយផ្អែកលើខ្លឹមសារនៃ WAL ។

ដូច្នេះ រាល់ពេលដែលអតិថិជនបន្ថែមកូនសោទៅហាង KV ឬធ្វើបច្ចុប្បន្នភាពតម្លៃនៃសោដែលមានស្រាប់ ល.ល. បន្ថែមការពិពណ៌នាអំពីប្រតិបត្តិការទៅ WAL ដែលជាឯកសារធម្មតានៅក្នុងហាងជាប់លាប់។ etcd ត្រូវតែប្រាកដ 100% ថាធាតុ WAL ពិតជាត្រូវបានរក្សាទុកមុនពេលដំណើរការ។ ដើម្បីសម្រេចបានវានៅលើលីនុច វាមិនគ្រប់គ្រាន់ទេក្នុងការប្រើការហៅតាមប្រព័ន្ធ writeចាប់តាំងពីប្រតិបត្តិការសរសេរដោយខ្លួនឯងទៅកាន់ប្រព័ន្ធផ្សព្វផ្សាយរូបវន្តអាចនឹងត្រូវបានពន្យារពេល។ ឧទាហរណ៍ លីនុចអាចរក្សាធាតុ WAL នៅក្នុងឃ្លាំងសម្ងាត់ខឺណែលក្នុងសតិ (ឧ. នៅក្នុងឃ្លាំងសម្ងាត់ទំព័រ) សម្រាប់ពេលខ្លះ។ ដើម្បីធានាថាទិន្នន័យត្រូវបានសរសេរទៅកាន់ប្រព័ន្ធផ្សព្វផ្សាយ ការហៅប្រព័ន្ធត្រូវតែត្រូវបានហៅបន្ទាប់ពីការសរសេរ fdatasync - នេះគឺជាអ្វីដែល etcd ធ្វើ (ដូចដែលអ្នកឃើញនៅក្នុងលទ្ធផលខាងក្រោម strace; នៅទីនេះ 8 - អ្នកពិពណ៌នាឯកសារ WAL៖

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

ជាអកុសល ការសរសេរទៅកាន់ការផ្ទុកជាប់លាប់ត្រូវការពេលវេលាខ្លះ។ ការប្រតិបត្តិយូរនៃការហៅ fdatasync អាចប៉ះពាល់ដល់ដំណើរការរបស់ etcd ។ នៅក្នុងឯកសារឃ្លាំង ចង្អុលបង្ហាញថាសម្រាប់ដំណើរការគ្រប់គ្រាន់វាចាំបាច់ថាភាគរយទី 99 នៃរយៈពេលនៃការហៅទូរស័ព្ទទាំងអស់។ fdatasync នៅពេលសរសេរទៅឯកសារ WAL គឺតិចជាង 10 ms ។ មានរង្វាស់ផ្សេងទៀតដែលទាក់ទងនឹងការផ្ទុក ប៉ុន្តែអត្ថបទនេះនឹងផ្តោតលើវា។

ការវាយតម្លៃការផ្ទុកជាមួយ fio

អ្នកអាចវាយតម្លៃថាតើទំហំផ្ទុកជាក់លាក់មួយសមរម្យសម្រាប់ប្រើជាមួយ etcd ដោយប្រើឧបករណ៍ប្រើប្រាស់ fio - អ្នកសាកល្បង I/O ដ៏ពេញនិយម។ សូមចងចាំថា ថាស I/O អាចកើតឡើងតាមវិធីផ្សេងៗគ្នាជាច្រើន៖ ការធ្វើសមកាលកម្ម/អសមកាល ថ្នាក់ syscall ផ្សេងៗគ្នាជាច្រើន និងអ្វីៗផ្សេងទៀត។ ផ្នែកម្ខាងទៀតនៃកាក់គឺនោះ។ fio ពិបាកប្រើណាស់។ ឧបករណ៍ប្រើប្រាស់មានប៉ារ៉ាម៉ែត្រជាច្រើន ហើយការរួមផ្សំផ្សេងគ្នានៃតម្លៃរបស់វានាំឱ្យមានលទ្ធផលខុសគ្នាទាំងស្រុង។ ដើម្បីទទួលបានការប៉ាន់ប្រមាណសមហេតុផលសម្រាប់ etcd អ្នកត្រូវប្រាកដថាការផ្ទុកការសរសេរដែលបង្កើតដោយ fio គឺជិតបំផុតតាមដែលអាចធ្វើទៅបានចំពោះការផ្ទុកឯកសារ WAL របស់ etcd:

• នេះមានន័យថាបានបង្កើត fio បន្ទុកគួរតែជាស៊េរីនៃការសរសេរជាប់ៗគ្នាទៅកាន់ឯកសារ ដែលការសរសេរនីមួយៗមានការហៅជាប្រព័ន្ធ writeតាមដាន​ដោយ fdatasync.
• ដើម្បីបើកការសរសេរតាមលំដាប់លំដោយ អ្នកត្រូវតែបញ្ជាក់ទង់ --rw=write.
• ថា fio សរសេរដោយប្រើការហៅទូរស័ព្ទ write (ជាជាងការហៅតាមប្រព័ន្ធផ្សេងទៀត - ឧទាហរណ៍ pwrite) ប្រើទង់ជាតិ --ioengine=sync.
• ទីបំផុតទង់ជាតិ --fdatasync=1 ធានាថារាល់ write ត្រូវតែជា fdatasync.
• ប៉ារ៉ាម៉ែត្រពីរផ្សេងទៀតនៅក្នុងឧទាហរណ៍របស់យើងគឺ: --size и --bs - អាចប្រែប្រួលអាស្រ័យលើករណីប្រើប្រាស់ជាក់លាក់។ ផ្នែកបន្ទាប់នឹងពិពណ៌នាអំពីការកំណត់រចនាសម្ព័ន្ធរបស់ពួកគេ។

ហេតុអ្វីបានជាយើងជ្រើសរើស fio និងរបៀបដែលយើងបានរៀនពីរបៀបរៀបចំវា។

កំណត់សម្គាល់នេះកើតចេញពីករណីពិតដែលយើងជួបប្រទះ។ យើងមានចង្កោមនៅលើ Kubernetes v1.13 ជាមួយនឹងការត្រួតពិនិត្យនៅលើ Prometheus ។ SSDs ត្រូវបានប្រើជាកន្លែងផ្ទុកសម្រាប់ etcd v3.2.24 ។ Etcd metrics បានបង្ហាញពីភាពយឺតយ៉ាវខ្ពស់ពេក fdatasyncសូម្បីតែនៅពេលដែលចង្កោមនៅទំនេរ។ ចំពោះយើង មាត្រដ្ឋានទាំងនេះហាក់ដូចជាគួរឱ្យសង្ស័យណាស់ ហើយយើងមិនប្រាកដថាអ្វីដែលតំណាងឱ្យពិតប្រាកដនោះទេ។ លើសពីនេះ ចង្កោមមានម៉ាស៊ីននិម្មិត ដូច្នេះវាមិនអាចនិយាយបានថាតើការពន្យារពេលនេះបណ្តាលមកពីនិម្មិត ឬ SSD ត្រូវស្តីបន្ទោសនោះទេ។

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

នេះតម្រូវឱ្យមានការដោះស្រាយបញ្ហាពីរ:

• ទីមួយ តើការផ្ទុក I/O ដែលបង្កើតដោយ etcd នៅពេលសរសេរទៅឯកសារ WAL មើលទៅដូចអ្វី? តើ​ការ​ហៅ​ទូរសព្ទ​ប្រព័ន្ធ​អ្វី​ត្រូវ​បាន​ប្រើ? តើប្លុកកំណត់ត្រាមានទំហំប៉ុនណា?
• ទីពីរ ឧបមាថាយើងមានចម្លើយចំពោះសំណួរខាងលើ។ របៀបបង្កើតបន្ទុកដែលត្រូវគ្នាជាមួយ fio? បន្ទាប់ពីទាំងអស់។ fio - ឧបករណ៍ប្រើប្រាស់ដែលអាចបត់បែនបានជាមួយនឹងប៉ារ៉ាម៉ែត្រដ៏សម្បូរបែប (ឧទាហរណ៍នេះងាយស្រួលផ្ទៀងផ្ទាត់។ នៅទីនេះ - ប្រហែល បកប្រែ។ ).

យើងបានដោះស្រាយបញ្ហាទាំងពីរជាមួយនឹងវិធីសាស្រ្តដែលមានមូលដ្ឋានលើពាក្យបញ្ជាដូចគ្នា។ lsof и strace:

• ដោយមានជំនួយពី lsof អ្នក​អាច​មើល​ឯកសារ​ពណ៌នា​ទាំងអស់​ដែល​បាន​ប្រើ​ដោយ​ដំណើរការ​ក៏ដូចជា​ឯកសារ​ដែល​ពួកគេ​យោង​ទៅ។​
• ដោយមានជំនួយពី strace អ្នកអាចវិភាគដំណើរការដែលកំពុងដំណើរការរួចហើយ ឬដំណើរការដំណើរការ ហើយមើលវា។ ពាក្យបញ្ជាបង្ហាញការហៅប្រព័ន្ធទាំងអស់ដែលធ្វើឡើងដោយដំណើរការនេះ ហើយបើចាំបាច់ កូនចៅរបស់វា។ ក្រោយមកទៀតគឺមានសារៈសំខាន់សម្រាប់ដំណើរការដែលត្រូវបាន forking ហើយ etcd គឺជាដំណើរការបែបនេះ។

រឿងដំបូងដែលយើងបានធ្វើគឺត្រូវប្រើ strace ដើម្បីពិនិត្យមើលម៉ាស៊ីនមេ etcd នៅក្នុងចង្កោម Kubernetes ខណៈពេលដែលវានៅទំនេរ។

ដូច្នេះវាត្រូវបានគេរកឃើញថាប្លុកកំណត់ត្រា WAL ត្រូវបានដាក់ជាក្រុមយ៉ាងក្រាស់ ទំហំនៃភាគច្រើនគឺស្ថិតនៅក្នុងចន្លោះពី 2200-2400 បៃ។ នោះហើយជាមូលហេតុដែលពាក្យបញ្ជានៅដើមអត្ថបទនេះប្រើទង់ --bs=2300 (bs គឺជាទំហំគិតជាបៃនៃប្លុកសរសេរនីមួយៗ fio).

សូមចំណាំថាទំហំនៃប្លុកសរសេរ etcd អាចប្រែប្រួលអាស្រ័យលើកំណែ ការដាក់ពង្រាយ តម្លៃប៉ារ៉ាម៉ែត្រ។ល។ - វាប៉ះពាល់ដល់រយៈពេល fdatasync. ប្រសិនបើអ្នកមានករណីប្រើប្រាស់ស្រដៀងគ្នា សូមវិភាគជាមួយ strace ដំណើរការ etcd របស់អ្នកដើម្បីទទួលបានតម្លៃទាន់សម័យ។

បន្ទាប់មក ដើម្បីទទួលបានគំនិតច្បាស់លាស់ និងទូលំទូលាយអំពីរបៀបដែល etcd ដំណើរការជាមួយប្រព័ន្ធឯកសារ យើងបានចាប់ផ្តើមវាពីក្រោម strace ជាមួយនឹងទង់ជាតិ -ffttT. នេះធ្វើឱ្យវាអាចចាប់យកដំណើរការរបស់កុមារ និងសរសេរលទ្ធផលនីមួយៗទៅជាឯកសារដាច់ដោយឡែកមួយ។ លើសពីនេះ ព័ត៌មានលំអិតអំពីពេលវេលាចាប់ផ្តើម និងរយៈពេលនៃការហៅតាមប្រព័ន្ធនីមួយៗត្រូវបានទទួល។

យើងក៏បានប្រើពាក្យបញ្ជាផងដែរ។ lsofដើម្បីបញ្ជាក់ការយល់ដឹងរបស់អ្នកអំពីលទ្ធផល strace នៅក្នុងលក្ខខណ្ឌនៃឯកសារពិពណ៌នាដែលត្រូវបានប្រើសម្រាប់គោលបំណងណាមួយ។ ខ្ញុំបានទទួលការសន្និដ្ឋាន straceស្រដៀងទៅនឹងអ្វីដែលខាងលើ។ ឧបាយកលស្ថិតិជាមួយនឹងពេលវេលាធ្វើសមកាលកម្មបានបញ្ជាក់ថាម៉ែត្រ wal_fsync_duration_seconds ពីការហៅការប្រកួត etcd fdatasync ជាមួយនឹងការពិពណ៌នាឯកសារ WAL ។

ដើម្បីបង្កើតជាមួយ fio បន្ទុកការងារស្រដៀងនឹងឯកសារពី etcd ឯកសារនៃឧបករណ៍ប្រើប្រាស់ត្រូវបានសិក្សា ហើយប៉ារ៉ាម៉ែត្រដែលសមរម្យសម្រាប់កិច្ចការរបស់យើងត្រូវបានជ្រើសរើស។ យើង​បាន​ផ្ទៀងផ្ទាត់​ថា​ការ​ហៅ​ទូរសព្ទ​ប្រព័ន្ធ​ដែល​ត្រឹមត្រូវ​កំពុង​ដំណើរការ​ហើយ​បាន​បញ្ជាក់​ពី​រយៈពេល​ដោយ​ការ​ដំណើរការ fio ពី strace (ដូចដែលវាត្រូវបានធ្វើក្នុងករណី ល។ ) ។

ការយកចិត្តទុកដាក់ជាពិសេសត្រូវបានបង់ដើម្បីកំណត់តម្លៃនៃប៉ារ៉ាម៉ែត្រ --size. វាតំណាងឱ្យបន្ទុក I/O សរុបដែលបង្កើតឡើងដោយឧបករណ៍ប្រើប្រាស់ fio ។ ក្នុងករណីរបស់យើង នេះគឺជាចំនួនសរុបនៃបៃដែលសរសេរទៅកាន់ប្រព័ន្ធផ្សព្វផ្សាយ។ វាសមាមាត្រដោយផ្ទាល់ទៅនឹងចំនួននៃការហៅទូរស័ព្ទ write (និង fdatasync) សម្រាប់ជាក់លាក់មួយ។ bs ចំនួននៃការហៅទូរស័ព្ទ fdatasync ស្មើ size / bs.

ដោយសារយើងចាប់អារម្មណ៍លើភាគរយ យើងចង់ឱ្យចំនួនគំរូមានទំហំធំល្មមដើម្បីឱ្យមានសារសំខាន់តាមស្ថិតិ។ ហើយ​បាន​សម្រេច​ចិត្ត​នោះ។ 10^4 (ដែលត្រូវនឹងទំហំ 22 MB) នឹងគ្រប់គ្រាន់។ តម្លៃប៉ារ៉ាម៉ែត្រតូចជាង --size ផ្តល់សំលេងលឺច្បាស់ជាងមុន (ឧទាហរណ៍ ការហៅទូរសព្ទ fdatasyncដែលចំណាយពេលយូរជាងធម្មតា និងប៉ះពាល់ដល់ភាគរយទី 99)។

តាម​តែ​ចិត្ត​របស់​អ្នក​ចុះ

អត្ថបទបង្ហាញពីរបៀបប្រើ fio គេអាចវិនិច្ឆ័យថាតើប្រព័ន្ធផ្សព្វផ្សាយដែលមានបំណងប្រើជាមួយ etcd លឿនគ្រប់គ្រាន់ឬអត់។ ឥឡូវនេះវាអាស្រ័យលើអ្នក! អ្នកអាចរុករកម៉ាស៊ីននិម្មិតជាមួយនឹងកន្លែងផ្ទុកទិន្នន័យដែលមានមូលដ្ឋានលើ SSD នៅក្នុងសេវាកម្ម IBM Cloud.

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

ជាមួយនឹងករណីប្រើប្រាស់រួចរាល់ fio សម្រាប់កិច្ចការផ្សេងទៀត សូមមើល ឯកសារ ឬដោយផ្ទាល់ទៅ ឃ្លាំងគម្រោង (មាន​ច្រើន​ជាង​ការ​រៀបរាប់​ក្នុង​ឯកសារ)។

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

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

• «etcd 3.4.3៖ ការសិក្សាអំពីភាពជឿជាក់នៃការផ្ទុក និងសុវត្ថិភាព»
• «បទពិសោធន៍របស់យើងជាមួយនឹងទិន្នន័យនៅក្នុង etcd Kubernetes cluster ដោយផ្ទាល់ (ដោយគ្មាន K8s API)»
• «កំហុសប្រព័ន្ធកម្សាន្តចំនួន 6 នៅក្នុងប្រតិបត្តិការរបស់ Kubernetes [និងដំណោះស្រាយរបស់ពួកគេ]"។

ប្រភព: www.habr.com