ផ្ទុកសមតុល្យ និងពង្រីកការតភ្ជាប់ដែលមានអាយុកាលយូរនៅក្នុង Kubernetes

អត្ថបទនេះនឹងជួយអ្នកឱ្យយល់ពីរបៀបដែលសមតុល្យបន្ទុកដំណើរការនៅក្នុង Kubernetes តើមានអ្វីកើតឡើងនៅពេលធ្វើមាត្រដ្ឋានការតភ្ជាប់ដែលមានអាយុកាលយូរ និងមូលហេតុដែលអ្នកគួរពិចារណាអំពីតុល្យភាពផ្នែកខាងអតិថិជន ប្រសិនបើអ្នកប្រើ HTTP/2, gRPC, RSockets, AMQP ឬពិធីការដែលមានអាយុកាលយូរផ្សេងទៀត . 

បន្តិចអំពីរបៀបដែលចរាចរណ៍ត្រូវបានចែកចាយឡើងវិញនៅក្នុង Kubernetes 

Kubernetes ផ្តល់នូវការសង្ខេបដ៏ងាយស្រួលចំនួនពីរសម្រាប់ការដាក់ពង្រាយកម្មវិធី៖ សេវាកម្ម និងការដាក់ឱ្យប្រើប្រាស់។

ការដាក់ឱ្យប្រើប្រាស់ពិពណ៌នាអំពីរបៀប និងចំនួនច្បាប់ចម្លងនៃកម្មវិធីរបស់អ្នកគួរដំណើរការនៅពេលណាក៏បាន។ កម្មវិធីនីមួយៗត្រូវបានដាក់ពង្រាយជា Pod ហើយត្រូវបានផ្តល់អាសយដ្ឋាន IP ។

សេវាកម្មគឺស្រដៀងគ្នានៅក្នុងមុខងារទៅនឹងតុល្យភាពបន្ទុក។ ពួកវាត្រូវបានរចនាឡើងដើម្បីចែកចាយចរាចរឆ្លងកាត់ផតថលជាច្រើន។

តោះមើលថាតើវាមើលទៅដូចអ្វី.

1. នៅក្នុងដ្យាក្រាមខាងក្រោម អ្នកអាចមើលឃើញឧទាហរណ៍បីនៃកម្មវិធីដូចគ្នា និងតុល្យភាពបន្ទុក៖

   

2. ឧបករណ៍ផ្ទុកតុល្យភាពត្រូវបានគេហៅថាសេវាកម្ម ហើយត្រូវបានផ្តល់អាសយដ្ឋាន IP ។ រាល់​សំណើ​ចូល​ត្រូវ​បាន​បញ្ជូន​បន្ត​ទៅ​កាន់​ផត​មួយ៖

   

3. សេណារីយ៉ូនៃការដាក់ពង្រាយកំណត់ចំនួនករណីនៃកម្មវិធី។ អ្នកស្ទើរតែមិនចាំបាច់ពង្រីកដោយផ្ទាល់នៅក្រោម៖

   

4. ផតនីមួយៗត្រូវបានផ្តល់អាសយដ្ឋាន IP ផ្ទាល់ខ្លួនរបស់វា៖

   

វាមានប្រយោជន៍ក្នុងការគិតពីសេវាកម្មជាបណ្តុំនៃអាសយដ្ឋាន IP ។ រាល់ពេលដែលអ្នកចូលប្រើសេវាកម្ម អាសយដ្ឋាន IP មួយត្រូវបានជ្រើសរើសពីបញ្ជី ហើយប្រើជាអាសយដ្ឋានគោលដៅ។

វាមើលទៅដូចនេះ.

1. ការស្នើសុំ curl 10.96.45.152 ត្រូវបានទទួលទៅសេវាកម្ម៖

   

2. សេវាកម្មជ្រើសរើសអាសយដ្ឋាន pod មួយក្នុងចំណោមបីជាទិសដៅ៖

   

3. ចរាចរណ៍​ត្រូវ​បាន​បញ្ជូន​បន្ត​ទៅ​កាន់​កន្លែង​ជាក់លាក់​មួយ៖

   

ប្រសិនបើកម្មវិធីរបស់អ្នកមានផ្នែកខាងមុខ និងផ្នែកខាងក្រោយ នោះអ្នកនឹងមានទាំងសេវាកម្ម និងការដាក់ឱ្យប្រើប្រាស់សម្រាប់នីមួយៗ។

