ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ និងការគ្រប់គ្រងធនធាននៅក្នុង Kubernetes (ការពិនិត្យឡើងវិញ និងរបាយការណ៍វីដេអូ)

ថ្ងៃទី 27 ខែមេសានៅក្នុងសន្និសីទ កូដកម្មឆ្នាំ 2019ជាផ្នែកមួយនៃផ្នែក "DevOps" របាយការណ៍ "ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ និងការគ្រប់គ្រងធនធាននៅក្នុង Kubernetes" ត្រូវបានផ្តល់ឱ្យ។ វានិយាយអំពីរបៀបដែលអ្នកអាចប្រើ K8s ដើម្បីធានាបាននូវភាពអាចរកបានខ្ពស់នៃកម្មវិធីរបស់អ្នក និងធានាបាននូវប្រសិទ្ធភាពខ្ពស់បំផុត។

តាមប្រពៃណីយើងរីករាយក្នុងការបង្ហាញ វីដេអូនៃរបាយការណ៍ (៤៤ នាទី ផ្តល់ព័ត៌មានច្រើនជាងអត្ថបទ) និងសេចក្តីសង្ខេបសំខាន់ក្នុងទម្រង់ជាអត្ថបទ។ ទៅ!

ចូរយើងវិភាគប្រធានបទនៃពាក្យរបាយការណ៍ដោយពាក្យហើយចាប់ផ្តើមពីចុងបញ្ចប់។

Kubernetes

ចូរនិយាយថាយើងមាន Docker containers នៅលើម៉ាស៊ីនរបស់យើង។ ដើម្បីអ្វី? ដើម្បីធានាបាននូវភាពអាចធ្វើឡើងវិញបាន និងភាពឯកោ ដែលអនុញ្ញាតឱ្យមានការដាក់ពង្រាយសាមញ្ញ និងល្អ CI/CD ។ យើង​មាន​រថយន្ត​ប្រភេទ​នេះ​ជា​ច្រើន​ដែល​មាន​កុងតឺន័រ។

តើ Kubernetes ផ្តល់អ្វីខ្លះក្នុងករណីនេះ?

1. យើងឈប់គិតអំពីម៉ាស៊ីនទាំងនេះ ហើយចាប់ផ្តើមធ្វើការជាមួយ "ពពក" ចង្កោមធុង ឬផត (ក្រុមនៃធុង) ។
2. លើស​ពី​នេះ​ទៅ​ទៀត យើង​មិន​គិត​អំពី​ការ​ធ្វើ​ជា​បុគ្គល​នោះ​ទេ ប៉ុន្តែ​ត្រូវ​គ្រប់គ្រង​បន្ថែម​ទៀត។оក្រុមធំជាង។ បែប បុព្វបទកម្រិតខ្ពស់ អនុញ្ញាតឱ្យយើងនិយាយថាមានគំរូសម្រាប់ដំណើរការបន្ទុកការងារជាក់លាក់មួយ ហើយនេះគឺជាចំនួនករណីដែលត្រូវការដើម្បីដំណើរការវា។ ប្រសិនបើយើងផ្លាស់ប្តូរគំរូជាបន្តបន្ទាប់ នោះវត្ថុទាំងអស់នឹងផ្លាស់ប្តូរ។
3. ដោយមានជំនួយពី API ប្រកាស ជំនួសឱ្យការប្រតិបត្តិតាមលំដាប់នៃពាក្យបញ្ជាជាក់លាក់មួយ យើងពិពណ៌នាអំពី "រចនាសម្ព័ន្ធនៃពិភពលោក" (នៅក្នុង YAML) ដែលត្រូវបានបង្កើតឡើងដោយ Kubernetes ។ ហើយម្តងទៀត៖ នៅពេលដែលការពិពណ៌នាផ្លាស់ប្តូរ ការបង្ហាញជាក់ស្តែងរបស់វាក៏នឹងផ្លាស់ប្តូរផងដែរ។

ការ​គ្រប់​គ្រង​ធនធាន

ស៊ីភីយូ

អនុញ្ញាតឱ្យយើងដំណើរការ nginx, php-fpm និង mysql នៅលើម៉ាស៊ីនមេ។ សេវាកម្មទាំងនេះពិតជានឹងមានដំណើរការកាន់តែច្រើនដែលដំណើរការ ដែលនីមួយៗត្រូវការធនធានកុំព្យូទ័រ៖

