គូប-on-cube, metaclusters, Honeycombs, ការចែកចាយធនធាន

អង្ករ។ 1. ប្រព័ន្ធអេកូ Kubernetes នៅលើ Alibaba Cloud

ចាប់តាំងពីឆ្នាំ 2015 មក Alibaba Cloud Container Service for Kubernetes (ACK) គឺជាសេវាកម្មពពកដែលរីកលូតលាស់លឿនបំផុតនៅក្នុង Alibaba Cloud ។ វាបម្រើអតិថិជនជាច្រើន ហើយក៏គាំទ្រហេដ្ឋារចនាសម្ព័ន្ធផ្ទៃក្នុងរបស់ក្រុមហ៊ុន Alibaba និងសេវាកម្ម Cloud ផ្សេងទៀតរបស់ក្រុមហ៊ុនផងដែរ។

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

នៅក្នុងអត្ថបទនេះ យើងនឹងចែករំលែកបទពិសោធន៍របស់យើងក្នុងការគ្រប់គ្រងចង្កោម Kubernetes មួយចំនួនធំនៅលើហេដ្ឋារចនាសម្ព័ន្ធពពក ក៏ដូចជាស្ថាបត្យកម្មនៃវេទិកាមូលដ្ឋាន។

ធាតុ

Kubernetes បានក្លាយជាស្តង់ដារជាក់ស្តែងសម្រាប់បន្ទុកការងារជាច្រើននៅក្នុងពពក។ ដូចដែលបានបង្ហាញនៅក្នុងរូបភព។ 1 ខាងលើ កម្មវិធី Alibaba Cloud កាន់តែច្រើនឡើងៗឥឡូវនេះកំពុងដំណើរការនៅលើចង្កោម Kubernetes៖ កម្មវិធីគ្មានរដ្ឋ និងគ្មានរដ្ឋ ក៏ដូចជាអ្នកគ្រប់គ្រងកម្មវិធីផងដែរ។ ការគ្រប់គ្រង Kubernetes តែងតែជាប្រធានបទដ៏គួរឱ្យចាប់អារម្មណ៍ និងសំខាន់នៃការពិភាក្សាសម្រាប់វិស្វករដែលសាងសង់ និងថែទាំហេដ្ឋារចនាសម្ព័ន្ធ។ នៅពេលដែលវាមកដល់ក្រុមហ៊ុនផ្តល់សេវាពពកដូចជា Alibaba Cloud បញ្ហានៃការធ្វើមាត្រដ្ឋានកើតឡើង។ តើធ្វើដូចម្តេចដើម្បីគ្រប់គ្រងក្រុម Kubernetes នៅមាត្រដ្ឋាននេះ? យើងបានគ្របដណ្តប់លើការអនុវត្តល្អបំផុតសម្រាប់ការគ្រប់គ្រងចង្កោម Kubernetes ដ៏ធំចំនួន 10 ។ ជាការពិតណាស់នេះគឺជាបញ្ហាមាត្រដ្ឋានគួរឱ្យចាប់អារម្មណ៍។ ប៉ុន្តែមានមាត្រដ្ឋានមួយទៀត៖ បរិមាណ ចង្កោមខ្លួនឯង.

យើងបានពិភាក្សាប្រធានបទនេះជាមួយអ្នកប្រើប្រាស់ ACK ជាច្រើន។ ពួកគេភាគច្រើនជ្រើសរើសដំណើរការរាប់សិប ប្រសិនបើមិនមែនរាប់រយ នៃចង្កោម Kubernetes តូច ឬមធ្យម។ មានហេតុផលល្អសម្រាប់រឿងនេះ៖ ការកំណត់ការខូចខាតដែលអាចកើតមាន ការបំបែកចង្កោមសម្រាប់ក្រុមផ្សេងៗ ការបង្កើតចង្កោមនិម្មិតសម្រាប់ការធ្វើតេស្ត។ ប្រសិនបើ ACK មានបំណងបម្រើទស្សនិកជនជាសាកលជាមួយនឹងគំរូនៃការប្រើប្រាស់នេះ វាត្រូវតែអាចទុកចិត្តបាន និងប្រកបដោយប្រសិទ្ធភាពក្នុងការគ្រប់គ្រងក្រុមមួយចំនួនធំនៅទូទាំងតំបន់ជាង 20 ។