នៅពេលដែលផ្នែកខាងមុខធ្វើការស្នើសុំទៅផ្នែកខាងក្រោយ វាមិនចាំបាច់ដឹងច្បាស់ថាចំនួនផតដែលផ្នែកខាងក្រោយបម្រើនោះទេ៖ អាចមានមួយ ដប់ ឬមួយរយ។

ដូចគ្នានេះផងដែរ ផ្នែកខាងមុខមិនដឹងអ្វីទាំងអស់អំពីអាសយដ្ឋានរបស់ផតឃែរដែលបម្រើផ្នែកខាងក្រោយ។

នៅពេលដែល frontend ធ្វើការស្នើសុំទៅកាន់ backend វាប្រើអាសយដ្ឋាន IP នៃសេវាកម្ម backend ដែលមិនផ្លាស់ប្តូរ។

នេះជាអ្វីដែលវាមើលទៅ.

1. នៅក្រោម 1 ស្នើសុំសមាសភាគខាងក្រោយខាងក្នុង។ ជំនួសឱ្យការជ្រើសរើសជាក់លាក់មួយសម្រាប់ផ្នែកខាងក្រោយ វាធ្វើការស្នើសុំទៅកាន់សេវាកម្ម៖

   

2. សេវាកម្មនេះជ្រើសរើសផ្នែកខាងក្រោយមួយជាអាសយដ្ឋានគោលដៅ៖

   

3. ចរាចរណ៍ចាប់ពី Pod 1 ដល់ Pod 5 ដែលជ្រើសរើសដោយសេវាកម្ម៖

   

4. នៅក្រោម 1 មិនដឹងច្បាស់ថាចំនួន pods ដូចនៅក្រោម 5 ត្រូវបានលាក់នៅពីក្រោយសេវាកម្មនេះទេ:

   

ប៉ុន្តែ​តើ​សេវា​ចែកចាយ​សំណើ​យ៉ាង​ណា​ឲ្យ​ប្រាកដ? វាហាក់បីដូចជាតុល្យភាពវិលជុំត្រូវបានប្រើ? ចូរយើងដោះស្រាយវា។ 

តុល្យភាពនៅក្នុងសេវាកម្ម Kubernetes

សេវាកម្ម Kubernetes មិនមានទេ។ មិនមានដំណើរការសម្រាប់សេវាកម្មដែលត្រូវបានផ្តល់អាសយដ្ឋាន IP និងច្រកទេ។

អ្នកអាចផ្ទៀងផ្ទាត់វាដោយចូលទៅក្នុង node ណាមួយនៅក្នុង cluster ហើយដំណើរការពាក្យបញ្ជា netstat -ntlp ។

អ្នកនឹងមិនអាចស្វែងរកអាសយដ្ឋាន IP ដែលត្រូវបានបម្រុងទុកសម្រាប់សេវាកម្មនោះទេ។

អាសយដ្ឋាន IP របស់សេវាកម្មមានទីតាំងនៅក្នុងស្រទាប់វត្ថុបញ្ជា នៅក្នុងឧបករណ៍បញ្ជា និងត្រូវបានកត់ត្រានៅក្នុងមូលដ្ឋានទិន្នន័យ - ល។ អាសយដ្ឋានដូចគ្នានេះត្រូវបានប្រើដោយសមាសភាគផ្សេងទៀត - kube-ប្រូកស៊ី។
Kube-proxy ទទួលបានបញ្ជីអាសយដ្ឋាន IP សម្រាប់សេវាកម្មទាំងអស់ និងបង្កើតសំណុំនៃច្បាប់ iptables នៅលើថ្នាំងនីមួយៗក្នុងចង្កោម។

ច្បាប់ទាំងនេះនិយាយថា៖ "ប្រសិនបើយើងឃើញអាសយដ្ឋាន IP របស់សេវាកម្ម យើងត្រូវកែប្រែអាសយដ្ឋានទិសដៅនៃសំណើ ហើយផ្ញើវាទៅផតផតណាមួយ"។

អាសយដ្ឋាន IP របស់សេវាកម្មគឺត្រូវបានប្រើតែជាចំណុចចូលប៉ុណ្ណោះ ហើយមិនត្រូវបានបម្រើដោយដំណើរការណាមួយដែលស្តាប់អាសយដ្ឋាន IP និងច្រកនោះទេ។

តោះមើលរឿងនេះ. 

1. ពិចារណាចង្កោមនៃថ្នាំងបី។ ថ្នាំងនីមួយៗមានផតៈ

   