(លេខនៅលើស្លាយគឺ "សេក" តម្រូវការអរូបីនៃដំណើរការនីមួយៗសម្រាប់ថាមពលកុំព្យូទ័រ)

ដើម្បីធ្វើឱ្យវាកាន់តែងាយស្រួលក្នុងការធ្វើការជាមួយនេះ វាជាឡូជីខលក្នុងការបញ្ចូលគ្នានូវដំណើរការទៅជាក្រុម (ឧទាហរណ៍ ដំណើរការ nginx ទាំងអស់ទៅជាក្រុមតែមួយ "nginx")។ វិធីសាមញ្ញ និងជាក់ស្តែងក្នុងការធ្វើនេះគឺដាក់ក្រុមនីមួយៗក្នុងធុងមួយ៖

ដើម្បីបន្ត អ្នកត្រូវចាំថាធុងជាអ្វី (នៅក្នុងលីនុច)។ រូបរាង​របស់​ពួក​វា​ត្រូវ​បាន​ធ្វើ​ឡើង​ដោយ​សារ​តែ​លក្ខណៈ​សំខាន់​បី​នៅ​ក្នុង​ខឺណែល​ដែល​បាន​អនុវត្ត​ជា​យូរ​មក​ហើយ៖ សមត្ថភាព, ចន្លោះឈ្មោះ и ក្រុម. ហើយការអភិវឌ្ឍន៍បន្ថែមទៀតត្រូវបានសម្របសម្រួលដោយបច្ចេកវិទ្យាផ្សេងទៀត (រួមទាំង "សែល" ងាយស្រួលដូចជា Docker)៖

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

តោះត្រឡប់ទៅតម្រូវការ CPU សម្រាប់ដំណើរការទាំងនេះ ហើយឥឡូវនេះសម្រាប់ក្រុមនៃដំណើរការ៖

(ខ្ញុំនិយាយឡើងវិញថា លេខទាំងអស់គឺជាកន្សោមអរូបីនៃតម្រូវការធនធាន)

ក្នុងពេលជាមួយគ្នានេះ CPU ខ្លួនវាមានធនធានកំណត់ជាក់លាក់ (ក្នុងឧទាហរណ៍នេះគឺ 1000)ដែលគ្រប់គ្នាអាចនឹងខ្វះ (ផលបូកនៃតម្រូវការរបស់ក្រុមទាំងអស់គឺ 150+850+460=1460)។ តើនឹងមានអ្វីកើតឡើងក្នុងករណីនេះ?

ខឺណែលចាប់ផ្តើមចែកចាយធនធាន ហើយធ្វើវា "ដោយយុត្តិធម៌" ដោយផ្តល់ចំនួនធនធានដូចគ្នាដល់ក្រុមនីមួយៗ។ ប៉ុន្តែនៅក្នុងករណីដំបូង វាមានច្រើនជាងតម្រូវការ (333>150) ដូច្នេះចំនួនលើស (333-150=183) នៅតែមាននៅក្នុងទុនបម្រុង ដែលត្រូវបានចែកចាយស្មើៗគ្នារវាងធុងពីរផ្សេងទៀត៖

ជាលទ្ធផល៖ ធុងទីមួយមានធនធានគ្រប់គ្រាន់ ទីពីរ - វាមិនមានធនធានគ្រប់គ្រាន់ ទីបី - វាមិនមានធនធានគ្រប់គ្រាន់។ នេះគឺជាលទ្ធផលនៃសកម្មភាព កម្មវិធីកំណត់ពេល "ស្មោះត្រង់" នៅក្នុងលីនុច - CFS. ប្រតិបត្តិការរបស់វាអាចត្រូវបានកែតម្រូវដោយប្រើកិច្ចការ ទំងន់ ធុងនីមួយៗ។ ឧទាហរណ៍ដូចនេះ៖

សូមក្រឡេកមើលករណីនៃកង្វះធនធាននៅក្នុងធុងទីពីរ (php-fpm) ។ ធនធានធុងទាំងអស់ត្រូវបានចែកចាយស្មើៗគ្នារវាងដំណើរការ។ ជាលទ្ធផល ដំណើរការមេដំណើរការល្អ ប៉ុន្តែកម្មករទាំងអស់ថយចុះ ដោយទទួលបានតិចជាងពាក់កណ្តាលនៃអ្វីដែលពួកគេត្រូវការ៖

