K8S ដំណើរ​ពហុ​ចង្កោម

ហេហេ!

យើងតំណាងឱ្យក្រុមវេទិកា Exness ។ ពីមុនសហការីរបស់យើងបានសរសេរអត្ថបទមួយរួចហើយអំពី រូបភាពផលិតរួចរាល់សម្រាប់ k8s. ថ្ងៃនេះយើងចង់ចែករំលែកបទពិសោធន៍របស់យើងក្នុងការផ្ទេរសេវាកម្មទៅ Kubernetes ។

ដើម្បីចាប់ផ្តើមជាមួយ យើងផ្តល់ជូនអ្នកនូវលេខមួយចំនួនសម្រាប់ការយល់ដឹងកាន់តែច្បាស់អំពីអ្វីដែលនឹងត្រូវបានពិភាក្សា៖

• នាយកដ្ឋានអភិវឌ្ឍន៍របស់យើងមាន 100+ នាក់ រួមទាំងក្រុមជាង 10 ផ្សេងៗគ្នាដែលមានដំណើរការ QA, DevOps និង Scrum ដែលមានលក្ខណៈគ្រប់គ្រាន់ដោយខ្លួនឯង។ ជង់អភិវឌ្ឍន៍ - Python, PHP, C++, Java និង Golang ។ 
• ទំហំនៃការធ្វើតេស្តនិងបរិយាកាសផលិតកម្មគឺប្រហែល 2000 ធុងនីមួយៗ។ ពួកគេកំពុងដំណើរការ Rancher v1.6 នៅលើនិម្មិតផ្ទាល់ខ្លួនរបស់ពួកគេ និងនៅក្រោម VMware។ 

ការលើកទឹកចិត្ត

ដូចដែលពួកគេនិយាយ គ្មានអ្វីស្ថិតស្ថេរជារៀងរហូត ហើយ Rancher បានប្រកាសពីការបញ្ចប់ការគាំទ្រសម្រាប់កំណែ 1.6 ជាយូរមកហើយ។ មែនហើយ ក្នុងរយៈពេលជាងបីឆ្នាំ យើងបានរៀនពីរបៀបរៀបចំវា និងដោះស្រាយបញ្ហាដែលកើតឡើង ប៉ុន្តែកាន់តែច្រើនឡើងៗ យើងត្រូវប្រឈមមុខនឹងបញ្ហាដែលមិនអាចកែតម្រូវបាន។ Rancher 1.6 ក៏មានប្រព័ន្ធ ossified សម្រាប់ការចេញសិទ្ធិ ដែលអ្នកអាចធ្វើបានស្ទើរតែទាំងអស់ ឬគ្មានអ្វីទាំងអស់។

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

យើងចង់ធ្វើតាមស្តង់ដារ IaC ហើយប្រសិនបើចាំបាច់ ទទួលបានសមត្ថភាពយ៉ាងឆាប់រហ័សនៅក្នុងទីតាំងភូមិសាស្រ្តណាមួយ និងដោយគ្មានសោអ្នកលក់ ហើយក៏អាចបោះបង់ចោលវាបានយ៉ាងឆាប់រហ័សផងដែរ។

ជំហានដំបូង

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

បន្ទាប់​មក​សំណួរ​នៃ​ការ​ជ្រើសរើស​ឧបករណ៍​សម្រាប់​បង្កើត​ចង្កោម។ យើងបានប្រៀបធៀបដំណោះស្រាយពេញនិយមបំផុត: kops, kubespray, kubeadm ។

ដើម្បីចាប់ផ្តើម kubeadm ហាក់ដូចជាពួកយើងមានផ្លូវស្មុគស្មាញពេក ជាជាងអ្នកបង្កើត "កង់" ហើយ kops មិនមានភាពបត់បែនគ្រប់គ្រាន់ទេ។

ហើយអ្នកឈ្នះគឺ៖

យើងបានចាប់ផ្តើមពិសោធន៍ជាមួយនិម្មិតនិម្មិតរបស់យើង និង AWS ដោយព្យាយាមបង្កើតឡើងវិញនូវអ្វីដែលស្រដៀងនឹងគំរូការគ្រប់គ្រងធនធានពីមុនរបស់យើង ដែលគ្រប់គ្នាបានចែករំលែក "ចង្កោម" ដូចគ្នា។ ហើយឥឡូវនេះយើងមានចង្កោមដំបូងរបស់យើងនៃម៉ាស៊ីននិម្មិតតូចៗចំនួន 10 ដែលមួយចំនួនមានទីតាំងនៅ AWS ។ យើងបានចាប់ផ្តើមព្យាយាមធ្វើចំណាកស្រុកទៅក្រុមនៅទីនោះ អ្វីៗហាក់ដូចជា "ល្អ" ហើយរឿងអាចបញ្ចប់បាន ប៉ុន្តែ...

