Kubernetes នឹងកាន់កាប់ពិភពលោក។ តើនៅពេលណា និងដោយរបៀបណា?

នៅមុនថ្ងៃនៃ DevOpsConf Vitaly Khabarov សម្ភាស លោក Dmitry Stolyarov (ឌីស្តុល) នាយកបច្ចេកទេស និងជាសហស្ថាបនិកនៃក្រុមហ៊ុន Flant ។ Vitaly បានសួរ Dmitry អំពីអ្វីដែល Flan ធ្វើ អំពី Kubernetes ការអភិវឌ្ឍន៍ប្រព័ន្ធអេកូ ការគាំទ្រ។ យើងបានពិភាក្សាអំពីមូលហេតុដែល Kubernetes ត្រូវការ និងថាតើវាត្រូវការអ្វីទាំងអស់។ ហើយក៏អំពីសេវាកម្មខ្នាតតូចផងដែរ Amazon AWS វិធីសាស្រ្ត "ខ្ញុំនឹងមានសំណាង" ចំពោះ DevOps អនាគតរបស់ Kubernetes ខ្លួនវា ហេតុអ្វី ពេលណា និងរបៀបដែលវានឹងកាន់កាប់លើពិភពលោក ការរំពឹងទុករបស់ DevOps និងអ្វីដែលវិស្វករគួររៀបចំនៅក្នុង អនាគតដ៏ភ្លឺស្វាង ជាមួយនឹងភាពសាមញ្ញ និងបណ្តាញសរសៃប្រសាទ។

បទសម្ភាសន៍ដើម ស្តាប់ជាទម្រង់ផតខាសនៅលើ DevOps Deflop ដែលជាផតខាសជាភាសារុស្សីអំពី DevOps ហើយខាងក្រោមគឺជាកំណែអត្ថបទ។

នៅទីនេះនិងខាងក្រោមគាត់សួរសំណួរ Vitaly Khabarov វិស្វករមកពី Express42 ។

អំពី "Flant"

- សួស្តីឌីម៉ា។ អ្នកគឺជានាយកបច្ចេកទេស"ផ្លិត” ហើយ​ក៏​ជា​ស្ថាបនិក​របស់​វា​ដែរ។ សូម​ប្រាប់​យើង​ពី​អ្វី​ដែល​ក្រុមហ៊ុន​ធ្វើ និង​អ្វី​ដែល​អ្នក​នៅ​ក្នុង​នោះ?

Dmitry៖ ពីខាងក្រៅវាហាក់បីដូចជាយើងជាបុរសដែលចូលទៅដំឡើង Kubernetes សម្រាប់អ្នករាល់គ្នា ហើយធ្វើអ្វីមួយជាមួយវា។ ប៉ុន្តែនេះមិនមែនជាការពិតទេ។ យើងបានចាប់ផ្តើមជាក្រុមហ៊ុនដែលទាក់ទងនឹងលីនុច ប៉ុន្តែអស់រយៈពេលជាយូរណាស់មកហើយ សកម្មភាពចម្បងរបស់យើងគឺសេវាកម្មផលិតកម្ម និងគម្រោង turnkey ដែលមានបន្ទុកខ្ពស់។ ជាធម្មតាយើងសាងសង់ហេដ្ឋារចនាសម្ព័ន្ធទាំងមូលតាំងពីដំបូង ហើយបន្ទាប់មកទទួលខុសត្រូវចំពោះវាក្នុងរយៈពេលយូរ។ ដូច្នេះការងារចម្បងដែល "Flant" ធ្វើដែលវាទទួលបានប្រាក់គឺ ទទួលខុសត្រូវ និងអនុវត្តផលិតកម្ម turnkey.




ខ្ញុំក្នុងនាមជានាយកបច្ចេកទេស និងជាស្ថាបនិកម្នាក់នៃក្រុមហ៊ុន ចំណាយពេលពេញមួយថ្ងៃទាំងយប់ ព្យាយាមរកវិធីបង្កើនភាពងាយស្រួលនៃផលិតកម្ម សម្រួលប្រតិបត្តិការរបស់ខ្លួន ធ្វើឱ្យជីវិតអ្នកគ្រប់គ្រងកាន់តែងាយស្រួល និងធ្វើឱ្យជីវិតរបស់អ្នកអភិវឌ្ឍន៍កាន់តែច្រើន។ រីករាយ។

អំពី Kubernetes

- ថ្មីៗនេះខ្ញុំបានឃើញរបាយការណ៍ជាច្រើនពី "Flant" និង អត្ថបទ អំពី Kubernetes ។ តើអ្នកមករកគាត់ដោយរបៀបណា?

Dmitry៖ ខ្ញុំ​បាន​និយាយ​អំពី​រឿង​នេះ​ជា​ច្រើន​ដង​រួច​មក​ហើយ ប៉ុន្តែ​ខ្ញុំ​មិន​ខ្វល់​នឹង​ការ​និយាយ​វា​ម្ដង​ទៀត​ឡើយ។ ខ្ញុំ​គិត​ថា​វា​ត្រឹមត្រូវ​ក្នុង​ការ​និយាយ​ប្រធានបទ​នេះ​ឡើង​វិញ​ព្រោះ​មាន​ការ​ច្របូកច្របល់​រវាង​ហេតុ​និង​ផល។

យើងពិតជាត្រូវការឧបករណ៍។ យើងបានប្រឈមមុខនឹងបញ្ហាជាច្រើន តស៊ូ យកឈ្នះពួកគេដោយប្រើឈើច្រត់ផ្សេងៗ ហើយមានអារម្មណ៍ថាត្រូវការឧបករណ៍។ យើងបានឆ្លងកាត់ជម្រើសផ្សេងៗជាច្រើន បង្កើតកង់ដោយខ្លួនឯង និងទទួលបានបទពិសោធន៍។ បន្តិចម្ដងៗយើងឈានដល់ចំណុចដែលយើងចាប់ផ្តើមប្រើ Docker ស្ទើរតែភ្លាមៗនៅពេលដែលវាបង្ហាញខ្លួន - ប្រហែលឆ្នាំ 2013 ។ នៅពេលនៃការបង្ហាញខ្លួនរបស់វា យើងមានបទពិសោធន៍ជាច្រើនជាមួយកុងតឺន័រ យើងបានសរសេរ analogue នៃ "Docker" រួចហើយ ដែលជាឈើច្រត់ផ្ទាល់ខ្លួនរបស់យើងនៅក្នុង Python ។ ជាមួយនឹងវត្តមានរបស់ Docker វាអាចបោះឈើច្រត់ចេញ ហើយប្រើប្រាស់ដំណោះស្រាយដែលអាចទុកចិត្តបាន និងគាំទ្រដោយសហគមន៍។

ជាមួយ Kubernetes រឿងគឺស្រដៀងគ្នា។ នៅពេលដែលវាចាប់ផ្តើមទទួលបានសន្ទុះ - សម្រាប់ពួកយើង នេះគឺជាកំណែ 1.2 - យើងមានឈើច្រត់ជាច្រើននៅលើ Shell និង Chef រួចហើយ ដែលយើងព្យាយាមរៀបចំជាមួយ Docker ។ យើងកំពុងសម្លឹងមើលយ៉ាងយកចិត្តទុកដាក់ទៅលើ Rancher និងដំណោះស្រាយផ្សេងៗ ប៉ុន្តែបន្ទាប់មក Kubernetes បានបង្ហាញខ្លួន ដែលអ្វីៗទាំងអស់ត្រូវបានអនុវត្តយ៉ាងពិតប្រាកដដូចដែលយើងនឹងធ្វើវា ឬប្រសើរជាងនេះ។ មិនមានអ្វីត្រូវត្អូញត្អែរទេ។

បាទ មានភាពមិនល្អឥតខ្ចោះមួយចំនួននៅទីនេះ មានភាពមិនល្អឥតខ្ចោះមួយចំនួននៅទីនោះ - មានភាពមិនល្អឥតខ្ចោះជាច្រើន ហើយ 1.2 ជាទូទៅគួរឱ្យខ្លាច ប៉ុន្តែ... Kubernetes គឺដូចជាអគារដែលកំពុងសាងសង់ - អ្នកមើលគម្រោងហើយយល់។ ថាវានឹងត្រជាក់។ ប្រសិនបើអគារឥឡូវនេះមានគ្រឹះ និងពីរជាន់ នោះអ្នកយល់ថា វាជាការប្រសើរជាងកុំរើចូល ប៉ុន្តែមិនមានបញ្ហាបែបនេះជាមួយកម្មវិធីទេ អ្នកអាចប្រើវាបានហើយ។

យើងមិនមានពេលដែលយើងគិតអំពីការប្រើប្រាស់ Kubernetes ឬអត់នោះទេ។ យើងបានរង់ចាំវាយូរមុនពេលវាលេចឡើង ហើយព្យាយាមបង្កើត analogues ដោយខ្លួនឯង។

អំពី Kubernetes

- តើអ្នកចូលរួមដោយផ្ទាល់ក្នុងការអភិវឌ្ឍន៍ Kubernetes ខ្លួនឯងទេ?

Dmitry៖ មធ្យម។ ផ្ទុយទៅវិញ យើងចូលរួមក្នុងការអភិវឌ្ឍន៍ប្រព័ន្ធអេកូឡូស៊ី។ យើងផ្ញើសំណើទាញមួយចំនួន៖ ទៅ Prometheus ទៅប្រតិបត្តិករផ្សេងៗ ទៅ Helm - ទៅប្រព័ន្ធអេកូឡូស៊ី។ ជាអកុសល ខ្ញុំមិនអាចតាមដានអ្វីៗទាំងអស់ដែលយើងធ្វើ ហើយខ្ញុំអាចខុស ប៉ុន្តែយើងមិនមានអាងតែមួយនៅក្នុងស្នូលទេ។

— ក្នុងពេលជាមួយគ្នានេះ តើអ្នកបង្កើតឧបករណ៍ជាច្រើនរបស់អ្នកនៅជុំវិញ Kubernetes ទេ?

Dmitry៖ យុទ្ធសាស្ត្រគឺនេះ៖ យើងទៅទាញសំណើទៅគ្រប់អ្វីៗដែលមានរួចហើយ។ ប្រសិនបើសំណើទាញមិនត្រូវបានទទួលយកនៅទីនោះទេ យើងគ្រាន់តែបំបែកវាដោយខ្លួនឯង ហើយរស់នៅរហូតដល់ពួកគេត្រូវបានទទួលយកជាមួយនឹងការសាងសង់របស់យើង។ បន្ទាប់​មក​នៅ​ពេល​វា​ឡើង​ដល់​ទឹក យើង​ត្រឡប់​ទៅ​កំណែ​ខាង​លើ​វិញ។

ជាឧទាហរណ៍ យើងមានប្រតិបត្តិករ Prometheus ដែលយើងបានប្តូរទៅខាងដើមនៃសន្និបាតរបស់យើងប្រហែលជា 5 ដងរួចទៅហើយ។ យើង​ត្រូវ​ការ​លក្ខណៈ​ពិសេស​មួយ​ចំនួន យើង​បាន​ផ្ញើ​សំណើ​ទាញ​យក យើង​ត្រូវ​ការ​វា​ចេញ​នៅ​ថ្ងៃ​ស្អែក ប៉ុន្តែ​យើង​មិន​ចង់​រង់​ចាំ​ឱ្យ​វា​ចេញ​ផ្សាយ​ជា​បន្ត​បន្ទាប់​ទេ។ ដូច្នោះហើយ យើងប្រមូលផ្តុំសម្រាប់ខ្លួនយើង រមៀលការជួបប្រជុំរបស់យើងជាមួយនឹងលក្ខណៈពិសេសរបស់យើង ដែលយើងត្រូវការសម្រាប់ហេតុផលមួយចំនួន ដល់ក្រុមទាំងអស់របស់យើង។ បន្ទាប់មក ជាឧទាហរណ៍ នៅក្នុងចរន្តទឹក ពួកគេបានបង្វែរវាមកយើងវិញដោយពាក្យថា "បុរសៗ ចូរធ្វើវាសម្រាប់ករណីទូទៅបន្ថែមទៀត" យើង ឬអ្នកផ្សេង បញ្ចប់វា ហើយយូរ ៗ ទៅវាបញ្ចូលគ្នាម្តងទៀត។

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

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

