ប្រតិបត្តិករនៅក្នុង Kubernetes សម្រាប់គ្រប់គ្រងចង្កោមមូលដ្ឋានទិន្នន័យ។ Vladislav Klimenko (Altinity, 2019)

របាយការណ៍នេះត្រូវបានឧទ្ទិសដល់បញ្ហាជាក់ស្តែងនៃការអភិវឌ្ឍន៍ប្រតិបត្តិករនៅក្នុង Kubernetes ការរចនាស្ថាបត្យកម្ម និងគោលការណ៍ប្រតិបត្តិការជាមូលដ្ឋាន។

នៅក្នុងផ្នែកដំបូងនៃរបាយការណ៍ យើងនឹងពិចារណា៖

• តើអ្វីជាប្រតិបត្តិករនៅក្នុង Kubernetes ហើយហេតុអ្វីបានជាវាត្រូវការ;
• របៀបដែលប្រតិបត្តិករធ្វើឱ្យការគ្រប់គ្រងប្រព័ន្ធស្មុគ្រស្មាញយ៉ាងជាក់លាក់។
• អ្វីដែលប្រតិបត្តិករអាចធ្វើបាន និងមិនអាចធ្វើបាន។

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

• អន្តរកម្មរវាងប្រតិបត្តិករ និង Kubernetes;
• មុខងារអ្វីដែលប្រតិបត្តិករអនុវត្ត និងមុខងារអ្វីដែលវាប្រគល់ឱ្យ Kubernetes ។

សូមក្រឡេកមើលការគ្រប់គ្រង shards និងការចម្លងមូលដ្ឋានទិន្នន័យនៅក្នុង Kubernetes ។
បន្ទាប់ យើងនឹងពិភាក្សាអំពីបញ្ហាផ្ទុកទិន្នន័យ៖

• របៀបធ្វើការជាមួយការផ្ទុកជាប់លាប់តាមទស្សនៈរបស់ប្រតិបត្តិករ;
• កំហុសនៃការប្រើប្រាស់ឧបករណ៍ផ្ទុកមូលដ្ឋាន។

នៅក្នុងផ្នែកចុងក្រោយនៃរបាយការណ៍ យើងនឹងពិចារណាឧទាហរណ៍ជាក់ស្តែងនៃការអនុវត្ត clickhouse-ប្រតិបត្តិករ ជាមួយ Amazon ឬ Google Cloud Service។ របាយការណ៍នេះគឺផ្អែកលើឧទាហរណ៍នៃការអភិវឌ្ឍន៍ និងបទពិសោធន៍ប្រតិបត្តិការរបស់ប្រតិបត្តិករសម្រាប់ ClickHouse ។

វីដេអូ:

ឈ្មោះរបស់ខ្ញុំគឺ Vladislav Klimenko ។ ថ្ងៃនេះខ្ញុំចង់និយាយអំពីបទពិសោធន៍របស់យើងក្នុងការអភិវឌ្ឍន៍ និងដំណើរការប្រតិបត្តិករ ហើយនេះគឺជាប្រតិបត្តិករឯកទេសសម្រាប់គ្រប់គ្រងចង្កោមមូលដ្ឋានទិន្នន័យ។ ឧទាហរណ៍ ប្រតិបត្តិករ ClickHouse ដើម្បីគ្រប់គ្រងចង្កោម ClickHouse ។

ហេតុអ្វីបានជាយើងមានឱកាសនិយាយអំពីប្រតិបត្តិករ និង ClickHouse?

• យើងគាំទ្រ និងអភិវឌ្ឍ ClickHouse ។
• នៅពេលនេះ យើងកំពុងព្យាយាមបន្តិចម្តងៗក្នុងការរួមចំណែករបស់យើងក្នុងការអភិវឌ្ឍន៍ ClickHouse ។ ហើយយើងស្ថិតនៅលំដាប់ទីពីរបន្ទាប់ពី Yandex ទាក់ទងនឹងបរិមាណនៃការផ្លាស់ប្តូរដែលបានធ្វើឡើងចំពោះ ClickHouse ។
• យើងកំពុងព្យាយាមធ្វើគម្រោងបន្ថែមសម្រាប់ប្រព័ន្ធអេកូឡូស៊ី ClickHouse ។

ខ្ញុំចង់ប្រាប់អ្នកអំពីគម្រោងមួយក្នុងចំណោមគម្រោងទាំងនេះ។ នេះគឺអំពី ClickHouse-operator សម្រាប់ Kubernetes។

នៅក្នុងរបាយការណ៍របស់ខ្ញុំ ខ្ញុំចង់និយាយអំពីប្រធានបទពីរ៖

• ប្រធានបទដំបូងគឺរបៀបដែលប្រតិបត្តិករគ្រប់គ្រងមូលដ្ឋានទិន្នន័យ ClickHouse របស់យើងដំណើរការនៅក្នុង Kubernetes ។
• ប្រធានបទទីពីរគឺរបៀបដែលប្រតិបត្តិករណាមួយដំណើរការ ពោលគឺរបៀបដែលវាមានអន្តរកម្មជាមួយ Kubernetes។

ទោះយ៉ាងណាក៏ដោយ សំណួរទាំងពីរនេះនឹងប្រសព្វគ្នាពេញមួយរបាយការណ៍របស់ខ្ញុំ។

តើអ្នកណាចាប់អារម្មណ៍ស្តាប់អ្វីដែលខ្ញុំកំពុងនិយាយ?

• វានឹងមានការចាប់អារម្មណ៍បំផុតចំពោះអ្នកដែលដំណើរការប្រតិបត្តិករ។
• ឬសម្រាប់អ្នកដែលចង់បង្កើតដោយខ្លួនឯង ដើម្បីស្វែងយល់ពីរបៀបដែលវាដំណើរការខាងក្នុង របៀបដែលប្រតិបត្តិករធ្វើអន្តរកម្មជាមួយ Kubernetes និងអ្វីដែលអាចកើតមាន។

ដើម្បីយល់ច្បាស់អំពីអ្វីដែលយើងនឹងពិភាក្សានៅថ្ងៃនេះ វាជាគំនិតល្អដើម្បីដឹងពីរបៀបដែល Kubernetes ដំណើរការ និងមានការបណ្តុះបណ្តាលលើពពកជាមូលដ្ឋានមួយចំនួន។

តើ ClickHouse ជាអ្វី? នេះគឺជាមូលដ្ឋានទិន្នន័យ columnar ដែលមានលក្ខណៈពិសេសជាក់លាក់សម្រាប់ដំណើរការលើអ៊ីនធឺណិតនៃសំណួរវិភាគ។ ហើយវាជាប្រភពបើកចំហទាំងស្រុង។

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

ហេតុអ្វីបានជាគាត់ត្រូវការនៅទីនោះ? ហេតុអ្វីបានជាយើងមិនអាចបន្តដំណើរការវាដោយខ្លួនឯង? ហើយ​ចម្លើយ​គឺ​ផ្នែក​បច្ចេកទេស និង​មួយ​ផ្នែក​ជា​ការ​រៀបចំ។

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

តើវាងាយស្រួល ឬពិបាកប៉ុណ្ណា? ជាការពិតណាស់នេះអាចត្រូវបានធ្វើដោយដៃ។ ប៉ុន្តែវាមិនមែនជារឿងសាមញ្ញនោះទេ ព្រោះយើងមានភាពស្មុគស្មាញបន្ថែមក្នុងការគ្រប់គ្រង Kubernetes ខ្លួនឯង ប៉ុន្តែនៅពេលជាមួយគ្នានោះ ភាពជាក់លាក់របស់ ClickHouse ត្រូវបានដាក់បញ្ចូល។ ហើយ​លទ្ធផល​នៃ​ការ​រួម​បញ្ចូល​គ្នា​បែប​នេះ។

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

ជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធថាមវន្ត ClickHouse មានបញ្ហាមួយចំនួនធំដែលបង្កើតបន្ទុកថេរនៅលើ DevOps៖

• នៅពេលដែលយើងចង់ផ្លាស់ប្តូរអ្វីមួយនៅក្នុង ClickHouse ឧទាហរណ៍ បន្ថែមការចម្លង ឬ shard បន្ទាប់មកយើងត្រូវគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធ។
• បន្ទាប់មកផ្លាស់ប្តូរគ្រោងការណ៍ទិន្នន័យ ពីព្រោះ ClickHouse មានវិធីសាស្ត្របំបែកជាក់លាក់។ នៅទីនោះអ្នកត្រូវរៀបចំដ្យាក្រាមទិន្នន័យ ដាក់ចេញការកំណត់រចនាសម្ព័ន្ធ។
• អ្នកត្រូវរៀបចំការត្រួតពិនិត្យ។
• ការប្រមូលកំណត់ហេតុសម្រាប់ shards ថ្មី សម្រាប់ការចម្លងថ្មី។
• ថែរក្សាការស្តារឡើងវិញ។
• ហើយចាប់ផ្តើមឡើងវិញ។

ទាំងនេះគឺជាកិច្ចការធម្មតាដែលខ្ញុំពិតជាចង់ធ្វើឱ្យកាន់តែងាយស្រួលប្រើ។

Kubernetes ខ្លួនវាជួយបានយ៉ាងល្អក្នុងប្រតិបត្តិការ ប៉ុន្តែនៅលើប្រព័ន្ធមូលដ្ឋាន។

Kubernetes ល្អក្នុងការសម្របសម្រួល និងស្វ័យប្រវត្តិកម្មដូចជា៖

• ការងើបឡើងវិញ។
• ចាប់ផ្ដើមឡើងវិញ។
• ការគ្រប់គ្រងប្រព័ន្ធផ្ទុក។

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

យើងចង់បានកាន់តែច្រើន យើងចង់ឱ្យមូលដ្ឋានទិន្នន័យទាំងមូលដំណើរការនៅក្នុង Kubernetes ។

ខ្ញុំ​ចង់​ទទួល​បាន​អ្វី​មួយ​ដូច​ជា​ប៊ូតុង​ក្រហម​វេទមន្ត​ដ៏​ធំ​មួយ​ដែល​អ្នក​ចុច ហើយ​ចង្កោម​ជាមួយ​នឹង​កិច្ចការ​ប្រចាំ​ថ្ងៃ​ដែល​ត្រូវ​ដោះស្រាយ​ត្រូវ​បាន​ដាក់​ពង្រាយ និង​ថែទាំ​ពេញ​មួយ​វដ្ត​ជីវិត​របស់​វា។ ចង្កោម ClickHouse នៅក្នុង Kubernetes ។

ហើយ​យើង​បាន​ព្យាយាម​បង្កើត​ដំណោះស្រាយ​ដែល​នឹង​ជួយ​ធ្វើ​ឱ្យ​ការងារ​កាន់តែ​ងាយស្រួល។ នេះគឺជា ClickHouse-operator សម្រាប់ Kubernetes ពី Altinity ។

ប្រតិបត្តិករគឺជាកម្មវិធីដែលភារកិច្ចចម្បងគឺគ្រប់គ្រងកម្មវិធីផ្សេងទៀត ពោលគឺវាជាអ្នកគ្រប់គ្រង។

ហើយវាមានលំនាំនៃអាកប្បកិរិយា។ អ្នកអាចហៅចំនេះដឹងដែលបានកំណត់អំពីប្រធានបទនេះ។

ហើយភារកិច្ចចម្បងរបស់គាត់គឺធ្វើឱ្យជីវិតរបស់ DevOps កាន់តែងាយស្រួល និងកាត់បន្ថយការគ្រប់គ្រងខ្នាតតូច ដូច្នេះគាត់ (DevOps) គិតរួចហើយក្នុងលក្ខខណ្ឌកម្រិតខ្ពស់ ពោលគឺ ដើម្បីឱ្យគាត់ (DevOps) មិនចូលរួមក្នុងការគ្រប់គ្រងមីក្រូ ដូច្នេះគាត់មិនកំណត់រចនាសម្ព័ន្ធ។ ព័ត៌មានលម្អិតទាំងអស់ដោយដៃ។

ហើយគ្រាន់តែប្រតិបត្តិករគឺជាជំនួយការមនុស្សយន្តដែលដោះស្រាយជាមួយ microtasks និងជួយ DevOps ។

ហេតុអ្វីបានជាអ្នកត្រូវការប្រតិបត្តិករ? គាត់ធ្វើបានល្អជាពិសេសក្នុងវិស័យពីរ៖

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

នេះត្រូវការជាចាំបាច់បំផុតដោយអ្នកដែលទើបតែចាប់ផ្តើមដំណើរ ឬអ្នកដែលត្រូវការធ្វើស្វ័យប្រវត្តិកម្មច្រើន។

តើវិធីសាស្រ្តផ្អែកលើប្រតិបត្តិករខុសពីប្រព័ន្ធផ្សេងទៀតយ៉ាងដូចម្តេច? មាន Helm ។ វាក៏ជួយក្នុងការដំឡើង ClickHouse ផងដែរ អ្នកអាចគូរគំនូសតាងជំនួយ ដែលនឹងដំឡើងទាំង ClickHouse cluster ទាំងមូល។ តើអ្វីជាភាពខុសគ្នារវាងប្រតិបត្តិករនិងដូចគ្នាឧទាហរណ៍ Helm?

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

នោះគឺជាផ្នែកណែនាំ សូមបន្តទៅមុខទៀត។

តើយើងបង្កើតប្រតិបត្តិកររបស់យើងដោយរបៀបណា? យើងកំពុងព្យាយាមដោះស្រាយបញ្ហាដើម្បីគ្រប់គ្រង ClickHouse cluster ជាធនធានតែមួយ។

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

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

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

ប្រសិនបើអ្នកចង់យល់ឱ្យបានលម្អិត នោះយើងព្យាយាមរក្សាឯកសារក្នុងទម្រង់សមរម្យតិចឬច្រើន។

ចូរចាប់ផ្តើមជាមួយនឹងបញ្ហាជាក់ស្តែង។ ភារកិច្ចដំបូងដែលយើងទាំងអស់គ្នាចង់ចាប់ផ្តើមគឺត្រូវដំណើរការឧទាហរណ៍ដំបូងតាមរបៀបណាមួយ។ តើខ្ញុំអាចបើកដំណើរការ ClickHouse ដោយប្រើប្រតិបត្តិករដោយរបៀបណា បើទោះបីជាខ្ញុំពិតជាមិនដឹងថាវាដំណើរការយ៉ាងណា? យើង​កំពុង​សរសេរ​សវនកម្ម​ព្រោះ... ការប្រាស្រ័យទាក់ទងទាំងអស់ជាមួយ k8s គឺជាការទំនាក់ទំនងតាមរយៈ manifests ។

នេះគឺជាការបង្ហាញដ៏ស្មុគស្មាញមួយ។ អ្វី​ដែល​យើង​បាន​បន្លិច​ជា​ពណ៌​ក្រហម​គឺ​ជា​អ្វី​ដែល​យើង​ត្រូវ​ផ្តោត​លើ។ យើងស្នើឱ្យប្រតិបត្តិករបង្កើតចង្កោមដែលមានឈ្មោះថា ការបង្ហាញ។