2. ខោទ្រនាប់ដែលលាបពណ៌បន៍ត្នោតខ្ចីគឺជាផ្នែកមួយនៃសេវាកម្ម។ ដោយសារតែសេវាកម្មមិនមានជាដំណើរការ វាត្រូវបានបង្ហាញជាពណ៌ប្រផេះ៖

   

3. ផតទី 1 ស្នើសុំសេវាកម្មមួយ ហើយត្រូវចូលទៅកាន់ផតផតដែលពាក់ព័ន្ធមួយ៖

   

4. ប៉ុន្តែសេវាកម្មមិនមានទេដំណើរការមិនមានទេ។ តើ​វា​ដំណើរការ​យ៉ាង​ដូចម្តេច?

   

5. មុនពេលសំណើចាកចេញពីថ្នាំង វាឆ្លងកាត់ច្បាប់ iptables៖

   

6. ច្បាប់ iptables ដឹងថាសេវាកម្មនេះមិនមានទេ ហើយជំនួសអាសយដ្ឋាន IP របស់វាជាមួយនឹងអាសយដ្ឋាន IP មួយក្នុងចំណោមអាសយដ្ឋាន IP នៃផតឃែរដែលទាក់ទងនឹងសេវាកម្មនោះ៖

   

7. សំណើទទួលបានអាសយដ្ឋាន IP ដែលមានសុពលភាពជាអាសយដ្ឋានគោលដៅ ហើយត្រូវបានដំណើរការជាធម្មតា៖

   

8. អាស្រ័យលើបណ្តាញ topology សំណើនៅទីបំផុតឈានដល់ pod៖

   

តើ iptables អាចផ្ទុកសមតុល្យបានទេ?

ទេ iptables ត្រូវបានប្រើសម្រាប់ការត្រង ហើយមិនត្រូវបានរចនាឡើងសម្រាប់តុល្យភាពទេ។

ទោះយ៉ាងណាក៏ដោយវាអាចទៅរួចក្នុងការសរសេរសំណុំនៃច្បាប់ដែលធ្វើការដូច pseudo-balancer.

ហើយនេះពិតជាអ្វីដែលត្រូវបានអនុវត្តនៅក្នុង Kubernetes ។

ប្រសិនបើអ្នកមានផតចំនួន 3 នោះ kube-proxy នឹងសរសេរច្បាប់ដូចខាងក្រោមៈ

1. ជ្រើសរើសអនុដំបូងដែលមានប្រូបាប៊ីលីតេ 33% បើមិនដូច្នេះទេ សូមចូលទៅកាន់ច្បាប់បន្ទាប់។
2. ជ្រើសរើសទីពីរដែលមានប្រូបាប៊ីលីតេ 50% បើមិនដូច្នេះទេទៅច្បាប់បន្ទាប់។
3. ជ្រើសរើសទីបីនៅក្រោម។

ប្រព័ន្ធនេះនាំឱ្យ pod នីមួយៗត្រូវបានជ្រើសរើសជាមួយនឹងប្រូបាប៊ីលីតេ 33% ។

ហើយមិនមានការធានាថា Pod 2 នឹងត្រូវបានជ្រើសរើសបន្ទាប់បន្ទាប់ពី Pod 1 នោះទេ។

ការកត់សម្គាល់៖ iptables ប្រើម៉ូឌុលស្ថិតិជាមួយនឹងការចែកចាយចៃដន្យ។ ដូច្នេះ ក្បួនដោះស្រាយតុល្យភាពគឺផ្អែកលើការជ្រើសរើសចៃដន្យ។

ឥឡូវនេះអ្នកយល់ពីរបៀបដែលសេវាកម្មដំណើរការ សូមក្រឡេកមើលសេណារីយ៉ូសេវាកម្មដែលគួរឱ្យចាប់អារម្មណ៍បន្ថែមទៀត។

ការតភ្ជាប់ដែលមានអាយុកាលយូរនៅក្នុង Kubernetes មិនមានទំហំតាមលំនាំដើមទេ។

សំណើ HTTP នីមួយៗពីផ្នែកខាងមុខទៅផ្នែកខាងក្រោយត្រូវបានបម្រើដោយការតភ្ជាប់ TCP ដាច់ដោយឡែកដែលត្រូវបានបើក និងបិទ។

