ការអនុវត្តល្អបំផុត Kubernetes ។ រៀបចំសំណើធនធាន និងដែនកំណត់

ការអនុវត្តល្អបំផុត Kubernetes ។ ការបង្កើតធុងតូច
ការអនុវត្តល្អបំផុត Kubernetes ។ អង្គការ Kubernetes ដែលមានលំហឈ្មោះ
ការអនុវត្តល្អបំផុត Kubernetes ។ ធ្វើឱ្យមានសុពលភាព Kubernetes Liveness ជាមួយនឹងការធ្វើតេស្តត្រៀមខ្លួន និងរស់

សម្រាប់ធនធាន Kubernetes នីមួយៗ អ្នកអាចកំណត់រចនាសម្ព័ន្ធតម្រូវការពីរប្រភេទ - សំណើ និងដែនកំណត់។ ទីមួយពិពណ៌នាអំពីតម្រូវការអប្បបរមាសម្រាប់ភាពអាចរកបាននៃធនធានថ្នាំងឥតគិតថ្លៃដែលចាំបាច់សម្រាប់ដំណើរការកុងតឺន័រ ឬផត ទីពីរកំណត់យ៉ាងតឹងរ៉ឹងនូវធនធានដែលមាននៅក្នុងកុងតឺន័រ។

នៅពេលដែល Kubernetes កំណត់កាលវិភាគ pods វាមានសារៈសំខាន់ខ្លាំងណាស់ដែលកុងតឺន័រមានធនធានគ្រប់គ្រាន់ដើម្បីដំណើរការបានត្រឹមត្រូវ។ ប្រសិនបើអ្នកគ្រោងនឹងដាក់ពង្រាយកម្មវិធីធំមួយនៅលើថ្នាំងដែលមានកម្រិតធនធាន វាអាចទៅរួចដែលថាវានឹងមិនដំណើរការទេ ដោយសារថ្នាំងនេះដំណើរការលើអង្គចងចាំទាប ឬអស់ថាមពលស៊ីភីយូ។ នៅក្នុងអត្ថបទនេះ យើងនឹងពិនិត្យមើលពីរបៀបដែលអ្នកអាចដោះស្រាយបញ្ហាកង្វះថាមពលកុំព្យូទ័រដោយប្រើសំណើធនធាន និងដែនកំណត់។

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

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

កុងតឺន័រនីមួយៗនៅក្នុងផតអាចកំណត់សំណួរ និងដែនកំណត់របស់វាបាន វាជាការបន្ថែមទាំងអស់។ ធនធានរបស់ឧបករណ៍ដំណើរការត្រូវបានកំណត់ជាមីល្លីក។ ប្រសិនបើកុងតឺន័ររបស់អ្នកត្រូវការស្នូលពីរដើម្បីដំណើរការ អ្នកកំណត់តម្លៃទៅ 2000 ម៉ែត្រ។ ប្រសិនបើកុងតឺន័រត្រូវការថាមពលត្រឹមតែ 1/4 នៃស្នូលនោះតម្លៃនឹងមាន 250 ម។ សូមចងចាំថា ប្រសិនបើអ្នកកំណត់តម្លៃធនធាន CPU ធំជាងចំនួនស្នូលនៃ node ធំបំផុតនោះ pod របស់អ្នកនឹងមិនត្រូវបានកំណត់ពេលចាប់ផ្តើមទាល់តែសោះ។ ស្ថានភាពស្រដៀងគ្នានឹងកើតឡើងប្រសិនបើអ្នកមាន Pod ដែលត្រូវការស្នូលចំនួនបួន ហើយចង្កោម Kubernetes មានម៉ាស៊ីននិម្មិតចម្បងពីរប៉ុណ្ណោះ។

លុះត្រាតែកម្មវិធីរបស់អ្នកត្រូវបានរចនាឡើងជាពិសេសដើម្បីទាញយកអត្ថប្រយោជន៍ពីស្នូលច្រើន (កម្មវិធីដូចជាការគណនាវិទ្យាសាស្រ្តដ៏ស្មុគស្មាញ និងប្រតិបត្តិការមូលដ្ឋានទិន្នន័យមកក្នុងចិត្ត) នោះការអនុវត្តល្អបំផុតគឺត្រូវកំណត់សំណើស៊ីភីយូទៅ 1 ឬទាបជាងនេះ ហើយបន្ទាប់មកដំណើរការការចម្លងបន្ថែមទៀតដើម្បីពង្រីកទំហំ។ ដំណោះស្រាយនេះនឹងផ្តល់ឱ្យប្រព័ន្ធនូវភាពបត់បែននិងភាពជឿជាក់កាន់តែច្រើន។

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

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