ទាំងនេះគឺជាឧទាហរណ៍ជាមូលដ្ឋានសម្រាប់ពេលនេះ។ ទំហំផ្ទុកមិនទាន់ត្រូវបានពិពណ៌នានៅឡើយទេ ប៉ុន្តែយើងនឹងត្រលប់ទៅកន្លែងផ្ទុកវិញបន្តិចក្រោយមក។ សម្រាប់ពេលនេះ យើងនឹងសង្កេតមើលពីសក្ដានុពលនៃការអភិវឌ្ឍន៍របស់ចង្កោម។

យើងបានបង្កើត manifesto នេះ។ យើងផ្តល់វាដល់ប្រតិបត្តិកររបស់យើង។ គាត់បានធ្វើការគាត់បានធ្វើវេទមន្ត។

យើងមើលកុងសូល។ សមាសភាគបីគឺគួរឱ្យចាប់អារម្មណ៍: Pod មួយ សេវាពីរ និង StatefulSet ។

ប្រតិបត្តិករបានដំណើរការហើយយើងអាចមើលឃើញអ្វីដែលពិតប្រាកដដែលគាត់បានបង្កើត។

គាត់បង្កើតអ្វីមួយដូចនេះ។ យើងមាន StatefulSet, Pod, ConfigMap សម្រាប់ការចម្លងនីមួយៗ ConfigMap សម្រាប់ចង្កោមទាំងមូល។ សេវាកម្មត្រូវបានទាមទារជាចំណុចចូលទៅក្នុងចង្កោម។

សេវាកម្មគឺជាសេវាតុល្យភាពបន្ទុកកណ្តាល ហើយក៏អាចប្រើសម្រាប់ការចម្លងនីមួយៗផងដែរ សម្រាប់ shard នីមួយៗ។

ចង្កោមមូលដ្ឋានរបស់យើងមើលទៅដូចនេះ។ វាមកពីថ្នាំងតែមួយ។

ចូរ​យើង​បន្ត​ទៅ​មុខ​ទៀត ហើយ​ធ្វើ​ឲ្យ​ស្មុគស្មាញ។ យើងត្រូវបំបែកចង្កោម។

ភារកិច្ចរបស់យើងកំពុងរីកចម្រើន ថាមវន្តកំពុងចាប់ផ្តើម។ យើង​ចង់​បន្ថែម​បន្ទះ។ យើងធ្វើតាមការអភិវឌ្ឍន៍។ យើងកំពុងផ្លាស់ប្តូរការបញ្ជាក់របស់យើង។ យើង​បង្ហាញ​ថា​យើង​ចង់​បាន​បន្ទះ​ពីរ។

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

យើងចិញ្ចឹមប្រតិបត្តិករ YAML ហើយមើលថាមានអ្វីកើតឡើង។

ប្រតិបត្តិករបានគិត និងបង្កើតអង្គភាពដូចខាងក្រោម។ យើងមាន Pods ពីររួចហើយ សេវាបី ហើយភ្លាមៗនោះ 2 StatefulSets ។ ហេតុអ្វីបានជា 2 StatefulSets?

នៅលើដ្យាក្រាមវាគឺដូចនេះ - នេះគឺជាស្ថានភាពដំបូងរបស់យើងនៅពេលដែលយើងមាន pod មួយ។

វាបានក្លាយជាបែបនេះ។ រហូតមកដល់ពេលនេះអ្វីគ្រប់យ៉ាងគឺសាមញ្ញវាត្រូវបានចម្លង។

ហើយហេតុអ្វីបានជាមាន StatefulSets ពីរ? នៅទីនេះ យើងត្រូវបកស្រាយ និងពិភាក្សាអំពីសំណួរអំពីរបៀបដែល Pods ត្រូវបានគ្រប់គ្រងនៅក្នុង Kubernetes ។

មានវត្ថុមួយហៅថា StatefulSet ដែលអនុញ្ញាតឱ្យអ្នកបង្កើតសំណុំនៃ Pods ពីគំរូមួយ។ កត្តាសំខាន់នៅទីនេះគឺ Template ។ ហើយអ្នកអាចបើកដំណើរការ Pods ជាច្រើនដោយប្រើគំរូមួយនៅក្នុង StatefulSet មួយ។ ហើយឃ្លាសំខាន់នៅទីនេះគឺ "Pods ជាច្រើនសម្រាប់គំរូមួយ" ។

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

ប៉ុន្តែប្រសិនបើយើងបូកសរុបកិច្ចការ ហើយនិយាយថាយើងចង់បង្កើតចង្កោមមិនដូចគ្នាទាំងស្រុង ហើយយើងមិនចង់ផ្លាស់ប្តូរពីកំណែចាស់ទៅកំណែថ្មីដោយប្រើការអាប់ដេតរំកិលនោះទេ ប៉ុន្តែយើងគ្រាន់តែចង់បង្កើតចង្កោមដែលខុសពីគ្នាទាំងពីរនៅក្នុងលក្ខខណ្ឌ។ នៃកំណែផ្សេងគ្នានៃ ClickHouse និងនៅក្នុងលក្ខខណ្ឌនៃការផ្ទុកផ្សេងគ្នា។ ជាឧទាហរណ៍ យើងចង់បង្កើតការចម្លងមួយចំនួននៅលើថាសដាច់ដោយឡែក ជាទូទៅនៅលើថាសយឺត ដើម្បីបង្កើតជាចង្កោមមិនដូចគ្នាទាំងស្រុង។ ហើយដោយសារតែ StatefulSet បង្កើតដំណោះស្រាយស្តង់ដារពីគំរូមួយ វាមិនមានវិធីដើម្បីធ្វើវាបានទេ។

ក្រោយ​ពី​បាន​គិត​ខ្លះ​ហើយ​ក៏​សម្រេច​ចិត្ត​ថា​យើង​នឹង​ធ្វើ​តាម​វិធី​នេះ។ យើងមានការចម្លងនីមួយៗនៅក្នុង StatefulSet របស់វា។ មានគុណវិបត្តិមួយចំនួនចំពោះដំណោះស្រាយនេះ ប៉ុន្តែនៅក្នុងការអនុវត្ត វាត្រូវបានបិទបាំងទាំងស្រុងដោយប្រតិបត្តិករ។ ហើយមានអត្ថប្រយោជន៍ជាច្រើន។ យើង​អាច​បង្កើត​ចង្កោម​ពិតប្រាកដ​ដែល​យើង​ចង់​បាន​ជា​ឧទាហរណ៍​ថា​ជា​ចង្កោម​ខុស​គ្នា​ពិត​ប្រាកដ។ ដូច្នេះហើយ នៅក្នុងចង្កោមដែលយើងមាន 2 shards ជាមួយការចម្លងមួយ យើងនឹងមាន 2 StatefulSets និង XNUMX Pods យ៉ាងជាក់លាក់ ដោយសារតែយើងបានជ្រើសរើសវិធីសាស្រ្តនេះសម្រាប់ហេតុផលដែលបានរៀបរាប់ខាងលើ ដើម្បីអាចបង្កើតចង្កោមមិនស្មើគ្នា។

ចូរយើងត្រលប់ទៅបញ្ហាជាក់ស្តែងវិញ។ នៅក្នុងចង្កោមរបស់យើង យើងត្រូវកំណត់រចនាសម្ព័ន្ធអ្នកប្រើប្រាស់ i.e. អ្នកត្រូវធ្វើការកំណត់រចនាសម្ព័ន្ធមួយចំនួននៃ ClickHouse នៅក្នុង Kubernetes ។ ប្រតិបត្តិករផ្តល់លទ្ធភាពទាំងអស់សម្រាប់រឿងនេះ។

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

អ្នកអាចសរសេរវាដូចនេះ។ នេះជាឧទាហរណ៍។ ពាក្យសម្ងាត់អាចត្រូវបានអ៊ិនគ្រីប។ ជម្រើសកំណត់រចនាសម្ព័ន្ធ ClickHouse ទាំងអស់ត្រូវបានគាំទ្រ។ នេះគ្រាន់តែជាឧទាហរណ៍ប៉ុណ្ណោះ។

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