ឧបករណ៍ Flanta

- ខ្ញុំដឹងថាឥឡូវនេះ Flant មានប្រតិបត្តិករ addon ប្រតិបត្តិករសែល និងឧបករណ៍ dapp/werf ។ ដូចដែលខ្ញុំយល់ នេះគឺជាឧបករណ៍ដូចគ្នានៅក្នុងការចាប់កំណើតខុសៗគ្នា។ ខ្ញុំក៏យល់ដែរថា មានឧបករណ៍ផ្សេងៗជាច្រើនទៀតនៅក្នុង Flaunt។ វា​ជា​ការពិត?

Dmitry៖ យើងមានច្រើនទៀតនៅលើ GitHub ។ ពីអ្វីដែលខ្ញុំចងចាំឥឡូវនេះ យើងមានផែនទីស្ថានភាព - បន្ទះសម្រាប់ Grafana ដែលមនុស្សគ្រប់គ្នាបានជួបប្រទះ។ វាត្រូវបានលើកឡើងនៅក្នុងស្ទើរតែគ្រប់អត្ថបទទីពីរអំពីការត្រួតពិនិត្យ Kubernetes នៅលើ Medium ។ វាមិនអាចទៅរួចទេក្នុងការពន្យល់យ៉ាងខ្លីអំពីអ្វីដែលផែនទីស្ថានភាពគឺ - វាត្រូវការអត្ថបទដាច់ដោយឡែកមួយ ប៉ុន្តែវាជារឿងមានប្រយោជន៍ខ្លាំងណាស់សម្រាប់ការត្រួតពិនិត្យស្ថានភាពតាមពេលវេលា ដោយសារនៅក្នុង Kubernetes យើងច្រើនតែត្រូវបង្ហាញស្ថានភាពតាមពេលវេលា។ យើងក៏មាន LogHouse ដែលជាវត្ថុផ្អែកលើ ClickHouse និងវេទមន្តខ្មៅសម្រាប់ការប្រមូលកំណត់ហេតុនៅក្នុង Kubernetes ។

ឧបករណ៍ប្រើប្រាស់ច្រើន! ហើយវានឹងមានច្រើនជាងនេះទៅទៀត ដោយសារតែដំណោះស្រាយផ្ទៃក្នុងមួយចំនួននឹងត្រូវបានចេញផ្សាយនៅឆ្នាំនេះ។ ក្នុងចំណោមរបស់ធំ ៗ ដោយផ្អែកលើប្រតិបត្តិករ addon មានកម្មវិធីបន្ថែមជាច្រើនសម្រាប់ Kubernetes, ala របៀបដំឡើងកម្មវិធីគ្រប់គ្រង sert ឱ្យបានត្រឹមត្រូវ - ឧបករណ៍សម្រាប់គ្រប់គ្រងវិញ្ញាបនបត្រ របៀបដំឡើង Prometheus ឱ្យបានត្រឹមត្រូវជាមួយនឹងគ្រឿងបន្លាស់ - ទាំងនេះគឺប្រហែលម្ភៃផ្សេងគ្នា។ ប្រព័ន្ធគោលពីរដែលនាំចេញទិន្នន័យ និងប្រមូលអ្វីមួយសម្រាប់ Prometheus នេះមានក្រាហ្វិក និងការជូនដំណឹងដ៏អស្ចារ្យបំផុត។ ទាំងអស់នេះគឺគ្រាន់តែជាផ្នែកបន្ថែមនៃ Kubernetes ដែលត្រូវបានដាក់ក្នុងចង្កោម ហើយវាប្រែពីសាមញ្ញទៅត្រជាក់ ទំនើប ស្វ័យប្រវត្តិ ដែលបញ្ហាជាច្រើនត្រូវបានដោះស្រាយរួចហើយ។ បាទ យើងធ្វើបានច្រើន។

ការអភិវឌ្ឍន៍ប្រព័ន្ធអេកូឡូស៊ី

— វាហាក់បីដូចជាខ្ញុំថា នេះគឺជាការរួមចំណែកដ៏ធំមួយក្នុងការអភិវឌ្ឍន៍ឧបករណ៍នេះ និងវិធីសាស្រ្តនៃការប្រើប្រាស់របស់វា។ តើ​អ្នក​អាច​ប៉ាន់ស្មាន​បាន​ទេ​ថា តើ​អ្នក​ណា​ទៀត​នឹង​ចូល​រួម​ចំណែក​ដូច​គ្នា​ក្នុង​ការ​អភិវឌ្ឍ​ប្រព័ន្ធ​អេកូឡូស៊ី?

Dmitry: នៅក្នុងប្រទេសរុស្ស៊ីនៃក្រុមហ៊ុនដែលប្រតិបត្តិការនៅលើទីផ្សាររបស់យើងគ្មាននរណាម្នាក់ជិតស្និទ្ធទេ។. ជាការពិតណាស់ នេះគឺជាសេចក្តីថ្លែងការណ៍ដ៏ខ្លាំងមួយ ដោយសារតែមានអ្នកលេងធំៗដូចជា Mail និង Yandex ពួកគេក៏កំពុងធ្វើអ្វីមួយជាមួយ Kubernetes ផងដែរ ប៉ុន្តែទោះបីជាពួកគេមិនចូលជិតការរួមចំណែករបស់ក្រុមហ៊ុនជុំវិញពិភពលោកដែលធ្វើច្រើនជាងយើងក៏ដោយ។ វាពិបាកក្នុងការប្រៀបធៀប Flant ជាមួយបុគ្គលិក 80 នាក់ និង Red Hat ដែលមានវិស្វករ 300 នាក់ក្នុងមួយ Kubernetes តែម្នាក់ឯង ប្រសិនបើខ្ញុំមិនច្រឡំទេ។ វាពិបាកក្នុងការប្រៀបធៀប។ យើងមានមនុស្ស 6 នាក់នៅក្នុងនាយកដ្ឋាន RnD រួមទាំងខ្ញុំដែលបានកាត់ឧបករណ៍ទាំងអស់របស់យើង។ មនុស្ស 6 នាក់ធៀបនឹងវិស្វករ Red Hat 300 នាក់ - វាពិបាកក្នុងការប្រៀបធៀប។

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

Dmitry៖ នេះ​ប្រហែល​ជា​លក្ខណៈ​ពិសេស​មួយ​នៃ​ឧបករណ៍​បញ្ចូល​គ្នា ភាព​ពិសេស​របស់​វា។ យើងមានគម្រោងជាច្រើន ហើយយើងឃើញស្ថានភាពផ្សេងៗគ្នាជាច្រើន។ សម្រាប់យើង មធ្យោបាយសំខាន់ក្នុងការបង្កើតតម្លៃបន្ថែមគឺការវិភាគករណីទាំងនេះ ស្វែងរកភាពសាមញ្ញ និងធ្វើឱ្យពួកគេមានតម្លៃថោកតាមដែលអាចធ្វើទៅបានសម្រាប់យើង។ នេះគឺជាអ្វីដែលយើងកំពុងស្វែងរកយ៉ាងសកម្ម។ វាពិបាកសម្រាប់ខ្ញុំក្នុងការនិយាយអំពីប្រទេសរុស្ស៊ី និងពិភពលោក ប៉ុន្តែយើងមានវិស្វករ DevOps ប្រហែល 40 នាក់នៅក្នុងក្រុមហ៊ុនដែលធ្វើការលើ Kubernetes ។ ខ្ញុំមិនគិតថាមានក្រុមហ៊ុនជាច្រើននៅក្នុងប្រទេសរុស្ស៊ីដែលមានចំនួនអ្នកជំនាញដែលអាចប្រៀបធៀបបានដែលយល់ពី Kubernetes ប្រសិនបើមានទាំងអស់។

ខ្ញុំយល់គ្រប់យ៉ាងអំពីចំណងជើងការងារ DevOps វិស្វករ អ្នកគ្រប់គ្នាយល់គ្រប់យ៉ាង ហើយធ្លាប់ហៅវិស្វករ DevOps វិស្វករ DevOps យើងនឹងមិនពិភាក្សារឿងនេះទេ។ វិស្វករ DevOps ដ៏អស្ចារ្យទាំង 40 នាក់នេះ ប្រឈមមុខនឹងបញ្ហា ហើយដោះស្រាយវាជារៀងរាល់ថ្ងៃ យើងគ្រាន់តែវិភាគបទពិសោធន៍នេះ ហើយព្យាយាមធ្វើទូទៅ។ យើងយល់ថា ប្រសិនបើវានៅតែមាននៅក្នុងខ្លួនយើង នោះក្នុងមួយឆ្នាំ ឬពីរឆ្នាំ ឧបករណ៍នឹងគ្មានប្រយោជន៍ទេ ពីព្រោះកន្លែងណាមួយនៅក្នុងសហគមន៍ Tula ដែលត្រៀមរួចជាស្រេចនឹងលេចឡើង។ វាគ្មានន័យអ្វីទេក្នុងការប្រមូលបទពិសោធន៍នេះនៅខាងក្នុង - វាគ្រាន់តែជាការបង្ហូរថាមពល និងពេលវេលាចូលទៅក្នុង dev/null ។ ហើយយើងមិនសោកស្តាយអ្វីទាំងអស់។ យើងបោះពុម្ពផ្សាយអ្វីៗគ្រប់យ៉ាងដោយសេចក្តីរីករាយ ហើយយល់ថាវាត្រូវការបោះពុម្ព អភិវឌ្ឍ ផ្សព្វផ្សាយ ផ្សព្វផ្សាយ ដូច្នេះមនុស្សប្រើវា និងបន្ថែមបទពិសោធន៍ផ្ទាល់ខ្លួនរបស់ពួកគេ - បន្ទាប់មកអ្វីៗក៏រីកចម្រើន និងរស់នៅ។ បន្ទាប់មកពីរឆ្នាំក្រោយមក ឧបករណ៍មិនទៅគំនរសំរាមទេ។ វាមិនមែនជាការសោកស្តាយទេក្នុងការបន្តពង្រឹងកម្លាំង ព្រោះវាច្បាស់ណាស់ថាមាននរណាម្នាក់កំពុងប្រើឧបករណ៍របស់អ្នក ហើយបន្ទាប់ពីពីរឆ្នាំអ្នកគ្រប់គ្នាកំពុងប្រើវា។

