ការរចនាចង្កោម Kubernetes៖ តើគួរតែមានចំនួនប៉ុន្មាន?

ចំណាំ។ បកប្រែ៖ សម្ភារៈនេះគឺបានមកពីគម្រោងអប់រំ learnk8s គឺជាចម្លើយចំពោះសំណួរដ៏ពេញនិយមមួយនៅពេលរចនាហេដ្ឋារចនាសម្ព័ន្ធដែលមានមូលដ្ឋានលើ Kubernetes ។ យើងសង្ឃឹមថាការពិពណ៌នាលម្អិតដោយស្មើភាពនៃគុណសម្បត្តិ និងគុណវិបត្តិនៃជម្រើសនីមួយៗនឹងជួយអ្នកធ្វើជម្រើសដ៏ល្អបំផុតសម្រាប់គម្រោងរបស់អ្នក។

TL; កុង៖ សំណុំនៃបន្ទុកការងារដូចគ្នាអាចដំណើរការលើចង្កោមធំជាច្រើន (ចង្កោមនីមួយៗនឹងមានចំនួនការងារច្រើន) ឬលើចំនួនតូចជាច្រើន (ជាមួយនឹងចំនួនផ្ទុកតិចតួចនៅក្នុងចង្កោមនីមួយៗ)។

ខាង​ក្រោម​នេះ​គឺ​ជា​តារាង​ដែល​វាយ​តម្លៃ​គុណសម្បត្តិ និង​គុណវិបត្តិ​នៃ​វិធីសាស្ត្រ​នីមួយៗ៖

នៅពេលប្រើ Kubernetes ជាវេទិកាសម្រាប់ដំណើរការកម្មវិធី សំណួរជាមូលដ្ឋានជាច្រើនតែងតែកើតឡើងអំពីភាពស្មុគស្មាញនៃការដំឡើងចង្កោម៖

• តើខ្ញុំគួរប្រើចង្កោមប៉ុន្មាន?
• តើខ្ញុំគួរបង្កើតពួកវាទំហំប៉ុនណា?
• តើចង្កោមនីមួយៗគួររួមបញ្ចូលអ្វីខ្លះ?

នៅក្នុងអត្ថបទនេះ ខ្ញុំនឹងព្យាយាមឆ្លើយសំណួរទាំងអស់នេះដោយការវិភាគពីគុណសម្បត្តិ និងគុណវិបត្តិនៃវិធីសាស្រ្តនីមួយៗ។

សេចក្តីថ្លែងការណ៍នៃសំណួរមួយ។

ក្នុងនាមជាអ្នកបង្កើតកម្មវិធី អ្នកទំនងជាបង្កើត និងដំណើរការកម្មវិធីជាច្រើនក្នុងពេលតែមួយ។

លើសពីនេះ ករណីជាច្រើននៃកម្មវិធីទាំងនេះទំនងជាដំណើរការក្នុងបរិយាកាសផ្សេងៗគ្នា - ឧទាហរណ៍ ទាំងនេះអាចជា dev, ការធ្វើតេស្ត и ផលិតផល.

លទ្ធផលគឺជាម៉ាទ្រីសទាំងមូលនៃកម្មវិធី និងបរិស្ថាន៖

កម្មវិធី និងបរិស្ថាន

ឧទាហរណ៍ខាងលើតំណាងឱ្យកម្មវិធី 3 និងបរិស្ថានចំនួន 3 ដែលបណ្តាលឱ្យមានជម្រើសសរុបចំនួន 9 ។

កម្មវិធីនីមួយៗគឺជាអង្គភាពដាក់ឱ្យប្រើប្រាស់ដោយខ្លួនឯង ដែលអាចធ្វើការជាមួយដោយឯករាជ្យពីអ្នកដទៃ។

ចំណាំ​ថា ឧទាហរណ៍កម្មវិធី អាចមានច្រើន។ សមាសភាគដូចជា frontend, backend, database ជាដើម។ ក្នុង​ករណី​នៃ​កម្មវិធី microservices នោះ​នឹង​រួម​បញ្ចូល microservices ទាំងអស់។

ជាលទ្ធផល អ្នកប្រើប្រាស់ Kubernetes មានសំណួរជាច្រើន៖