វាជារឿងសំខាន់ដែលត្រូវចងចាំថា អ្នកមិនអាចកំណត់រចនាសម្ព័ន្ធសំណើដែលលើសពីធនធានដែលថ្នាំងរបស់អ្នកអាចផ្តល់ឱ្យបានទេ។ លក្ខណៈបច្ចេកទេសនៃធនធានដែលបានចែករំលែកសម្រាប់ម៉ាស៊ីននិម្មិត GKE អាចរកបាននៅក្នុងតំណភ្ជាប់ខាងក្រោមវីដេអូនេះ។

នៅក្នុងពិភពដ៏ល្អ ការកំណត់លំនាំដើមរបស់កុងតឺន័រនឹងគ្រប់គ្រាន់ដើម្បីរក្សាលំហូរការងារឱ្យដំណើរការដោយរលូន។ ប៉ុន្តែពិភពពិតមិនដូចនោះទេ មនុស្សអាចភ្លេចយ៉ាងងាយស្រួលក្នុងការកំណត់រចនាសម្ព័ន្ធការប្រើប្រាស់ធនធាន ឬពួក Hacker នឹងកំណត់សំណើ និងការរឹតបន្តឹងដែលលើសពីសមត្ថភាពពិតនៃហេដ្ឋារចនាសម្ព័ន្ធ។ ដើម្បីការពារសេណារីយ៉ូបែបនេះកុំឱ្យកើតឡើង អ្នកអាចកំណត់រចនាសម្ព័ន្ធកូតាធនធាន ResourceQuota និង LimitRange ។

នៅពេលដែល namespace ត្រូវបានបង្កើត វាអាចត្រូវបានទប់ស្កាត់ដោយប្រើកូតា។ ឧទាហរណ៍ ប្រសិនបើអ្នកមាន prod និង dev namespaces នោះលំនាំគឺថាមិនមានកូតាផលិតកម្មទាល់តែសោះ ហើយកូតាអភិវឌ្ឍន៍តឹងរ៉ឹងខ្លាំង។ នេះអនុញ្ញាតឱ្យ prod នៅក្នុងព្រឹត្តិការណ៍នៃការកើនឡើងយ៉ាងខ្លាំងនៃចរាចរណ៍ គ្រប់គ្រងធនធានដែលមានទាំងស្រុង ដោយរារាំង dev ទាំងស្រុង។

កូតាធនធានអាចមើលទៅដូចនេះ។ ក្នុងឧទាហរណ៍នេះមាន 4 ផ្នែក - នេះគឺជា 4 បន្ទាត់ខាងក្រោមនៃកូដ។

សូមក្រឡេកមើលពួកគេម្នាក់ៗ។ Requests.cpu គឺ​ជា​ចំនួន​អតិបរមា​នៃ​សំណើ​ស៊ីភីយូ​រួម​គ្នា​ដែល​អាច​មក​ពី​កុងតឺន័រ​ទាំងអស់​ក្នុង​ទំហំ​ឈ្មោះ។ ក្នុងឧទាហរណ៍នេះ អ្នកអាចមានកុងតឺន័រចំនួន 50 ដែលមានសំណើរ 10 ម៉ែត្រ ធុងចំនួន 100 ដែលមានសំណើរ 500 ម៉ែត្រ ឬមួយធុងដែលមានសំណើរ 500 ម៉ែត្រ។ ដរាបណាចំនួន request.cpu សរុបនៃ namespace មួយមានតិចជាង XNUMXm នោះអ្វីៗនឹងល្អ។