ប្រសិនបើ frontend ផ្ញើសំណើ 100 ក្នុងមួយវិនាទីទៅ backend នោះ ការតភ្ជាប់ TCP ផ្សេងគ្នា 100 ត្រូវបានបើក និងបិទ។

អ្នកអាចកាត់បន្ថយពេលវេលាដំណើរការសំណើ និងការផ្ទុកដោយបើកការតភ្ជាប់ TCP មួយ ហើយប្រើវាសម្រាប់សំណើ HTTP ជាបន្តបន្ទាប់ទាំងអស់។

ពិធីការ HTTP មានលក្ខណៈពិសេសមួយហៅថា HTTP Keep-alive ឬការប្រើប្រាស់ការតភ្ជាប់ឡើងវិញ។ ក្នុងករណីនេះ ការតភ្ជាប់ TCP តែមួយត្រូវបានប្រើដើម្បីផ្ញើ និងទទួលសំណើ HTTP និងការឆ្លើយតបជាច្រើន៖

មុខងារនេះមិនត្រូវបានបើកតាមលំនាំដើមទេ៖ ទាំងម៉ាស៊ីនមេ និងម៉ាស៊ីនភ្ញៀវត្រូវតែកំណត់រចនាសម្ព័ន្ធស្របតាម។

ការដំឡើងដោយខ្លួនវាគឺសាមញ្ញ និងអាចចូលប្រើបានសម្រាប់ភាសាកម្មវិធី និងបរិស្ថានភាគច្រើន។

នេះគឺជាតំណភ្ជាប់មួយចំនួនទៅកាន់ឧទាហរណ៍ជាភាសាផ្សេងៗគ្នា៖

• រក្សាជីវិតនៅក្នុង Node.js
• រក្សាជីវិតនៅក្នុងស្បែកជើងនិទាឃរដូវ
• រក្សាជីវិតនៅក្នុង Python
• រក្សាជីវិតនៅក្នុង .NET

តើមានអ្វីកើតឡើងប្រសិនបើយើងប្រើ Keep-alive នៅក្នុងសេវាកម្ម Kubernetes?
ឧបមាថាទាំងផ្នែកខាងមុខ និងផ្នែកខាងក្រោយគាំទ្របន្ត។

យើងមានច្បាប់ចម្លងផ្នែកខាងមុខមួយ និងផ្នែកខាងក្រោយចំនួនបី។ ផ្នែកខាងមុខបង្កើតសំណើដំបូង ហើយបើកការតភ្ជាប់ TCP ទៅផ្នែកខាងក្រោយ។ សំណើឈានដល់សេវាកម្ម ផតផតផ្នែកខាងក្រោយមួយត្រូវបានជ្រើសរើសជាអាសយដ្ឋានគោលដៅ។ ផ្នែកខាងក្រោយផ្ញើការឆ្លើយតប ហើយផ្នែកខាងមុខទទួលបានវា។

មិនដូចស្ថានភាពធម្មតាដែលការភ្ជាប់ TCP ត្រូវបានបិទបន្ទាប់ពីទទួលបានការឆ្លើយតប ឥឡូវនេះវាត្រូវបានរក្សាទុកសម្រាប់សំណើ HTTP បន្ថែមទៀត។

តើមានអ្វីកើតឡើងប្រសិនបើ Frontend ផ្ញើសំណើបន្ថែមទៅផ្នែកខាងក្រោយ?

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

iptables មិនគួរចែកចាយចរាចរណ៍ឡើងវិញទេ?

មិនមែនក្នុងករណីនេះទេ។

នៅពេលដែលការតភ្ជាប់ TCP ត្រូវបានបង្កើត វាឆ្លងកាត់ច្បាប់ iptables ដែលជ្រើសរើសផ្នែកខាងក្រោយជាក់លាក់មួយដែលចរាចរណ៍នឹងទៅ។

ដោយសារសំណើជាបន្តបន្ទាប់ទាំងអស់គឺនៅលើការតភ្ជាប់ TCP ដែលបានបើករួចហើយ ច្បាប់ iptables មិនត្រូវបានហៅទៀតទេ។

តោះមើលថាតើវាមើលទៅដូចអ្វី.

1. ផតទីមួយផ្ញើសំណើទៅសេវាកម្ម៖

   

2. អ្នកដឹងរួចហើយថានឹងមានអ្វីកើតឡើងបន្ទាប់។ សេវាកម្មនេះមិនមានទេ ប៉ុន្តែមានច្បាប់ iptables ដែលនឹងដំណើរការសំណើ៖

   