• តើ​កម្មវិធី​ទាំងអស់​គួរ​ដាក់​ក្នុង​ចង្កោម​មួយ​ឬ?
• តើវាមានតម្លៃក្នុងការមានចង្កោមដាច់ដោយឡែកសម្រាប់កម្មវិធីនីមួយៗដែរឬទេ?
• ឬប្រហែលជាការរួមបញ្ចូលគ្នានៃវិធីសាស្រ្តខាងលើគួរតែត្រូវបានប្រើ?

ជម្រើស​ទាំង​អស់​នេះ​គឺ​អាច​ប្រើ​បាន​ដោយ​សារ Kubernetes ជា​ប្រព័ន្ធ​អាច​បត់​បែន​បាន​ដែល​មិន​កំណត់​សមត្ថភាព​របស់​អ្នក​ប្រើ។

នេះគឺជាវិធីមួយចំនួនដែលអាចធ្វើទៅបាន៖

• ចង្កោមទូទៅដ៏ធំមួយ;
• ចង្កោមឯកទេសខ្ពស់តូចៗជាច្រើន;
• មួយក្រុមក្នុងមួយកម្មវិធី;
• មួយចង្កោមក្នុងមួយបរិស្ថាន។

ដូចដែលបានបង្ហាញខាងក្រោម វិធីសាស្រ្តពីរដំបូងគឺនៅទល់មុខគ្នានៃទំហំជម្រើស៖

ពីចង្កោមធំមួយចំនួន (ឆ្វេង) ទៅតូចជាច្រើន (ស្តាំ)

ជាទូទៅ ចង្កោមមួយត្រូវបានចាត់ទុកថា "ធំជាង" ជាងមួយទៀត ប្រសិនបើវាមានចំនួនថ្នាំង និងផតធំជាង។ ឧទាហរណ៍ ចង្កោមដែលមាន 10 nodes និង 100 pods ធំជាង cluster ដែលមាន 1 node និង 10 pods។

អញ្ចឹងតោះចាប់ផ្តើម!

1. ចង្កោមទូទៅធំមួយ។

ជម្រើសដំបូងគឺដាក់បន្ទុកការងារទាំងអស់នៅក្នុងចង្កោមតែមួយ៖

ចង្កោមធំមួយ។

នៅក្នុងវិធីសាស្រ្តនេះចង្កោមត្រូវបានប្រើជាសកល វេទិកាហេដ្ឋារចនាសម្ព័ន្ធ — អ្នកគ្រាន់តែដាក់ពង្រាយអ្វីគ្រប់យ៉ាងដែលអ្នកត្រូវការនៅក្នុងចង្កោម Kubernetes ដែលមានស្រាប់។

ចន្លោះឈ្មោះ Kubernetes អនុញ្ញាតឱ្យផ្នែកនៃចង្កោមត្រូវបានបំបែកចេញពីគ្នាដោយឡូជីខល ដូច្នេះកម្មវិធីនីមួយៗអាចមានទំហំឈ្មោះផ្ទាល់ខ្លួនរបស់វា។

សូមក្រឡេកមើលគុណសម្បត្តិនិងគុណវិបត្តិនៃវិធីសាស្រ្តនេះ។

+ ការប្រើប្រាស់ធនធានប្រកបដោយប្រសិទ្ធភាព

ជាមួយនឹងចង្កោមតែមួយ អ្នកគ្រាន់តែត្រូវការច្បាប់ចម្លងមួយនៃធនធានទាំងអស់ដែលត្រូវការដើម្បីដំណើរការ និងគ្រប់គ្រងចង្កោម Kubernetes ។

ជាឧទាហរណ៍ នេះជាការពិតសម្រាប់ថ្នាំងមេ។ ជាធម្មតា ចង្កោម Kubernetes នីមួយៗមានថ្នាំងមេចំនួន 3 ដូច្នេះសម្រាប់ចង្កោមតែមួយចំនួនរបស់ពួកគេនឹងនៅដដែល (សម្រាប់ការប្រៀបធៀប ចង្កោម 10 នឹងត្រូវការថ្នាំងមេចំនួន 30) ។

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

នៅក្នុងចង្កោមតែមួយ សេវាកម្មទាំងអស់នេះអាចត្រូវបានប្រើក្នុងពេលតែមួយសម្រាប់បន្ទុកការងារទាំងអស់ (មិនចាំបាច់បង្កើតច្បាប់ចម្លងនៃពួកវា ដូចករណីដែលមានចង្កោមច្រើនទេ)។