នេះគឺជាផ្នែកមួយនៃយុទ្ធសាស្រ្តដ៏ធំរបស់យើងជាមួយ dapp/werf. ខ្ញុំ​មិន​ចាំ​ថា​យើង​ចាប់​ផ្ដើម​បង្កើត​វា​នៅ​ពេល​ណា​ទេ វា​ហាក់​ដូច​ជា​៣​ឆ្នាំ​មុន។ ដំបូងបង្អស់វាជាទូទៅនៅលើសំបក។ វាជាភស្តុតាងដ៏អស្ចារ្យនៃគំនិត យើងបានដោះស្រាយបញ្ហាឯកជនមួយចំនួនរបស់យើង - វាដំណើរការ! ប៉ុន្តែមានបញ្ហាជាមួយសែល វាមិនអាចទៅរួចទេក្នុងការពង្រីកវាបន្ថែមទៀត ការសរសេរកម្មវិធីនៅក្នុងសែលគឺជាកិច្ចការមួយផ្សេងទៀត។ យើងមានទម្លាប់សរសេរជា Ruby អាស្រ័យហេតុនេះ នៅក្នុង Ruby យើងបានកែច្នៃអ្វីមួយ បង្កើត បង្កើត អភិវឌ្ឍ ហើយរត់ចូលទៅក្នុងការពិតដែលសហគមន៍ ហ្វូងមនុស្សដែលមិននិយាយថា "ថាតើយើងចង់បានវាឬអត់" ប្រែជា ច្រមុះរបស់វានៅ Ruby មិនថាវាកំប្លែងយ៉ាងណាទេ។ យើងបានដឹងថាយើងគួរតែសរសេរអ្វីៗទាំងអស់នេះនៅក្នុង Go ដើម្បីបំពេញចំណុចដំបូងនៅក្នុងបញ្ជីត្រួតពិនិត្យ៖ ឧបករណ៍ DevOps គួរតែជាប្រព័ន្ធគោលពីរឋិតិវន្ត. ដើម្បីប្រើ Go ឬមិនប្រើ Go គឺមិនសំខាន់ទេ ប៉ុន្តែគោលពីរឋិតិវន្តដែលសរសេរក្នុង Go គឺប្រសើរជាង។

យើងបានចំណាយថាមពលរបស់យើង សរសេរ dapp ឡើងវិញនៅក្នុង Go ហើយហៅវាថា werf ។ Dapp មិន​ត្រូវ​បាន​គាំទ្រ​ទៀត​ទេ មិន​ត្រូវ​បាន​បង្កើត​ឡើង ដំណើរការ​ក្នុង​កំណែ​ចុង​ក្រោយ​បំផុត​មួយ​ចំនួន ប៉ុន្តែ​មាន​ផ្លូវ​ធ្វើ​ឱ្យ​ប្រសើរ​ឡើង​ដាច់​ខាត​ដល់​កំពូល ហើយ​អ្នក​អាច​ធ្វើ​តាម​បាន។

ហេតុអ្វីបានជា dapp ត្រូវបានបង្កើតឡើង?

- តើអ្នកអាចប្រាប់យើងដោយសង្ខេបថាហេតុអ្វីបានជា dapp ត្រូវបានបង្កើតឡើង តើវាដោះស្រាយបញ្ហាអ្វីខ្លះ?

Dmitry៖ មូលហេតុដំបូងគឺការជួបប្រជុំគ្នា។ ដំបូងឡើយ យើងមានបញ្ហាធ្ងន់ធ្ងរជាមួយការស្ថាបនា នៅពេលដែល Docker មិនមានសមត្ថភាពពហុដំណាក់កាល ហើយយើងបង្កើតពហុដំណាក់កាលដោយខ្លួនឯង។ បន្ទាប់មក យើងមានបញ្ហាជាច្រើនទៀតជាមួយនឹងការសម្អាតរូបភាព។ អ្នកគ្រប់គ្នាដែលធ្វើ CI/CD ឆាប់ជាជាងពេលក្រោយ ប្រឈមមុខនឹងបញ្ហាដែលមានរូបភាពប្រមូលបានច្រើន វាចាំបាច់ក្នុងការសម្អាតអ្វីដែលមិនត្រូវការ ហើយទុកអ្វីដែលចាំបាច់។

មូលហេតុទីពីរគឺការដាក់ពង្រាយ។ បាទ មាន Helm ប៉ុន្តែវាគ្រាន់តែដោះស្រាយបញ្ហាមួយចំនួនប៉ុណ្ណោះ។ មិនថាវាគួរឱ្យអស់សំណើចយ៉ាងណានោះទេ វាត្រូវបានសរសេរថា "Helm គឺជាកម្មវិធីគ្រប់គ្រងកញ្ចប់សម្រាប់ Kubernetes"។ អ្វី​ដែល​ជា "​" ។ ក៏មានពាក្យថា "កម្មវិធីគ្រប់គ្រងកញ្ចប់" - តើអ្វីជាការរំពឹងទុកធម្មតាពីអ្នកគ្រប់គ្រងកញ្ចប់? យើងនិយាយថា “កម្មវិធីគ្រប់គ្រងកញ្ចប់ – ចែកចាយកញ្ចប់!” ហើយ​យើង​រំពឹង​ថា​គាត់​នឹង​ប្រាប់​យើង​ថា​៖ «​កញ្ចប់​ត្រូវ​បាន​បញ្ជូន​ហើយ​»។

វាជាការគួរឱ្យចាប់អារម្មណ៍ដែលយើងនិយាយថា: "Helm, ដំឡើងកញ្ចប់" ហើយនៅពេលដែលគាត់ឆ្លើយថាគាត់បានដំឡើងវាវាប្រែថាគាត់ទើបតែចាប់ផ្តើមការដំឡើង - គាត់បានបង្ហាញ Kubernetes: "ចាប់ផ្តើមរឿងនេះ!" ហើយថាតើវាបានចាប់ផ្តើមឬអត់។ ទោះបីជាវាដំណើរការឬអត់ក៏ដោយ Helm មិនដោះស្រាយបញ្ហានេះទាល់តែសោះ។

វាប្រែថា Helm គ្រាន់តែជាឧបករណ៍ដំណើរការអត្ថបទដែលផ្ទុកទិន្នន័យទៅក្នុង Kubernetes ប៉ុណ្ណោះ។

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

ផែនការ

ឆ្នាំ​នេះ​យើង​នឹង​ចូល​ទៅ​ក្នុង​ការ​អភិវឌ្ឍ​មូលដ្ឋាន​ផង​ដែរ​។ យើងចង់សម្រេចបាននូវអ្វីដែលពីមុននៅក្នុង Vagrant - យើងវាយពាក្យ "vagrant up" ហើយយើងដាក់ពង្រាយម៉ាស៊ីននិម្មិត។ យើងចង់ទៅដល់ចំណុចមួយដែលមានគម្រោងនៅក្នុង Git យើងសរសេរ "werf up" នៅទីនោះ ហើយវាយកច្បាប់ចម្លងក្នុងស្រុកនៃគម្រោងនេះ ដាក់ពង្រាយក្នុង mini-Kub ក្នុងស្រុក ជាមួយនឹងថតទាំងអស់ដែលងាយស្រួលសម្រាប់ការអភិវឌ្ឍន៍តភ្ជាប់។ អាស្រ័យលើភាសាអភិវឌ្ឍន៍ វាត្រូវបានធ្វើខុសគ្នា ប៉ុន្តែយ៉ាងណាក៏ដោយ ដើម្បីឱ្យអ្នកអាចធ្វើការអភិវឌ្ឍន៍មូលដ្ឋានបានយ៉ាងងាយស្រួលនៅក្រោមឯកសារដែលបានម៉ោន។

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

ប៉ុន្តែផ្លូវទៅកាន់ dapp/werf តែងតែដូចគ្នាទៅនឹង Kubernetes កាលពីដើម។ យើងបានជួបប្រទះបញ្ហា ដោះស្រាយពួកគេដោយប្រើវិធីដោះស្រាយ - មកជាមួយដំណោះស្រាយមួយចំនួនសម្រាប់ខ្លួនយើងដោយប្រើសែល ប្រើអ្វីក៏បាន។ បន្ទាប់មកពួកគេបានព្យាយាមធ្វើឱ្យត្រង់ ធ្វើឱ្យទូទៅ និងបង្រួបបង្រួមដំណោះស្រាយទាំងនេះទៅជាប្រព័ន្ធគោលពីរក្នុងករណីនេះ ដែលយើងគ្រាន់តែចែករំលែក។

មានវិធីមួយផ្សេងទៀតដើម្បីមើលរឿងទាំងមូលនេះដោយមានការប្រៀបធៀប។

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

នៅក្នុងករណីនៃ werf នេះគឺជាសមាសធាតុមួយផ្សេងទៀតសម្រាប់ Kubernetes ។ មានតែឥឡូវនេះនៅក្នុងកំណែអាល់ហ្វារបស់យើងនៃ werf ជាឧទាហរណ៍ Helm ត្រូវបានចងក្រងនៅខាងក្នុង werf ដោយសារតែយើងធុញទ្រាន់នឹងការធ្វើវាដោយខ្លួនឯង។ មានហេតុផលជាច្រើនដើម្បីធ្វើរឿងនេះ ខ្ញុំនឹងប្រាប់អ្នកឱ្យលម្អិតអំពីមូលហេតុដែលយើងចងក្រងមួកទាំងមូលរួមគ្នាជាមួយ tiller នៅខាងក្នុង werf នៅក្នុងរបាយការណ៍របស់ RIT++.

ឥឡូវនេះ werf គឺជាសមាសធាតុរួមបញ្ចូលគ្នាកាន់តែច្រើន។ យើងទទួលបានដៃចង្កូតដែលបានបញ្ចប់ ម្ជុលចង្កូត - ខ្ញុំមិនសូវពូកែខាងរថយន្តទេ ប៉ុន្តែនេះគឺជាប្លុកដ៏ធំមួយដែលដោះស្រាយបញ្ហាជាច្រើនរួចទៅហើយ។ យើង​មិន​ចាំបាច់​ឡើង​តាម​កាតាឡុក​ខ្លួន​ឯង​ទេ ជ្រើសរើស​ផ្នែក​មួយ​ពី​ផ្នែក​មួយ​ទៀត គិត​ពី​របៀប​ដាក់​វា​ឱ្យ​គ្នា។ យើងទទួលបានការរួមបញ្ចូលគ្នាដែលត្រៀមរួចជាស្រេចដែលដោះស្រាយបញ្ហាមួយចំនួនធំក្នុងពេលតែមួយ។ ប៉ុន្តែនៅខាងក្នុងវាត្រូវបានបង្កើតឡើងដោយសមាសភាគប្រភពបើកចំហដូចគ្នា វានៅតែប្រើ Docker សម្រាប់ការជួបប្រជុំគ្នា Helm សម្រាប់មុខងារមួយចំនួន និងមានបណ្ណាល័យជាច្រើនទៀត។ នេះ​ជា​ឧបករណ៍​ដែល​រួម​បញ្ចូល​គ្នា​ដើម្បី​យក CI/CD ដ៏​ត្រជាក់​ចេញ​ពី​ប្រអប់​យ៉ាង​លឿន និង​ងាយស្រួល។

តើវាពិបាកក្នុងការថែទាំ Kubernetes មែនទេ?

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

Dmitry៖ នេះ​ជា​សំណួរ​ពិបាក​ណាស់ ហើយ​ដើម្បី​ឆ្លើយ យើង​ត្រូវ​យល់​ថា​អ្វី​ជា​ការ​គាំទ្រ និង​អ្វី​ដែល​យើង​ចង់​បាន​ពី Kubernetes។ ប្រហែលជាអ្នកនឹងបង្ហាញវា?

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

Dmitry៖ វា​ដូច​ជា​អញ្ចឹង។

- តើវាពិបាកប៉ុណ្ណាក្នុងការយក និងដំឡើង Kubernetes ពីគ្មានអ្វីសោះ ដើម្បីឱ្យការផលិតរួចរាល់?

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