3. ផ្នែកខាងក្រោយមួយនឹងត្រូវបានជ្រើសរើសជាអាសយដ្ឋានគោលដៅ៖

   

4. សំណើ​នេះ​បាន​ឈាន​ដល់​កួរ។ នៅចំណុចនេះ ការតភ្ជាប់ TCP ជាប់លាប់រវាងផតទាំងពីរនឹងត្រូវបានបង្កើតឡើង៖

   

5. រាល់សំណើជាបន្តបន្ទាប់ពីផតទីមួយនឹងឆ្លងកាត់ការតភ្ជាប់ដែលបានបង្កើតឡើងរួចហើយ៖

   

លទ្ធផលគឺពេលវេលាឆ្លើយតបកាន់តែលឿន និងទិន្នផលខ្ពស់ ប៉ុន្តែអ្នកបាត់បង់សមត្ថភាពក្នុងការធ្វើមាត្រដ្ឋានផ្នែកខាងក្រោយ។

ទោះបីជាអ្នកមានផតពីរនៅក្នុងផ្នែកខាងក្រោយក៏ដោយ ជាមួយនឹងការតភ្ជាប់ថេរ ចរាចរណ៍នឹងតែងតែទៅកាន់មួយក្នុងចំណោមពួកវា។

តើនេះអាចជួសជុលបានទេ?

ដោយសារ Kubernetes មិនដឹងពីរបៀបធ្វើឱ្យមានតុល្យភាពនៃការតភ្ជាប់ជាប់លាប់ កិច្ចការនេះធ្លាក់មកលើអ្នក។

សេវាកម្មគឺជាបណ្តុំនៃអាសយដ្ឋាន IP និងច្រកដែលហៅថា ចំណុចបញ្ចប់។

កម្មវិធីរបស់អ្នកអាចទទួលបានបញ្ជីនៃចំណុចបញ្ចប់ពីសេវាកម្ម និងសម្រេចចិត្តពីរបៀបចែកចាយសំណើរវាងពួកគេ។ អ្នកអាចបើកការតភ្ជាប់ជាប់លាប់ទៅនឹងផតនីមួយៗ និងសំណើសមតុល្យរវាងការភ្ជាប់ទាំងនេះដោយប្រើ round-robin ។

ឬអនុវត្តបន្ថែមទៀត ក្បួនដោះស្រាយតុល្យភាពស្មុគស្មាញ.

កូដភាគីអតិថិជនដែលទទួលខុសត្រូវចំពោះតុល្យភាពគួរតែអនុវត្តតាមតក្កវិជ្ជានេះ៖

1. ទទួលបានបញ្ជីនៃចំណុចបញ្ចប់ពីសេវាកម្ម។
2. បើកការតភ្ជាប់ជាប់លាប់សម្រាប់ចំណុចបញ្ចប់នីមួយៗ។
3. នៅពេលសំណើត្រូវធ្វើ សូមប្រើការតភ្ជាប់បើកចំហមួយ។
4. ធ្វើឱ្យទាន់សម័យជាទៀងទាត់នូវបញ្ជីនៃចំណុចបញ្ចប់ បង្កើតថ្មី ឬបិទការតភ្ជាប់ជាប់លាប់ចាស់ ប្រសិនបើបញ្ជីផ្លាស់ប្តូរ។

នេះជាអ្វីដែលវានឹងមើលទៅ.

1. ជំនួសឱ្យផតទីមួយផ្ញើសំណើទៅសេវាកម្ម អ្នកអាចធ្វើសមតុល្យសំណើនៅខាងអតិថិជន៖

   

2. អ្នក​ត្រូវ​សរសេរ​កូដ​ដែល​សួរ​ថា​ផត​ណា​ជា​ផ្នែក​នៃ​សេវាកម្ម៖

   

3. នៅពេលដែលអ្នកមានបញ្ជី សូមរក្សាទុកវានៅលើផ្នែកអតិថិជន ហើយប្រើវាដើម្បីភ្ជាប់ទៅផតស៍៖

   

4. អ្នកទទួលខុសត្រូវចំពោះក្បួនដោះស្រាយតុល្យភាពបន្ទុក៖

   

ឥឡូវនេះសំណួរកើតឡើង: តើបញ្ហានេះអនុវត្តចំពោះ HTTP Keep-alive ទេ?

តុល្យភាពបន្ទុកខាងអតិថិជន