អង្ករ។ 2. បញ្ហានៃការគ្រប់គ្រងក្រុម Kubernetes មួយចំនួនធំ

តើអ្វីជាបញ្ហាប្រឈមចម្បងនៃការគ្រប់គ្រងចង្កោមក្នុងមាត្រដ្ឋាននេះ? ដូចដែលបានបង្ហាញក្នុងរូប មានបញ្ហាបួនដែលត្រូវដោះស្រាយ៖

• តំណពូជ

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

• ទំហំចង្កោមផ្សេងៗគ្នា

ចង្កោម​មាន​ទំហំ​ខុស​គ្នា ចាប់​ពី​ថ្នាំង​ពីរ​បី​គ្រាប់​ដល់​រាប់​ម៉ឺន​ថ្នាំង​ដែល​មាន​ផត​រាប់ពាន់។ តម្រូវការធនធានក៏ប្រែប្រួលយ៉ាងខ្លាំងផងដែរ។ ការបែងចែកធនធានមិនត្រឹមត្រូវអាចប៉ះពាល់ដល់ការអនុវត្ត ឬអាចបណ្តាលឱ្យបរាជ័យ។

• កំណែផ្សេងគ្នា

Kubernetes កំពុងវិវត្តយ៉ាងលឿន។ កំណែថ្មីត្រូវបានចេញផ្សាយរៀងរាល់ពីរបីខែម្តង។ អតិថិជនតែងតែមានឆន្ទៈក្នុងការសាកល្បងមុខងារថ្មីៗ។ ដូច្នេះពួកគេចង់ដាក់បន្ទុកសាកល្បងលើកំណែថ្មីរបស់ Kubernetes និងការផ្ទុកផលិតកម្មនៅលើស្ថេរភាព។ ដើម្បីបំពេញតាមតម្រូវការនេះ ACK ត្រូវតែបន្តផ្តល់កំណែថ្មីរបស់ Kubernetes ដល់អតិថិជន ខណៈពេលដែលរក្សាបាននូវកំណែដែលមានស្ថេរភាព។

• ការអនុលោមតាមសុវត្ថិភាព

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

វេទិកា ACK ត្រូវបានរចនាឡើងដើម្បីដោះស្រាយបញ្ហាភាគច្រើនខាងលើ។ បច្ចុប្បន្ន​វា​អាច​ទុក​ចិត្ត​បាន និង​មាន​ស្ថិរភាព​គ្រប់គ្រង​ក្រុម Kubernetes ជាង 10 ពាន់​ជុំវិញ​ពិភពលោក។ សូមក្រឡេកមើលពីរបៀបដែលវាត្រូវបានសម្រេច រួមទាំងតាមរយៈគោលការណ៍រចនា/ស្ថាបត្យកម្មសំខាន់ៗមួយចំនួន។

ការរចនា

គូបនៅលើគូបនិង Honeycomb

មិនដូចឋានានុក្រមមជ្ឈិមទេ ស្ថាបត្យកម្មដែលមានមូលដ្ឋានលើក្រឡាជាធម្មតាត្រូវបានប្រើដើម្បីពង្រីកវេទិកាលើសពីមជ្ឈមណ្ឌលទិន្នន័យតែមួយ ឬពង្រីកវិសាលភាពនៃការសង្គ្រោះគ្រោះមហន្តរាយ។

តំបន់នីមួយៗនៅក្នុង Alibaba Cloud មានតំបន់ជាច្រើន (AZ) ហើយជាធម្មតាត្រូវគ្នាទៅនឹងមជ្ឈមណ្ឌលទិន្នន័យជាក់លាក់មួយ។ នៅក្នុងតំបន់ធំមួយ (ឧ. Huangzhou) ជាញឹកញាប់មានចង្កោមអតិថិជន Kubernetes រាប់ពាន់ដែលកំពុងដំណើរការ ACK ។