+ ថោក

អាស្រ័យហេតុនេះ ចង្កោមតិចជាងមុនជាធម្មតាមានតម្លៃថោកជាង ដោយសារមិនមានការចំណាយលើស។

នេះជាការពិតជាពិសេសសម្រាប់ថ្នាំងមេ ដែលអាចចំណាយប្រាក់យ៉ាងច្រើនដោយមិនគិតពីរបៀបដែលពួកវាត្រូវបានបង្ហោះ (ក្នុងបរិវេណ ឬក្នុងពពក)។

សេវាកម្ម Kubernetes ដែលគ្រប់គ្រងមួយចំនួនដូចជា Google Kubernetes Engine (GKE) ឬ សេវាកម្ម Azure Kubernetes (អេអេសខេ)ផ្តល់ស្រទាប់ត្រួតពិនិត្យដោយឥតគិតថ្លៃ។ ក្នុងករណីនេះបញ្ហាចំណាយគឺមិនសូវធ្ងន់ធ្ងរទេ។

មានសេវាកម្មគ្រប់គ្រងផងដែរ ដែលគិតថ្លៃថេរសម្រាប់ប្រតិបត្តិការនៃក្រុម Kubernetes នីមួយៗ (ឧទាហរណ៍ សេវាកម្ម Amazon Elastic Kubernetes, EKS).

+ ការគ្រប់គ្រងប្រកបដោយប្រសិទ្ធភាព

ការគ្រប់គ្រងមួយចង្កោមគឺងាយស្រួលជាងការគ្រប់គ្រងមួយចំនួន។

ការគ្រប់គ្រងអាចរួមបញ្ចូលការងារដូចខាងក្រោមៈ

• អាប់ដេតកំណែ Kubernetes;
• ការដំឡើងបំពង់ CI/CD;
• ការដំឡើងកម្មវិធីជំនួយ CNI;
• រៀបចំប្រព័ន្ធផ្ទៀងផ្ទាត់អ្នកប្រើប្រាស់;
• ការដំឡើងឧបករណ៍បញ្ជាចូល;

និងអ្នកផ្សេងទៀតជាច្រើន…

ក្នុងករណីមួយចង្កោម អ្នកនឹងត្រូវធ្វើទាំងអស់នេះតែម្តងគត់។

សម្រាប់ចង្កោមជាច្រើន ប្រតិបត្តិការនឹងត្រូវធ្វើម្តងទៀតច្រើនដង ដែលទំនងជាត្រូវការស្វ័យប្រវត្តិកម្មនៃដំណើរការ និងឧបករណ៍មួយចំនួន ដើម្បីធានាបាននូវភាពស៊ីសង្វាក់គ្នា និងស្ថិរភាពនៅក្នុងដំណើរការ។

ហើយឥឡូវនេះពាក្យពីរបីអំពីគុណវិបត្តិ។

- ចំណុចតែមួយនៃការបរាជ័យ

ក្នុងករណីបដិសេធ តែមួយគត់ ចង្កោមនឹងឈប់ដំណើរការភ្លាមៗ ទាំងអស់ បន្ទុកការងារ!

មានវិធីជាច្រើនដែលអាចខុស៖

• ការធ្វើបច្ចុប្បន្នភាព Kubernetes នាំឱ្យមានផលប៉ះពាល់ដែលមិនរំពឹងទុក។
• សមាសធាតុទាំងមូលនៃចង្កោម (ឧទាហរណ៍ កម្មវិធីជំនួយ CNI) ចាប់ផ្តើមមិនដំណើរការដូចការរំពឹងទុក។
• សមាសធាតុចង្កោមមួយមិនត្រូវបានតំឡើងត្រឹមត្រូវទេ។
• ការបរាជ័យក្នុងហេដ្ឋារចនាសម្ព័ន្ធមូលដ្ឋាន។

ឧប្បត្តិហេតុបែបនេះអាចបណ្តាលឱ្យខូចខាតយ៉ាងធ្ងន់ធ្ងរដល់បន្ទុកការងារទាំងអស់ដែលបានរៀបចំនៅក្នុងចង្កោមរួមគ្នា។

- មិនមានអ៊ីសូឡង់រឹង