ការដំឡើង Kubernetes និងធ្វើឱ្យវាដំណើរការគឺងាយស្រួល៖ ឈី! - ដំឡើងរួច មានវិធីសាស្រ្តដំឡើងច្រើន។ ប៉ុន្តែ តើមានអ្វីកើតឡើងនៅពេលមានបញ្ហា?

សំណួរតែងតែកើតឡើង៖ តើយើងមិនទាន់គិតពីអ្វី? តើ​យើង​មិន​ទាន់​បាន​ធ្វើ​អ្វី? តើប៉ារ៉ាម៉ែត្រខឺណែលលីនុចមួយណាត្រូវបានបញ្ជាក់មិនត្រឹមត្រូវ? ព្រះអម្ចាស់អើយ តើយើងបានចង្អុលបង្ហាញពួកគេទេ?! តើសមាសធាតុ Kubernetes មួយណាដែលយើងបានចែកចាយ ហើយតើមួយណាដែលយើងមិនទាន់មាន? សំណួររាប់ពាន់កើតឡើង ហើយដើម្បីឆ្លើយពួកគេ អ្នកត្រូវចំណាយពេល 15-20 ឆ្នាំនៅក្នុងឧស្សាហកម្មនេះ។

ខ្ញុំមានឧទាហរណ៍ថ្មីៗអំពីប្រធានបទនេះ ដែលអាចបង្ហាញពីអត្ថន័យនៃបញ្ហា “តើវាពិបាកក្នុងការថែទាំ Kubernetes មែនទេ?” មួយរយៈមុន យើងបានពិចារណាយ៉ាងយកចិត្តទុកដាក់ក្នុងការព្យាយាមអនុវត្ត Cilium ជាបណ្តាញនៅក្នុង Kubernetes ។

ខ្ញុំសូមពន្យល់ពីអ្វីដែល Cilium ជាអ្វី។ មានការអនុវត្តផ្សេងៗគ្នាជាច្រើននៃប្រព័ន្ធរងបណ្តាញនៅក្នុង Kubernetes ហើយមួយដ៏ត្រជាក់បំផុតគឺ Cilium ។ តើវាមានន័យយ៉ាងណា? នៅក្នុងខឺណែល ពេលខ្លះវាអាចទៅរួចក្នុងការសរសេរទំពក់សម្រាប់ខឺណែល ដែលដូចម្ដេចបានលុកលុយប្រព័ន្ធរងបណ្តាញ និងប្រព័ន្ធរងផ្សេងៗ ហើយអនុញ្ញាតឱ្យអ្នកឆ្លងកាត់កំណាត់ធំៗនៅក្នុងខឺណែល។

ខឺណែលលីនុចជាប្រវត្តិសាស្ត្រមានផ្លូវ ip, តម្រងលើស, ស្ពាន និងសមាសធាតុចាស់ៗផ្សេងៗគ្នាជាច្រើនដែលមានអាយុកាល 15, 20, 30 ឆ្នាំ។ ជាទូទៅពួកគេធ្វើការ អ្វីគ្រប់យ៉ាងគឺអស្ចារ្យណាស់ ប៉ុន្តែឥឡូវនេះពួកគេបានគប់ធុង ហើយវាមើលទៅដូចជាប៉មមួយដែលមានឥដ្ឋចំនួន 15 នៅពីលើគ្នា ហើយអ្នកឈរនៅលើវានៅលើជើងម្ខាង ដែលជាអារម្មណ៍ចម្លែក។ ប្រព័ន្ធនេះមានការវិវត្តជាប្រវត្តិសាស្ត្រជាមួយនឹងភាពខុសប្លែកគ្នាជាច្រើន ដូចជាឧបសម្ព័ន្ធនៅក្នុងរាងកាយ។ ឧទាហរណ៍ក្នុងស្ថានភាពខ្លះមានបញ្ហាជាមួយការអនុវត្ត។

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

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

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

ហើយ​មាន​អ្វី​ខុស​គ្នា? វាប្រែថាមានផ្លូវ ip, ខឺណែលលីនុច ហើយមានឧបករណ៍ថ្មី - តើវាខុសគ្នាយ៉ាងណាដែរ យើងមិនយល់មួយ ឬផ្សេងទៀតទេ។ ប៉ុន្តែយើងខ្លាចប្រើអ្វីដែលថ្មី - ហេតុអ្វី? ដោយសារតែប្រសិនបើឧបករណ៍នេះមានអាយុ 30 ឆ្នាំបន្ទាប់មកក្នុងរយៈពេល 30 ឆ្នាំកំហុសទាំងអស់ត្រូវបានរកឃើញកំហុសទាំងអស់ត្រូវបានបោះជំហានទៅមុខហើយអ្នកមិនចាំបាច់ដឹងអំពីអ្វីគ្រប់យ៉ាងទេ - វាដំណើរការដូចជាប្រអប់ខ្មៅហើយតែងតែដំណើរការ។ អ្នករាល់គ្នាដឹងថាវីសវិនិច្ឆយមួយណាដែលត្រូវបិទនៅកន្លែងណា tcpdump ដែលត្រូវដំណើរការនៅពេលនោះ។ មនុស្សគ្រប់គ្នាស្គាល់ឧបករណ៍ប្រើប្រាស់ក្នុងការវិនិច្ឆ័យបានយ៉ាងល្អ ហើយយល់ពីរបៀបដែលសំណុំនៃសមាសភាគនេះដំណើរការនៅក្នុងខឺណែលលីនុច មិនមែនរបៀបដែលវាដំណើរការនោះទេ ប៉ុន្តែរបៀបប្រើវា។

ហើយ Cilium ត្រជាក់អស្ចារ្យមិនមានអាយុ 30 ឆ្នាំទេ វាមិនទាន់ពេញវ័យនៅឡើយ។ Kubernetes មានបញ្ហាដូចគ្នា ចម្លង។ ថា Cilium ដំណើរការល្អ ដែល Kubernetes ដំណើរការល្អ ប៉ុន្តែនៅពេលដែលមានអ្វីមួយខុសប្រក្រតីក្នុងផលិតកម្ម តើអ្នកអាចយល់បានយ៉ាងឆាប់រហ័សក្នុងស្ថានភាពធ្ងន់ធ្ងរថាមានអ្វីខុស?

នៅពេលដែលយើងនិយាយថាវាពិបាកក្នុងការថែទាំ Kubernetes - ទេ ងាយស្រួលណាស់ ហើយបាទពិបាកមិនគួរឱ្យជឿ។ Kubernetes ដំណើរការល្អដោយខ្លួនឯង ប៉ុន្តែជាមួយនឹងតម្លៃរាប់ពាន់លានដុល្លារ។

អំពីវិធីសាស្រ្ត "ខ្ញុំនឹងមានសំណាង"

- តើមានក្រុមហ៊ុនណាដែលភាពមិនច្បាស់លាស់ទាំងនេះត្រូវបានធានាស្ទើរតែលេចឡើង? ឧបមាថា Yandex ភ្លាមៗប្តូរសេវាកម្មទាំងអស់ទៅ Kubernetes វានឹងមានបន្ទុកដ៏ធំមួយនៅទីនោះ។

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

ខ្ញុំមានអ៊ូប៊ុនទូ 16.04 ។ អ្នក​អាច​និយាយ​បាន​ថា​នេះ​គឺ​ជា​កំណែ​ចាស់​ប៉ុន្តែ​យើង​នៅ​តែ​នៅ​លើ​វា​ព្រោះ​វា​ជា LTS ។ មានប្រព័ន្ធ ដែលការព្រមាននោះគឺថាវាមិនសម្អាតក្រុម C ទេ។ Kubernetes បើកដំណើរការ pods បង្កើត C-groups បន្ទាប់មកលុប pods ហើយវាប្រែជា - ខ្ញុំមិនចាំព័ត៌មានលម្អិតទេ សូមអភ័យទោស - ដែលផ្នែក systemd នៅតែមាន។ នេះនាំឱ្យមានការពិតដែលថាយូរ ៗ ទៅរថយន្តណាមួយចាប់ផ្តើមបន្ថយល្បឿនយ៉ាងខ្លាំង។ នេះមិនមែនជាសំណួរអំពីការផ្ទុកខ្ពស់ទេ។ ប្រសិនបើផតឃែរជាប់លាប់ត្រូវបានបើកដំណើរការ ឧទាហរណ៍ប្រសិនបើមាន Cron Job ដែលបង្កើតផតជាប្រចាំ នោះម៉ាស៊ីនដែលមានអ៊ូប៊ុនទូ 16.04 នឹងចាប់ផ្តើមយឺតបន្ទាប់ពីមួយសប្តាហ៍។ វានឹងមានជាមធ្យមការផ្ទុកខ្ពស់ឥតឈប់ឈរដោយសារតែការពិតដែលថាក្រុម C ត្រូវបានបង្កើតឡើង។ នេះគឺជាបញ្ហាដែលបុគ្គលណាម្នាក់ដែលគ្រាន់តែដំឡើង Ubuntu 16 និង Kubernetes នៅលើកំពូលនឹងត្រូវប្រឈមមុខ។

ឧបមាថាគាត់ធ្វើបច្ចុប្បន្នភាពប្រព័ន្ធឬអ្វីផ្សេងទៀតប៉ុន្តែនៅក្នុងខឺណែលលីនុចរហូតដល់ 4.16 វាកាន់តែកំប្លែងជាង - នៅពេលអ្នកលុប C-groups ពួកវាលេចធ្លាយនៅក្នុងខឺណែលហើយមិនត្រូវបានលុបពិតប្រាកដទេ។ ដូច្នេះបន្ទាប់ពីមួយខែនៃការធ្វើការលើម៉ាស៊ីននេះ វានឹងមិនអាចទៅរួចទេក្នុងការមើលស្ថិតិនៅលើអង្គចងចាំដោយ subserver ។ យើងយកឯកសារមួយចេញ រមៀលវានៅក្នុងកម្មវិធី ហើយឯកសារមួយវិលក្នុងរយៈពេល 15 វិនាទី ព្រោះខឺណែលត្រូវចំណាយពេលយូរណាស់ក្នុងការរាប់ក្រុម C មួយលាននៅក្នុងខ្លួនវា ដែលហាក់ដូចជាត្រូវបានលុប ប៉ុន្តែមិនមែនទេ - ពួកគេកំពុងលេចធ្លាយ។ .

នៅមានរឿងតូចៗជាច្រើននៅទីនេះ និងទីនោះ។ នេះមិនមែនជាបញ្ហាទេដែលជួនកាលក្រុមហ៊ុនយក្សអាចប្រឈមមុខនឹងបន្ទុកធ្ងន់ - ទេ វាជាបញ្ហាប្រចាំថ្ងៃ។ មនុស្សអាចរស់នៅបែបនេះបានរាប់ខែ - ពួកគេបានដំឡើង Kubernetes, ដាក់ពង្រាយកម្មវិធី - វាហាក់ដូចជាដំណើរការ។ សម្រាប់មនុស្សជាច្រើននេះជារឿងធម្មតា។ ពួកគេ​នឹង​មិន​ដឹង​ថា​ថ្ងៃ​ណា​មួយ​កម្មវិធី​នេះ​នឹង​គាំង​ដោយ​ហេតុផល​មួយ​ចំនួន ពួកគេ​នឹង​មិន​ទទួល​បាន​ការ​ជូន​ដំណឹង​ទេ ប៉ុន្តែ​សម្រាប់​ពួកគេ​នេះ​ជា​បទដ្ឋាន។ ពីមុនយើងរស់នៅលើម៉ាស៊ីននិម្មិតដោយមិនមានការត្រួតពិនិត្យ ឥឡូវនេះយើងបានផ្លាស់ទៅ Kubernetes ដោយគ្មានការត្រួតពិនិត្យផងដែរ - តើមានអ្វីប្លែក?

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