ចូរធ្វើឱ្យកិច្ចការស្មុគស្មាញ។ ចង្កោមកំពុងអភិវឌ្ឍ។ យើងចង់ចម្លងទិន្នន័យ។ នោះ​គឺ​យើង​មាន shards ពីរ​រួច​ហើយ មួយ​ចម្លង​គ្នា ហើយ​អ្នក​ប្រើ​ត្រូវ​បាន​កំណត់​រចនាសម្ព័ន្ធ។ យើងកំពុងរីកចម្រើន ហើយចង់ធ្វើការចម្លង។

តើយើងត្រូវការអ្វីខ្លះសម្រាប់ការចម្លង?

យើងត្រូវការ ZooKeeper ។ នៅក្នុង ClickHouse ការចម្លងត្រូវបានបង្កើតឡើងដោយប្រើ ZooKeeper ។ ZooKeeper គឺត្រូវការជាចាំបាច់ដើម្បីឱ្យការចម្លង ClickHouse ផ្សេងៗគ្នាមានការឯកភាពគ្នាទាក់ទងនឹងប្លុកទិន្នន័យដែល ClickHouse ។

ZooKeeper អាចប្រើបានដោយនរណាម្នាក់។ ប្រសិនបើសហគ្រាសមាន ZooKeeper ខាងក្រៅ នោះវាអាចប្រើបាន។ ប្រសិនបើមិនមានទេ អ្នកអាចដំឡើងវាពីឃ្លាំងរបស់យើង។ មានកម្មវិធីដំឡើងដែលធ្វើអោយរឿងទាំងមូលកាន់តែងាយស្រួល។

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

ហើយទាំងអស់នេះគឺចាំបាច់សម្រាប់ ClickHouse ដើម្បីចម្លងទិន្នន័យដោយជោគជ័យក្នុង k8s ។

ឥឡូវ​នេះ​យើង​មើល​កិច្ចការ​ដោយ​ខ្លួន​ឯង​ថា​តើ​ការ​ចម្លង​នឹង​មាន​រូបរាង​ដូច​ម្តេច។

យើងកំពុងបន្ថែមផ្នែកពីរទៅការបង្ហាញរបស់យើង។ ទីមួយគឺកន្លែងដែលត្រូវយក ZooKeeper ដែលអាចនៅខាងក្នុង Kubernetes ឬខាងក្រៅ។ នេះគ្រាន់តែជាការពិពណ៌នាប៉ុណ្ណោះ។ ហើយយើងបញ្ជាទិញចម្លង។ ទាំងនោះ។ យើងចង់បានការចម្លងពីរ។ សរុបមក យើងគួរតែមាន 4 pods នៅទិន្នផល។ យើងចងចាំអំពីទំហំផ្ទុក វានឹងត្រលប់មកវិញបន្តិចក្រោយមក។ ការផ្ទុកគឺជារឿងដាច់ដោយឡែក។

វាគឺដូចនេះ។

វាក្លាយជាបែបនេះ។ ការចម្លងត្រូវបានបន្ថែម។ ទី 4 មិនសមទេយើងជឿថាអាចមានពួកគេជាច្រើននៅទីនោះ។ ហើយ ZooKeeper ត្រូវបានបន្ថែមទៅចំហៀង។ គ្រោងការណ៍កាន់តែស្មុគស្មាញ។

ហើយវាដល់ពេលដែលត្រូវបន្ថែមកិច្ចការបន្ទាប់។ យើងនឹងបន្ថែមការផ្ទុកជាប់លាប់។

សម្រាប់កន្លែងផ្ទុកជាប់លាប់ យើងមានជម្រើសផ្សេងៗ។

ប្រសិនបើយើងកំពុងដំណើរការនៅក្នុងក្រុមហ៊ុនផ្តល់សេវាពពក ជាឧទាហរណ៍ ការប្រើប្រាស់ Amazon, Google នោះមានការល្បួងដ៏អស្ចារ្យក្នុងការប្រើកន្លែងផ្ទុកពពក។ វា​ជា​ការ​ងាយ​ស្រួល​ណាស់​វា​ជា​ការ​ល្អ​។

ហើយមានជម្រើសទីពីរ។ វា​គឺ​សម្រាប់​ការ​ផ្ទុក​ក្នុង​មូលដ្ឋាន​នៅ​ពេល​ដែល​យើង​មាន​ថាស​មូលដ្ឋាន​នៅ​លើ​ថ្នាំង​នីមួយៗ។ ជម្រើសនេះកាន់តែពិបាកអនុវត្ត ប៉ុន្តែក្នុងពេលតែមួយវាមានផលិតភាពជាង។

សូមមើលអ្វីដែលយើងមានទាក់ទងនឹងការផ្ទុកពពក។

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

ហើយមានគុណវិបត្តិមួយ។ សម្រាប់អ្នកខ្លះ នេះគឺជាគុណវិបត្តិដែលមិនសំខាន់។ ប្រាកដ​ណាស់ វា​នឹង​មាន​បញ្ហា​ក្នុង​ការ​អនុវត្ត​មួយ​ចំនួន។ វាងាយស្រួលប្រើ និងអាចទុកចិត្តបាន ប៉ុន្តែមានគុណវិបត្តិនៃការអនុវត្តសក្តានុពលមួយចំនួន។

ហើយដោយសារតែ ClickHouse ផ្តោតជាពិសេសលើផលិតភាព មនុស្សម្នាក់អាចនិយាយបានថាវាច្របាច់ចេញនូវអ្វីគ្រប់យ៉ាងដែលវាអាចធ្វើបាន ដែលជាមូលហេតុដែលអតិថិជនជាច្រើនព្យាយាមច្របាច់ចេញនូវផលិតភាពអតិបរមា។

ហើយដើម្បីទទួលបានអត្ថប្រយោជន៍ច្រើនបំផុតពីវា យើងត្រូវការកន្លែងផ្ទុកក្នុងមូលដ្ឋាន។

Kubernetes ផ្តល់នូវអរូបីចំនួនបីសម្រាប់ការប្រើប្រាស់កន្លែងផ្ទុកក្នុងតំបន់នៅក្នុង Kubernetes ។ នេះ៖

• ទទេ
• HostPath ។
• ក្នុងស្រុក

សូមក្រឡេកមើលពីរបៀបដែលពួកគេខុសគ្នា និងរបៀបដែលពួកគេស្រដៀងគ្នា។

ទីមួយ នៅក្នុងវិធីសាស្រ្តទាំងបី យើងមានការផ្ទុក - ទាំងនេះគឺជាថាសមូលដ្ឋានដែលមានទីតាំងនៅលើថ្នាំង k8s ដូចគ្នា។ ប៉ុន្តែពួកគេមានភាពខុសគ្នាខ្លះ។

ចូរចាប់ផ្តើមជាមួយនឹងអ្វីដែលសាមញ្ញបំផុត ពោលគឺទទេ ឌី។ តើនេះជាអ្វីនៅក្នុងការអនុវត្ត? នៅក្នុងការបញ្ជាក់របស់យើង យើងសុំឱ្យប្រព័ន្ធកុងតឺន័រ (ភាគច្រើនជាញឹកញាប់ Docker) ផ្តល់ឱ្យយើងនូវការចូលទៅកាន់ថតឯកសារនៅលើថាសមូលដ្ឋាន។

នៅក្នុងការអនុវត្តជាក់ស្តែង Docker បង្កើតថតបណ្ដោះអាសន្ននៅកន្លែងណាមួយតាមផ្លូវរបស់វា ហើយហៅវាថាជាសញ្ញាវែង។ និងផ្តល់ចំណុចប្រទាក់ដើម្បីចូលប្រើវា។