ACK គ្រប់គ្រងចង្កោម Kubernetes ទាំងនេះដោយប្រើ Kubernetes ខ្លួនវា មានន័យថាយើងមាន Metacluster Kubernetes ដែលដំណើរការដើម្បីគ្រប់គ្រងចង្កោម Kubernetes អតិថិជន។ ស្ថាបត្យកម្មនេះត្រូវបានគេហៅថា "kube-on-kube" (KoK) ផងដែរ។ ស្ថាបត្យកម្ម KoK សម្រួលការគ្រប់គ្រងក្រុមអតិថិជន ពីព្រោះការដាក់ពង្រាយចង្កោមគឺសាមញ្ញ និងកំណត់។ សំខាន់ជាងនេះទៅទៀត យើងអាចប្រើមុខងារ Kubernetes ដើមឡើងវិញបាន។ ឧទាហរណ៍ ការគ្រប់គ្រងម៉ាស៊ីនមេ API តាមរយៈការដាក់ឱ្យប្រើប្រាស់ ដោយប្រើប្រតិបត្តិករ etcd ដើម្បីគ្រប់គ្រង etcds ច្រើន។ ការហៅឡើងវិញបែបនេះតែងតែនាំមកនូវសេចក្តីរីករាយពិសេស។

Kubernetes metaclusters ជាច្រើនត្រូវបានដាក់ពង្រាយនៅក្នុងតំបន់មួយ អាស្រ័យលើចំនួនអតិថិជន។ យើងហៅកោសិកាមេតាគ្លីសទាំងនេះ។ ដើម្បីការពារប្រឆាំងនឹងការបរាជ័យនៃតំបន់ទាំងមូល ACK គាំទ្រការដាក់ឱ្យប្រើប្រាស់ច្រើនសកម្មនៅក្នុងតំបន់តែមួយ៖ metacluster ចែកចាយសមាសធាតុមេនៃចង្កោមអតិថិជន Kubernetes នៅទូទាំងតំបន់ជាច្រើន ហើយដំណើរការពួកវាក្នុងពេលដំណាលគ្នា ពោលគឺនៅក្នុងរបៀបពហុសកម្ម។ ដើម្បីធានាបាននូវភាពជឿជាក់ និងប្រសិទ្ធភាពរបស់មេ ACK បង្កើនប្រសិទ្ធភាពការដាក់សមាសធាតុ និងធានាថាម៉ាស៊ីនមេ API និង etcd នៅជិតគ្នាទៅវិញទៅមក។

គំរូនេះអនុញ្ញាតឱ្យអ្នកគ្រប់គ្រង Kubernetes ប្រកបដោយប្រសិទ្ធភាព បត់បែន និងអាចទុកចិត្តបាន។

ការធ្វើផែនការធនធាន metacluster

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

ជាឧទាហរណ៍ ចូរយើងយកធនធានបណ្តាញ។ នៅក្នុងស្ថាបត្យកម្ម KoK សមាសធាតុ Kubernetes ពីក្រុមអតិថិជនត្រូវបានដាក់ពង្រាយជាផតនៅក្នុង metacluster ។ យើង​ប្រើ Terway (រូបទី 3) គឺជាកម្មវិធីជំនួយដែលមានប្រសិទ្ធភាពខ្ពស់ដែលត្រូវបានបង្កើតឡើងដោយ Alibaba Cloud សម្រាប់ការគ្រប់គ្រងបណ្តាញកុងតឺន័រ។ វាផ្តល់នូវសំណុំនៃគោលការណ៍សុវត្ថិភាពដ៏សម្បូរបែប និងអនុញ្ញាតឱ្យអ្នកភ្ជាប់ទៅពពកឯកជននិម្មិត (VPCs) របស់អតិថិជនតាមរយៈ Alibaba Cloud Elastic Networking Interface (ENI)។ ដើម្បីចែកចាយធនធានបណ្តាញប្រកបដោយប្រសិទ្ធភាពលើថ្នាំង ផត និងសេវាកម្មនៅក្នុង metacluster យើងត្រូវតាមដានការប្រើប្រាស់របស់ពួកគេដោយប្រុងប្រយ័ត្ននៅក្នុង metacluster នៃពពកឯកជននិម្មិត។ នៅពេលដែលធនធានបណ្តាញមកដល់ទីបញ្ចប់ ក្រឡាថ្មីមួយត្រូវបានបង្កើត។

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