HTTP មិនមែនជាពិធីការតែមួយគត់ដែលអាចប្រើការភ្ជាប់ TCP ជាប់លាប់នោះទេ។

ប្រសិនបើកម្មវិធីរបស់អ្នកប្រើមូលដ្ឋានទិន្នន័យ នោះការតភ្ជាប់ TCP មិនត្រូវបានបើករាល់ពេលដែលអ្នកត្រូវការធ្វើការស្នើសុំ ឬទាញយកឯកសារពីមូលដ្ឋានទិន្នន័យនោះទេ។ 

ជំនួសមកវិញ ការតភ្ជាប់ TCP ជាប់លាប់ទៅមូលដ្ឋានទិន្នន័យត្រូវបានបើក និងប្រើប្រាស់។

ប្រសិនបើមូលដ្ឋានទិន្នន័យរបស់អ្នកត្រូវបានដាក់ពង្រាយនៅលើ Kubernetes ហើយការចូលប្រើត្រូវបានផ្តល់ជាសេវាកម្ម នោះអ្នកនឹងជួបប្រទះបញ្ហាដូចគ្នាដែលបានពិពណ៌នានៅក្នុងផ្នែកមុន។

ការចម្លងមូលដ្ឋានទិន្នន័យមួយនឹងត្រូវបានផ្ទុកច្រើនជាងកម្មវិធីផ្សេងទៀត។ Kube-proxy និង Kubernetes នឹងមិនជួយធ្វើឱ្យការតភ្ជាប់មានតុល្យភាពទេ។ អ្នកត្រូវតែយកចិត្តទុកដាក់ដើម្បីធ្វើឱ្យមានតុល្យភាពសំណួរទៅមូលដ្ឋានទិន្នន័យរបស់អ្នក។

អាស្រ័យលើបណ្ណាល័យណាដែលអ្នកប្រើដើម្បីភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យ អ្នកអាចមានជម្រើសផ្សេងគ្នាសម្រាប់ការដោះស្រាយបញ្ហានេះ។

ខាងក្រោមនេះជាឧទាហរណ៍នៃការចូលប្រើចង្កោមមូលដ្ឋានទិន្នន័យ MySQL ពី Node.js៖

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

មានពិធីការជាច្រើនទៀតដែលប្រើការភ្ជាប់ TCP ជាប់លាប់៖

• WebSockets និង WebSockets សុវត្ថិភាព
• HTTP / 2
• gRPC
• RSockets
• អេអឹមខេភី

អ្នក​គួរ​តែ​ស៊ាំ​ជាមួយ​ពិធីការ​ទាំងនេះ​ភាគច្រើន​រួចហើយ។

ប៉ុន្តែប្រសិនបើពិធីការទាំងនេះមានប្រជាប្រិយភាពខ្លាំង ហេតុអ្វីបានជាមិនមានដំណោះស្រាយតុល្យភាពស្តង់ដារ? ហេតុអ្វីបានជាតក្កវិជ្ជាអតិថិជនត្រូវការផ្លាស់ប្តូរ? តើមានដំណោះស្រាយ Kubernetes ដើមទេ?

Kube-proxy និង iptables ត្រូវ​បាន​រចនា​ឡើង​ដើម្បី​គ្រប​ដណ្តប់​លើ​ករណី​ប្រើប្រាស់​ទូទៅ​បំផុត​នៅ​ពេល​ដាក់​ពង្រាយ​ទៅ Kubernetes។ នេះគឺសម្រាប់ភាពងាយស្រួល។

ប្រសិនបើអ្នកកំពុងប្រើប្រាស់សេវាកម្មគេហទំព័រដែលបង្ហាញ REST API អ្នកមានសំណាង - ក្នុងករណីនេះ ការតភ្ជាប់ TCP ជាប់លាប់មិនត្រូវបានប្រើទេ អ្នកអាចប្រើសេវាកម្ម Kubernetes ណាមួយ។

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

ទោះយ៉ាងណាក៏ដោយ វាពិតជាមានជម្រើសដែលអាចជួយបាន។

ធ្វើឱ្យមានតុល្យភាពនៃការតភ្ជាប់ដែលមានអាយុកាលយូរនៅក្នុង Kubernetes

មានសេវាកម្មបួនប្រភេទនៅក្នុង Kubernetes៖

1. ClusterIP
2. NodePort
3. LoadBalancer
4. គ្មានក្បាល