ការដំណើរការនៅក្នុងចង្កោមដែលបានចែករំលែកមានន័យថាកម្មវិធីចែករំលែកផ្នែករឹង សមត្ថភាពបណ្តាញ និងប្រព័ន្ធប្រតិបត្តិការនៅលើថ្នាំងចង្កោម។

ក្នុងន័យមួយ កុងតឺន័រពីរដែលមានកម្មវិធីពីរផ្សេងគ្នាដែលដំណើរការលើថ្នាំងដូចគ្នាគឺដូចជាដំណើរការពីរដែលដំណើរការលើម៉ាស៊ីនតែមួយដែលកំពុងដំណើរការខឺណែល OS ដូចគ្នា។

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

នេះអាចជាបញ្ហាសុវត្ថិភាព៖ ការរៀបចំនេះតាមទ្រឹស្តីអនុញ្ញាតឱ្យកម្មវិធីដែលមិនទាក់ទងគ្នាអាចទំនាក់ទំនងគ្នាទៅវិញទៅមក (ទាំងចេតនា ឬដោយចៃដន្យ)។

លើសពីនេះ បន្ទុកការងារទាំងអស់នៅក្នុងចង្កោម Kubernetes ចែករំលែកនូវសេវាកម្មទាំងមូលនៃចង្កោមមួយចំនួនដូចជា ឈ្មោះ DNS - វាអនុញ្ញាតឱ្យកម្មវិធីស្វែងរកសេវាកម្មនៃកម្មវិធីផ្សេងទៀតនៅក្នុងចង្កោម។

ចំណុចទាំងអស់ខាងលើអាចមានអត្ថន័យខុសៗគ្នា អាស្រ័យលើតម្រូវការសុវត្ថិភាពកម្មវិធី។

Kubernetes ផ្តល់ឧបករណ៍ជាច្រើនដើម្បីការពារបញ្ហាសុវត្ថិភាពដូចជា PodSecurityPolicies и គោលការណ៍បណ្តាញ. ទោះជាយ៉ាងណាក៏ដោយ ការដំឡើងពួកវាឱ្យបានត្រឹមត្រូវទាមទារបទពិសោធន៍ខ្លះ លើសពីនេះទៅទៀត ពួកគេមិនអាចបិទរន្ធសុវត្ថិភាពទាំងអស់បានទេ។

វាជារឿងសំខាន់ក្នុងការចងចាំជានិច្ចថា Kubernetes ត្រូវបានរចនាឡើងដំបូងសម្រាប់ ការចែករំលែកមិនមែនសម្រាប់ ភាពឯកោ និងសុវត្ថិភាព.

- កង្វះការជួលច្រើនយ៉ាងតឹងរឹង

ដោយសារធនធានចែករំលែកច្រើនក្រៃលែងនៅក្នុងចង្កោម Kubernetes មានវិធីជាច្រើនដែលកម្មវិធីផ្សេងៗអាចឈានទៅដល់ម្រាមជើងរបស់គ្នាទៅវិញទៅមក។

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

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

- ចំនួនអ្នកប្រើប្រាស់ច្រើន។

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

នៅក្នុងចង្កោម អ្នកអាចគ្រប់គ្រងថាអ្នកណាអាចធ្វើអ្វីដោយប្រើ ការគ្រប់គ្រងការចូលប្រើដោយផ្អែកលើតួនាទី (RBAC) (សូមមើលអត្ថបទ " អ្នកប្រើប្រាស់ និងការអនុញ្ញាត RBAC នៅក្នុង Kubernetes " - ប្រហែល។ បកប្រែ។ ). ទោះយ៉ាងណាក៏ដោយ វានឹងមិនរារាំងអ្នកប្រើប្រាស់ពីការ "បំបែក" អ្វីមួយនៅក្នុងតំបន់នៃការទទួលខុសត្រូវរបស់ពួកគេនោះទេ។

- ចង្កោមមិនអាចលូតលាស់ដោយគ្មានកំណត់

ចង្កោម​ដែល​ត្រូវ​បាន​ប្រើ​សម្រាប់​បន្ទុក​ការងារ​ទាំងអស់​ទំនង​ជា​ធំ​ណាស់ (បើ​គិត​តាម​ចំនួន​ថ្នាំង និង​ផត)។