អង្ករ។ 3. ស្ថាបត្យកម្មបណ្តាញ Terway

ធ្វើមាត្រដ្ឋានសមាសធាតុអ្នកជំនួយការនៅទូទាំងចង្កោមអតិថិជន

សមាសធាតុអ្នកជំនួយការមានតម្រូវការធនធានខុសៗគ្នា។ ពួកវាអាស្រ័យលើចំនួនថ្នាំង និងផតនៅក្នុងចង្កោម ចំនួនឧបករណ៍បញ្ជា/ប្រតិបត្តិករមិនស្តង់ដារដែលធ្វើអន្តរកម្មជាមួយ APIServer ។

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

ដើម្បីស្វែងរកការដោះដូរបន្តិចបន្តួចរវាងភាពអាចជឿជាក់បាន និងការចំណាយ ACK ប្រើប្រព័ន្ធប្រភេទមួយ។ មានន័យថា យើងកំណត់ចង្កោមបីប្រភេទ៖ តូច មធ្យម និងធំ។ ប្រភេទនីមួយៗមានទម្រង់បែងចែកធនធានដាច់ដោយឡែក។ ប្រភេទត្រូវបានកំណត់ដោយផ្អែកលើបន្ទុកនៃសមាសធាតុអ្នកជំនួយការ ចំនួនថ្នាំង និងកត្តាផ្សេងៗទៀត។ ប្រភេទចង្កោមអាចផ្លាស់ប្តូរតាមពេលវេលា។ ACK បន្តតាមដានកត្តាទាំងនេះ ហើយអាចឡើង/ចុះប្រភេទទៅតាមនោះ។ នៅពេលដែលប្រភេទចង្កោមត្រូវបានផ្លាស់ប្តូរ ការបែងចែកធនធានត្រូវបានធ្វើបច្ចុប្បន្នភាពដោយស្វ័យប្រវត្តិជាមួយនឹងអន្តរាគមន៍អ្នកប្រើប្រាស់តិចតួចបំផុត។

យើងកំពុងធ្វើការដើម្បីកែលម្អប្រព័ន្ធនេះជាមួយនឹងការធ្វើមាត្រដ្ឋានដែលមានលក្ខណៈល្អិតល្អន់ និងការធ្វើបច្ចុប្បន្នភាពប្រភេទច្បាស់លាស់ជាងមុន ដើម្បីឱ្យការផ្លាស់ប្តូរទាំងនេះកើតឡើងកាន់តែរលូន និងធ្វើឱ្យមានអត្ថន័យសេដ្ឋកិច្ចកាន់តែច្រើន។

អង្ករ។ 4. ការប្តូរប្រភេទពហុដំណាក់កាលឆ្លាតវៃ

ការវិវត្តន៍នៃក្រុមអតិថិជនតាមមាត្រដ្ឋាន

ផ្នែកមុនបានគ្របដណ្តប់ទិដ្ឋភាពមួយចំនួននៃការគ្រប់គ្រងក្រុម Kubernetes មួយចំនួនធំ។ ទោះយ៉ាងណាក៏ដោយ មានបញ្ហាមួយទៀតដែលត្រូវដោះស្រាយ៖ ការវិវត្តន៍នៃចង្កោម។

