ការណែនាំ Kubernetes CCM (Cloud Controller Manager) សម្រាប់ Yandex.Cloud

បន្តទៅថ្មីៗនេះ ការចេញផ្សាយកម្មវិធីបញ្ជា CSI សម្រាប់ Yandex.Cloud យើងកំពុងបោះផ្សាយគម្រោងប្រភពបើកចំហមួយផ្សេងទៀតសម្រាប់ពពកនេះ - កម្មវិធីគ្រប់គ្រង Cloud Controller. CCM ត្រូវបានទាមទារមិនត្រឹមតែសម្រាប់ចង្កោមទាំងមូលប៉ុណ្ណោះទេ ប៉ុន្តែក៏សម្រាប់កម្មវិធីបញ្ជា CSI ខ្លួនឯងផងដែរ។ ព័ត៌មានលម្អិតអំពីគោលបំណងរបស់វា និងលក្ខណៈពិសេសមួយចំនួននៃការអនុវត្តគឺស្ថិតនៅក្រោមការកាត់។

សេចក្តីណែនាំ

ហេតុអ្វីបានជានេះ?

ការជម្រុញដែលជំរុញឱ្យយើងអភិវឌ្ឍ CCM សម្រាប់ Yandex.Cloud ទាំងស្រុងស្របគ្នាជាមួយនឹងអ្វីដែលបានពិពណ៌នារួចហើយនៅក្នុង សេចក្តីប្រកាស អ្នកបើកបរ CSI ។ យើងរក្សាបាននូវចង្កោម Kubernetes ជាច្រើនពីអ្នកផ្តល់សេវាពពកផ្សេងៗគ្នា ដែលយើងប្រើឧបករណ៍តែមួយ។ វាអនុវត្តភាពងាយស្រួលជាច្រើន "ឆ្លងកាត់" ដំណោះស្រាយដែលបានគ្រប់គ្រងរបស់អ្នកផ្តល់សេវាទាំងនេះ។ បាទ/ចាស យើងមានករណី និងតម្រូវការជាក់លាក់មួយ ប៉ុន្តែការវិវឌ្ឍដែលបានបង្កើតឡើងដោយសារតែពួកវាអាចមានប្រយោជន៍សម្រាប់អ្នកប្រើប្រាស់ផ្សេងទៀត។

តើ CCM ជាអ្វី?

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

ជាពិសេស Cloud Controller Manager ផ្តល់នូវអន្តរកម្មសំខាន់ៗចំនួនប្រាំប្រភេទ៖

1. វត្ថុ - អនុវត្តទំនាក់ទំនង 1: 1 រវាងវត្ថុថ្នាំងនៅក្នុង Kubernetes (Node) និងម៉ាស៊ីននិម្មិតនៅក្នុងក្រុមហ៊ុនផ្តល់សេវាពពក។ សម្រាប់នេះយើង:
   • បំពេញក្នុងវាល spec.providerID នៅក្នុងវត្ថុ Node. ឧទាហរណ៍ សម្រាប់ OpenStack CCM វាលនេះមានទម្រង់ដូចខាងក្រោម៖ openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. អ្នកអាចមើលឃើញឈ្មោះរបស់អ្នកផ្តល់សេវាពពក និង UUID តែមួយគត់នៃម៉ាស៊ីនមេ (ម៉ាស៊ីននិម្មិតនៅក្នុង OpenStack) នៃវត្ថុ។
   • បំពេញបន្ថែម nodeInfo នៅក្នុងវត្ថុ Node ព័ត៌មានអំពីម៉ាស៊ីននិម្មិត។ ឧទាហរណ៍ យើងបញ្ជាក់ប្រភេទ instance ក្នុង AWS;
   • យើងពិនិត្យមើលវត្តមានរបស់ម៉ាស៊ីននិម្មិតនៅក្នុងពពក។ ឧទាហរណ៍ប្រសិនបើវត្ថុមួយ។ Node បានចូលទៅក្នុងរដ្ឋមួយ។ NotReadyអ្នកអាចពិនិត្យមើលថាតើម៉ាស៊ីននិម្មិតមាននៅក្នុងក្រុមហ៊ុនផ្តល់សេវាពពកដែរឬទេ providerID. ប្រសិនបើវាមិននៅទីនោះទេ លុបវត្ថុ Nodeដែលនឹងនៅតែស្ថិតក្នុងចង្កោមជារៀងរហូត។