ប៉ុន្តែនៅទីនេះបញ្ហាមួយទៀតកើតឡើង៖ ចង្កោមនៅក្នុង Kubernetes មិនអាចរីកចម្រើនដោយគ្មានកំណត់បានទេ។

មានដែនកំណត់ទ្រឹស្តីលើទំហំចង្កោម។ នៅក្នុង Kubernetes វាប្រហាក់ប្រហែល ថ្នាំង 5000, 150 ពាន់ pods និង 300 ពាន់ធុង.

ទោះយ៉ាងណាក៏ដោយនៅក្នុងជីវិតពិតបញ្ហាអាចចាប់ផ្តើមច្រើនមុន - ឧទាហរណ៍គ្រាន់តែជាមួយ 500 knots.

ការពិតគឺថាចង្កោមធំដាក់បន្ទុកខ្ពស់លើស្រទាប់គ្រប់គ្រង Kubernetes ។ ម្យ៉ាង​ទៀត ការ​រក្សា​ចង្កោម​ឱ្យ​ដំណើរការ​ឱ្យ​មាន​ប្រសិទ្ធភាព​តម្រូវ​ឱ្យ​មាន​ការ​សម្រួល​យ៉ាង​ប្រុង​ប្រយ័ត្ន។

បញ្ហា​នេះ​ត្រូវ​បាន​សិក្សា​នៅ​ក្នុង​អត្ថបទ​ទាក់​ទង​នៅ​លើ​ប្លក់​ដើម​ដែល​មាន​ឈ្មោះ​ថា "ការស្ថាបត្យកម្មក្រុម Kubernetes — ជ្រើសរើសទំហំថ្នាំងកម្មករ"។

ប៉ុន្តែសូមពិចារណាវិធីសាស្រ្តផ្ទុយគ្នា: ចង្កោមតូចៗជាច្រើន។

2. ចង្កោមឯកទេសតូចៗជាច្រើន។

ជាមួយនឹងវិធីសាស្រ្តនេះ អ្នកប្រើចង្កោមដាច់ដោយឡែកសម្រាប់ធាតុនីមួយៗដែលអ្នកដាក់ពង្រាយ៖

ចង្កោមតូចៗជាច្រើន។

សម្រាប់គោលបំណងនៃអត្ថបទនេះ, នៅក្រោម ធាតុដែលអាចប្រើបាន។ សំដៅទៅលើឧទាហរណ៍នៃកម្មវិធីមួយ - ឧទាហរណ៍ កំណែ dev នៃកម្មវិធីដាច់ដោយឡែកមួយ។

យុទ្ធសាស្ត្រនេះប្រើ Kubernetes ជាឯកទេស ពេលដំណើរការ សម្រាប់ឧទាហរណ៍កម្មវិធីបុគ្គល។

សូមក្រឡេកមើលគុណសម្បត្តិនិងគុណវិបត្តិនៃវិធីសាស្រ្តនេះ។

+ "កាំផ្ទុះ" មានកំណត់

នៅពេលដែលចង្កោមបរាជ័យ ផលវិបាកអវិជ្ជមានត្រូវបានកំណត់តែចំពោះបន្ទុកការងារទាំងនោះដែលត្រូវបានដាក់ពង្រាយនៅក្នុងចង្កោមនោះ។ បន្ទុកការងារផ្សេងទៀតទាំងអស់នៅតែមិនត្រូវបានប៉ះពាល់។

+ អ៊ីសូឡង់

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

លទ្ធផលគឺភាពឯកោតឹងតែងរវាងកម្មវិធីដែលមិនទាក់ទងគ្នា ដែលអាចមានប្រយោជន៍សម្រាប់សុវត្ថិភាពរបស់ពួកគេ។

+ ចំនួនអ្នកប្រើប្រាស់តិចតួច

ដោយសារចង្កោមនីមួយៗមានតែសំណុំនៃបន្ទុកការងារមានកំណត់ ចំនួនអ្នកប្រើប្រាស់ដែលមានសិទ្ធិចូលប្រើប្រាស់វាត្រូវបានកាត់បន្ថយ។

មនុស្សតិចជាងមុនមានសិទ្ធិចូលទៅកាន់ចង្កោម ហានិភ័យកាន់តែទាបដែលអ្វីមួយដែលនឹង "បំបែក" ។

តោះមើលគុណវិបត្តិ។

- ការប្រើប្រាស់ធនធានមិនមានប្រសិទ្ធភាព