Kubernetes គឺជា "លីនុច" នៃពិភពពពក។ វាត្រូវបានអាប់ដេតជាបន្តបន្ទាប់ ហើយក្លាយជាម៉ូឌុលកាន់តែច្រើន យើងត្រូវតែផ្តល់កំណែថ្មីឥតឈប់ឈរដល់អតិថិជនរបស់យើង ជួសជុលភាពងាយរងគ្រោះ និងធ្វើបច្ចុប្បន្នភាពចង្កោមដែលមានស្រាប់ ក៏ដូចជាគ្រប់គ្រងផ្នែកពាក់ព័ន្ធមួយចំនួនធំ (CSI, CNI, Device Plugin, Scheduler Plugin និងជាច្រើនទៀត)។

តោះយកការគ្រប់គ្រងសមាសធាតុ Kubernetes ជាឧទាហរណ៍។ ដើម្បីចាប់ផ្តើមជាមួយ យើងបានបង្កើតប្រព័ន្ធមជ្ឈិមមួយសម្រាប់ការចុះឈ្មោះ និងគ្រប់គ្រងសមាសធាតុដែលបានតភ្ជាប់ទាំងអស់នេះ។

អង្ករ។ 5. សមាសធាតុដែលអាចបត់បែនបាន និងអាចដោតបាន។

មុននឹងឈានទៅមុខ អ្នកត្រូវប្រាកដថាការអាប់ដេតបានជោគជ័យ។ ដើម្បីធ្វើដូចនេះយើងបានបង្កើតប្រព័ន្ធសម្រាប់ពិនិត្យមើលមុខងារនៃសមាសធាតុ។ ការត្រួតពិនិត្យត្រូវបានអនុវត្តមុន និងក្រោយពេលធ្វើបច្ចុប្បន្នភាព។

អង្ករ។ 6. ការត្រួតពិនិត្យបឋមនៃសមាសធាតុចង្កោម

ដើម្បីធ្វើបច្ចុប្បន្នភាពសមាសធាតុទាំងនេះយ៉ាងឆាប់រហ័ស និងគួរឱ្យទុកចិត្ត ប្រព័ន្ធដាក់ពង្រាយបន្តដំណើរការដោយមានការគាំទ្រសម្រាប់ការរីកចម្រើនផ្នែក (មាត្រដ្ឋានប្រផេះ) ការផ្អាក និងមុខងារផ្សេងទៀត។ ឧបករណ៍បញ្ជា Kubernetes ស្តង់ដារមិនសមល្អសម្រាប់ករណីប្រើប្រាស់នេះទេ។ ដូច្នេះ ដើម្បីគ្រប់គ្រងសមាសធាតុចង្កោម យើងបានបង្កើតសំណុំឧបករណ៍បញ្ជាឯកទេស រួមទាំងកម្មវិធីជំនួយ និងម៉ូឌុលត្រួតពិនិត្យជំនួយ (ការគ្រប់គ្រងចំហៀង)។

ឧទាហរណ៍ ឧបករណ៍បញ្ជា BroadcastJob ត្រូវបានរចនាឡើងដើម្បីធ្វើបច្ចុប្បន្នភាពសមាសធាតុនៅលើម៉ាស៊ីនកម្មករនីមួយៗ ឬពិនិត្យថ្នាំងនៅលើម៉ាស៊ីននីមួយៗ។ ការងារ Broadcast ដំណើរការ pod នៅលើ node នីមួយៗក្នុង cluster ដូចជា DaemonSet។ ទោះយ៉ាងណាក៏ដោយ DaemonSet តែងតែរក្សា pod ដំណើរការបានយូរ ខណៈពេលដែល BroadcastJob ដួលរលំវា។ ឧបករណ៍បញ្ជា Broadcast ក៏បើកដំណើរការ pods នៅលើថ្នាំងដែលបានភ្ជាប់ថ្មី និងចាប់ផ្តើមថ្នាំងជាមួយនឹងសមាសធាតុចាំបាច់។ នៅខែមិថុនា ឆ្នាំ 2019 យើងបានបើកកូដប្រភពនៃម៉ាស៊ីនស្វ័យប្រវត្តិ OpenKruise ដែលខ្លួនយើងប្រើប្រាស់នៅក្នុងក្រុមហ៊ុន។