អង្គចងចាំដែលបានស្នើសុំ requests.memory គឺជាចំនួនអតិបរមានៃសំណើអង្គចងចាំរួមបញ្ចូលគ្នា ដែលធុងទាំងអស់នៅក្នុង namespace អាចមាន។ ដូចនៅក្នុងករណីមុន អ្នកអាចមាន 50 2 mib containers ប្រាំ 20 mib containers ឬធុង 100 mib តែមួយ ដរាបណាចំនួនសរុបនៃអង្គចងចាំដែលបានស្នើសុំក្នុង namespace គឺតិចជាង 100 mebibytes។

Limits.cpu គឺជាចំនួនអតិបរមានៃថាមពលស៊ីភីយូរួមបញ្ចូលគ្នា ដែលកុងតឺន័រទាំងអស់នៅក្នុង namespace អាចប្រើប្រាស់បាន។ យើងអាចចាត់ទុកថានេះជាដែនកំណត់នៃសំណើថាមពលរបស់ខួរក្បាល។

ទីបំផុត limits.memory គឺជាចំនួនអតិបរមានៃអង្គចងចាំដែលបានចែករំលែក ដែលធុងទាំងអស់នៅក្នុង namespace អាចប្រើប្រាស់បាន។ នេះគឺជាដែនកំណត់លើសំណើអង្គចងចាំសរុប។
ដូច្នេះ តាមលំនាំដើម កុងតឺន័រនៅក្នុងចង្កោម Kubernetes ដំណើរការជាមួយធនធានគណនាគ្មានដែនកំណត់។ ជាមួយនឹងកូតាធនធាន អ្នកគ្រប់គ្រងចង្កោមអាចកំណត់ការប្រើប្រាស់ធនធាន និងការបង្កើតធនធានដោយផ្អែកលើទំហំឈ្មោះ។ នៅក្នុង namespace មួយ pod ឬ container អាចប្រើប្រាស់ថាមពល CPU និង memory ច្រើនដូចដែលបានកំណត់ដោយ namespace resource quota។ ទោះយ៉ាងណាក៏ដោយ មានការព្រួយបារម្ភដែលថាផត ឬធុងមួយអាចផ្តាច់មុខធនធានដែលមានទាំងអស់។ ដើម្បីទប់ស្កាត់ស្ថានភាពនេះ ជួរដែនកំណត់មួយត្រូវបានប្រើប្រាស់ - គោលការណ៍សម្រាប់កំណត់ការបែងចែកធនធាន (សម្រាប់ផតឃែរ ឬធុង) ក្នុងចន្លោះឈ្មោះ។

ជួរដែនកំណត់ផ្តល់នូវការរឹតបន្តឹងដែលអាច៖

• ធានាការប្រើប្រាស់អប្បបរមា និងអតិបរមានៃធនធានកុំព្យូទ័រសម្រាប់ម៉ូឌុល ឬកុងតឺន័រនីមួយៗក្នុងចន្លោះឈ្មោះ។
• អនុវត្តការស្នើសុំផ្ទុកអប្បបរមា និងអតិបរមានៃសំណើផ្ទុក Starage សម្រាប់ PersistentVolumeClaim នីមួយៗនៅក្នុង namespace ។
• ពង្រឹងទំនាក់ទំនងរវាងសំណើ និងដែនកំណត់សម្រាប់ធនធាននៅក្នុង namespace;
• កំណត់ការស្នើសុំ/ដែនកំណត់លំនាំដើមសម្រាប់ធនធានគណនានៅក្នុង namespace ហើយបញ្ចូលពួកវាទៅក្នុងកុងតឺន័រដោយស្វ័យប្រវត្តិនៅពេលដំណើរការ។

វិធីនេះអ្នកអាចបង្កើតជួរដែនកំណត់ក្នុងទំហំឈ្មោះរបស់អ្នក។ មិនដូចកូតាដែលអនុវត្តចំពោះទំហំឈ្មោះទាំងមូល ជួរដែនកំណត់ត្រូវបានប្រើសម្រាប់ធុងនីមួយៗ។ នេះអាចរារាំងអ្នកប្រើប្រាស់ពីការបង្កើតធុងតូចបំផុត ឬផ្ទុយទៅវិញ ធុងដ៏ធំសម្បើមនៅក្នុងចន្លោះឈ្មោះ។ ជួរដែនកំណត់អាចមើលទៅដូចនេះ។