ដូចដែលបានរៀបរាប់ខាងលើ ចង្កោម Kubernetes នីមួយៗទាមទារសំណុំជាក់លាក់នៃធនធានគ្រប់គ្រង៖ ថ្នាំងមេ សមាសធាតុស្រទាប់គ្រប់គ្រង ការត្រួតពិនិត្យ និងដំណោះស្រាយការកត់ត្រា។

ក្នុង​ករណី​នៃ​ក្រុម​តូច​ធំ​មួយ​ចំណែក​ធំ​នៃ​ធនធាន​ត្រូវ​តែ​ត្រូវ​បាន​បែងចែក​ទៅ​ឱ្យ​អ្នក​គ្រប់​គ្រង។

- ថ្លៃ

ការប្រើប្រាស់ធនធានគ្មានប្រសិទ្ធភាពធ្វើឱ្យការចំណាយខ្ពស់ដោយស្វ័យប្រវត្តិ។

ឧទាហរណ៍ ការរក្សាថ្នាំងមេចំនួន 30 ជំនួសឱ្យបីដែលមានថាមពលកុំព្យូទ័រដូចគ្នានឹងចាំបាច់ប៉ះពាល់ដល់ការចំណាយ។

- ភាពលំបាកក្នុងការគ្រប់គ្រង

ការគ្រប់គ្រងចង្កោម Kubernetes ច្រើនគឺពិបាកជាងការគ្រប់គ្រងតែមួយ។

ឧទាហរណ៍ អ្នកនឹងត្រូវកំណត់រចនាសម្ព័ន្ធការផ្ទៀងផ្ទាត់ និងការអនុញ្ញាតសម្រាប់ចង្កោមនីមួយៗ។ កំណែ Kubernetes ក៏នឹងត្រូវធ្វើបច្ចុប្បន្នភាពជាច្រើនដងផងដែរ។

អ្នកទំនងជាត្រូវប្រើស្វ័យប្រវត្តិកម្ម ដើម្បីធ្វើឱ្យកិច្ចការទាំងអស់នេះកាន់តែមានប្រសិទ្ធភាព។

ឥឡូវនេះ សូមក្រឡេកមើលសេណារីយ៉ូតិចបំផុត

3. ចង្កោមមួយក្នុងមួយកម្មវិធី

នៅក្នុងវិធីសាស្រ្តនេះ អ្នកបង្កើតចង្កោមដាច់ដោយឡែកសម្រាប់គ្រប់ករណីនៃកម្មវិធីជាក់លាក់មួយ៖

ចង្កោមក្នុងមួយកម្មវិធី

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

សូមក្រឡេកមើលគុណសម្បត្តិនិងគុណវិបត្តិនៃវិធីសាស្រ្តនេះ។

+ ចង្កោមអាចត្រូវបានលៃតម្រូវទៅនឹងកម្មវិធី

ប្រសិនបើកម្មវិធីមានតម្រូវការពិសេស ពួកគេអាចត្រូវបានអនុវត្តនៅក្នុងចង្កោមដោយមិនប៉ះពាល់ដល់ចង្កោមផ្សេងទៀត។

តម្រូវការបែបនេះអាចរួមបញ្ចូលបុគ្គលិក GPU, កម្មវិធីជំនួយ CNI ជាក់លាក់, សំណាញ់សេវា ឬសេវាកម្មមួយចំនួនផ្សេងទៀត។

ចង្កោមនីមួយៗអាចត្រូវបានកែសម្រួលទៅតាមកម្មវិធីដែលកំពុងដំណើរការនៅក្នុងវា ដូច្នេះវាមានតែអ្វីដែលត្រូវការប៉ុណ្ណោះ។

- បរិស្ថានផ្សេងគ្នានៅក្នុងចង្កោមមួយ។

គុណវិបត្តិនៃវិធីសាស្រ្តនេះគឺថាកម្មវិធីពីបរិស្ថានផ្សេងៗគ្នាមាននៅក្នុងចង្កោមតែមួយ។

ឧទាហរណ៍ កំណែ prod នៃកម្មវិធីដំណើរការក្នុងចង្កោមដូចគ្នានឹងកំណែ dev ។ នេះក៏មានន័យថាអ្នកអភិវឌ្ឍន៍ដំណើរការនៅក្នុងចង្កោមដូចគ្នាដែលកំណែផលិតកម្មនៃកម្មវិធីត្រូវបានដំណើរការ។