សេវាកម្មបីដំបូងដំណើរការដោយផ្អែកលើអាសយដ្ឋាន IP និម្មិត ដែលត្រូវបានប្រើដោយ kube-proxy ដើម្បីបង្កើតច្បាប់ iptables ។ ប៉ុន្តែ​មូលដ្ឋាន​គ្រឹះ​នៃ​សេវា​ទាំងអស់​គឺ​សេវា​គ្មាន​ក្បាល។

សេវាគ្មានក្បាលមិនមានអាសយដ្ឋាន IP ណាមួយដែលភ្ជាប់ជាមួយវាទេ ហើយគ្រាន់តែផ្តល់យន្តការសម្រាប់ការទាញយកបញ្ជីអាសយដ្ឋាន IP និងច្រកនៃផត (ចំណុចបញ្ចប់) ដែលភ្ជាប់ជាមួយវា។

សេវាកម្មទាំងអស់គឺផ្អែកលើសេវាគ្មានក្បាល។

សេវា ClusterIP គឺជាសេវាកម្មគ្មានក្បាលជាមួយនឹងការបន្ថែមមួយចំនួន៖ 

1. ស្រទាប់គ្រប់គ្រងកំណត់វានូវអាសយដ្ឋាន IP ។
2. Kube-proxy បង្កើតច្បាប់ iptables ចាំបាច់។

វិធីនេះអ្នកអាចមិនអើពើ kube-ប្រូកស៊ី ហើយប្រើដោយផ្ទាល់នូវបញ្ជីនៃចំណុចបញ្ចប់ដែលទទួលបានពីសេវាកម្មគ្មានក្បាល ដើម្បីផ្ទុកសមតុល្យកម្មវិធីរបស់អ្នក។

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

ប្រសិនបើកម្មវិធីរបស់អ្នកត្រូវបានដាក់ឱ្យប្រើប្រាស់រួចហើយ កិច្ចការនេះហាក់ដូចជាមិនអាចទៅរួចនោះទេ។ ទោះយ៉ាងណាក៏ដោយមានជម្រើសជំនួស។

Service Mesh នឹងជួយអ្នក។

អ្នកប្រហែលជាបានកត់សម្គាល់រួចហើយថា យុទ្ធសាស្ត្រតុល្យភាពបន្ទុកភាគីអតិថិជនគឺមានលក្ខណៈស្តង់ដារ។

នៅពេលដែលកម្មវិធីចាប់ផ្តើម វា៖

1. ទទួលបានបញ្ជីអាសយដ្ឋាន IP ពីសេវាកម្ម។
2. បើក និងថែទាំអាងតភ្ជាប់។
3. ធ្វើបច្ចុប្បន្នភាពបណ្តុំជាប្រចាំដោយបន្ថែម ឬដកចំណុចបញ្ចប់ចេញ។

នៅពេលដែលកម្មវិធីចង់ធ្វើការស្នើសុំ វា៖

1. ជ្រើសរើសការតភ្ជាប់ដែលមានដោយប្រើតក្កវិជ្ជាមួយចំនួន (ឧ. ជុំ-រ៉ូប៊ីន)។
2. អនុវត្តការស្នើសុំ។

ជំហានទាំងនេះដំណើរការសម្រាប់ទាំងការភ្ជាប់ WebSockets, gRPC និង AMQP ។

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

ទោះយ៉ាងណាក៏ដោយ អ្នកអាចប្រើសេវា Meshes ដូចជា Istio ឬ Linkerd ជំនួសវិញ។

Service Mesh បង្កើនកម្មវិធីរបស់អ្នកជាមួយនឹងដំណើរការដែល៖

1. ស្វែងរកអាសយដ្ឋាន IP សេវាកម្មដោយស្វ័យប្រវត្តិ។
2. សាកល្បងការតភ្ជាប់ដូចជា WebSockets និង gRPC ។
3. សំណើសមតុល្យដោយប្រើពិធីការត្រឹមត្រូវ។

Service Mesh ជួយគ្រប់គ្រងចរាចរណ៍នៅក្នុងចង្កោម ប៉ុន្តែវាពិតជាពឹងផ្អែកលើធនធាន។ ជម្រើសផ្សេងទៀតកំពុងប្រើបណ្ណាល័យភាគីទីបីដូចជា Netflix Ribbon ឬប្រូកស៊ីដែលអាចសរសេរកម្មវិធីបានដូចជា Envoy ។

តើមានអ្វីកើតឡើង ប្រសិនបើអ្នកមិនអើពើនឹងបញ្ហាតុល្យភាព?