បញ្ហាដំបូង

Ansible គឺជាអ្វីដែល kubespray ត្រូវបានបង្កើតឡើង វាមិនមែនជាឧបករណ៍ដែលអនុញ្ញាតឱ្យអ្នកធ្វើតាម IaC នោះទេ៖ នៅពេលដែលការបញ្ជូន/ដកថ្នាំង អ្វីមួយតែងតែខុស ហើយការអន្តរាគមន៍មួយចំនួនត្រូវបានទាមទារ ហើយនៅពេលប្រើ OSes ផ្សេងៗ សៀវភៅលេងមានឥរិយាបថខុសគ្នា។ . នៅពេលដែលចំនួនក្រុម និងថ្នាំងនៅក្នុងចង្កោមកើនឡើង យើងចាប់ផ្តើមកត់សំគាល់ថា សៀវភៅលេងត្រូវចំណាយពេលយូរ និងយូរជាងនេះដើម្បីបញ្ចប់ ហើយជាលទ្ធផល កំណត់ត្រារបស់យើងគឺ 3,5 ម៉ោង ចុះអ្នកវិញ? 🙂

ហើយវាហាក់ដូចជា kubespray គឺគ្រាន់តែជា Ansible ហើយអ្វីគ្រប់យ៉ាងគឺច្បាស់នៅ glance ដំបូង ប៉ុន្តែ:

នៅដើមដំបូងនៃការធ្វើដំណើរ ភារកិច្ចគឺដើម្បីបើកដំណើរការសមត្ថភាពតែនៅក្នុង AWS និងនៅលើនិម្មិត ប៉ុន្តែបន្ទាប់មក តម្រូវការបានផ្លាស់ប្តូរដូចដែលកើតឡើងជាញឹកញាប់។
 


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

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

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

តើធ្វើដូចម្តេចដើម្បីឱ្យមាន?

ដោយគិតពីចំណុចខាងលើ និងបំណងប្រាថ្នារបស់ក្រុមដើម្បីឱ្យមានភាពឯករាជ្យ យើងបានធ្វើការសន្និដ្ឋានសាមញ្ញមួយ៖ ក្រុមមួយ - ចង្កោមមួយ។ 

ដូច្នេះយើងទទួលបានទីពីរ៖

ហើយបន្ទាប់មកក្រុមទីបី៖ 

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

Kubernetes ពេញនឹងមក! នេះគឺជាប្រភេទមួយចំនួននៃ MultiKubernetes វាប្រែចេញ។ 

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

ពេលវេលាខ្លះបានកន្លងផុតទៅចាប់តាំងពីការចាប់ផ្តើមនៃការធ្វើដំណើររបស់យើងនៅក្នុងពិភព Kubernetes ហើយយើងបានសម្រេចចិត្តពិនិត្យមើលឡើងវិញនូវដំណោះស្រាយដែលមាន។ វាប្រែថាវាមានរួចហើយនៅលើទីផ្សារ - Rancher 2.2 ។

នៅដំណាក់កាលដំបូងនៃការស្រាវជ្រាវរបស់យើង Rancher Labs បានបង្កើតកំណែទី 2 ជាលើកដំបូងរួចហើយ ប៉ុន្តែទោះបីជាវាអាចត្រូវបានលើកឡើងយ៉ាងឆាប់រហ័សដោយការបើកដំណើរការកុងតឺន័រដោយគ្មានភាពអាស្រ័យខាងក្រៅជាមួយនឹងប៉ារ៉ាម៉ែត្រពីរ ឬប្រើតារាង HELM ផ្លូវការក៏ដោយ វាហាក់ដូចជាឆៅ។ ចំពោះពួកយើង ហើយយើងមិនដឹងថាតើយើងអាចពឹងផ្អែកលើការសម្រេចចិត្តនេះថាតើវានឹងត្រូវបានអភិវឌ្ឍ ឬបោះបង់ចោលយ៉ាងឆាប់រហ័ស។ cluster = clicks paradigm នៅក្នុង UI ខ្លួនឯងក៏មិនសមនឹងយើងដែរ ហើយយើងមិនចង់ចងភ្ជាប់ជាមួយ RKE ទេ ព្រោះវាជាឧបករណ៍ដែលផ្តោតការយកចិត្តទុកដាក់។ 