ប្រសិនបើដោយសារតែសកម្មភាពរបស់អ្នកអភិវឌ្ឍន៍ ឬភាពមិនប្រក្រតីនៅក្នុងកំណែ dev ការបរាជ័យកើតឡើងនៅក្នុងចង្កោម នោះកំណែផលិតផលក៏អាចរងទុក្ខផងដែរ - គុណវិបត្តិដ៏ធំនៃវិធីសាស្រ្តនេះ។

ហើយចុងក្រោយ សេណារីយ៉ូចុងក្រោយនៅក្នុងបញ្ជីរបស់យើង។

4. ចង្កោមមួយក្នុងមួយបរិស្ថាន

សេណារីយ៉ូនេះពាក់ព័ន្ធនឹងការបែងចែកចង្កោមដាច់ដោយឡែកសម្រាប់បរិស្ថាននីមួយៗ៖

មួយចង្កោមក្នុងមួយបរិស្ថាន

ឧទាហរណ៍ អ្នកអាចមានចង្កោម dev, ការធ្វើតេស្ត и ផលិតផលដែលអ្នកនឹងដំណើរការគ្រប់ករណីនៃកម្មវិធីដែលឧទ្ទិសដល់បរិស្ថានជាក់លាក់មួយ។

នេះគឺជាគុណសម្បត្តិ និងគុណវិបត្តិនៃវិធីសាស្រ្តនេះ។

+ ភាពឯកោនៃបរិស្ថានផលិតផល

នៅក្នុងវិធីសាស្រ្តនេះ បរិស្ថានទាំងអស់គឺដាច់ឆ្ងាយពីគ្នាទៅវិញទៅមក។ ទោះជាយ៉ាងណាក៏ដោយនៅក្នុងការអនុវត្តនេះមានសារៈសំខាន់ជាពិសេសនៅក្នុងបរិយាកាសផលិតផល។

កំណែផលិតកម្មនៃកម្មវិធីឥឡូវនេះគឺឯករាជ្យពីអ្វីដែលកំពុងកើតឡើងនៅក្នុងក្រុម និងបរិស្ថានផ្សេងទៀត។

វិធីនេះ ប្រសិនបើបញ្ហាកើតឡើងភ្លាមៗនៅក្នុងចង្កោមអ្នកអភិវឌ្ឍន៍ នោះកំណែផលិតផលនៃកម្មវិធីនឹងបន្តដំណើរការដូចជាមិនមានអ្វីកើតឡើង។

+ ចង្កោមអាចត្រូវបានលៃតម្រូវទៅនឹងបរិស្ថាន

ចង្កោមនីមួយៗអាចត្រូវបានកែតម្រូវទៅតាមបរិយាកាសរបស់វា។ ឧទាហរណ៍ អ្នកអាច៖

• ដំឡើងឧបករណ៍សម្រាប់ការអភិវឌ្ឍន៍ និងការបំបាត់កំហុសនៅក្នុងក្រុមអ្នកអភិវឌ្ឍន៍។
• ដំឡើងក្របខ័ណ្ឌសាកល្បង និងឧបករណ៍នៅក្នុងចង្កោម ការធ្វើតេស្ត;
• ប្រើផ្នែករឹង និងបណ្តាញបណ្តាញដែលមានថាមពលខ្លាំងជាងនៅក្នុងចង្កោម ផលិតផល.

នេះអនុញ្ញាតឱ្យអ្នកបង្កើនប្រសិទ្ធភាពទាំងការអភិវឌ្ឍន៍កម្មវិធី និងប្រតិបត្តិការ។

+ ដាក់កម្រិតការចូលប្រើចង្កោមផលិតកម្ម

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

អ្នក​អាច​ទៅ​បន្ថែម​ទៀត ហើយ​បដិសេធ​មនុស្ស​ចូល​ប្រើ​ចង្កោម​នេះ​ទាំង​អស់ ហើយ​អនុវត្ត​ការ​ដាក់​ពង្រាយ​ទាំងអស់​ដោយ​ប្រើ​ឧបករណ៍ CI/CD ស្វ័យប្រវត្តិ។ វិធីសាស្រ្តបែបនេះនឹងកាត់បន្ថយហានិភ័យនៃកំហុសរបស់មនុស្សឱ្យតិចបំផុតនៅកន្លែងដែលវាពាក់ព័ន្ធបំផុត។