តាមទស្សនៈរបស់ខ្ញុំ ភាពមិនច្បាស់លាស់ និងភាពស្មុគស្មាញនៃការដំណើរការប្រព័ន្ធណាមួយគឺដើម្បីធានាថាកម្រាស់របស់ទឹកកកគឺពិតជាគ្រប់គ្រាន់ដើម្បីដោះស្រាយបញ្ហារបស់យើង។ វាគឺអំពីរឿងនេះ។

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

- ពីការវាយតម្លៃទុទិដ្ឋិនិយមរបស់ខ្ញុំ វាមើលទៅដូចនេះ៖ នៅពេលដែលហានិភ័យខ្ពស់ ហើយកម្មវិធីត្រូវតែដំណើរការ នោះត្រូវការការគាំទ្រពី Flant ប្រហែលជាមកពី Red Hat ឬអ្នកត្រូវការក្រុមការងារផ្ទៃក្នុងផ្ទាល់ខ្លួនរបស់អ្នកដែលឧទ្ទិសជាពិសេសដល់ Kubernetes ដែលត្រៀមរួចរាល់។ ដើម្បីទាញវាចេញ។

Dmitry៖ គោលបំណង នេះគឺដូច្នេះ។ ការចូលទៅក្នុងរឿង Kubernetes សម្រាប់ក្រុមតូចមួយដោយខ្លួនឯង ពាក់ព័ន្ធនឹងហានិភ័យមួយចំនួន។

តើយើងត្រូវការធុងទេ?

- តើអ្នកអាចប្រាប់យើងពីរបៀបដែល Kubernetes រីករាលដាលនៅក្នុងប្រទេសរុស្ស៊ីបានទេ?

Dmitry៖ ខ្ញុំមិនមានទិន្នន័យនេះទេ ហើយខ្ញុំមិនប្រាកដថាអ្នកផ្សេងមានវាទេ។ យើងនិយាយថា៖ “Kubernetes, Kubernetes” ប៉ុន្តែមានវិធីមួយផ្សេងទៀតក្នុងការមើលបញ្ហានេះ។ ខ្ញុំក៏មិនដឹងថាកុងតឺន័ររីករាលដាលប៉ុនណាដែរ ប៉ុន្តែខ្ញុំដឹងពីតួលេខពីរបាយការណ៍នៅលើអ៊ីនធឺណិតថា 70% នៃកុងតឺន័រត្រូវបានចាត់ចែងដោយ Kubernetes ។ វាគឺជាប្រភពដែលអាចទុកចិត្តបានសម្រាប់គំរូដ៏ធំមួយនៅជុំវិញពិភពលោក។

បន្ទាប់មកសំណួរមួយទៀត - តើយើងត្រូវការធុងទេ? អារម្មណ៍ផ្ទាល់ខ្លួនរបស់ខ្ញុំ និងទីតាំងទាំងមូលរបស់ក្រុមហ៊ុន Flan គឺថា Kubernetes គឺជាស្តង់ដារជាក់ស្តែង។

គ្មានអ្វីក្រៅពី Kubernetes ទេ។

នេះគឺជាការផ្លាស់ប្តូរហ្គេមទាំងស្រុងនៅក្នុងវិស័យគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធ។ គ្រាន់តែដាច់ខាត - នោះហើយជាវា, មិនមាន Ansible, ចុងភៅ, ម៉ាស៊ីននិម្មិត, Terraform ។ ខ្ញុំមិននិយាយអំពីវិធីសាស្រ្តកសិកម្មសមូហភាពចាស់ទេ។ Kubernetes គឺជាអ្នកផ្លាស់ប្តូរចុងក្រោយហើយឥឡូវនេះវានឹងក្លាយទៅជាដូចនេះ។

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

- នោះគឺក្រុមហ៊ុនទាំងនោះដែលមិនទាន់បានប្តូរទៅ Kubernetes ច្បាស់ជាប្តូរទៅវា ឬនៅតែស្ថិតក្នុងការភ្លេចភ្លាំង។ ខ្ញុំបានយល់អ្នកត្រឹមត្រូវទេ?

Dmitry៖ នេះ​ក៏​មិន​ពិត​ទាំង​ស្រុង​ដែរ។ ឧទាហរណ៍ប្រសិនបើភារកិច្ចរបស់យើងគឺដើម្បីដំណើរការម៉ាស៊ីនមេ DNS នោះវាអាចត្រូវបានដំណើរការនៅលើ FreeBSD 4.10 ហើយវាអាចដំណើរការបានល្អឥតខ្ចោះសម្រាប់រយៈពេល 20 ឆ្នាំ។ គ្រាន់តែធ្វើការហើយនោះជាវា។ ប្រហែលជាក្នុងរយៈពេល 20 ឆ្នាំ អ្វីៗនឹងត្រូវធ្វើបច្ចុប្បន្នភាពម្តង។ ប្រសិនបើយើងកំពុងនិយាយអំពីកម្មវិធីក្នុងទម្រង់ដែលយើងបានដាក់ឱ្យដំណើរការ ហើយវាពិតជាដំណើរការអស់រយៈពេលជាច្រើនឆ្នាំដោយគ្មានការអាប់ដេតណាមួយឡើយ ដោយមិនមានការកែប្រែទេនោះ ពិតណាស់វានឹងមិនមាន Kubernetes នៅទីនោះទេ។ គាត់មិនត្រូវការនៅទីនោះទេ។

អ្វីគ្រប់យ៉ាងដែលទាក់ទងនឹង CI/CD - គ្រប់ទីកន្លែងដែលត្រូវការការចែកចាយបន្ត កន្លែងដែលអ្នកត្រូវការធ្វើបច្ចុប្បន្នភាពកំណែ ធ្វើការផ្លាស់ប្តូរសកម្ម គ្រប់ទីកន្លែងដែលអ្នកត្រូវការដើម្បីបង្កើតការអត់ឱនកំហុស - មានតែ Kubernetes ប៉ុណ្ណោះ។

អំពីសេវាកម្មមីក្រូ

- នៅទីនេះខ្ញុំមានការមិនចុះសម្រុងបន្តិច។ ដើម្បីធ្វើការជាមួយ Kubernetes អ្នកត្រូវការជំនួយខាងក្រៅ ឬខាងក្នុង - នេះគឺជាចំណុចដំបូង។ ទីពីរ នៅពេលដែលយើងទើបតែចាប់ផ្តើមអភិវឌ្ឍន៍ យើងជាអាជីវកម្មចាប់ផ្តើមតូចមួយ យើងមិនទាន់មានអ្វីនៅឡើយទេ ការអភិវឌ្ឍន៍សម្រាប់ Kubernetes ឬស្ថាបត្យកម្មមីក្រូសេវាកម្មជាទូទៅអាចស្មុគស្មាញ ហើយមិនតែងតែមានភាពយុត្តិធម៌ខាងសេដ្ឋកិច្ចនោះទេ។ ខ្ញុំចាប់អារម្មណ៍លើគំនិតរបស់អ្នក - តើការចាប់ផ្ដើមអាជីវកម្មចាំបាច់ត្រូវចាប់ផ្តើមសរសេរភ្លាមៗសម្រាប់ Kubernetes ពីដំបូងឬពួកគេនៅតែអាចសរសេរ monolith ហើយបន្ទាប់មកមកតែ Kubernetes ទេ?

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

ជាឧទាហរណ៍ មនោរម្យមួយដែលត្រូវបានសរសេរដោយមនុស្ស 300 នាក់ ហើយអ្នកគ្រប់គ្នាដែលបានចូលរួមក្នុងការអភិវឌ្ឍន៍យល់ថាមានបញ្ហានៅទីនោះ ហើយវាគួរតែត្រូវបានបំបែកទៅជាបំណែកតូចៗប្រហែល 10 បំណែក ដែលនីមួយៗត្រូវបានសរសេរដោយមនុស្ស 30 នាក់ នៅក្នុងកំណែអប្បបរមា។ នេះគឺសំខាន់ ចាំបាច់ និងត្រជាក់។ ប៉ុន្តែនៅពេលដែលការចាប់ផ្ដើមអាជីវកម្មមួយមកដល់ពួកយើង ជាកន្លែងដែលបុរសល្អ និងប៉ិនប្រសប់ 3 នាក់បានសរសេរសេវាកម្មមីក្រូចំនួន 60 នៅលើជង្គង់របស់ពួកគេ រាល់ពេលដែលខ្ញុំស្វែងរក Corvalol ។

វាហាក់ដូចជាខ្ញុំថារឿងនេះត្រូវបានគេនិយាយរាប់ពាន់ដងរួចហើយ - ពួកគេបានទទួល monolith ចែកចាយក្នុងទម្រង់មួយឬផ្សេងទៀត។ នេះមិនសមហេតុផលខាងសេដ្ឋកិច្ចទេ ជាទូទៅវាពិបាកណាស់។ គ្រាន់​តែ​ថា​ខ្ញុំ​ឃើញ​រឿង​នេះ​ច្រើន​ដង​ហើយ​ដែល​ធ្វើ​ឲ្យ​ខ្ញុំ​ឈឺ​ចិត្ត​ខ្លាំង​ណាស់ ដូច្នេះ​ខ្ញុំ​បន្ត​និយាយ​អំពី​រឿង​នេះ។

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

វានៅទីនេះ - ទាំងយើងផ្លាស់ទីយ៉ាងលឿន ហើយ Kubernetes អនុញ្ញាតឱ្យយើងធ្វើកិច្ចការជាច្រើនបានលឿន និងប្រសើរជាងមុន ឬយើងប្រើដំណោះស្រាយដែលអាចទុកចិត្តបាន និងសាកល្បងតាមពេលវេលា ប៉ុន្តែផ្លាស់ទីយឺតជាងច្រើន។ នេះជាជម្រើសដែលគ្រប់ក្រុមហ៊ុនត្រូវតែធ្វើ។ អ្នក​អាច​គិត​ថា​វា​ជា​ផ្លូវ​ក្នុង​ព្រៃ - ពេល​អ្នក​ដើរ​ជា​លើក​ដំបូង​អ្នក​អាច​ជួប​នឹង​ពស់ ខ្លា ឬ​ខ្មោច​ឆ្កួត ហើយ​ពេល​ដើរ​១០​ដង អ្នក​បាន​ជាន់​ផ្លូវ​ចេញ។ មែកឈើហើយដើរកាន់តែងាយស្រួល។ រាល់ពេលដែលផ្លូវកាន់តែធំ។ បន្ទាប់​មក​វា​ជា​ផ្លូវ​ក្រាល​កៅស៊ូ ហើយ​ក្រោយ​មក​ជា​មហាវិថី​ដ៏​ស្រស់​ស្អាត។