នេះជារបៀបដែលកម្មវិធីកំណត់ពេល CFS ដំណើរការ។ យើង​នឹង​ហៅ​ទៀត​ថា​ទម្ងន់​ដែល​យើង​កំណត់​ទៅ​កុងតឺន័រ សំណើ. ហេតុអ្វីបានជាដូច្នេះ - សូមមើលបន្ថែម។

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

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

តោះត្រឡប់ទៅខឺណែលលីនុច និងអន្តរកម្មរបស់វាជាមួយស៊ីភីយូ - រូបភាពរួមមានដូចខាងក្រោម៖

cgroup មានការកំណត់ពីរ - សំខាន់ទាំងនេះគឺជា "ការបង្វិល" សាមញ្ញចំនួនពីរដែលអនុញ្ញាតឱ្យអ្នកកំណត់:

1. ទំងន់សម្រាប់កុងតឺន័រ (សំណើ) គឺ ភាគហ៊ុន;
2. ភាគរយនៃពេលវេលាស៊ីភីយូសរុបសម្រាប់ធ្វើការលើកិច្ចការកុងតឺន័រ (ដែនកំណត់) គឺ កូតា.

របៀបវាស់ស៊ីភីយូ?

មានវិធីផ្សេងៗគ្នា៖

1. តើអ្វីទៅជា សេកគ្មាននរណាម្នាក់ដឹងទេ - អ្នកត្រូវចរចារាល់ពេល។
2. ចំណាប់អារម្មណ៍ ច្បាស់ជាង ប៉ុន្តែទាក់ទងគ្នា៖ 50% នៃ server ដែលមាន 4 cores និង 20 cores គឺខុសគ្នាទាំងស្រុង។
3. អ្នកអាចប្រើអ្វីដែលបានរៀបរាប់រួចហើយ ទំងន់ដែលលីនុចដឹង ប៉ុន្តែពួកគេក៏ជាសាច់ញាតិផងដែរ។
4. ជម្រើសដែលសមស្របបំផុតគឺការវាស់វែងធនធានកុំព្យូទ័រ វិនាទី. ទាំងនោះ។ គិតជាវិនាទីនៃពេលវេលាដំណើរការទាក់ទងទៅនឹងវិនាទីនៃពេលវេលាពិត៖ 1 វិនាទីនៃពេលវេលាដំណើរការត្រូវបានផ្តល់ឱ្យក្នុង 1 វិនាទីពិតប្រាកដ - នេះគឺជាស្នូលស៊ីភីយូទាំងមូល។

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

សូមពិចារណាឧទាហរណ៍ដ៏សាមញ្ញមួយជាមួយម៉ាស៊ីនមេដែលមានស្នូលស៊ីភីយូ 3 ដែលផតឃែរចំនួនបីនឹងត្រូវបានផ្តល់ទម្ងន់ (500, 1000 និង 1500) ដែលត្រូវបានបម្លែងយ៉ាងងាយស្រួលទៅជាផ្នែកដែលត្រូវគ្នានៃស្នូលដែលបានបម្រុងទុកសម្រាប់ពួកគេ (0,5, 1 និង 1,5) ។

ប្រសិនបើអ្នកយកម៉ាស៊ីនមេទីពីរ ដែលជាកន្លែងដែលនឹងមានស្នូលពីរដង (6) ហើយដាក់ផតដូចគ្នានៅទីនោះ ការចែកចាយស្នូលអាចត្រូវបានគណនាយ៉ាងងាយស្រួលដោយគ្រាន់តែគុណនឹង 2 (1, 2 និង 3 រៀងគ្នា)។ ប៉ុន្តែពេលដ៏សំខាន់មួយកើតឡើងនៅពេលដែលផតទីបួនលេចឡើងនៅលើម៉ាស៊ីនមេនេះ ដែលទម្ងន់របស់វាសម្រាប់ភាពងាយស្រួលនឹងមាន 3000។ វាដកផ្នែកមួយនៃធនធានស៊ីភីយូ (ពាក់កណ្តាលស្នូល) ហើយសម្រាប់ផតដែលនៅសេសសល់ ពួកគេត្រូវបានគណនាឡើងវិញ (ពាក់កណ្តាល):