ហើយឥឡូវនេះពាក្យពីរបីអំពីគុណវិបត្តិ។

- គ្មានភាពឯកោរវាងកម្មវិធី

គុណវិបត្តិចម្បងនៃវិធីសាស្រ្តគឺការខ្វះខាតផ្នែករឹង និងធនធានដាច់ដោយឡែករវាងកម្មវិធី។

កម្មវិធីដែលមិនពាក់ព័ន្ធចែករំលែកធនធានចង្កោម៖ ស្នូលប្រព័ន្ធ ខួរក្បាល អង្គចងចាំ និងសេវាកម្មមួយចំនួនទៀត។

ដូចដែលបានរៀបរាប់ នេះអាចមានគ្រោះថ្នាក់។

- អសមត្ថភាពក្នុងការធ្វើមូលដ្ឋានីយកម្មភាពអាស្រ័យកម្មវិធី

ប្រសិនបើកម្មវិធីមានតម្រូវការពិសេស នោះពួកគេត្រូវតែពេញចិត្តនៅទូទាំងចង្កោមទាំងអស់។

ឧទាហរណ៍ ប្រសិនបើកម្មវិធីទាមទារ GPU នោះចង្កោមនីមួយៗត្រូវតែមានយ៉ាងហោចណាស់បុគ្គលិកម្នាក់ដែលមាន GPU (ទោះបីជាវាត្រូវបានប្រើតែដោយកម្មវិធីនោះក៏ដោយ)។

ជាលទ្ធផល យើងប្រថុយនឹងការចំណាយខ្ពស់ និងការប្រើប្រាស់ធនធានគ្មានប្រសិទ្ធភាព។

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

ប្រសិនបើអ្នកមានសំណុំជាក់លាក់នៃកម្មវិធី ពួកគេអាចត្រូវបានដាក់ក្នុងចង្កោមធំជាច្រើន ឬកម្មវិធីតូចៗជាច្រើន។

អត្ថបទពិភាក្សាអំពីគុណសម្បត្តិ និងគុណវិបត្តិនៃវិធីសាស្រ្តផ្សេងៗ រាប់ចាប់ពីចង្កោមសកលមួយទៅផ្នែកតូចៗ និងឯកទេសខ្ពស់មួយចំនួន៖

• ចង្កោមទូទៅធំមួយ;
• ចង្កោមឯកទេសខ្ពស់តូចៗជាច្រើន;
• មួយក្រុមក្នុងមួយកម្មវិធី;
• មួយចង្កោមក្នុងមួយបរិស្ថាន។

ដូច្នេះ​តើ​អ្នក​គួរ​អនុវត្ត​វិធី​មួយ​ណា?

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

ទោះជាយ៉ាងណាក៏ដោយជម្រើសមិនត្រូវបានកំណត់ចំពោះឧទាហរណ៍ខាងលើទេ - អ្នកអាចប្រើបន្សំណាមួយនៃពួកវា!

ឧទាហរណ៍ អ្នកអាចរៀបចំចង្កោមពីរបីសម្រាប់ក្រុមនីមួយៗ៖ ចង្កោមអភិវឌ្ឍន៍ (ដែលនឹងមានបរិស្ថាន dev и ការធ្វើតេស្ត) និងចង្កោមសម្រាប់ ផលិតកម្ម (កន្លែងដែលបរិយាកាសផលិតកម្មនឹងស្ថិតនៅ) ។

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

PS

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

• «មគ្គុទ្ទេសក៍ដែលមើលឃើញសម្រាប់ការដោះស្រាយបញ្ហា Kubernetes»
• «ចូល Kubernetes (មិនត្រឹមតែប៉ុណ្ណោះ) ថ្ងៃនេះ៖ ការរំពឹងទុក និងការពិត»
• «Service Mesh: អ្វីដែលវិស្វករកម្មវិធីគ្រប់រូបត្រូវដឹងអំពីបច្ចេកវិទ្យាដ៏ពេញនិយមបំផុត។»
• «ABC នៃសន្តិសុខនៅក្នុង Kubernetes: ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ ការអនុញ្ញាត សវនកម្ម"។

ប្រភព: www.habr.com