Kubernetes មិននៅស្ងៀមទេ។ សំណួរម្តងទៀត៖ Kubernetes នៅលើដៃម្ខាងគឺ 4-5 ប្រព័ន្ធគោលពីរ ម្យ៉ាងវិញទៀតវាគឺជាប្រព័ន្ធអេកូឡូស៊ីទាំងមូល។ នេះគឺជាប្រព័ន្ធប្រតិបត្តិការដែលយើងមាននៅលើម៉ាស៊ីនរបស់យើង។ តើ​នេះ​ជា​អ្វី? Ubuntu ឬ Curios? នេះគឺជាខឺណែលលីនុច ដែលជាបណ្តុំនៃសមាសភាគបន្ថែម។ របស់ទាំងអស់នេះនៅទីនេះ ពស់ពិសមួយក្បាលត្រូវបានបោះចោលតាមផ្លូវ របងមួយត្រូវបានសាងសង់នៅទីនោះ។ Kubernetes កំពុងអភិវឌ្ឍយ៉ាងឆាប់រហ័ស និងថាមវន្ត ហើយបរិមាណនៃហានិភ័យ បរិមាណនៃការមិនស្គាល់មានការថយចុះជារៀងរាល់ខែ ហើយតាមនោះ មាត្រដ្ឋានទាំងនេះមានតុល្យភាពឡើងវិញ។

ឆ្លើយសំណួរថាតើការចាប់ផ្តើមអាជីវកម្មគួរធ្វើអ្វី ខ្ញុំនឹងនិយាយថា - មក Flaunt បង់ 150 ពាន់រូប្លិ៍ហើយទទួលបានសេវាងាយស្រួល DevOps turnkey ។ ប្រសិនបើអ្នកជាអ្នកចាប់ផ្តើមអាជីវកម្មតូចមួយដែលមានអ្នកអភិវឌ្ឍន៍តិចតួច វាដំណើរការ។ ជំនួសឱ្យការជួល DevOps ផ្ទាល់ខ្លួនរបស់អ្នក ដែលនឹងត្រូវរៀនដោះស្រាយបញ្ហារបស់អ្នក និងបើកប្រាក់ខែនៅពេលនេះ អ្នកនឹងទទួលបានដំណោះស្រាយ turnkey ចំពោះបញ្ហាទាំងអស់។ បាទ មានគុណវិបត្តិមួយចំនួន។ យើង ក្នុងនាមជាអ្នកផ្គត់ផ្គង់ខាងក្រៅ មិនអាចចូលរួម និងឆ្លើយតបយ៉ាងឆាប់រហ័សចំពោះការផ្លាស់ប្តូរនោះទេ។ ប៉ុន្តែយើងមានជំនាញ និងការអនុវត្តដែលត្រៀមរួចជាស្រេច។ យើងធានាថាក្នុងស្ថានភាពណាក៏ដោយ យើងនឹងដោះស្រាយវាឱ្យបានឆាប់រហ័ស និងប្រោសឱ្យ Kubernetes ពីស្លាប់។

ខ្ញុំសូមផ្តល់អនុសាសន៍យ៉ាងមុតមាំថា ការផ្តល់ធនធានដល់អាជីវកម្មចាប់ផ្តើមអាជីវកម្ម និងបង្កើតអាជីវកម្មរហូតដល់ទំហំដែលអ្នកអាចលះបង់ក្រុមមនុស្ស 10 នាក់ដើម្បីធ្វើប្រតិបត្តិការ ពីព្រោះបើមិនដូច្នេះទេ វាគ្មានន័យអ្វីនោះទេ។ វាពិតជាសមហេតុផលក្នុងការ outsource នេះ។

អំពី Amazon និង Google

- តើម៉ាស៊ីនពីដំណោះស្រាយពី Amazon ឬ Google អាចចាត់ទុកថាជាប្រភពខាងក្រៅបានទេ?

Dmitry៖ បាទ ពិតណាស់ វាដោះស្រាយបញ្ហាមួយចំនួន។ ប៉ុន្តែជាថ្មីម្តងទៀតមានការ nuances ។ អ្នកនៅតែត្រូវយល់ពីរបៀបប្រើវា។ ជាឧទាហរណ៍ មានរឿងតូចតាចមួយពាន់នៅក្នុងការងាររបស់ Amazon AWS៖ Load Balancer ត្រូវការកំដៅឡើង ឬសំណើមួយត្រូវតែសរសេរជាមុនថា "បុរស យើងកំពុងទទួលបានចរាចរណ៍ កំដៅ Load Balancer ឱ្យយើង! ” អ្នកត្រូវដឹងពី nuances ទាំងនេះ។

នៅពេលអ្នកងាកទៅរកមនុស្សដែលមានជំនាញក្នុងរឿងនេះ អ្នកទទួលបានអ្វីៗធម្មតាស្ទើរតែទាំងអស់។ បច្ចុប្បន្ននេះ យើងមានវិស្វករចំនួន 40 នាក់ ហើយនៅចុងឆ្នាំនេះប្រហែលជាមាន 60 នាក់ យើងពិតជាបានជួបប្រទះរឿងទាំងអស់នេះហើយ។ ទោះបីជាយើងជួបប្រទះបញ្ហានេះម្តងទៀតលើគម្រោងមួយចំនួនក៏ដោយ ក៏យើងសួរគ្នាភ្លាមៗ និងដឹងពីរបៀបដោះស្រាយវា។

ប្រហែលជាចម្លើយគឺថា ជាការពិត រឿងដែលបានរៀបចំធ្វើឱ្យផ្នែកខ្លះកាន់តែងាយស្រួល។ សំណួរគឺថាតើអ្នកត្រៀមខ្លួនរួចជាស្រេចក្នុងការជឿទុកចិត្តលើម្ចាស់ផ្ទះទាំងនេះហើយថាតើពួកគេនឹងដោះស្រាយបញ្ហារបស់អ្នកដែរឬទេ។ Amazon និង Google ដំណើរការបានល្អ។ សម្រាប់ករណីទាំងអស់របស់យើង - ពិតប្រាកដ។ យើងមិនមានបទពិសោធន៍វិជ្ជមានទៀតទេ។ ពពកផ្សេងទៀតទាំងអស់ដែលយើងព្យាយាមធ្វើការជាមួយបង្កើតបញ្ហាជាច្រើន - Ager និងអ្វីគ្រប់យ៉ាងដែលមាននៅក្នុងប្រទេសរុស្ស៊ី និងគ្រប់ប្រភេទ OpenStack នៅក្នុងការអនុវត្តផ្សេងៗគ្នា៖ Headster, Overage - អ្វីក៏ដោយដែលអ្នកចង់បាន។ ពួកគេទាំងអស់បង្កើតបញ្ហាដែលអ្នកមិនចង់ដោះស្រាយ។

ដូច្នេះ ចម្លើយគឺបាទ ប៉ុន្តែតាមពិត ដំណោះស្រាយដែលរៀបចំដោយចាស់ទុំមិនមានច្រើនទេ។

តើអ្នកណាត្រូវការ Kubernetes?

- ហើយអ្នកណាត្រូវការ Kubernetes? តើអ្នកណាគួរតែប្តូរទៅ Kubernetes រួចហើយ តើអ្នកណាជាអតិថិជន Flaunt ធម្មតាដែលមកជាពិសេសសម្រាប់ Kubernetes?

Dmitry៖ នេះ​ជា​សំណួរ​ដែល​គួរ​ឱ្យ​ចាប់​អារម្មណ៍ ព្រោះ​ឥឡូវ​នេះ នៅ​លើ​រលក​នៃ Kubernetes មាន​មនុស្ស​ជា​ច្រើន​មក​រក​យើង៖ "បុរស យើង​ដឹង​ថា​អ្នក​កំពុង​បង្កើត Kubernetes ធ្វើ​វា​សម្រាប់​យើង!" យើងឆ្លើយពួកគេថា "សុភាពបុរស យើងមិនធ្វើ Kubernetes ទេ យើងធ្វើផលិតផល និងអ្វីគ្រប់យ៉ាងដែលភ្ជាប់ជាមួយវា" ។ ព្រោះវាមិនអាចទៅរួចទេក្នុងការបង្កើតផលិតផលដោយមិនធ្វើ CI/CD និងរឿងទាំងមូលនេះ។ មនុស្សគ្រប់គ្នាបានផ្លាស់ប្តូរឆ្ងាយពីការបែងចែកដែលយើងមានការអភិវឌ្ឍន៍ដោយការអភិវឌ្ឍន៍ហើយបន្ទាប់មកការកេងប្រវ័ញ្ចដោយការកេងប្រវ័ញ្ច។

អតិថិជនរបស់យើងរំពឹងថានឹងមានអ្វីប្លែក ប៉ុន្តែគ្រប់គ្នាកំពុងរង់ចាំអព្ភូតហេតុដ៏ល្អមួយចំនួនដែលពួកគេមានបញ្ហាជាក់លាក់ ហើយឥឡូវនេះ - hop! - Kubernetes នឹងដោះស្រាយពួកគេ។ មនុស្សជឿលើអព្ភូតហេតុ។ ក្នុង​ចិត្ត​ពួកគេ​យល់​ថា​នឹង​មិន​មាន​អព្ភូតហេតុ​ទេ ប៉ុន្តែ​ក្នុង​ព្រលឹង​ពួកគេ​សង្ឃឹម​ថា Kubernetes នេះ​នឹង​ដោះស្រាយ​គ្រប់​យ៉ាង​សម្រាប់​យើង​ឥឡូវ​នេះ ពួកគេ​និយាយ​ច្រើន​អំពី​វា! ស្រាប់តែ​គាត់​កណ្តាស់​! - និងគ្រាប់កាំភ្លើងមួយគ្រាប់ កណ្តាស់! - ហើយយើងមានពេលដំណើរការ 100% អ្នកអភិវឌ្ឍន៍ទាំងអស់អាចបញ្ចេញនូវអ្វីដែលពួកគេបានចូលទៅក្នុងផលិតកម្ម 50 ដង ហើយវាមិនគាំងទេ។ ជាទូទៅអព្ភូតហេតុ!

ពេល​មនុស្ស​បែប​នេះ​មក​រក​យើង យើង​និយាយ​ថា​៖ ​«​សូម​ទោស ប៉ុន្តែ​អព្ភូតហេតុ​មិន​កើត​ឡើង​ទេ​»។ ដើម្បីមានសុខភាពល្អ អ្នកត្រូវញ៉ាំអាហារឱ្យបានល្អ និងហាត់ប្រាណ។ ដើម្បី​មាន​ផលិតផល​គួរ​ឱ្យ​ទុក​ចិត្ត​បាន​ត្រូវ​ធ្វើ​ឱ្យ​មាន​ភាព​ទុក​ចិត្ត​។ ដើម្បីមាន CI/CD ងាយស្រួល អ្នកត្រូវធ្វើវាដូចនេះ។ នោះជាការងារជាច្រើនដែលត្រូវធ្វើ។

ដើម្បីឆ្លើយសំណួរថាតើអ្នកណាត្រូវការ Kubernetes គ្មាននរណាម្នាក់ត្រូវការ Kubernetes ទេ។

មនុស្សមួយចំនួនមានការយល់ខុសថាពួកគេត្រូវការ Kubernetes ។ មនុស្សត្រូវការ ពួកគេមានតម្រូវការស៊ីជម្រៅក្នុងការឈប់គិត សិក្សា ចាប់អារម្មណ៍លើបញ្ហាទាំងអស់នៃហេដ្ឋារចនាសម្ព័ន្ធ និងបញ្ហានៃការដំណើរការកម្មវិធីរបស់ពួកគេ។ ពួកគេចង់ឱ្យកម្មវិធីដំណើរការ និងគ្រាន់តែដាក់ពង្រាយ។ សម្រាប់ពួកគេ Kubernetes គឺជាក្តីសង្ឃឹមដែលថាពួកគេនឹងឈប់ស្តាប់រឿងដែលថា "យើងកំពុងដេកនៅទីនោះ" ឬ "យើងមិនអាចចេញបានទេ" ឬអ្វីក៏ដោយ។

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