តើការងារនេះនឹងដំណើរការយ៉ាងដូចម្តេច? វានឹងដំណើរការនៅល្បឿនឌីសក្នុងស្រុក i.e. នេះ​ជា​ការ​ចូល​ប្រើប្រាស់​វីស​របស់​អ្នក​ពេញលេញ។

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

វិធីសាស្រ្តនេះគឺល្អសម្រាប់ការធ្វើតេស្តព្រោះវាបង្ហាញល្បឿនធម្មតារួចទៅហើយ ប៉ុន្តែសម្រាប់អ្វីដែលធ្ងន់ធ្ងរជម្រើសនេះគឺមិនសមរម្យ។

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

វិធីសាស្រ្តនេះមានគុណសម្បត្តិ។ នេះ​គឺ​ជា​ការ​តស៊ូ​ពិត​ប្រាកដ​មួយ​រួច​ទៅ​ហើយ និង​ជា​រឿង​បុរាណ​នៅ​ទីនោះ។ យើងនឹងមានទិន្នន័យកត់ត្រានៅលើឌីសនៅអាសយដ្ឋានមួយចំនួន។

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

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

ប៉ុន្តែយើងមិនមែនជាមនុស្សតែម្នាក់ដែលត្រូវការតម្រូវការនេះទេ ដូច្នេះសុភាពបុរសមកពី Kubernetes ខ្លួនឯងក៏យល់ថាមនុស្សចង់មានសិទ្ធិចូលប្រើថាសរាងកាយ ដូច្នេះពួកគេផ្តល់ស្រទាប់ទីបី។

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

ចូរយើងត្រលប់ទៅបញ្ហាជាក់ស្តែងរបស់យើង។ តោះត្រឡប់ទៅគំរូ YAML វិញ។ នៅទីនេះយើងមានកន្លែងផ្ទុកពិតប្រាកដ។ យើង​ត្រឡប់​មក​វិញ​ហើយ។ យើងកំណត់គំរូ VolumeClaim បុរាណដូចនៅក្នុង k8s ។ ហើយ​យើង​ពណ៌នា​អំពី​ប្រភេទ​កន្លែង​ផ្ទុក​ដែល​យើង​ចង់​បាន។

បន្ទាប់ពីនេះ k8s នឹងស្នើសុំការផ្ទុក។ នឹងបែងចែកវាឱ្យយើងនៅក្នុង StatefulSet ។ ហើយ​នៅ​ទី​បញ្ចប់​វា​នឹង​ស្ថិត​នៅ​ក្នុង​ការ​ចោល​របស់ ClickHouse ។

យើងមានគ្រោងការណ៍នេះ។ កន្លែងផ្ទុកជាប់លាប់របស់យើងមានពណ៌ក្រហម ដែលហាក់ដូចជាផ្តល់សញ្ញាថាវាចាំបាច់ត្រូវតែធ្វើ។

ហើយវាប្រែទៅជាពណ៌បៃតង។ ឥឡូវនេះ ClickHouse on k8s cluster scheme ត្រូវបានបញ្ចប់ទាំងស្រុងហើយ។ យើងមាន shards, ចម្លង, ZooKeeper, យើងមាន Persistent ពិតប្រាកដ, ដែលត្រូវបានអនុវត្តនៅក្នុងវិធីមួយឬមួយផ្សេងទៀត។ គ្រោងការណ៍នេះដំណើរការពេញលេញហើយ។

យើងបន្តរស់នៅ។ ចង្កោមរបស់យើងកំពុងអភិវឌ្ឍ។ ហើយ Alexey ព្យាយាម និងចេញផ្សាយកំណែថ្មីរបស់ ClickHouse ។

ភារកិច្ចជាក់ស្តែងកើតឡើង - ដើម្បីសាកល្បងកំណែថ្មីរបស់ ClickHouse នៅលើចង្កោមរបស់យើង។ ហើយតាមធម្មជាតិ អ្នកមិនចង់រមៀលវាចេញទេ អ្នកចង់ដាក់កំណែថ្មីនៅក្នុងកន្លែងចម្លងមួយកន្លែងនៅជ្រុងឆ្ងាយ ហើយប្រហែលជាមិនមែនជាកំណែថ្មីទេ ប៉ុន្តែមានពីរក្នុងពេលតែមួយ ព្រោះវាចេញមកញឹកញាប់។

តើយើងអាចនិយាយអ្វីខ្លះអំពីរឿងនេះ?

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

តោះចូលជ្រៅបន្តិចទៅខាងក្នុង។ មុននេះ យើងបាននិយាយអំពីរបៀបដែល ClickHouse-operator ធ្វើការទាក់ទងទៅនឹងលក្ខណៈពិសេសរបស់ ClickHouse ។

ឥឡូវនេះខ្ញុំចង់និយាយពាក្យពីរបីអំពីរបៀបដែលប្រតិបត្តិករណាមួយធ្វើការជាទូទៅ ក៏ដូចជារបៀបដែលវាមានអន្តរកម្មជាមួយ K8s។

សូមក្រឡេកមើលអន្តរកម្មជាមួយ K8s ជាមុនសិន។ តើមានអ្វីកើតឡើងនៅពេលដែលយើងអនុវត្ត kubectl? វត្ថុរបស់យើងលេចឡើងនៅក្នុង etcd តាមរយៈ API ។

ឧទាហរណ៍ វត្ថុ Kubernetes មូលដ្ឋាន៖ pod, StatefulSet, សេវាកម្ម និងផ្សេងៗទៀត។

ទន្ទឹម​នឹង​នេះ​ក៏​មិន​ទាន់​មាន​អ្វី​កើត​ឡើង​ខាង​រាងកាយ​ដែរ។ វត្ថុទាំងនេះត្រូវតែជាវត្ថុធាតុនៅក្នុងចង្កោម។

ចំពោះគោលបំណងនេះឧបករណ៍បញ្ជាមួយលេចឡើង។ ឧបករណ៍បញ្ជាគឺជាសមាសធាតុ k8s ពិសេសដែលអាចបង្កើតការពិពណ៌នាទាំងនេះ។ គាត់ដឹងពីរបៀប និងអ្វីដែលត្រូវធ្វើខាងរាងកាយ។ គាត់ដឹងពីរបៀបដំណើរការកុងតឺន័រ អ្វីដែលត្រូវកំណត់រចនាសម្ព័ន្ធនៅទីនោះ ដើម្បីឱ្យម៉ាស៊ីនមេដំណើរការ។

ហើយវាបង្កើតវត្ថុរបស់យើងនៅក្នុង K8s ។

ប៉ុន្តែយើងចង់ដំណើរការមិនត្រឹមតែជាមួយ pods និង StatefulSets ប៉ុណ្ណោះទេ យើងចង់បង្កើត ClickHouseInstallation ពោលគឺវត្ថុនៃប្រភេទ ClickHouse ដើម្បីដំណើរការជាមួយវាទាំងមូល។ រហូតមកដល់ពេលនេះមិនមានលទ្ធភាពបែបនេះទេ។

ប៉ុន្តែ K8s មានរបស់ល្អដូចខាងក្រោម។ យើង​ចង់​ឱ្យ​យើង​មាន​កន្លែង​មួយ​ដូច​ជា​អង្គភាព​ដ៏​ស្មុគស្មាញ​នេះ ដែល​ចង្កោម​របស់​យើង​នឹង​ត្រូវ​បាន​ផ្គុំ​ចេញ​ពី pods និង StatefulSet។

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

យើងក៏ផ្ញើវាទៅទីនោះតាមរយៈ kubectl apply ។ Kubernetes បានយកវាដោយរីករាយ។