Kubernetes និងធនធាន CPU

នៅក្នុង Kubernetes ធនធាន CPU ជាធម្មតាត្រូវបានវាស់នៅក្នុង មីលាដ្រាក់, i.e. ស្នូល 0,001 ត្រូវបានយកជាទម្ងន់មូលដ្ឋាន។ (ពាក្យដដែលៗនៅក្នុងលីនុច/cgroups វាក្យស័ព្ទត្រូវបានគេហៅថា ការចែករំលែកស៊ីភីយូ ទោះបីជាច្បាស់ជាងនេះទៅទៀត 1000 millicores = 1024 CPU shares។) K8s ធានាថាវាមិនដាក់ pods ច្រើននៅលើ server ជាជាងមានធនធាន CPU សម្រាប់ផលបូកនៃទម្ងន់នៃ pods ទាំងអស់។

តើរឿងនេះកើតឡើងដោយរបៀបណា? នៅពេលអ្នកបន្ថែមម៉ាស៊ីនមេទៅចង្កោម Kubernetes វាត្រូវបានរាយការណ៍ថាមានស្នូលស៊ីភីយូប៉ុន្មានដែលវាមាន។ ហើយនៅពេលបង្កើតផតថ្មី អ្នកកំណត់ពេល Kubernetes ដឹងពីចំនួនស្នូលដែលផតនេះនឹងត្រូវការ។ ដូច្នេះ ផតនឹងត្រូវបានចាត់ឱ្យទៅម៉ាស៊ីនមេដែលមានស្នូលគ្រប់គ្រាន់។

តើនឹងមានអ្វីកើតឡើងប្រសិនបើ មិនមាន សំណើត្រូវបានបញ្ជាក់ (ឧ. pod មិនមានចំនួនស្នូលដែលវាត្រូវការ)? ចូរយើងស្វែងយល់ពីរបៀបដែល Kubernetes ជាទូទៅរាប់ធនធាន។

សម្រាប់ pod អ្នកអាចបញ្ជាក់សំណើទាំងពីរ (កម្មវិធីកំណត់ពេល CFS) និងដែនកំណត់ (ចងចាំភ្លើងចរាចរណ៍?)៖

• ប្រសិនបើពួកវាត្រូវបានបញ្ជាក់ស្មើ នោះផតត្រូវបានចាត់ថ្នាក់ QoS ធានា. ចំនួនស្នូលនេះតែងតែមានសម្រាប់វាត្រូវបានធានា។
• ប្រសិនបើសំណើតិចជាងដែនកំណត់ - ថ្នាក់ QoS អាចផ្ទុះបាន។. ទាំងនោះ។ ជាឧទាហរណ៍ យើងរំពឹងថា pod តែងតែប្រើ 1 core ប៉ុន្តែតម្លៃនេះមិនមែនជាដែនកំណត់សម្រាប់វាទេ៖ иногда pod អាចប្រើប្រាស់បានច្រើនជាងនេះ (នៅពេលដែលម៉ាស៊ីនមេមានធនធានឥតគិតថ្លៃសម្រាប់វា)។
• ក៏មានថ្នាក់ QoS ផងដែរ។ ការខិតខំប្រឹងប្រែងដ៏ល្អបំផុត - វារួមបញ្ចូលផតថលទាំងនោះ ដែលសំណើមិនត្រូវបានបញ្ជាក់។ ធនធានត្រូវបានផ្តល់ឱ្យពួកគេចុងក្រោយ។

អង្គចងចាំ

ជាមួយនឹងការចងចាំស្ថានភាពគឺស្រដៀងគ្នាប៉ុន្តែខុសគ្នាបន្តិចបន្តួច - បន្ទាប់ពីទាំងអស់ធម្មជាតិនៃធនធានទាំងនេះគឺខុសគ្នា។ ជាទូទៅ ភាពស្រដៀងគ្នាមានដូចខាងក្រោម៖

តោះមើលពីរបៀបដែលសំណើត្រូវបានអនុវត្តនៅក្នុងសតិ។ អនុញ្ញាតឱ្យផតផតរស់នៅលើម៉ាស៊ីនមេ ផ្លាស់ប្តូរការប្រើប្រាស់អង្គចងចាំ រហូតដល់មួយក្នុងចំណោមពួកវាធំរហូតដល់អស់អង្គចងចាំ។ ក្នុងករណីនេះឃាតករ OOM លេចឡើងហើយសម្លាប់ដំណើរការធំបំផុត:

នេះមិនតែងតែសមនឹងយើងទេ ដូច្នេះវាអាចគ្រប់គ្រងដំណើរការណាមួយដែលសំខាន់សម្រាប់យើង និងមិនគួរត្រូវបានសម្លាប់។ ដើម្បីធ្វើដូចនេះសូមប្រើប៉ារ៉ាម៉ែត្រ oom_score_adj.

ចូរយើងត្រលប់ទៅថ្នាក់ QoS នៃស៊ីភីយូ ហើយគូរភាពស្រដៀងគ្នាជាមួយនឹងតម្លៃ oom_score_adj ដែលកំណត់អាទិភាពនៃការប្រើប្រាស់អង្គចងចាំសម្រាប់ផតៈ

• តម្លៃ oom_score_adj ទាបបំផុតសម្រាប់ផត - -998 - មានន័យថាផតបែបនេះគួរតែត្រូវបានសម្លាប់ចុងក្រោយនេះ ធានា.
• ខ្ពស់បំផុត - 1000 - គឺ ការខិតខំប្រឹងប្រែងដ៏ល្អបំផុតគ្រាប់បែបនេះត្រូវបានសម្លាប់មុន។
• ដើម្បីគណនាតម្លៃដែលនៅសល់ (អាចផ្ទុះបាន។) មានរូបមន្តមួយ ខ្លឹមសារដែលពុះកញ្ជ្រោលដល់ការពិតដែលថា ធនធានកាន់តែច្រើនដែល pod បានស្នើសុំនោះ ទំនងជាវានឹងត្រូវបានសម្លាប់តិច។

"បង្វិល" ទីពីរ - limit_in_bytes - សម្រាប់ដែនកំណត់។ ជាមួយវា អ្វីគ្រប់យ៉ាងគឺសាមញ្ញជាង៖ យើងគ្រាន់តែកំណត់ចំនួនអតិបរមានៃអង្គចងចាំដែលបានចេញ ហើយនៅទីនេះ (មិនដូច CPU) មិនមានសំណួរអំពីរបៀបវាស់វា (អង្គចងចាំ) ទេ។

សរុប

ផតនីមួយៗនៅក្នុង Kubernetes ត្រូវបានផ្តល់ឱ្យ requests и limits - ប៉ារ៉ាម៉ែត្រទាំងពីរសម្រាប់ CPU និងអង្គចងចាំ៖

1. ដោយផ្អែកលើសំណើ កម្មវិធីកំណត់ពេល Kubernetes ដំណើរការ ដែលចែកចាយ pods ក្នុងចំណោមម៉ាស៊ីនមេ។
2. ដោយផ្អែកលើប៉ារ៉ាម៉ែត្រទាំងអស់ ថ្នាក់ QoS របស់ pod ត្រូវបានកំណត់។
3. ទម្ងន់ដែលទាក់ទងត្រូវបានគណនាដោយផ្អែកលើសំណើរបស់ស៊ីភីយូ។
4. កម្មវិធីកំណត់ពេល CFS ត្រូវបានកំណត់រចនាសម្ព័ន្ធដោយផ្អែកលើសំណើរបស់ស៊ីភីយូ។
5. ឃាតករ OOM ត្រូវបានកំណត់រចនាសម្ព័ន្ធដោយផ្អែកលើសំណើអង្គចងចាំ។
6. "ភ្លើងចរាចរណ៍" ត្រូវបានកំណត់រចនាសម្ព័ន្ធដោយផ្អែកលើដែនកំណត់ស៊ីភីយូ។
7. ដោយផ្អែកលើដែនកំណត់នៃអង្គចងចាំ ដែនកំណត់មួយត្រូវបានកំណត់រចនាសម្ព័ន្ធសម្រាប់ cgroup ។

ជាទូទៅ រូបភាពនេះឆ្លើយសំណួរទាំងអស់អំពីរបៀបដែលផ្នែកសំខាន់នៃការគ្រប់គ្រងធនធានកើតឡើងនៅក្នុង Kubernetes ។

ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ

K8s cluster-autoscaler