2. តំបន់ - កំណត់ដែនបរាជ័យសម្រាប់វត្ថុ Nodeដើម្បីឱ្យកម្មវិធីកំណត់ពេលអាចជ្រើសរើសថ្នាំងសម្រាប់ Pod យោងទៅតាមតំបន់ និងតំបន់នៅក្នុងក្រុមហ៊ុនផ្តល់សេវាពពក។
3. LoadBalancer - នៅពេលបង្កើតវត្ថុ Service ជាមួយប្រភេទ LoadBalancer បង្កើតប្រភេទនៃតុល្យភាពដែលនឹងដឹកនាំចរាចរពីខាងក្រៅទៅកាន់ថ្នាំងចង្កោម។ ឧទាហរណ៍នៅក្នុង Yandex.Cloud អ្នកអាចប្រើ NetworkLoadBalancer и TargetGroup សម្រាប់គោលបំណងទាំងនេះ;
4. ផ្លូវ - បង្កើតបណ្តាញរវាងថ្នាំង ពីព្រោះ យោងតាមតម្រូវការ Kubernetes ផតនីមួយៗត្រូវតែមានអាសយដ្ឋាន IP ផ្ទាល់ខ្លួន ហើយអាចទៅដល់ផតផ្សេងទៀតបាន។ សម្រាប់គោលបំណងទាំងនេះ អ្នកអាចប្រើបណ្តាញត្រួតលើគ្នា (VXLAN, GENEVE) ឬកំណត់តារាងនាំផ្លូវដោយផ្ទាល់នៅក្នុងបណ្តាញនិម្មិតរបស់អ្នកផ្តល់សេវាពពក៖

   

5. បរិមាណ - អនុញ្ញាតឱ្យមានការបញ្ជាទិញ PV ថាមវន្តដោយប្រើ PVC និង SC ។ ដំបូង មុខងារនេះគឺជាផ្នែកមួយនៃ CCM ប៉ុន្តែដោយសារតែភាពស្មុគស្មាញដ៏អស្ចារ្យរបស់វា វាត្រូវបានផ្លាស់ប្តូរទៅគម្រោងដាច់ដោយឡែកមួយគឺ Container Storage Interface (CSI)។ យើងបាននិយាយអំពី CSI ច្រើនជាងម្តង បានសរសេរ ហើយដូចដែលបានបញ្ជាក់រួចមកហើយ សូម្បីតែ បានចេញផ្សាយ កម្មវិធីបញ្ជា CSI ។

ពីមុន កូដទាំងអស់ដែលធ្វើអន្តរកម្មជាមួយពពកមានទីតាំងនៅក្នុងឃ្លាំង Git សំខាន់នៃគម្រោង Kubernetes នៅ k8s.io/kubernetes/pkg/cloudprovider/providersប៉ុន្តែពួកគេបានសម្រេចចិត្តបោះបង់វាចោលដោយសារតែភាពរអាក់រអួលក្នុងការធ្វើការជាមួយមូលដ្ឋានកូដដ៏ធំមួយ។ ការអនុវត្តចាស់ទាំងអស់ត្រូវបានផ្លាស់ប្តូរទៅ ឃ្លាំងដាច់ដោយឡែក. ដើម្បីភាពងាយស្រួលនៃការគាំទ្រ និងការអភិវឌ្ឍន៍បន្ថែមទៀត សមាសធាតុរួមទាំងអស់ក៏ត្រូវបានផ្លាស់ប្តូរទៅ ឃ្លាំងដាច់ដោយឡែក.

ដូចទៅនឹង CSI អ្នកផ្តល់សេវាពពកធំជាច្រើនបានរចនា CCMs របស់ពួកគេរួចហើយ ដើម្បីប្រើប្រាស់ពពកនៅលើ Kubernetes ។ ប្រសិនបើអ្នកផ្គត់ផ្គង់មិនមាន CCM ប៉ុន្តែមុខងារចាំបាច់ទាំងអស់អាចរកបានតាមរយៈ API នោះអ្នកអាចអនុវត្ត CCM ដោយខ្លួនឯងបាន។

ដើម្បីសរសេរការអនុវត្តផ្ទាល់របស់អ្នកនៃ CCM វាគ្រប់គ្រាន់ក្នុងការអនុវត្ត ត្រូវការចំណុចប្រទាក់ Go.

И នេះជាអ្វីដែលយើងទទួលបាន.

Реализация

តើអ្នកមកនេះដោយរបៀបណា

យើងបានចាប់ផ្តើមការអភិវឌ្ឍន៍ (ឬផ្ទុយទៅវិញសូម្បីតែប្រើ) ជាមួយ រួចរាល់ (!) CCM សម្រាប់ Yandex.Cloud មួយឆ្នាំមុន។

ទោះយ៉ាងណាក៏ដោយ នៅក្នុងការអនុវត្តនេះ យើងមិនបានបាត់បង់ទេ៖

• ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវតាមរយៈនិមិត្តសញ្ញា JWT IAM;
• ការគាំទ្រឧបករណ៍បញ្ជាសេវាកម្ម។

យល់ស្របជាមួយអ្នកនិពន្ធ (ឌីលីស៊ីន) នៅក្នុង Telegram យើងបានបំបែក yandex-cloud-controller-manager ហើយបានបន្ថែមមុខងារដែលបាត់។

លក្ខណៈ​ពិសេស

បច្ចុប្បន្ន CCM គាំទ្រចំណុចប្រទាក់ដូចខាងក្រោម៖

• វត្ថុ;
• តំបន់;
• LoadBalancer.