ពាក្យដែលយើង ឬនរណាម្នាក់ផ្សេងទៀតត្រូវការ Kubernetes គឺខុស។

Admin ពិត​ជា​ត្រូវ​ការ Kubernetes ព្រោះ​វា​ជា​ប្រដាប់​ក្មេង​លេង​ដែល​គួរ​ឱ្យ​ចាប់​អារម្មណ៍​ខ្លាំង​ណាស់​ដែល​អ្នក​អាច​លេង​ជាមួយ​បាន​។ ចូរនិយាយដោយស្មោះត្រង់ — អ្នករាល់គ្នាចូលចិត្តរបស់លេង។ យើងទាំងអស់គ្នាជាកុមារនៅកន្លែងណាមួយហើយនៅពេលដែលយើងឃើញអ្នកថ្មីយើងចង់លេងជាមួយវា។ មនុស្សមួយចំនួនបានច្រានចោលរឿងនេះ ជាឧទាហរណ៍ ក្នុងផ្នែករដ្ឋបាល ព្រោះពួកគេបានលេងគ្រប់គ្រាន់ហើយ ហើយហត់នឿយដល់ចំណុចដែលគេមិនចង់បាន។ ប៉ុន្តែនេះមិនត្រូវបានបាត់បង់ទាំងស្រុងទៅនរណាម្នាក់ទេ។ ជាឧទាហរណ៍ ប្រសិនបើខ្ញុំធុញទ្រាន់នឹងប្រដាប់ប្រដាក្មេងលេងក្នុងវិស័យគ្រប់គ្រងប្រព័ន្ធ និង DevOps អស់រយៈពេលជាយូរមកហើយនោះ ខ្ញុំនៅតែស្រលាញ់របស់ក្មេងលេង ហើយនៅតែទិញរបស់ថ្មីមួយចំនួនទៀត។ មនុស្សទាំងអស់មិនថាមធ្យោបាយមួយឬក៏ផ្សេងទៀតនៅតែចង់បានរបស់ក្មេងលេងមួយចំនួន។

មិនចាំបាច់លេងជាមួយផលិតកម្មទេ។ អ្វី​ដែល​ខ្ញុំ​មិន​ណែនាំ​ឲ្យ​ធ្វើ​ជា​ដាច់​ខាត និង​អ្វី​ដែល​ខ្ញុំ​មើល​ឃើញ​នៅ​ពេល​នេះ៖ “អូ ប្រដាប់​ក្មេង​លេង​ថ្មី!” - ពួកគេបានរត់ទៅទិញវាទិញវាហើយ "តោះយកវាទៅសាលារៀនឥឡូវនេះហើយបង្ហាញវាដល់មិត្តរបស់យើងទាំងអស់គ្នា" ។ កុំធ្វើបែបនេះ។ ខ្ញុំសុំទោស កូនរបស់ខ្ញុំទើបតែធំឡើង ខ្ញុំតែងតែឃើញអ្វីមួយនៅក្នុងកុមារ កត់សម្គាល់វានៅក្នុងខ្លួនខ្ញុំ ហើយបន្ទាប់មកប្រាប់វាដល់អ្នកដទៃ។

ចម្លើយចុងក្រោយគឺ៖ អ្នកមិនត្រូវការ Kubernetes ទេ។ អ្នកត្រូវដោះស្រាយបញ្ហារបស់អ្នក។

អ្វីដែលអ្នកអាចធ្វើបានគឺ៖

• ផលិតផលមិនធ្លាក់ចុះ;
• ទោះបីជាគាត់ព្យាយាមដួលក៏ដោយ ក៏យើងដឹងអំពីវាជាមុន ហើយអាចដាក់អ្វីមួយបានដែរ។
• យើង​អាច​ផ្លាស់ប្តូរ​វា​តាម​ល្បឿន​ដែល​អាជីវកម្ម​របស់​យើង​ទាមទារ ហើយ​យើង​អាច​ធ្វើ​វា​បាន​ដោយ​ងាយស្រួល វា​មិន​បង្ក​បញ្ហា​ដល់​យើង​ទេ។

មានតម្រូវការពិតពីរ៖ ភាពអាចជឿជាក់បាន និងដំណើរការថាមវន្ត/អាចបត់បែនបាន។ មនុស្សគ្រប់រូបដែលបច្ចុប្បន្នកំពុងធ្វើគម្រោង IT មួយចំនួន មិនថានៅក្នុងអាជីវកម្មណាមួយ - ទន់សម្រាប់បន្ធូរបន្ថយពិភពលោក ហើយអ្នកណាដែលយល់អំពីបញ្ហានេះ ចាំបាច់ត្រូវដោះស្រាយតម្រូវការទាំងនេះ។ Kubernetes ជាមួយនឹងវិធីសាស្រ្តត្រឹមត្រូវ ជាមួយនឹងការយល់ដឹងត្រឹមត្រូវ និងជាមួយនឹងបទពិសោធន៍គ្រប់គ្រាន់អនុញ្ញាតឱ្យពួកគេដោះស្រាយ។

អំពី serverless

— ប្រសិនបើអ្នកក្រឡេកមើលទៅអនាគតបន្តិចទៀតនោះ ការព្យាយាមដោះស្រាយបញ្ហាអវត្តមាននៃការឈឺក្បាលជាមួយនឹងហេដ្ឋារចនាសម្ព័ន្ធ ជាមួយនឹងល្បឿននៃការដាក់ឱ្យដំណើរការ និងល្បឿននៃការផ្លាស់ប្តូរកម្មវិធី ដំណោះស្រាយថ្មីនឹងលេចឡើង ឧទាហរណ៍ដូចជា serverless ។ តើអ្នកមានអារម្មណ៍ថាមានសក្តានុពលណាមួយនៅក្នុងទិសដៅនេះ ហើយឧបមាថាគ្រោះថ្នាក់សម្រាប់ Kubernetes និងដំណោះស្រាយស្រដៀងគ្នាដែរឬទេ?

Dmitry៖ នៅទីនេះយើងត្រូវធ្វើការកត់សម្គាល់ម្តងទៀតថា ខ្ញុំមិនមែនជាអ្នកមើលមុខដែលមើលទៅមុខ ហើយនិយាយថា "វានឹងដូចនេះ!" ទោះបីជាខ្ញុំទើបតែធ្វើដូចគ្នាក៏ដោយ។ ខ្ញុំក្រឡេកមើលជើងរបស់ខ្ញុំ ហើយឃើញបញ្ហាជាច្រើននៅទីនោះ ជាឧទាហរណ៍ របៀបដែលត្រង់ស៊ីស្ទ័រដំណើរការនៅក្នុងកុំព្យូទ័រ។ គួរឱ្យអស់សំណើចណាស់មែនទេ? យើងកំពុងជួបប្រទះបញ្ហាមួយចំនួននៅក្នុង CPU ។

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

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

ជាមួយនឹង serverless one on one: រឿងគឺត្រជាក់ប៉ុន្តែវានៅឆ្ងាយពីបញ្ហានៃ 2019 ។ កាន់តែខិតជិតដល់ឆ្នាំ 2030 - តោះទស្សនាទាំងអស់គ្នា។ ខ្ញុំគ្មានមន្ទិលទេថាយើងនឹងរស់ យើងប្រាកដជារស់នៅ (និយាយម្តងទៀតមុនពេលចូលគេង) ប៉ុន្តែឥឡូវនេះយើងត្រូវដោះស្រាយបញ្ហាផ្សេងទៀត។ វាដូចជាការជឿលើសត្វសេះឥន្ទធនូ។ បាទ / ចាស៎ ពីរបីភាគរយនៃករណីត្រូវបានដោះស្រាយ ហើយពួកគេត្រូវបានដោះស្រាយយ៉ាងល្អឥតខ្ចោះ ប៉ុន្តែតាមប្រធានបទ ការគ្មានម៉ាស៊ីនមេគឺជាឥន្ទធនូ... សម្រាប់ខ្ញុំ ប្រធានបទនេះគឺនៅឆ្ងាយពេក និងមិនអាចយល់បាន។ ខ្ញុំមិនទាន់ត្រៀមខ្លួននិយាយទេ។ នៅឆ្នាំ 2019 អ្នកមិនអាចសរសេរកម្មវិធីតែមួយជាមួយ serverless បានទេ។

របៀបដែល Kubernetes នឹងវិវត្ត

— នៅពេលដែលយើងឆ្ពោះទៅរកអនាគតដ៏ឆ្ងាយដ៏មានសក្តានុពលនេះ តើអ្នកគិតថា Kubernetes និងប្រព័ន្ធអេកូឡូស៊ីជុំវិញវានឹងអភិវឌ្ឍយ៉ាងដូចម្តេច?

Dmitry៖ ខ្ញុំបានគិតអំពីរឿងនេះច្រើន ហើយខ្ញុំមានចម្លើយច្បាស់លាស់។ ទីមួយគឺមានលក្ខណៈរដ្ឋ - បន្ទាប់ពីទាំងអស់ ភាពគ្មានរដ្ឋគឺងាយស្រួលធ្វើ។ ដើមឡើយ Kubernetes បានបណ្តាក់ទុនកាន់តែច្រើនក្នុងរឿងនេះ វាទាំងអស់បានចាប់ផ្តើមជាមួយវា។ Stateless ដំណើរការស្ទើរតែឥតខ្ចោះនៅក្នុង Kubernetes គ្មានអ្វីដែលត្រូវត្អូញត្អែរអំពីនោះទេ។ យោងទៅតាម Statefull នៅតែមានបញ្ហាជាច្រើន ឬផ្ទុយទៅវិញ ភាពមិនច្បាស់លាស់។ អ្វី​គ្រប់​យ៉ាង​នៅ​ទីនោះ​ដំណើរការ​ល្អ​សម្រាប់​យើង​រួច​ហើយ ប៉ុន្តែ​នោះ​ជា​យើង។ វានឹងត្រូវចំណាយពេលយ៉ាងហោចណាស់ពីរបីឆ្នាំទៀត ដើម្បីដំណើរការសម្រាប់មនុស្សគ្រប់គ្នា។ នេះមិនមែនជាសូចនាករដែលបានគណនាទេ ប៉ុន្តែអារម្មណ៍របស់ខ្ញុំចេញពីក្បាលរបស់ខ្ញុំ។

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

កម្រិតនៃការមិនស្គាល់ កម្រិតនៃបញ្ហាដែលមិនអាចដោះស្រាយបាន កម្រិតនៃប្រូបាប៊ីលីតេនៃការជួបប្រទះអ្វីមួយនឹងធ្លាក់ចុះយ៉ាងខ្លាំង។ នេះជារឿងសំខាន់មួយ។ និងប្រតិបត្តិករ - អ្វីគ្រប់យ៉ាងដែលទាក់ទងនឹងការសរសេរកូដនៃតក្កវិជ្ជាគ្រប់គ្រង តក្កវិជ្ជាគ្រប់គ្រង ដើម្បីទទួលបានសេវាកម្មងាយស្រួល: សេវាងាយស្រួល MySQL សេវាងាយស្រួល RabbitMQ សេវាងាយស្រួល Memcache - ជាទូទៅ សមាសធាតុទាំងអស់នេះដែលយើងត្រូវធានាដើម្បីដំណើរការ។ ប្រអប់។ វាគ្រាន់តែដោះស្រាយការឈឺចាប់ដែលយើងចង់បានមូលដ្ឋានទិន្នន័យ ប៉ុន្តែមិនចង់គ្រប់គ្រងវា ឬចង់បាន Kubernetes ប៉ុន្តែមិនចង់គ្រប់គ្រងវាទេ។