ហើយឥឡូវនេះនៅក្នុងការផ្ទុករបស់យើង វត្ថុនៅក្នុង etcd មានឱកាសដើម្បីកត់ត្រាធនធានផ្ទាល់ខ្លួនដែលហៅថា ClickHouseInstallation ។

ប៉ុន្តែសម្រាប់ពេលនេះ គ្មានអ្វីនឹងកើតឡើងទៀតទេ។ នោះគឺប្រសិនបើឥឡូវនេះយើងបង្កើតឯកសារ YAML ដែលយើងមើលការពិពណ៌នាអំពី shards និងការចម្លង ហើយនិយាយថា "kubectl apply" បន្ទាប់មក Kubernetes នឹងទទួលយកវា ដាក់វានៅក្នុង etcd ហើយនិយាយថា "ល្អណាស់ ប៉ុន្តែខ្ញុំមិនដឹងថាត្រូវធ្វើអ្វីនោះទេ។ ជាមួយ​វា។ ខ្ញុំមិនដឹងពីរបៀបថែទាំ ClickHouseInstallation ទេ។"

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

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

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

តើប្រតិបត្តិករដំណើរការយ៉ាងដូចម្តេច? សូមក្រឡេកមើលផ្នែកខាងស្តាំដើម្បីមើលពីរបៀបដែលគាត់ធ្វើវា។ ចូរយើងស្វែងយល់ពីរបៀបដែលប្រតិបត្តិករបង្កើតអ្វីៗទាំងអស់នេះ និងរបៀបដែលអន្តរកម្មបន្ថែមទៀតជាមួយ K8s កើតឡើង។

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

ប្រតិបត្តិករជាវព្រឹត្តិការណ៍ ហើយត្រូវតែធ្វើប្រតិកម្មមួយចំនួន។ ភារកិច្ចរបស់វាគឺដើម្បីឆ្លើយតបទៅនឹងព្រឹត្តិការណ៍ដែលកំពុងកើតឡើង។

ព្រឹត្តិការណ៍ត្រូវបានបង្កើតដោយការអាប់ដេតជាក់លាក់។ ឯកសារ YAML របស់យើងជាមួយនឹងការពិពណ៌នាអំពី ClickHouseInstallation មកដល់។ គាត់បានទៅ etcd តាមរយៈ kubectl អនុវត្ត។ ព្រឹត្តិការណ៍មួយត្រូវបានបង្កឡើងនៅទីនោះ ហើយជាលទ្ធផលព្រឹត្តិការណ៍នេះបានមកដល់ ClickHouse-operator។ ប្រតិបត្តិករបានទទួលការពិពណ៌នានេះ។ ហើយគាត់ត្រូវតែធ្វើអ្វីមួយ។ ប្រសិនបើការអាប់ដេតបានមកដល់សម្រាប់វត្ថុ ClickHouseInstallation នោះអ្នកត្រូវធ្វើបច្ចុប្បន្នភាពចង្កោម។ ហើយភារកិច្ចរបស់ប្រតិបត្តិករគឺធ្វើបច្ចុប្បន្នភាពចង្កោម។

តើ​គាត់​កំពុង​ធ្វើអ្វី? ជាដំបូង យើងត្រូវរៀបចំផែនការសកម្មភាពសម្រាប់អ្វីដែលយើងនឹងធ្វើជាមួយនឹងការអាប់ដេតនេះ។ ការអាប់ដេតអាចមានទំហំតូចណាស់ i.e. តូចនៅក្នុងការប្រតិបត្តិ YAML ប៉ុន្តែអាចបញ្ចូលការផ្លាស់ប្តូរដ៏ធំនៅលើចង្កោម។ ដូច្នេះប្រតិបត្តិករបង្កើតផែនការមួយ ហើយបន្ទាប់មកគាត់នៅជាប់នឹងវា។

យោងតាមផែនការនេះ គាត់ចាប់ផ្តើមចម្អិនរចនាសម្ព័ន្ធនេះនៅខាងក្នុង ដើម្បីសម្រេចបាននូវផតឃែរ សេវាកម្ម ពោលគឺឧ។ ធ្វើអ្វីដែលភារកិច្ចចម្បងរបស់គាត់។ នេះជារបៀបបង្កើត ClickHouse cluster នៅក្នុង Kubernetes។

ឥឡូវ​យើង​ប៉ះ​រឿង​គួរ​ឱ្យ​ចាប់​អារម្មណ៍​បែប​នេះ។ នេះគឺជាការបែងចែកការទទួលខុសត្រូវរវាង Kubernetes និងប្រតិបត្តិករ, i.e. អ្វីដែល Kubernetes ធ្វើ អ្វីដែលប្រតិបត្តិករធ្វើ និងរបៀបដែលពួកគេធ្វើអន្តរកម្មជាមួយគ្នា។

Kubernetes ទទួលខុសត្រូវចំពោះអ្វីៗជាប្រព័ន្ធ ពោលគឺឧ។ សម្រាប់សំណុំមូលដ្ឋាននៃវត្ថុដែលអាចត្រូវបានបកស្រាយថាជាប្រព័ន្ធ-វិសាលភាព។ Kubernetes ដឹងពីរបៀបចាប់ផ្តើមផត, របៀបចាប់ផ្តើមកុងតឺន័រឡើងវិញ, របៀបម៉ោនភាគ, របៀបធ្វើការជាមួយ ConfigMap, i.e. អ្វីគ្រប់យ៉ាងដែលអាចហៅថាប្រព័ន្ធ។

ប្រតិបត្តិករដំណើរការក្នុងដែន។ ប្រតិបត្តិករនីមួយៗត្រូវបានបង្កើតឡើងសម្រាប់ប្រធានបទផ្ទាល់ខ្លួន។ យើងបានធ្វើវាសម្រាប់ ClickHouse ។

ហើយប្រតិបត្តិករធ្វើអន្តរកម្មយ៉ាងជាក់លាក់នៅក្នុងលក្ខខណ្ឌនៃប្រធានបទ ដូចជាការបន្ថែមការចម្លង បង្កើតដ្យាក្រាម ការដំឡើងការត្រួតពិនិត្យ។ នេះបណ្តាលឱ្យមានការបែងចែក។

សូមក្រឡេកមើលឧទាហរណ៍ជាក់ស្តែងអំពីរបៀបដែលការបែងចែកការទទួលខុសត្រូវនេះកើតឡើងនៅពេលដែលយើងធ្វើសកម្មភាពចម្លងបន្ថែម។

ប្រតិបត្តិករទទួលបានភារកិច្ច - ដើម្បីបន្ថែមការចម្លង។ តើប្រតិបត្តិករធ្វើអ្វី? ប្រតិបត្តិករនឹងគណនាថា StatefulSet ថ្មីត្រូវតែត្រូវបានបង្កើត ដែលនៅក្នុងនោះ និងគំរូបែបនេះ ការទាមទារបរិមាណ ត្រូវតែត្រូវបានពិពណ៌នា។

គាត់រៀបចំវាទាំងអស់ ហើយបញ្ជូនវាទៅ K8s ។ គាត់និយាយថាគាត់ត្រូវការ ConfigMap, StatefulSet, Volume ។ Kubernetes កំពុងដំណើរការ។ គាត់បង្កើតគ្រឿងមូលដ្ឋានដែលគាត់ដំណើរការ។