នៅពេលអនាគត នៅពេលដែល Yandex.Cloud ចាប់ផ្តើមធ្វើការជាមួយសមត្ថភាព VPC កម្រិតខ្ពស់ យើងនឹងបន្ថែមចំណុចប្រទាក់មួយ។ ផ្លូវ.

LoadBalancer ជាបញ្ហាប្រឈមចម្បង

ជាដំបូង យើងបានព្យាយាម ដូចជាការអនុវត្ត CCM ផ្សេងទៀត ដើម្បីបង្កើតគូ LoadBalancer и TargetGroup សម្រាប់គ្នា។ Service ជាមួយប្រភេទ LoadBalancer. ទោះយ៉ាងណាក៏ដោយ Yandex.Cloud បានរកឃើញដែនកំណត់គួរឱ្យចាប់អារម្មណ៍មួយ: អ្នកមិនអាចប្រើបានទេ។ TargetGroups ជាមួយនឹងការប្រសព្វ Targets (គូ SubnetID - IpAddress).

ដូច្នេះ នៅខាងក្នុង CCM ដែលបានបង្កើត ឧបករណ៍បញ្ជាមួយត្រូវបានបើកដំណើរការ ដែលនៅពេលដែលវត្ថុផ្លាស់ប្តូរ Node ប្រមូលព័ត៌មានអំពីចំណុចប្រទាក់ទាំងអស់នៅលើម៉ាស៊ីននិម្មិតនីមួយៗ ដាក់ជាក្រុមទៅតាមកម្មសិទ្ធិរបស់ពួកគេជាក់លាក់ NetworkID, បង្កើត​ដោយ​ TargetGroup នៅលើ NetworkIDនិងតាមដានភាពពាក់ព័ន្ធផងដែរ។ ក្រោយមកទៀតនៅពេលបង្កើតវត្ថុមួយ។ Service ជាមួយប្រភេទ LoadBalanacer យើងគ្រាន់តែភ្ជាប់នូវអ្វីដែលបានបង្កើតជាមុន TargetGroup ទៅថ្មី NetworkLoadBalanacerខ្ញុំ។

តើធ្វើដូចម្តេចដើម្បីចាប់ផ្តើមប្រើ?

CCM គាំទ្រ Kubernetes កំណែ 1.15 និងខ្ពស់ជាងនេះ។ នៅក្នុងចង្កោមមួយ ដើម្បីឱ្យវាដំណើរការ វាទាមទារទង់ជាតិ --cloud-provider=external ត្រូវបានកំណត់ទៅ true សម្រាប់ kube-apiserver, kube-controller-manager, kube-scheduler និង kubelets ទាំងអស់។

ជំហានចាំបាច់ទាំងអស់សម្រាប់ការដំឡើងខ្លួនវាត្រូវបានពិពណ៌នានៅក្នុង README. ការដំឡើងធ្លាក់ចុះដល់ការបង្កើតវត្ថុនៅក្នុង Kubernetes ពី manifests ។

ដើម្បីប្រើ CCM អ្នកក៏នឹងត្រូវការ:

• ចង្អុលបង្ហាញ នៅក្នុង manifest កំណត់អត្តសញ្ញាណថត (folder-id) Yandex.Cloud;
• គណនីសេវាកម្មសម្រាប់អន្តរកម្មជាមួយ Yandex.Cloud API ។ នៅក្នុងសេចក្តីថ្លែងការណ៍ Secret គឺចាំបាច់ ផ្ទេរសោដែលមានការអនុញ្ញាត ពីគណនីសេវាកម្ម។ នៅក្នុងឯកសារ បានពិពណ៌នា, របៀបបង្កើតគណនីសេវាកម្ម និងទទួលបានសោ។

យើងនឹងរីករាយក្នុងការទទួលបានមតិកែលម្អរបស់អ្នក និង បញ្ហាថ្មី។បើជួបបញ្ហា!

លទ្ធផល

យើងបានប្រើប្រាស់ CCM ដែលបានអនុវត្តនៅក្នុងចង្កោម Kubernetes ចំនួនប្រាំក្នុងរយៈពេលពីរសប្តាហ៍កន្លងមកនេះ ហើយគ្រោងនឹងពង្រីកចំនួនរបស់ពួកគេដល់ 20 នៅក្នុងខែខាងមុខនេះ។ បច្ចុប្បន្ន យើងមិនណែនាំឱ្យប្រើ CCM សម្រាប់ការដំឡើង K8s ធំ និងសំខាន់ទេ។

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

PS

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• «បទពិសោធន៍របស់យើងក្នុងការអភិវឌ្ឍន៍កម្មវិធីបញ្ជា CSI នៅក្នុង Kubernetes សម្រាប់ Yandex.Cloud»
• «តើវាងាយស្រួល និងងាយស្រួលក្នុងការរៀបចំចង្កោម Kubernetes ទេ? ប្រកាស​ប្រតិបត្តិករ addon»
• «ការពង្រីក និងបន្ថែម Kubernetes (របាយការណ៍ទូទៅ និងវីដេអូ)"។

ប្រភព: www.habr.com