រឿងរ៉ាវនៃការអភិវឌ្ឍន៍ប្រតិបត្តិករនេះក្នុងទម្រង់មួយ ឬមួយនឹងមានសារៈសំខាន់នៅក្នុងរយៈពេលពីរបីឆ្នាំខាងមុខនេះ។

ខ្ញុំគិតថាភាពងាយស្រួលនៃការប្រើប្រាស់គួរតែកើនឡើងយ៉ាងខ្លាំង - ប្រអប់នឹងកាន់តែខ្មៅ កាន់តែអាចទុកចិត្តបាន ជាមួយនឹងប៊ូតុងសាមញ្ញកាន់តែច្រើន។

ខ្ញុំបានស្តាប់បទសម្ភាសន៍ចាស់ជាមួយ Isaac Asimov ពីទសវត្សរ៍ទី 80 នៅលើ YouTube នៅលើកម្មវិធី Saturday Night Live ដែលជាកម្មវិធីដូចជា Urgant គួរឱ្យចាប់អារម្មណ៍តែប៉ុណ្ណោះ។ ពួកគេបានសួរគាត់អំពីអនាគតនៃកុំព្យូទ័រ។ លោក​ថា អនាគត​គឺ​នៅ​ក្នុង​ភាព​សាមញ្ញ​ដូច​វិទ្យុ​អ៊ីចឹង។ ដើមឡើយអ្នកទទួលវិទ្យុគឺជារឿងស្មុគស្មាញ។ ដើម្បីចាប់រលក អ្នកត្រូវបង្វិលគ្រាប់ចុចរយៈពេល 15 នាទី បង្វែរ skewers ហើយជាទូទៅដឹងពីរបៀបដែលអ្វីៗដំណើរការ យល់អំពីរូបវិទ្យានៃការបញ្ជូនរលកវិទ្យុ។ ជា​លទ្ធផល​នៅ​សល់​តែ​ប៊ូតុង​មួយ​ប៉ុណ្ណោះ​ក្នុង​វិទ្យុ។

តើវាជាវិទ្យុអ្វីនៅឆ្នាំ 2019? នៅក្នុងឡានអ្នកទទួលវិទ្យុរកឃើញរលកទាំងអស់និងឈ្មោះស្ថានីយ៍។ រូបវិទ្យានៃដំណើរការមិនផ្លាស់ប្តូរក្នុងរយៈពេល 100 ឆ្នាំនោះទេ ប៉ុន្តែភាពងាយស្រួលនៃការប្រើប្រាស់មាន។ ឥឡូវនេះហើយមិនត្រឹមតែប៉ុណ្ណោះឥឡូវនេះរួចទៅហើយនៅឆ្នាំ 1980 នៅពេលដែលមានបទសម្ភាសន៍ជាមួយ Azimov មនុស្សគ្រប់គ្នាបានប្រើវិទ្យុហើយគ្មាននរណាម្នាក់គិតអំពីរបៀបដែលវាដំណើរការនោះទេ។ វាតែងតែដំណើរការ — នោះគឺជាការផ្តល់ឱ្យ។

បន្ទាប់មក Asimov បាននិយាយថាវានឹងដូចគ្នាជាមួយនឹងកុំព្យូទ័រ។ ភាពងាយស្រួលនៃការប្រើប្រាស់នឹងកើនឡើង. ប្រសិនបើនៅឆ្នាំ 1980 អ្នកត្រូវទទួលបានការអប់រំពិសេសដើម្បីចុចប៊ូតុងនៅលើកុំព្យូទ័រនោះនៅពេលអនាគតវានឹងមិនមាននោះទេ។

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

តើត្រូវធ្វើអ្វីជាមួយវិស្វករ?

- តើនឹងមានអ្វីកើតឡើងចំពោះវិស្វករ និងអ្នកគ្រប់គ្រងប្រព័ន្ធដែលគាំទ្រ Kubernetes?

Dmitry៖ តើមានអ្វីកើតឡើងចំពោះគណនេយ្យករបន្ទាប់ពីការមកដល់នៃ 1C? អំពីដូចគ្នា។ មុននេះពួកគេបានរាប់នៅលើក្រដាស - ឥឡូវនេះនៅក្នុងកម្មវិធីមួយ។ ផលិតភាពការងារបានកើនឡើងតាមលំដាប់លំដោយ ប៉ុន្តែកម្លាំងពលកម្មខ្លួនឯងមិនបានរលាយបាត់ឡើយ។ ប្រសិនបើពីមុនវាយកវិស្វករ 10 នាក់មកវីសក្នុងអំពូលនោះ ឥឡូវនេះមួយនឹងគ្រប់គ្រាន់ហើយ។

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

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

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

DevOps ឬវិស្វកម្មប្រព័ន្ធនឹងមិនទៅណាទេ - ការងារកម្រិតខ្ពស់ និងប្រសិទ្ធភាពនឹងកើនឡើង។

- ខ្ញុំក៏បានឮគំនិតគួរឱ្យចាប់អារម្មណ៍មួយថា ការងារពិតជានឹងកើនឡើង។

Dmitry៖ ពិតណាស់មួយរយភាគរយ! ដោយសារតែចំនួនកម្មវិធីដែលយើងសរសេរកំពុងកើនឡើងឥតឈប់ឈរ។ ចំនួននៃបញ្ហាដែលយើងដោះស្រាយជាមួយកម្មវិធីកំពុងកើនឡើងឥតឈប់ឈរ។ បរិមាណការងារកំពុងកើនឡើង។ ឥឡូវនេះទីផ្សារ DevOps កំពុងឡើងកំដៅខ្លាំង។ នេះអាចត្រូវបានគេមើលឃើញនៅក្នុងការរំពឹងទុកប្រាក់ខែ។ តាមរបៀបដ៏ល្អ ដោយមិនចូលទៅក្នុងពត៌មានលំអិត គួរតែមានក្មេងតូចៗដែលចង់បាន X មធ្យមដែលចង់បាន 1,5X និងមនុស្សចាស់ដែលចង់បាន 2X។ ហើយឥឡូវនេះ ប្រសិនបើអ្នកក្រឡេកមើលទីផ្សារប្រាក់បៀវត្សរ៍របស់ Moscow DevOps យុវជនចង់បានពី X ដល់ 3X និងមនុស្សចាស់ចង់បានពី X ទៅ 3X។

គ្មាននរណាម្នាក់ដឹងថាវាមានតម្លៃប៉ុន្មានទេ។ កម្រិតប្រាក់បៀវត្សរ៍ត្រូវបានវាស់ដោយទំនុកចិត្តរបស់អ្នក - ផ្ទះឆ្កួតទាំងស្រុង និយាយដោយស្មោះត្រង់ ទីផ្សារក្តៅខ្លាំង។

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

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

Dmitry: មួយ​រយ​ភាគរយ។ ជាទូទៅយើងរស់នៅក្នុងឆ្នាំ 2019 ហើយច្បាប់នៃជីវិតគឺនេះ: ការរៀនពេញមួយជីវិត - យើងរៀនពេញមួយជីវិតរបស់យើង។. វាហាក់ដូចជាខ្ញុំថាឥឡូវនេះមនុស្សគ្រប់គ្នាដឹងនិងមានអារម្មណ៍នេះរួចហើយប៉ុន្តែការដឹងគឺមិនគ្រប់គ្រាន់ទេ - អ្នកត្រូវតែធ្វើវា។ ជារៀងរាល់ថ្ងៃ យើងត្រូវផ្លាស់ប្តូរ។ បើ​យើង​មិន​ធ្វើ​បែប​នេះ​ទេ មិន​យូរ​មិន​ឆាប់ យើង​នឹង​ត្រូវ​គេ​បោះបង់​អាជីព។

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

បំណងប្រាថ្នានិងនាទីនៃការផ្សាយពាណិជ្ជកម្ម

- តើអ្នកមានបំណងប្រាថ្នាទេ?

Dmitry៖ បាទ ខ្ញុំមានបំណងប្រាថ្នាជាច្រើន។

ទំនិញដំបូង និងច្រើនបំផុត - ជាវ YouTube. អ្នកអានជាទីគោរព សូមចូលទៅកាន់ YouTube និងជាវឆានែលរបស់យើង។ ក្នុងរយៈពេលប្រហែលមួយខែទៀត យើងនឹងចាប់ផ្តើមការពង្រីកយ៉ាងសកម្មលើសេវាកម្មវីដេអូ។ យើងនឹងមានខ្លឹមសារអប់រំជាច្រើនអំពី Kubernetes បើកចំហ និងខុសប្លែកពីគេ៖ ពីវត្ថុជាក់ស្តែង រហូតដល់មន្ទីរពិសោធន៍ រហូតដល់ទ្រឹស្តីជាមូលដ្ឋានយ៉ាងស៊ីជម្រៅ និងរបៀបអនុវត្ត Kubernetes នៅ កម្រិតនៃគោលការណ៍និងលំនាំ។

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

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

នេះមិនមានន័យថាអ្នកមិនគួរពិសោធន៍ទេ។ យើងត្រូវធ្វើការពិសោធន៍ យើងធ្វើដោយខ្លួនឯង និយាយឱ្យត្រង់ទៅ ពេលខ្លះយើងក៏លេងដែរ - នេះជាការពិតណាស់ វាអាក្រក់ណាស់ ប៉ុន្តែគ្មានអ្វីដែលមនុស្សចម្លែកចំពោះយើងទេ។ សូមប្រកាសឆ្នាំ 2019 ថាជាឆ្នាំនៃការពិសោធដែលគិតបានល្អិតល្អន់ ហើយមិនមែនជាហ្គេមលើការផលិតនោះទេ។ ប្រហែលជាដូច្នេះ។

- អរគុណ​ច្រើន!

Dmitry៖ សូមអរគុណ វីតាលី ទាំងពេលវេលា និងសម្រាប់ការសម្ភាសន៍។ អ្នកអានជាទីគោរព សូមអរគុណច្រើន ប្រសិនបើអ្នកបានឈានដល់ចំណុចនេះភ្លាមៗ។ ខ្ញុំសង្ឃឹមថា យើងបាននាំអ្នកនូវគំនិតមួយចំនួនយ៉ាងតិច។

នៅក្នុងបទសម្ភាសន៍ Dmitry បានប៉ះលើបញ្ហានៃ werf ។ ឥឡូវនេះនេះគឺជាកាំបិតស្វីសជាសកលដែលដោះស្រាយបញ្ហាស្ទើរតែទាំងអស់។ ប៉ុន្តែវាមិនតែងតែដូច្នេះទេ។ បើក DevOpsConf  នៅពិធីបុណ្យ RIT++ Dmitry Stolyarov នឹងនិយាយអំពីឧបករណ៍នេះឱ្យបានលំអិត។ នៅក្នុងរបាយការណ៍ "werf គឺជាឧបករណ៍របស់យើងសម្រាប់ CI/CD នៅលើ Kubernetes ។" វានឹងមានអ្វីៗគ្រប់យ៉ាង៖ បញ្ហា និងការលាក់កំបាំងរបស់ Kubernetes ជម្រើសសម្រាប់ដោះស្រាយការលំបាកទាំងនេះ និងការអនុវត្តបច្ចុប្បន្ននៃ werf យ៉ាងលម្អិត។ ចូលរួមជាមួយពួកយើងនៅថ្ងៃទី 27 និង 28 ឧសភា យើងនឹងបង្កើតឧបករណ៍ដ៏ល្អឥតខ្ចោះ។

ប្រភព: www.habr.com