ដូចនៅក្នុងករណីមុន 4 ផ្នែកអាចត្រូវបានសម្គាល់នៅទីនេះ។ តោះមើលទាំងអស់គ្នា។
ផ្នែកលំនាំដើមកំណត់ដែនកំណត់លំនាំដើមសម្រាប់កុងតឺន័រនៅក្នុងផត។ ប្រសិនបើអ្នកកំណត់តម្លៃទាំងនេះទៅជួរខ្លាំង នោះកុងតឺន័រណាមួយដែលតម្លៃទាំងនេះមិនត្រូវបានកំណត់ច្បាស់លាស់នឹងធ្វើតាមតម្លៃលំនាំដើម។

ផ្នែកសំណើលំនាំដើម defaultRequest កំណត់រចនាសម្ព័ន្ធសំណើលំនាំដើមសម្រាប់កុងតឺន័រនៅក្នុងផត។ ជាថ្មីម្តងទៀត ប្រសិនបើអ្នកកំណត់តម្លៃទាំងនេះទៅជួរខ្លាំង នោះកុងតឺន័រណាដែលមិនកំណត់ជម្រើសទាំងនេះច្បាស់លាស់នឹងកំណត់តម្លៃទាំងនេះតាមលំនាំដើម។

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

ផ្នែក min បញ្ជាក់សំណើអប្បបរមាដែលអាចកំណត់សម្រាប់កុងតឺន័រនៅក្នុងផត។ ទោះយ៉ាងណាក៏ដោយ តម្លៃនៅក្នុងផ្នែកលំនាំដើម និងសំណួរសម្រាប់កុងតឺន័រមិនអាចកំណត់នៅក្រោមដែនកំណត់នេះបានទេ។

ជាថ្មីម្តងទៀត វាជាការសំខាន់ក្នុងការកត់សម្គាល់ថាប្រសិនបើតម្លៃនេះត្រូវបានកំណត់ នោះលំនាំដើមគឺមិនមែនទេ នោះតម្លៃអប្បបរមានឹងក្លាយជាប្រអប់បញ្ចូលលំនាំដើម។

សំណើធនធានទាំងនេះត្រូវបានប្រើប្រាស់ចុងក្រោយដោយកម្មវិធីកំណត់ពេល Kubernetes ដើម្បីប្រតិបត្តិបន្ទុកការងាររបស់អ្នក។ ដើម្បីឱ្យអ្នកកំណត់រចនាសម្ព័ន្ធកុងតឺន័ររបស់អ្នកបានត្រឹមត្រូវ វាមានសារៈសំខាន់ខ្លាំងណាស់ក្នុងការយល់ដឹងពីរបៀបដែលវាដំណើរការ។ ចូរនិយាយថាអ្នកចង់ដំណើរការ pods ច្រើននៅក្នុងចង្កោមរបស់អ្នក។ ដោយសន្មត់ថាលក្ខណៈបច្ចេកទេសរបស់ផតមានសុពលភាព កាលវិភាគ Kubernetes នឹងប្រើតុល្យភាព robin ដើម្បីជ្រើសរើសថ្នាំងដើម្បីដំណើរការបន្ទុកការងារ។

Kubernetes នឹងពិនិត្យមើលថាតើ Node 1 មានធនធានគ្រប់គ្រាន់ដើម្បីបំពេញសំណើពីធុង pod ឬអត់ វានឹងបន្តទៅថ្នាំងបន្ទាប់។ ប្រសិនបើគ្មានថ្នាំងណាមួយនៅក្នុងប្រព័ន្ធអាចបំពេញសំណើបានទេនោះ ផតស៍នឹងចូលទៅក្នុងស្ថានភាពកំពុងរង់ចាំ។ ដោយប្រើមុខងារម៉ាស៊ីនរបស់ Google Kubernetes ដូចជាការពង្រីកថ្នាំងដោយស្វ័យប្រវត្តិ GKE អាចរកឃើញស្ថានភាពរង់ចាំដោយស្វ័យប្រវត្តិ និងបង្កើតថ្នាំងបន្ថែមជាច្រើនទៀត។

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

ដូចដែលខ្ញុំបាននិយាយ នៅពេលដែលវាមកដល់ CPU Kubernetes នឹងចាប់ផ្តើមកំណត់ pods ។ ផតនីមួយៗនឹងទទួលបានច្រើនតាមការស្នើសុំ ប៉ុន្តែប្រសិនបើវាមិនដល់កម្រិតកំណត់ទេ ការបិទបើកនឹងចាប់ផ្តើមអនុវត្ត។