ចូរយើងស្រមៃថាចង្កោមទាំងមូលត្រូវបានកាន់កាប់រួចហើយ ហើយត្រូវការបង្កើតផតថ្មីមួយ។ ខណៈពេលដែលផតមិនអាចលេចឡើង វាព្យួរនៅក្នុងស្ថានភាព មិនទាន់សម្រេច. ដើម្បីឱ្យវាលេចឡើង យើងអាចភ្ជាប់ម៉ាស៊ីនមេថ្មីទៅចង្កោម ឬ... ដំឡើង cluster-autoscaler ដែលនឹងធ្វើវាសម្រាប់យើង៖ បញ្ជាម៉ាស៊ីននិម្មិតពីអ្នកផ្តល់សេវាពពក (ដោយប្រើសំណើ API) ហើយភ្ជាប់វាទៅចង្កោម បន្ទាប់ពីនោះ ផតនឹងត្រូវបានបន្ថែម។

នេះគឺជាការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិនៃក្រុម Kubernetes ដែលដំណើរការល្អ (នៅក្នុងបទពិសោធន៍របស់យើង)។ ទោះយ៉ាងណាក៏ដោយដូចនៅកន្លែងផ្សេងទៀតមាន nuances មួយចំនួននៅទីនេះ ...

ដរាបណាយើងបង្កើនទំហំចង្កោម អ្វីគ្រប់យ៉ាងគឺល្អ ប៉ុន្តែតើមានអ្វីកើតឡើងនៅពេលដែលចង្កោម បានចាប់ផ្តើមដោះលែងខ្លួនឯង? បញ្ហាគឺថាការធ្វើចំណាកស្រុក pods (ដើម្បីដោះលែង hosts) គឺពិបាកណាស់តាមបច្ចេកទេស និងមានតម្លៃថ្លៃទាក់ទងនឹងធនធាន។ Kubernetes ប្រើវិធីសាស្រ្តខុសគ្នាទាំងស្រុង។

ពិចារណាលើចង្កោមនៃម៉ាស៊ីនមេចំនួន 3 ដែលមានការដាក់ពង្រាយ។ វាមាន 6 pods: ឥឡូវនេះមាន 2 សម្រាប់ម៉ាស៊ីនមេនីមួយៗ។ សម្រាប់ហេតុផលមួយចំនួន យើងចង់បិទម៉ាស៊ីនមេមួយ។ ដើម្បីធ្វើដូចនេះយើងនឹងប្រើពាក្យបញ្ជា kubectl drainដែល៖

• នឹងហាមឃាត់ការផ្ញើ pods ថ្មីទៅកាន់ម៉ាស៊ីនមេនេះ;
• នឹងលុបផតដែលមានស្រាប់នៅលើម៉ាស៊ីនមេ។

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

ទោះយ៉ាងណាក៏ដោយ ក៏មានចំណុចពិសេសមួយនៅទីនេះផងដែរ។ នៅក្នុងស្ថានភាពស្រដៀងគ្នានេះ សម្រាប់ StatefulSet (ជំនួសឱ្យការដាក់ពង្រាយ) សកម្មភាពនឹងខុសគ្នា។ ឥឡូវនេះ យើងមានកម្មវិធីដែលមានលក្ខណៈរដ្ឋរួចហើយ - ឧទាហរណ៍ ផតឃែរចំនួនបីជាមួយ MongoDB ដែលមួយក្នុងចំណោមនោះមានបញ្ហាមួយចំនួន (ទិន្នន័យបានក្លាយទៅជាខូច ឬកំហុសមួយទៀតដែលរារាំងផតផតពីការចាប់ផ្តើមត្រឹមត្រូវ)។ ហើយយើងម្តងទៀតសម្រេចចិត្តបិទម៉ាស៊ីនមេមួយ។ តើនឹងមានអ្វីកើតឡើង?

MongoDB អាច ស្លាប់ព្រោះវាត្រូវការកូរ៉ុម៖ សម្រាប់ចង្កោមនៃការដំឡើងបី យ៉ាងហោចណាស់ពីរត្រូវតែដំណើរការ។ ទោះយ៉ាងណាក៏ដោយនេះ។ មិនកើតឡើង - អរគុណ​ចំពោះ PodDisruptionBudget. ប៉ារ៉ាម៉ែត្រនេះកំណត់ចំនួនអប្បបរមាដែលត្រូវការនៃ pods ដែលធ្វើការ។ ដោយដឹងថាផតផត MongoDB មួយមិនដំណើរការទៀតទេ ហើយឃើញថា PodDisruptionBudget ត្រូវបានកំណត់សម្រាប់ MongoDB minAvailable: 2Kubernetes នឹងមិនអនុញ្ញាតឱ្យអ្នកលុបផតទេ។