ហើយបន្ទាប់មក ClickHouse-operator ចូលមកលេងម្តងទៀត។ គាត់មានរូបរាងកាយរួចហើយ ដែលគាត់អាចធ្វើអ្វីមួយបានហើយ។ ហើយ ClickHouse-operator ធ្វើការម្តងទៀតក្នុងលក្ខខណ្ឌដែន។ ទាំងនោះ។ ជាពិសេស ClickHouse ដើម្បីរួមបញ្ចូលការចម្លងនៅក្នុងចង្កោម អ្នកត្រូវតែកំណត់រចនាសម្ព័ន្ធទិន្នន័យដែលមាននៅក្នុងចង្កោមនេះជាមុនសិន។ ហើយទីពីរ ការចម្លងនេះត្រូវតែដាក់បញ្ចូលក្នុងការត្រួតពិនិត្យ ទើបអាចតាមដានបានយ៉ាងច្បាស់។ ប្រតិបត្តិករកំណត់រចនាសម្ព័ន្ធនេះរួចហើយ។

ហើយមានតែបន្ទាប់ពីនោះ ClickHouse ខ្លួនវាចូលមកលេង i.e. អង្គភាពកម្រិតខ្ពស់មួយទៀត។ នេះគឺជាមូលដ្ឋានទិន្នន័យរួចហើយ។ វាមានឧទាហរណ៍ផ្ទាល់របស់វា រូបចម្លងដែលបានកំណត់រចនាសម្ព័ន្ធមួយផ្សេងទៀតដែលត្រៀមរួចជាស្រេចដើម្បីចូលរួមចង្កោម។

វាប្រែថាខ្សែសង្វាក់នៃការប្រតិបត្តិនិងការបែងចែកការទទួលខុសត្រូវនៅពេលបន្ថែមការចម្លងគឺវែងណាស់។

យើងបន្តការងារជាក់ស្តែងរបស់យើង។ ប្រសិនបើអ្នកមានចង្កោមរួចហើយ អ្នកអាចផ្ទេរការកំណត់។

យើង​បាន​បង្កើត​វា​ឡើង ដើម្បី​ឱ្យ​អ្នក​អាច​បិទ​ភ្ជាប់​ទៅ​ក្នុង xml ដែល​មាន​ស្រាប់ ដែល ClickHouse យល់។

អ្នកអាចកែសំរួល ClickHouse ។ ការ​ដាក់​ពង្រាយ​តាម​តំបន់​គឺ​ជា​អ្វី​ដែល​ខ្ញុំ​បាន​និយាយ​នៅ​ពេល​ពន្យល់​អំពី hostPath ការ​ផ្ទុក​ក្នុង​តំបន់។ នេះជារបៀបដាក់ពង្រាយតំបន់ឱ្យបានត្រឹមត្រូវ។

ភារកិច្ចជាក់ស្តែងបន្ទាប់គឺការត្រួតពិនិត្យ។

ប្រសិនបើចង្កោមរបស់យើងផ្លាស់ប្តូរ នោះយើងត្រូវកំណត់រចនាសម្ព័ន្ធការត្រួតពិនិត្យជាប្រចាំ។

សូមក្រឡេកមើលដ្យាក្រាម។ យើងបានមើលព្រួញពណ៌បៃតងនៅទីនេះរួចហើយ។ ឥឡូវនេះសូមក្រឡេកមើលព្រួញក្រហម។ នេះជារបៀបដែលយើងចង់តាមដានចង្កោមរបស់យើង។ របៀបដែលម៉ែត្រពីចង្កោម ClickHouse ចូលទៅក្នុង Prometheus ហើយបន្ទាប់មកចូលទៅក្នុង Grafana ។

តើ​អ្វី​ជា​ការ​លំបាក​ក្នុង​ការ​ត្រួត​ពិនិត្យ? ហេតុ​អ្វី​បាន​ជា​ការ​បង្ហាញ​នេះ​ជា​ប្រភេទ​សមិទ្ធផល​មួយ​ចំនួន? ការលំបាកស្ថិតនៅក្នុងថាមវន្ត។ នៅពេលដែលយើងមានចង្កោមមួយហើយវាឋិតិវន្ត នោះយើងអាចរៀបចំការត្រួតពិនិត្យម្តងហើយមិនរំខានទៀតទេ។

ប៉ុន្តែប្រសិនបើយើងមានចង្កោមច្រើន ឬអ្វីមួយកំពុងផ្លាស់ប្តូរឥតឈប់ឈរ នោះដំណើរការគឺថាមវន្ត។ ហើយ​ការ​កំណត់​រចនាសម្ព័ន្ធ​ការ​ត្រួត​ពិនិត្យ​ឡើង​វិញ​ជា​ប្រចាំ​គឺ​ជា​ការ​ខ្ជះខ្ជាយ​ធនធាន​និង​ពេល​វេលា i.e. សូម្បីតែគ្រាន់តែខ្ជិល នេះត្រូវតែស្វ័យប្រវត្តិ។ ការលំបាកស្ថិតនៅក្នុងថាមវន្តនៃដំណើរការ។ ហើយប្រតិបត្តិករធ្វើស្វ័យប្រវត្តិកម្មនេះបានយ៉ាងល្អ។

តើចង្កោមរបស់យើងបានអភិវឌ្ឍយ៉ាងដូចម្តេច? កាលពីដើមគាត់គឺបែបនោះ។

ពេលនោះគាត់គឺបែបនេះ។

នៅ​ទី​បំផុត គាត់​បាន​ក្លាយ​ជា​បែប​នេះ។

ហើយការត្រួតពិនិត្យត្រូវបានធ្វើឡើងដោយស្វ័យប្រវត្តិដោយប្រតិបត្តិករ។ ចំណុចចូលតែមួយ។

ហើយគ្រាន់តែនៅច្រកចេញ យើងមើលផ្ទាំងគ្រប់គ្រង Grafana ដើម្បីមើលពីរបៀបដែលជីវិតរបស់ចង្កោមរបស់យើងកំពុងពុះកញ្ជ្រោលនៅខាងក្នុង។

ដោយវិធីនេះ ផ្ទាំងគ្រប់គ្រង Grafana ក៏ត្រូវបានចែកចាយជាមួយប្រតិបត្តិកររបស់យើងដោយផ្ទាល់នៅក្នុងកូដប្រភពផងដែរ។ អ្នកអាចភ្ជាប់និងប្រើ។ DevOps របស់យើងបានផ្តល់ឱ្យខ្ញុំនូវរូបថតអេក្រង់នេះ។

តើយើងចង់ទៅកន្លែងណាបន្ទាប់? នេះ៖

• អភិវឌ្ឍស្វ័យប្រវត្តិកម្មសាកល្បង។ ភារកិច្ចចម្បងគឺការធ្វើតេស្តដោយស្វ័យប្រវត្តិនៃកំណែថ្មី។
• យើងក៏ពិតជាចង់ធ្វើសមាហរណកម្មដោយស្វ័យប្រវត្តិជាមួយ ZooKeeper ផងដែរ។ ហើយមានគម្រោងក្នុងការរួមបញ្ចូលជាមួយ ZooKeeper-operator ។ ទាំងនោះ។ ប្រតិបត្តិករមួយត្រូវបានសរសេរសម្រាប់ ZooKeeper ហើយវាសមហេតុផលដែលប្រតិបត្តិករទាំងពីរចាប់ផ្តើមបញ្ចូលគ្នាដើម្បីបង្កើតដំណោះស្រាយដែលងាយស្រួលជាង។
• យើងចង់ធ្វើសញ្ញាសំខាន់ៗដែលស្មុគស្មាញជាងនេះ។
• ខ្ញុំបានគូសបញ្ជាក់ជាពណ៌បៃតងថា យើងកំពុងខិតជិតការទទួលមរតកនៃគំរូ - រួចរាល់ ពោលគឺជាមួយនឹងការចេញផ្សាយបន្ទាប់នៃប្រតិបត្តិករ យើងនឹងទទួលបានមរតកនៃគំរូរួចហើយ។ នេះគឺជាឧបករណ៍ដ៏មានឥទ្ធិពលដែលអនុញ្ញាតឱ្យអ្នកបង្កើតរចនាសម្ព័ន្ធស្មុគស្មាញពីបំណែក។
• ហើយយើងចង់បានស្វ័យប្រវត្តិកម្មនៃកិច្ចការស្មុគស្មាញ។ ចំណុចសំខាន់គឺការបំបែកឡើងវិញ។