អង្ករ។ 7. OpenKurise រៀបចំការប្រតិបត្តិភារកិច្ច Broadcast នៅលើថ្នាំងទាំងអស់។

ដើម្បីជួយអតិថិជនជ្រើសរើសការកំណត់រចនាសម្ព័ន្ធចង្កោមត្រឹមត្រូវ យើងក៏ផ្តល់នូវសំណុំនៃទម្រង់ដែលបានកំណត់ជាមុន រួមទាំងទម្រង់ Serverless, Edge, Windows និង Bare Metal ផងដែរ។ នៅពេលដែលទេសភាពពង្រីក ហើយតម្រូវការរបស់អតិថិជនយើងកើនឡើង យើងនឹងបន្ថែមទម្រង់បន្ថែមទៀត ដើម្បីសម្រួលដំណើរការរៀបចំដ៏ធុញទ្រាន់។

អង្ករ។ 8. ទម្រង់ចង្កោមកម្រិតខ្ពស់ និងអាចបត់បែនបានសម្រាប់សេណារីយ៉ូផ្សេងៗ

ការសង្កេតជាសកលនៅទូទាំងមជ្ឈមណ្ឌលទិន្នន័យ

ដូចបានបង្ហាញក្នុងរូបខាងក្រោម។ 9, សេវាពពក Alibaba Cloud Container ត្រូវបានដាក់ពង្រាយនៅក្នុងតំបន់ចំនួនម្ភៃជុំវិញពិភពលោក។ ដោយបានផ្ដល់ឱ្យនូវមាត្រដ្ឋាននេះ គោលដៅសំខាន់មួយនៃ ACK គឺដើម្បីត្រួតពិនិត្យស្ថានភាពនៃក្រុមដែលកំពុងដំណើរការយ៉ាងងាយស្រួល ដូច្នេះប្រសិនបើក្រុមអតិថិជនជួបប្រទះបញ្ហា យើងអាចឆ្លើយតបយ៉ាងរហ័សទៅនឹងស្ថានភាព។ ម្យ៉ាងវិញទៀត អ្នកត្រូវបង្កើតដំណោះស្រាយដែលនឹងអនុញ្ញាតឱ្យអ្នកប្រមូលស្ថិតិប្រកបដោយប្រសិទ្ធភាព និងសុវត្ថិភាពក្នុងពេលវេលាជាក់ស្តែងពីក្រុមអតិថិជននៅគ្រប់តំបន់ទាំងអស់ ហើយបង្ហាញលទ្ធផលដោយមើលឃើញ។

អង្ករ។ 9. ការដាក់ពង្រាយសេវាកម្ម Alibaba Cloud Container ជាសកលនៅក្នុងតំបន់ចំនួនម្ភៃ

ដូចប្រព័ន្ធត្រួតពិនិត្យ Kubernetes ជាច្រើនដែរ យើងប្រើ Prometheus ជាឧបករណ៍ចម្បងរបស់យើង។ សម្រាប់ metacluster នីមួយៗ ភ្នាក់ងារ Prometheus ប្រមូលរង្វាស់ដូចខាងក្រោម៖

• រង្វាស់ប្រព័ន្ធប្រតិបត្តិការ ដូចជាធនធានម៉ាស៊ីន (ស៊ីភីយូ អង្គចងចាំ ថាស។ល។) និងកម្រិតបញ្ជូនបណ្តាញ។
• ម៉ែត្រសម្រាប់ប្រព័ន្ធគ្រប់គ្រង metacluster និង client cluster ដូចជា kube-apiserver, kube-controller-manager និង kube-scheduler ។
• ម៉ែត្រពី kubernetes-state-metrics និង cadvisor ។
• etcd metrics ដូចជា disk write time, database size, throughput of connection between nodes ជាដើម។