កំណែ Rancher 2.2 មានរូបរាងដែលអាចធ្វើការបានច្រើនជាងមុនហើយ រួមជាមួយមុខងារមុនៗ មានលក្ខណៈពិសេសគួរឱ្យចាប់អារម្មណ៍ជាច្រើនចេញពីប្រអប់ ដូចជាការរួមបញ្ចូលជាមួយអ្នកផ្តល់សេវាខាងក្រៅជាច្រើន ចំណុចតែមួយនៃការចែកចាយសិទ្ធិ និងឯកសារ kubeconfig បើកដំណើរការ kubectl រូបភាពជាមួយនឹងសិទ្ធិរបស់អ្នកនៅក្នុង UI, nested namespaces aka project។ 

វាក៏មានសហគមន៍មួយដែលបានបង្កើតឡើងនៅជុំវិញ Rancher 2 ហើយអ្នកផ្តល់សេវាហៅថា HashiCorp Terraform ត្រូវបានបង្កើតឡើងដើម្បីគ្រប់គ្រងវា ដែលជួយយើងដាក់អ្វីៗគ្រប់យ៉ាងជាមួយគ្នា។

តើមានអ្វីកើតឡើង

ជាលទ្ធផល យើងបានបញ្ចប់ជាមួយនឹងចង្កោមតូចមួយដែលដំណើរការ Rancher ដែលអាចចូលប្រើបានសម្រាប់ចង្កោមផ្សេងទៀតទាំងអស់ ក៏ដូចជាចង្កោមជាច្រើនដែលភ្ជាប់ជាមួយវា ការចូលប្រើណាមួយដែលអាចផ្តល់ឲ្យដូចការបន្ថែមអ្នកប្រើប្រាស់ទៅថត ldap ដោយមិនគិតពី កន្លែងដែលវាស្ថិតនៅ និងធនធានរបស់អ្នកផ្តល់សេវាណាដែលវាប្រើប្រាស់។

ដោយប្រើ gitlab-ci និង Terraform ប្រព័ន្ធមួយត្រូវបានបង្កើតឡើងដែលអនុញ្ញាតឱ្យអ្នកបង្កើតចង្កោមនៃការកំណត់រចនាសម្ព័ន្ធណាមួយនៅក្នុងក្រុមហ៊ុនផ្តល់សេវាពពក ឬហេដ្ឋារចនាសម្ព័ន្ធផ្ទាល់ខ្លួនរបស់យើង ហើយភ្ជាប់ពួកវាទៅ Rancher ។ ទាំងអស់នេះត្រូវបានធ្វើនៅក្នុងរចនាប័ទ្ម IaC ដែលចង្កោមនីមួយៗត្រូវបានពិពណ៌នាដោយឃ្លាំង ហើយស្ថានភាពរបស់វាត្រូវបានកំណែ។ ក្នុងពេលជាមួយគ្នានេះ ម៉ូឌុលភាគច្រើនត្រូវបានភ្ជាប់ពីឃ្លាំងខាងក្រៅ ដូច្នេះអ្វីៗដែលនៅសេសសល់គឺត្រូវឆ្លងកាត់អថេរ ឬពិពណ៌នាអំពីការកំណត់រចនាសម្ព័ន្ធផ្ទាល់ខ្លួនរបស់អ្នកសម្រាប់ឧទាហរណ៍ ដែលជួយកាត់បន្ថយភាគរយនៃពាក្យដដែលៗនៃកូដ។

ជាការពិតណាស់ ការធ្វើដំណើររបស់យើងគឺនៅឆ្ងាយ ហើយនៅមានកិច្ចការគួរឱ្យចាប់អារម្មណ៍ជាច្រើននៅខាងមុខ ដូចជាការងារតែមួយជាមួយនឹងកំណត់ហេតុ និងម៉ែត្រនៃចង្កោមណាមួយ បណ្តាញសេវា gitops សម្រាប់គ្រប់គ្រងបន្ទុកក្នុងពហុចង្កោម និងច្រើនទៀត។ យើងសង្ឃឹមថាអ្នកនឹងរកឃើញបទពិសោធន៍របស់យើងគួរឱ្យចាប់អារម្មណ៍! 

អត្ថបទនេះត្រូវបានសរសេរដោយ A. Antipov, A. Ganush, Platform Engineers ។ 

ប្រភព: www.habr.com