នៅពេលនិយាយអំពីធនធានអង្គចងចាំ Kubernetes ត្រូវបានបង្ខំឱ្យធ្វើការសម្រេចចិត្តថាតើត្រូវលុប pods មួយណា ហើយត្រូវរក្សាទុករហូតដល់អ្នកបង្កើនធនធានប្រព័ន្ធ ឬប្រព័ន្ធទាំងមូលនឹងគាំង។

តោះស្រមៃមើលសេណារីយ៉ូដែលអ្នកមានម៉ាស៊ីនអស់អង្គចងចាំ - Kubernetes នឹងដោះស្រាយវាដោយរបៀបណា?

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

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

ក្នុងករណីដ៏កម្រ Kubernetes អាចបោះបង់ pods ដែលនៅតែស្ថិតក្នុងវិសាលភាពនៃសំណើរបស់ពួកគេ។ វាអាចកើតឡើងនៅពេលដែលសមាសធាតុប្រព័ន្ធសំខាន់ៗដូចជាភ្នាក់ងារ Kubelet ឬ Docker ចាប់ផ្តើមប្រើប្រាស់ធនធានច្រើនជាងអ្វីដែលបានបម្រុងទុកសម្រាប់ពួកគេ។
ដូច្នេះ នៅក្នុងដំណាក់កាលដំបូងនៃក្រុមហ៊ុនតូចៗ ចង្កោម Kubernetes អាចដំណើរការបានល្អដោយមិនកំណត់សំណើធនធាន និងការរឹតបន្តឹង ប៉ុន្តែនៅពេលដែលក្រុម និងគម្រោងរបស់អ្នកចាប់ផ្តើមកើនឡើង នោះអ្នកនឹងប្រឈមមុខនឹងបញ្ហានៅក្នុងតំបន់នេះ។ ការបន្ថែមសំណួរ និងឧបសគ្គទៅម៉ូឌុល និងចន្លោះឈ្មោះរបស់អ្នក ទាមទារការខិតខំប្រឹងប្រែងបន្ថែមតិចតួចបំផុត ហើយអាចសន្សំបានយ៉ាងច្រើន។

ការអនុវត្តល្អបំផុត Kubernetes ។ ការបិទត្រឹមត្រូវបញ្ចប់

ការផ្សាយពាណិជ្ជកម្មមួយចំនួន🙂

សូមអរគុណចំពោះការស្នាក់នៅជាមួយពួកយើង។ តើអ្នកចូលចិត្តអត្ថបទរបស់យើងទេ? ចង់មើលខ្លឹមសារគួរឱ្យចាប់អារម្មណ៍បន្ថែមទៀតទេ? គាំទ្រយើងដោយការបញ្ជាទិញឬណែនាំដល់មិត្តភក្តិ, cloud VPS សម្រាប់អ្នកអភិវឌ្ឍន៍ចាប់ពី $4.99, analogue តែមួយគត់នៃម៉ាស៊ីនមេកម្រិតធាតុ ដែលត្រូវបានបង្កើតឡើងដោយពួកយើងសម្រាប់អ្នក៖ ការពិតទាំងមូលអំពី VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ចាប់ពី $19 ឬរបៀបចែករំលែកម៉ាស៊ីនមេ? (អាចប្រើបានជាមួយ RAID1 និង RAID10 រហូតដល់ 24 cores និងរហូតដល់ 40GB DDR4)។

Dell R730xd 2x ថោកជាងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ Equinix Tier IV នៅទីក្រុង Amsterdam? នៅទីនេះ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ចាប់ពី $199 នៅប្រទេសហូឡង់! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ចាប់ពី $99! អាន​អំពី របៀបបង្កើតក្រុមហ៊ុនហេដ្ឋារចនាសម្ព័ន្ធ ថ្នាក់ជាមួយនឹងការប្រើប្រាស់ម៉ាស៊ីនមេ Dell R730xd E5-2650 v4 ដែលមានតម្លៃ 9000 អឺរ៉ូសម្រាប់មួយកាក់?

ប្រភព: www.habr.com