បន្ទាត់ខាងក្រោម៖ ដើម្បីឱ្យចលនា (ហើយជាការពិត ការបង្កើតឡើងវិញ) នៃផតឃែរ ដំណើរការបានត្រឹមត្រូវនៅពេលដែលចង្កោមត្រូវបានបញ្ចេញ វាចាំបាច់ក្នុងការកំណត់រចនាសម្ព័ន្ធ PodDisruptionBudget ។

ការធ្វើមាត្រដ្ឋានផ្ដេក

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

ថ្ងៃនេះនៅក្នុង Kubernetes វាមិនចាំបាច់ធ្វើដោយដៃទេ៖ ការកើនឡើង/បន្ថយដោយស្វ័យប្រវត្តិនៃចំនួន pods ត្រូវបានកំណត់រចនាសម្ព័ន្ធអាស្រ័យលើតម្លៃនៃសូចនាករបន្ទុកដែលបានវាស់។

សំណួរសំខាន់ៗនៅទីនេះគឺ៖ អ្វីដែលត្រូវវាស់វែង и របៀបបកស្រាយ ទទួលបានតម្លៃ (សម្រាប់ការសម្រេចចិត្តលើការផ្លាស់ប្តូរចំនួន pods) ។ អ្នកអាចវាស់វែងបានច្រើន៖

របៀបធ្វើវាតាមបច្ចេកទេស - ប្រមូលម៉ែត្រ។ល។ - ខ្ញុំបាននិយាយលម្អិតនៅក្នុងរបាយការណ៍អំពី ការត្រួតពិនិត្យ និង Kubernetes. ហើយដំបូន្មានសំខាន់សម្រាប់ការជ្រើសរើសប៉ារ៉ាម៉ែត្រដ៏ល្អប្រសើរគឺ ពិសោធន៍!

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

ជំនួសឱ្យការសន្និដ្ឋានមួយ

របាយការណ៍នេះមានការបន្ត៖ អំពីការធ្វើមាត្រដ្ឋានបញ្ឈរ និងរបៀបជ្រើសរើសធនធានត្រឹមត្រូវ។ ខ្ញុំនឹងនិយាយអំពីរឿងនេះនៅក្នុងវីដេអូនាពេលអនាគតនៅលើ YouTube របស់យើង។ - Subscribe ដើម្បីកុំឲ្យខកខាន!

វីដេអូ និងស្លាយ

វីដេអូពីការសម្តែង (៤៤ នាទី)៖

បទបង្ហាញនៃរបាយការណ៍៖

PS

របាយការណ៍ផ្សេងទៀតអំពី Kubernetes នៅលើប្លក់របស់យើង៖

• «ការពង្រីក និងបំពេញបន្ថែម Kubernetes» (Andrey Polovov; ថ្ងៃទី 8 ខែមេសា ឆ្នាំ 2019 នៅលើ Saint HighLoad++);
• «មូលដ្ឋានទិន្នន័យ និង Kubernetes» (Dmitry Stolyarov; ថ្ងៃទី 8 ខែវិច្ឆិកាឆ្នាំ 2018 នៅលើ HighLoad ++);
• «ការត្រួតពិនិត្យ និង Kubernetes» (Dmitry Stolyarov; 28 ឧសភា 2018 នៅ RootConf);
• «CI/CD ការអនុវត្តល្អបំផុតជាមួយ Kubernetes និង GitLab» (Dmitry Stolyarov; ថ្ងៃទី 7 ខែវិច្ឆិកាឆ្នាំ 2017 នៅលើ HighLoad ++);
• «បទពិសោធន៍របស់យើងជាមួយ Kubernetes ក្នុងគម្រោងតូចៗ» (Dmitry Stolyarov; ថ្ងៃទី 6 ខែមិថុនា ឆ្នាំ 2017 នៅ RootConf).

ប្រភព: www.habr.com