ចូរយើងទទួលយកលទ្ធផលកម្រិតមធ្យម។

តើយើងទទួលបានលទ្ធផលអ្វី? ហើយតើវាសមនឹងធ្វើឬអត់? តើវាចាំបាច់ទេក្នុងការព្យាយាមអូសមូលដ្ឋានទិន្នន័យទៅក្នុង Kubernetes ហើយប្រើប្រតិបត្តិករជាទូទៅ និងប្រតិបត្តិករ Alitnity ជាពិសេស?

នៅទិន្នផលយើងទទួលបាន:

• ភាពសាមញ្ញដ៏សំខាន់ និងស្វ័យប្រវត្តិកម្មនៃការកំណត់រចនាសម្ព័ន្ធ ការដាក់ពង្រាយ និងការថែទាំ។
• ត្រួតពិនិត្យភ្លាមៗ។
• និង​គំរូ​ដែល​បាន​សរសេរ​កូដ​រួចរាល់​សម្រាប់​ស្ថានភាព​ស្មុគស្មាញ។ សកម្មភាពដូចជាការបន្ថែមការចម្លង មិនចាំបាច់ធ្វើដោយដៃទេ។ ប្រតិបត្តិករធ្វើបែបនេះ។

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

ចម្លើយគឺអ្វីៗគឺល្អ! ខ្ញុំនឹងមិននិយាយលម្អិតទេ នេះជាប្រធានបទនៃរបាយការណ៍ដាច់ដោយឡែកមួយ។

ប៉ុន្តែមានគម្រោងដូចជា TSBS ។ តើអ្វីជាភារកិច្ចចម្បងរបស់វា? នេះគឺជាការសាកល្បងដំណើរការមូលដ្ឋានទិន្នន័យ។ នេះ​ជាការ​ប៉ុនប៉ង​ប្រៀបធៀប​ក្តៅ​ជាមួយ​ក្តៅ ទន់​ជាមួយ​ទន់។

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

វា​គាំទ្រ​មូលដ្ឋាន​ទិន្នន័យ​មួយ​បាច់​ធំ​រួច​ទៅ​ហើយ។ ខ្ញុំបានកំណត់អត្តសញ្ញាណសំខាន់ៗចំនួនបី។ នេះ៖

• TimescaleDB
• InfluxDB ។
• ClickHouse។

ការប្រៀបធៀបក៏ត្រូវបានធ្វើឡើងជាមួយនឹងដំណោះស្រាយស្រដៀងគ្នាមួយផ្សេងទៀតផងដែរ។ ការប្រៀបធៀបជាមួយ RedShift ។ ការប្រៀបធៀបត្រូវបានធ្វើឡើងនៅលើ Amazon ។ ClickHouse ក៏នាំមុខអ្នកគ្រប់គ្នាក្នុងបញ្ហានេះផងដែរ។

តើ​ការ​សន្និដ្ឋាន​អ្វី​ខ្លះ​អាច​ទាញ​បាន​ពី​អ្វី​ដែល​ខ្ញុំ​បាន​និយាយ?

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

ប្រភពបើកចំហ - ចូលរួមជាមួយយើង!

ដូចដែលខ្ញុំបាននិយាយរួចមកហើយ ប្រតិបត្តិករគឺជាផលិតផលប្រភពបើកចំហទាំងស្រុង ដូច្នេះវាពិតជាល្អណាស់ប្រសិនបើចំនួនអតិបរមានៃមនុស្សបានប្រើវា។ ចូលរួម​ជាមួយ​យើង! យើងកំពុងរង់ចាំអ្នកទាំងអស់គ្នា!

សូមអរគុណអ្នកទាំងអស់គ្នា!

សំណួរ

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

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

សួស្តី! អរគុណសម្រាប់របាយការណ៍! ខ្ញុំ​មាន​សំណួរ​ស្ដង់ដារ​មួយ​ទាក់ទង​នឹង​ភាគ​បន្ត។ នៅពេលយើងបង្កើតការកំណត់រចនាសម្ព័ន្ធជាមួយប្រតិបត្តិករនេះ តើប្រតិបត្តិករកំណត់ដោយរបៀបណាថាថ្នាំងណាដែលយើងមានឌីស ឬថតជាក់លាក់មួយដែលបានភ្ជាប់? យើងត្រូវពន្យល់គាត់ជាមុនថា សូមដាក់ ClickHouse របស់យើងនៅលើថ្នាំងទាំងនេះដែលមានថាស?

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

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

ហើយវាជាជម្រើសទី XNUMX ក្នុងស្រុក ដែលជួយធ្វើឱ្យវាកាន់តែងាយស្រួលបន្តិច។ ដូចដែលខ្ញុំបានគូសបញ្ជាក់រួចហើយ នេះគឺជាការងារដ៏ឧស្សាហ៍ព្យាយាមលើការលៃតម្រូវ ដែលនៅទីបំផុតអាចជួយឱ្យទទួលបានលទ្ធផលអតិបរមា។

ខ្ញុំមានសំណួរទីពីរទាក់ទងនឹងរឿងនេះ។ Kubernetes ត្រូវ​បាន​រចនា​ឡើង​ក្នុង​របៀប​ដែល​វា​មិន​សំខាន់​ចំពោះ​យើង​ថា​តើ​យើង​បាត់​បង់​ថ្នាំង​ឬ​អត់។ តើ​យើង​គួរ​ធ្វើ​យ៉ាង​ណា​ក្នុង​ករណី​នេះ ប្រសិន​បើ​យើង​បាត់​បង់​ថ្នាំង​ដែល​ shard របស់​យើង​ព្យួរ?

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

ឥឡូវនេះសម្រាប់សំណួរជាក់ស្តែង។ អ្វីដែលត្រូវធ្វើប្រសិនបើអ្នកបាត់ថ្នាំងដែលឌីសនោះ? នៅទីនេះបញ្ហាកំពុងត្រូវបានដោះស្រាយនៅកម្រិតខ្ពស់។ ក្នុងករណី ClickHouse យើងមានការចម្លងដែលដំណើរការនៅកម្រិតខ្ពស់ជាងនេះ ពោលគឺឧ។ នៅកម្រិត ClickHouse ។

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

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

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

តើមានអ្វីកើតឡើង ប្រសិនបើប្រតិបត្តិករគាំង ហើយចាប់ផ្តើមឡើងវិញមែនទេ?

បាទ។ ហើយនៅពេលនោះព្រឹត្តិការណ៍បានមកដល់។

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

សួស្តី! អរគុណសម្រាប់របាយការណ៍! Dmitry Zavyalov, ក្រុមហ៊ុន Smedova ។ តើមានគម្រោងបន្ថែមសមត្ថភាពក្នុងការកំណត់រចនាសម្ព័ន្ធជាមួយ haproxy ទៅប្រតិបត្តិករដែរឬទេ? ខ្ញុំនឹងចាប់អារម្មណ៍លើឧបករណ៍តុល្យភាពផ្សេងទៀតក្រៅពីស្តង់ដារមួយ ដូច្នេះវាឆ្លាត ហើយយល់ថា ClickHouse ពិតជានៅទីនោះ។

តើអ្នកកំពុងនិយាយអំពី Ingress ទេ?

បាទ/ចាស ជំនួស Ingress ដោយ haproxy ។ នៅក្នុង haproxy អ្នកអាចបញ្ជាក់ topology នៃ cluster ដែលវាមានចម្លង។

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

មានរួចហើយ។

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

ប្រភព: www.habr.com