អ្នកអាចជ្រើសរើសមិនប្រើតុល្យភាពបន្ទុក ហើយនៅតែមិនកត់សម្គាល់ការផ្លាស់ប្តូរណាមួយឡើយ។ សូមក្រឡេកមើលសេណារីយ៉ូការងារមួយចំនួន។

ប្រសិនបើអ្នកមានអតិថិជនច្រើនជាងម៉ាស៊ីនមេ នេះមិនមែនជាបញ្ហាធំនោះទេ។

ចូរនិយាយថាមានម៉ាស៊ីនភ្ញៀវប្រាំនាក់ដែលភ្ជាប់ទៅម៉ាស៊ីនមេពីរ។ ទោះបីជាមិនមានតុល្យភាពក៏ដោយ ម៉ាស៊ីនមេទាំងពីរនឹងត្រូវបានប្រើ៖

ការតភ្ជាប់ប្រហែលជាមិនត្រូវបានចែកចាយស្មើៗគ្នាទេ៖ ប្រហែលជាម៉ាស៊ីនភ្ញៀវបួននាក់បានភ្ជាប់ទៅម៉ាស៊ីនមេដូចគ្នា ប៉ុន្តែមានឱកាសល្អដែលម៉ាស៊ីនមេទាំងពីរនឹងត្រូវបានប្រើប្រាស់។

អ្វី​ដែល​ជា​បញ្ហា​ច្រើន​ជាង​នេះ​គឺ​សេណារីយ៉ូ​ផ្ទុយ។

ប្រសិនបើអ្នកមានម៉ាស៊ីនភ្ញៀវតិចជាងមុន និងម៉ាស៊ីនមេច្រើន ធនធានរបស់អ្នកអាចនឹងត្រូវបានប្រើប្រាស់តិច ហើយឧបសគ្គដែលអាចកើតមាននឹងលេចឡើង។

ឧបមាថាមានម៉ាស៊ីនភ្ញៀវពីរ និងម៉ាស៊ីនមេប្រាំ។ ក្នុងករណីដ៏ល្អបំផុត នឹងមានការតភ្ជាប់អចិន្ត្រៃយ៍ពីរទៅកាន់ម៉ាស៊ីនមេពីរក្នុងចំណោមប្រាំ។

ម៉ាស៊ីនមេដែលនៅសល់នឹងនៅទំនេរ៖

ប្រសិនបើម៉ាស៊ីនមេទាំងពីរនេះមិនអាចដោះស្រាយសំណើរបស់អតិថិជនបានទេ ការធ្វើមាត្រដ្ឋានផ្ដេកនឹងមិនអាចជួយបានទេ។

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

សេវាកម្ម Kubernetes ត្រូវបានរចនាឡើងដើម្បីដំណើរការនៅក្នុងសេណារីយ៉ូកម្មវិធីបណ្ដាញស្តង់ដារភាគច្រើន។

ទោះយ៉ាងណាក៏ដោយ នៅពេលដែលអ្នកចាប់ផ្តើមធ្វើការជាមួយពិធីការកម្មវិធីដែលប្រើការភ្ជាប់ TCP ជាប់លាប់ ដូចជាមូលដ្ឋានទិន្នន័យ gRPC ឬ WebSockets សេវាកម្មមិនសមរម្យទៀតទេ។ Kubernetes មិនផ្តល់យន្តការខាងក្នុងសម្រាប់តុល្យភាពការតភ្ជាប់ TCP ជាប់លាប់ទេ។

នេះមានន័យថាអ្នកត្រូវតែសរសេរកម្មវិធីដោយមានតុល្យភាពផ្នែកខាងអតិថិជននៅក្នុងចិត្ត។

ការបកប្រែរៀបចំដោយក្រុម Kubernetes aaS ពី Mail.ru.

តើមានអ្វីទៀតដែលត្រូវអានលើប្រធានបទ:

1. កម្រិតនៃការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិចំនួនបីនៅក្នុង Kubernetes និងរបៀបប្រើប្រាស់ពួកវាប្រកបដោយប្រសិទ្ធភាព. 
2. Kubernetes ក្នុងស្មារតីនៃការលួចចម្លងជាមួយគំរូសម្រាប់ការអនុវត្ត.
3. ប៉ុស្តិ៍ Telegram របស់យើងអំពីការផ្លាស់ប្តូរឌីជីថល.

ប្រភព: www.habr.com