ស្ថិតិសកលត្រូវបានប្រមូលដោយប្រើគំរូនៃការប្រមូលផ្តុំពហុស្រទាប់ធម្មតា។ ការត្រួតពិនិត្យទិន្នន័យពី metacluster នីមួយៗត្រូវបានប្រមូលផ្តុំជាលើកដំបូងនៅក្នុងតំបន់នីមួយៗ ហើយបន្ទាប់មកផ្ញើទៅកាន់ម៉ាស៊ីនមេកណ្តាលដែលបង្ហាញរូបភាពទាំងមូល។ អ្វីគ្រប់យ៉ាងដំណើរការតាមរយៈយន្តការសហព័ន្ធ។ ម៉ាស៊ីនមេ Prometheus នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យនីមួយៗប្រមូលម៉ែត្រពីមជ្ឈមណ្ឌលទិន្នន័យនោះ ហើយម៉ាស៊ីនមេ Prometheus កណ្តាលទទួលខុសត្រូវចំពោះការប្រមូលផ្តុំទិន្នន័យត្រួតពិនិត្យ។ AlertManager ភ្ជាប់ទៅកណ្តាល Prometheus ហើយប្រសិនបើចាំបាច់ ផ្ញើការដាស់តឿនតាមរយៈ DingTalk, email, SMS, etc. Visualization - using Grafana.

នៅក្នុងរូបភាពទី 10 ប្រព័ន្ធត្រួតពិនិត្យអាចបែងចែកជាបីកម្រិត៖

• កម្រិតព្រំដែន

ស្រទាប់នៅឆ្ងាយបំផុតពីកណ្តាល។ ម៉ាស៊ីនមេ Prometheus Edge ដំណើរការនៅក្នុង metacluster នីមួយៗ ដោយប្រមូលម៉ែត្រពី meta និង client clusters នៅក្នុងដែនបណ្តាញតែមួយ។

• កម្រិតល្បាក់

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

• កម្រិតកណ្តាល

ម៉ាស៊ីនមេ Prometheus កណ្តាលភ្ជាប់ទៅម៉ាស៊ីនមេល្បាក់ទាំងអស់ និងអនុវត្តការប្រមូលផ្តុំទិន្នន័យចុងក្រោយ។ សម្រាប់ភាពអាចជឿជាក់បាន អាំងតង់ស៊ីតេ Prometheus កណ្តាលពីរត្រូវបានលើកឡើងនៅក្នុងតំបន់ផ្សេងៗគ្នា ដោយភ្ជាប់ទៅម៉ាស៊ីនមេល្បាក់ដូចគ្នា។

អង្ករ។ 10. ស្ថាបត្យកម្មត្រួតពិនិត្យពហុកម្រិតសកលដោយផ្អែកលើយន្តការសហព័ន្ធ Prometheus

សង្ខេប

ដំណោះស្រាយពពកដែលមានមូលដ្ឋានលើ Kubernetes បន្តផ្លាស់ប្តូរឧស្សាហកម្មរបស់យើង។ សេវាកម្មធុងផ្ទុក Alibaba Cloud ផ្តល់នូវការបង្ហោះប្រកបដោយសុវត្ថិភាព គួរឱ្យទុកចិត្ត និងដំណើរការខ្ពស់ - វាគឺជាការបង្ហោះពពក Kubernetes ដ៏ល្អបំផុតមួយ។ ក្រុមការងារ Alibaba Cloud ជឿជាក់យ៉ាងមុតមាំលើគោលការណ៍នៃ Open Source និងសហគមន៍ប្រភពបើកចំហ។ យើងពិតជានឹងបន្តចែករំលែកចំណេះដឹងរបស់យើងក្នុងវិស័យប្រតិបត្តិការ និងគ្រប់គ្រងបច្ចេកវិទ្យាពពក។

ប្រភព: www.habr.com