🥇មួកសុវត្ថិភាព

Суть рассказа о самом популярном пакетном менеджере для Kubernetes можно было бы изобразить с помощью эмоджи:

ប្រអប់គឺ Helm (ដែលជាអ្វីដែលជិតបំផុតទៅនឹងការចេញផ្សាយ Emoji ចុងក្រោយបំផុត);
ចាក់សោ - សុវត្ថិភាព;
បុរសតូចគឺជាដំណោះស្រាយចំពោះបញ្ហា។

តាមពិតទៅ អ្វីៗនឹងមានភាពស្មុគស្មាញបន្តិច ហើយរឿងគឺពោរពេញទៅដោយព័ត៌មានលម្អិតអំពីបច្ចេកទេស វិធីធ្វើឱ្យមួកសុវត្ថិភាព.

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

អ្វីៗទាំងអស់នៅក្នុងអត្ថបទនេះអនុវត្តចំពោះ Helm 2។ កំណែនេះកំពុងដំណើរការនាពេលបច្ចុប្បន្ន ហើយទំនងជាកំណែដែលអ្នកកំពុងប្រើនាពេលបច្ចុប្បន្ននេះ ហើយវាគឺជាកំណែដែលមានហានិភ័យសុវត្ថិភាព។

អំពីអ្នកនិយាយ៖ Alexander Khayorov (អាឡិច) បាននិងកំពុងអភិវឌ្ឍអស់រយៈពេល 10 ឆ្នាំមកហើយ ដែលជួយកែលម្អខ្លឹមសារ ទីក្រុងម៉ូស្គូ Python Conf++ ហើយបានចូលរួមក្នុងគណៈកម្មាធិការ កិច្ចប្រជុំកំពូល Helm. ឥឡូវនេះគាត់ធ្វើការនៅ Chainstack ជាអ្នកនាំមុខក្នុងការអភិវឌ្ឍន៍ - នេះគឺជាកូនកាត់រវាងអ្នកគ្រប់គ្រងផ្នែកអភិវឌ្ឍន៍ និងអ្នកដែលទទួលខុសត្រូវក្នុងការផ្តល់នូវការចេញផ្សាយចុងក្រោយ។ នោះគឺវាមានទីតាំងនៅលើសមរភូមិដែលអ្វីៗគ្រប់យ៉ាងកើតឡើងតាំងពីការបង្កើតផលិតផលរហូតដល់ប្រតិបត្តិការរបស់វា។

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

កាន់តំណែង

នេះគឺជាកម្មវិធីគ្រប់គ្រងកញ្ចប់ (គំនូសតាង) សម្រាប់ Kubernetes ។ វិធីដ៏វិចារណញាណ និងជាសាកលបំផុតដើម្បីនាំយកកម្មវិធីទៅកាន់ចង្កោម Kubernetes ។

ជាការពិតណាស់ យើងកំពុងនិយាយអំពីវិធីសាស្រ្តរចនាសម្ព័ន្ធ និងឧស្សាហកម្មជាងការបង្កើត YAML ផ្ទាល់ខ្លួនរបស់អ្នក និងសរសេរឧបករណ៍ប្រើប្រាស់តូចៗ។

Helm គឺល្អបំផុតដែលបច្ចុប្បន្នមាន និងពេញនិយម។

ហេតុអ្វីបានជា Helm? ជាចម្បងដោយសារតែវាត្រូវបានគាំទ្រដោយ CNCF ។ Cloud Native គឺជាអង្គការដ៏ធំមួយ និងជាក្រុមហ៊ុនមេសម្រាប់គម្រោង Kubernetes, etcd, Fluentd និងផ្សេងទៀត។

ការពិតសំខាន់មួយទៀតគឺថា Helm គឺជាគម្រោងដ៏ពេញនិយមមួយ។ នៅពេលខ្ញុំចាប់ផ្តើមនិយាយអំពីរបៀបធ្វើឱ្យ Helm មានសុវត្ថិភាពក្នុងខែមករា ឆ្នាំ 2019 គម្រោងនេះមានផ្កាយមួយពាន់នៅលើ GitHub ។ នៅខែឧសភាមាន 12 ពាន់នាក់។

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

ក្រុមស្នូល Helm ត្រូវបានគាំទ្រដោយ Microsoft Azure ហើយដូច្នេះគឺជាគម្រោងដែលមានស្ថេរភាពមិនដូចអ្វីផ្សេងទៀតទេ។ ការចេញផ្សាយ Helm 3 Alpha 2 នៅពាក់កណ្តាលខែកក្កដា បង្ហាញថា មានមនុស្សជាច្រើនធ្វើការលើគម្រោងនេះ ហើយពួកគេមានបំណងប្រាថ្នា និងថាមពលក្នុងការអភិវឌ្ឍន៍ និងកែលម្អ Helm ។

Helm ដោះស្រាយបញ្ហាឫសគល់ជាច្រើននៃការគ្រប់គ្រងកម្មវិធីនៅក្នុង Kubernetes ។

ការវេចខ្ចប់កម្មវិធី។ សូម្បីតែកម្មវិធីដូចជា “Hello, World” នៅលើ WordPress មានសេវាកម្មជាច្រើនរួចហើយ ហើយអ្នកចង់វេចខ្ចប់វាជាមួយគ្នា។
ការគ្រប់គ្រងភាពស្មុគស្មាញដែលភ្ជាប់មកជាមួយការគ្រប់គ្រងកម្មវិធីទាំងនេះ។
វដ្តជីវិតដែលមិនបញ្ចប់បន្ទាប់ពីកម្មវិធីត្រូវបានដំឡើង ឬដាក់ឱ្យប្រើប្រាស់។ វាបន្តរស់នៅ ចាំបាច់ត្រូវធ្វើបច្ចុប្បន្នភាព ហើយ Helm ជួយក្នុងរឿងនេះ ហើយព្យាយាមនាំយកវិធានការ និងគោលនយោបាយត្រឹមត្រូវសម្រាប់រឿងនេះ។

កាបូប វាត្រូវបានរៀបចំតាមរបៀបច្បាស់លាស់៖ មានទិន្នន័យមេតាពេញលេញស្របតាមការងាររបស់អ្នកគ្រប់គ្រងកញ្ចប់ធម្មតាសម្រាប់ Linux, Windows ឬ MacOS ។ នោះគឺជាឃ្លាំង ភាពអាស្រ័យលើកញ្ចប់ផ្សេងៗ ព័ត៌មានមេតាសម្រាប់កម្មវិធី ការកំណត់ មុខងារកំណត់រចនាសម្ព័ន្ធ ការធ្វើលិបិក្រមព័ត៌មាន។ល។ Helm អនុញ្ញាតឱ្យអ្នកទទួលបាន និងប្រើប្រាស់ទាំងអស់នេះសម្រាប់កម្មវិធី។

ការគ្រប់គ្រងភាពស្មុគស្មាញ. ប្រសិនបើអ្នកមានកម្មវិធីជាច្រើននៃប្រភេទដូចគ្នា នោះការកំណត់គឺចាំបាច់។ គំរូបានមកពីនេះ ប៉ុន្តែដើម្បីជៀសវាងការមានវិធីផ្ទាល់ខ្លួនរបស់អ្នកក្នុងការបង្កើតគំរូ អ្នកអាចប្រើអ្វីដែល Helm ផ្តល់ជូនចេញពីប្រអប់។

កម្មវិធីគ្រប់គ្រងវដ្តជីវិត - តាមគំនិតរបស់ខ្ញុំ នេះគឺជាសំណួរដែលគួរឱ្យចាប់អារម្មណ៍បំផុត និងមិនអាចដោះស្រាយបាន។ នេះជាមូលហេតុដែលខ្ញុំមក Helm វិញនៅថ្ងៃនោះ។ យើងត្រូវតាមដានវដ្តជីវិតកម្មវិធី ហើយចង់ផ្លាស់ទី CI/CD និងវដ្តកម្មវិធីរបស់យើងទៅកាន់គំរូនេះ។

Helm អនុញ្ញាតឱ្យអ្នក:

គ្រប់គ្រងការដាក់ពង្រាយ ណែនាំគំនិតនៃការកំណត់រចនាសម្ព័ន្ធ និងការពិនិត្យឡើងវិញ;
អនុវត្តការវិលត្រឡប់មកវិញដោយជោគជ័យ;
ប្រើទំពក់សម្រាប់ព្រឹត្តិការណ៍ផ្សេងៗ;
បន្ថែមការត្រួតពិនិត្យកម្មវិធីបន្ថែម និងឆ្លើយតបទៅនឹងលទ្ធផលរបស់ពួកគេ។

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

Helm ផ្អែកលើគោលគំនិតសំខាន់ៗចំនួនបី៖

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

ស្ថាបត្យកម្មមួក

ដ្យាក្រាមបង្ហាញគំនិតអំពីស្ថាបត្យកម្មកម្រិតខ្ពស់របស់ Helm ។

ខ្ញុំសូមរំលឹកអ្នកថា Helm គឺជាអ្វីដែលទាក់ទងនឹង Kubernetes ។ ដូច្នេះហើយ យើងមិនអាចធ្វើដោយគ្មានចង្កោម Kubernetes (ចតុកោណ)ទេ។ សមាសធាតុ kube-apiserver ស្ថិតនៅលើមេ។ បើគ្មាន Helm យើងមាន Kubeconfig ។ Helm នាំមកនូវប្រព័ន្ធគោលពីរតូចមួយ ប្រសិនបើអ្នកអាចហៅវាថា Helm CLI utility ដែលត្រូវបានដំឡើងនៅលើកុំព្យូទ័រ កុំព្យូទ័រយួរដៃ និង mainframe - នៅលើអ្វីទាំងអស់។

ប៉ុន្តែនេះមិនគ្រប់គ្រាន់ទេ។ Helm មានសមាសភាគម៉ាស៊ីនមេហៅថា Tiller ។ វាតំណាងឱ្យផលប្រយោជន៍របស់ Helm នៅក្នុងចង្កោម វាគឺជាកម្មវិធីនៅក្នុងចង្កោម Kubernetes ដូចជាកម្មវិធីផ្សេងទៀតដែរ។

សមាសធាតុបន្ទាប់នៃ Chart Repo គឺជាឃ្លាំងដែលមានគំនូសតាង។ មានឃ្លាំងផ្លូវការ ហើយអាចមានឃ្លាំងឯកជនរបស់ក្រុមហ៊ុន ឬគម្រោង។

អន្តរកម្ម

សូមក្រឡេកមើលពីរបៀបដែលសមាសធាតុស្ថាបត្យកម្មមានអន្តរកម្មនៅពេលដែលយើងចង់ដំឡើងកម្មវិធីដោយប្រើ Helm ។

យើងកំពុងនិយាយ Helm installចូលទៅកាន់ឃ្លាំង (គំនូសតាង Repo) និងទទួលបានគំនូសតាង Helm ។

ឧបករណ៍ប្រើប្រាស់ Helm (Helm CLI) ធ្វើអន្តរកម្មជាមួយ Kubeconfig ដើម្បីស្វែងយល់ថាតើក្រុមណាដែលត្រូវទាក់ទង។
ដោយបានទទួលព័ត៌មាននេះ ឧបករណ៍ប្រើប្រាស់សំដៅលើ Tiller ដែលមានទីតាំងនៅក្នុងចង្កោមរបស់យើង ជាកម្មវិធីមួយ។
Tiller ហៅ Kube-apiserver ដើម្បីអនុវត្តសកម្មភាពនៅក្នុង Kubernetes បង្កើតវត្ថុមួយចំនួន (សេវាកម្ម ផតថល ការចម្លង អាថ៌កំបាំង។ល។)។

បន្ទាប់មក យើងនឹងធ្វើឱ្យស្មុគស្មាញដល់ដ្យាក្រាម ដើម្បីមើលវ៉ិចទ័រវាយប្រហារ ដែលស្ថាបត្យកម្ម Helm ទាំងមូលអាចត្រូវបានបង្ហាញ។ ហើយបន្ទាប់មកយើងនឹងព្យាយាមការពារនាង។

វ៉ិចទ័រវាយប្រហារ

ចំណុចខ្សោយសក្តានុពលដំបូងគឺ API ដែលមានសិទ្ធិ-អ្នកប្រើ។. ជាផ្នែកមួយនៃគ្រោងការណ៍ នេះគឺជាពួក Hacker ដែលទទួលបានសិទ្ធិគ្រប់គ្រងទៅកាន់ Helm CLI ។

អ្នកប្រើប្រាស់ API ដែលមិនមានសិទ្ធិ ក៏អាចបង្កគ្រោះថ្នាក់ផងដែរ ប្រសិនបើវាស្ថិតនៅកន្លែងណាមួយនៅក្បែរនោះ។ អ្នកប្រើបែបនេះនឹងមានបរិបទផ្សេងគ្នា ជាឧទាហរណ៍ គាត់អាចត្រូវបានជួសជុលក្នុងចន្លោះឈ្មោះចង្កោមមួយក្នុងការកំណត់ Kubeconfig ។

វ៉ិចទ័រវាយប្រហារគួរឱ្យចាប់អារម្មណ៍បំផុតអាចជាដំណើរការដែលស្ថិតនៅក្នុងចង្កោមកន្លែងណាមួយនៅជិត Tiller ហើយអាចចូលប្រើវាបាន។ នេះអាចជា web server ឬ microservice ដែលមើលឃើញបរិយាកាសបណ្តាញនៃ cluster ។

វ៉ារ្យ៉ង់វាយប្រហារកម្រនិងអសកម្ម ប៉ុន្តែមានការពេញនិយមកាន់តែខ្លាំងឡើងពាក់ព័ន្ធនឹង Chart Repo ។ គំនូសតាងដែលបង្កើតឡើងដោយអ្នកនិពន្ធដែលគ្មានសីលធម៌អាចមានធនធានដែលមិនមានសុវត្ថិភាព ហើយអ្នកនឹងបំពេញវាដោយទទួលយកវាដោយជំនឿ។ ឬវាអាចជំនួសគំនូសតាងដែលអ្នកទាញយកពីឃ្លាំងផ្លូវការ ហើយឧទាហរណ៍ បង្កើតធនធានក្នុងទម្រង់ជាគោលការណ៍ និងបង្កើនការចូលប្រើរបស់វា។

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

ចូរពង្រីកដ្យាក្រាម បន្ថែមធាតុបន្ថែមទៀត ប៉ុន្តែរក្សាសមាសធាតុមូលដ្ឋានទាំងអស់។

Helm CLI ទាក់ទងជាមួយ Chart Repo ធ្វើអន្តរកម្មជាមួយ Kubeconfig ហើយការងារត្រូវបានផ្ទេរទៅចង្កោមទៅសមាសភាគ Tiller ។

Tiller ត្រូវបានតំណាងដោយវត្ថុពីរ៖

Tiller-deploy svc ដែលបង្ហាញសេវាកម្មជាក់លាក់។
Tiller-deploy pod (ក្នុងដ្យាក្រាមក្នុងច្បាប់ចម្លងតែមួយនៅក្នុងច្បាប់ចម្លងមួយ) ដែលបន្ទុកទាំងមូលដំណើរការ ដែលចូលប្រើចង្កោម។

ពិធីការ និងគ្រោងការណ៍ផ្សេងគ្នាត្រូវបានប្រើសម្រាប់អន្តរកម្ម។ តាមទស្សនៈសុវត្ថិភាព យើងចាប់អារម្មណ៍បំផុតលើ៖

យន្តការដែល Helm CLI ចូលប្រើតារាង repo: ពិធីការអ្វី តើមានការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ និងអ្វីដែលអាចធ្វើបានជាមួយវា។
ពិធីការដែល Helm CLI ដោយប្រើ kubectl ទំនាក់ទំនងជាមួយ Tiller ។ នេះគឺជាម៉ាស៊ីនមេ RPC ដែលបានដំឡើងនៅខាងក្នុងចង្កោម។
Tiller ខ្លួនវាគឺអាចចូលដំណើរការបានចំពោះសេវាមីក្រូដែលរស់នៅក្នុងចង្កោម និងធ្វើអន្តរកម្មជាមួយ Kube-apiserver ។

ចូរយើងពិភាក្សាអំពីផ្នែកទាំងអស់នេះតាមលំដាប់លំដោយ។

RBAC

វាគ្មានន័យអ្វីទេក្នុងការនិយាយអំពីសុវត្ថិភាពណាមួយសម្រាប់ Helm ឬសេវាកម្មផ្សេងទៀតនៅក្នុងចង្កោម លុះត្រាតែ RBAC ត្រូវបានបើក។

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

https://rbac.dev/ - មេធាវីគេហទំព័រសម្រាប់ RBAC ។ វាមានបរិមាណដ៏ច្រើននៃសម្ភារៈគួរឱ្យចាប់អារម្មណ៍ដែលនឹងជួយអ្នកក្នុងការដំឡើង RBAC បង្ហាញពីមូលហេតុដែលវាល្អ និងរបៀបរស់នៅជាមូលដ្ឋានជាមួយវានៅក្នុងផលិតកម្ម។

ខ្ញុំនឹងព្យាយាមពន្យល់ពីរបៀបដែល Tiller និង RBAC ដំណើរការ។ Tiller ធ្វើការនៅខាងក្នុងចង្កោមក្រោមគណនីសេវាកម្មជាក់លាក់មួយ។ ជាធម្មតា ប្រសិនបើ RBAC មិនត្រូវបានកំណត់រចនាសម្ព័ន្ធទេ នេះនឹងក្លាយជាអ្នកប្រើប្រាស់កំពូល។ នៅក្នុងការកំណត់រចនាសម្ព័ន្ធមូលដ្ឋាន Tiller នឹងក្លាយជាអ្នកគ្រប់គ្រង។ នេះជាមូលហេតុដែលជារឿយៗគេនិយាយថា Tiller គឺជាផ្លូវរូងក្រោមដី SSH ទៅកាន់ចង្កោមរបស់អ្នក។ តាមពិត នេះជាការពិត ដូច្នេះអ្នកអាចប្រើគណនីសេវាកម្មដាច់ដោយឡែកមួយជំនួសឱ្យគណនីសេវាកម្មលំនាំដើមនៅក្នុងដ្យាក្រាមខាងលើ។

នៅពេលអ្នកចាប់ផ្តើម Helm ហើយដំឡើងវានៅលើម៉ាស៊ីនមេជាលើកដំបូង អ្នកអាចកំណត់គណនីសេវាកម្មដោយប្រើ --service-account. វានឹងអនុញ្ញាតឱ្យអ្នកប្រើអ្នកប្រើប្រាស់ដែលមានសំណុំសិទ្ធិអប្បបរមាដែលត្រូវការ។ ពិត អ្នកនឹងត្រូវបង្កើត "កម្រងផ្កា" បែបនេះ៖ តួនាទី និងតួនាទីចង។

ជាអកុសល Helm នឹងមិនធ្វើបែបនេះសម្រាប់អ្នកទេ។ អ្នក ឬអ្នកគ្រប់គ្រងចង្កោម Kubernetes របស់អ្នកត្រូវរៀបចំសំណុំនៃតួនាទី និង RoleBindings សម្រាប់គណនីសេវាកម្មជាមុន ដើម្បីឆ្លងកាត់ Helm ។

សំណួរកើតឡើង - តើអ្វីជាភាពខុសគ្នារវាង Role និង ClusterRole? ភាពខុសគ្នានោះគឺថា ClusterRole ដំណើរការសម្រាប់ namespaces ទាំងអស់ មិនដូច Roles ធម្មតា និង RoleBindings ដែលធ្វើការសម្រាប់ namespace ឯកទេសប៉ុណ្ណោះ។ អ្នកអាចកំណត់រចនាសម្ព័ន្ធគោលការណ៍សម្រាប់ចង្កោមទាំងមូល និងចន្លោះឈ្មោះទាំងអស់ ឬកំណត់លក្ខណៈផ្ទាល់ខ្លួនសម្រាប់ទំហំឈ្មោះនីមួយៗរៀងៗខ្លួន។

វាមានតំលៃនិយាយថា RBAC ដោះស្រាយបញ្ហាធំមួយទៀត។ មនុស្សជាច្រើនត្អូញត្អែរថា ជាអកុសល Helm មិនមែនជា multitenancy (មិនគាំទ្រ multitenancy) ។ ប្រសិនបើក្រុមជាច្រើនប្រើប្រាស់ចង្កោម ហើយប្រើ Helm ជាមូលដ្ឋាន វាមិនអាចទៅរួចទេក្នុងការរៀបចំគោលការណ៍ និងកំណត់ការចូលប្រើប្រាស់របស់ពួកគេនៅក្នុងចង្កោមនេះ ពីព្រោះមានគណនីសេវាកម្មជាក់លាក់មួយដែល Helm ដំណើរការ ហើយវាបង្កើតធនធានទាំងអស់នៅក្នុងចង្កោមពីក្រោមវា។ ដែលពេលខ្លះមានការរអាក់រអួលខ្លាំង។ នេះជាការពិត - ដូចជាឯកសារគោលពីរខ្លួនវា ដូចជាដំណើរការ Helm Tiller មិនមានគំនិតនៃពហុមុខងារទេ។.

ទោះយ៉ាងណាក៏ដោយ មានវិធីដ៏ល្អដែលអនុញ្ញាតឱ្យអ្នកដំណើរការ Tiller ច្រើនដងក្នុងចង្កោមមួយ។ មិនមានបញ្ហាជាមួយនេះទេ Tiller អាចត្រូវបានដាក់ឱ្យដំណើរការនៅគ្រប់កន្លែងឈ្មោះ។ ដូច្នេះ អ្នកអាចប្រើ RBAC, Kubeconfig ជាបរិបទ និងកំណត់ការចូលប្រើ Helm ពិសេស។

វានឹងមើលទៅដូចនេះ។

ឧទាហរណ៍ មាន Kubeconfigs ពីរដែលមានបរិបទសម្រាប់ក្រុមផ្សេងគ្នា (ចន្លោះឈ្មោះពីរ): ក្រុម X សម្រាប់ក្រុមអភិវឌ្ឍន៍ និងក្រុមអ្នកគ្រប់គ្រង។ ចង្កោមអ្នកគ្រប់គ្រងមាន Tiller ធំទូលាយរបស់វា ដែលមានទីតាំងនៅក្នុងចន្លោះឈ្មោះប្រព័ន្ធ Kube ដែលជាគណនីសេវាកម្មកម្រិតខ្ពស់ដែលត្រូវគ្នា។ ហើយកន្លែងដាក់ឈ្មោះដាច់ដោយឡែកសម្រាប់ក្រុមអភិវឌ្ឍន៍ ពួកគេនឹងអាចដាក់ពង្រាយសេវាកម្មរបស់ពួកគេទៅកាន់ namespace ពិសេស។

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

មានអារម្មណ៍សេរីក្នុងការកំណត់ Tiller ដោយឡែកពីគ្នា និងផ្ដល់ឱ្យ Kubeconfig ជាមួយបរិបទសម្រាប់ក្រុម សម្រាប់អ្នកអភិវឌ្ឍន៍ជាក់លាក់ ឬសម្រាប់បរិស្ថាន៖ Dev, Staging, Production (វាគួរឱ្យសង្ស័យថាអ្វីៗទាំងអស់នឹងស្ថិតនៅលើចង្កោមតែមួយ ទោះយ៉ាងណាក៏ដោយ នេះអាចត្រូវបានធ្វើ)។

បន្តរឿងរបស់យើង យើងប្តូរពី RBAC ហើយនិយាយអំពី ConfigMaps ។

ផែនទីកំណត់រចនាសម្ព័ន្ធ

Helm ប្រើ ConfigMaps ជាកន្លែងផ្ទុកទិន្នន័យរបស់វា។ នៅពេលដែលយើងនិយាយអំពីស្ថាបត្យកម្ម វាមិនមានមូលដ្ឋានទិន្នន័យនៅកន្លែងណាមួយដែលនឹងរក្សាទុកព័ត៌មានអំពីការចេញផ្សាយ ការកំណត់រចនាសម្ព័ន្ធ ការវិលត្រឡប់មកវិញ។ ល។ ConfigMaps ត្រូវបានប្រើសម្រាប់ការនេះ។

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

នេះត្រូវបានធ្វើយ៉ាងសាមញ្ញបំផុត។ បដិសេធការកំណត់ Tiller ហើយបញ្ជាក់ថាការផ្ទុកនឹងជាអាថ៌កំបាំង។ បន្ទាប់មក សម្រាប់ការដាក់ពង្រាយនីមួយៗ អ្នកនឹងទទួលមិនមែនជា ConfigMap ទេ ប៉ុន្តែជាការសម្ងាត់។

អ្នកអាចប្រកែកថាអាថ៌កំបាំងខ្លួនឯងជាគំនិតចម្លែក ហើយមិនមានសុវត្ថិភាពខ្លាំងទេ។ ទោះយ៉ាងណាក៏ដោយ វាមានតម្លៃយល់ថាអ្នកអភិវឌ្ឍន៍ Kubernetes ខ្លួនឯងកំពុងធ្វើរឿងនេះ។ ចាប់ផ្តើមពីកំណែ 1.10, i.e. អស់មួយរយៈឥឡូវនេះ វាអាចទៅរួច យ៉ាងហោចណាស់នៅក្នុងពពកសាធារណៈ ដើម្បីភ្ជាប់កន្លែងផ្ទុកត្រឹមត្រូវដើម្បីរក្សាទុកអាថ៌កំបាំង។ ឥឡូវនេះ ក្រុមការងារកំពុងធ្វើការលើមធ្យោបាយដើម្បីចែកចាយការចូលប្រើបានប្រសើរជាងមុនទៅកាន់អាថ៌កំបាំង ផតថលបុគ្គល ឬអង្គភាពផ្សេងទៀត។

វាជាការប្រសើរក្នុងការផ្ទេរ Storage Helm ទៅជាអាថ៌កំបាំង ហើយពួកវាត្រូវបានធានាសុវត្ថិភាពនៅចំកណ្តាល។

ជាការពិតណាស់វានឹងនៅតែមាន ដែនកំណត់ផ្ទុកទិន្នន័យ 1 MB. Helm នៅទីនេះប្រើ etcd ជាកន្លែងផ្ទុកចែកចាយសម្រាប់ ConfigMaps ។ ហើយនៅទីនោះពួកគេបានចាត់ទុកថានេះជាកំណាត់ទិន្នន័យសមរម្យសម្រាប់ការចម្លងជាដើម។ មានការពិភាក្សាគួរឱ្យចាប់អារម្មណ៍អំពីរឿងនេះនៅលើ Reddit ខ្ញុំសូមណែនាំឱ្យស្វែងរកការអានដ៏គួរឱ្យអស់សំណើចនេះសម្រាប់ចុងសប្តាហ៍ ឬអានការដកស្រង់ នៅទីនេះ.

គំនូសតាង Repos

គំនូសតាងគឺងាយរងគ្រោះបំផុតក្នុងសង្គម ហើយអាចក្លាយជាប្រភពនៃ "បុរសនៅកណ្តាល" ជាពិសេសប្រសិនបើអ្នកប្រើដំណោះស្រាយភាគហ៊ុន។ ដំបូងយើងកំពុងនិយាយអំពីឃ្លាំងដែលត្រូវបានលាតត្រដាងតាមរយៈ HTTP ។

អ្នកប្រាកដជាត្រូវបង្ហាញ Helm Repo លើ HTTPS - នេះគឺជាជម្រើសដ៏ល្អបំផុត និងមានតម្លៃថោក។

យកចិត្តទុកដាក់ យន្តការហត្ថលេខាគំនូសតាង. បច្ចេកវិទ្យាគឺសាមញ្ញដូចឋាននរក។ នេះគឺជារឿងដូចគ្នាដែលអ្នកប្រើនៅលើ GitHub ដែលជាម៉ាស៊ីន PGP ធម្មតាដែលមានសោសាធារណៈ និងឯកជន។ រៀបចំ និងត្រូវប្រាកដថា មានសោចាំបាច់ និងចុះហត្ថលេខាលើអ្វីគ្រប់យ៉ាង ថានេះពិតជាតារាងរបស់អ្នក។

លើសពីនេះទៀត, អតិថិជន Helm គាំទ្រ TLS (មិនមែននៅក្នុងន័យ HTTP ខាង server ទេ ប៉ុន្តែ TLS ទៅវិញទៅមក)។ អ្នកអាចប្រើកូនសោម៉ាស៊ីនមេ និងម៉ាស៊ីនភ្ញៀវ ដើម្បីទំនាក់ទំនង។ និយាយឱ្យត្រង់ទៅ ខ្ញុំមិនប្រើយន្តការបែបនេះទេ ព្រោះខ្ញុំមិនចូលចិត្តវិញ្ញាបនបត្រទៅវិញទៅមក។ ជាមូលដ្ឋាន សារមន្ទីរគំនូសតាង - ឧបករណ៍សំខាន់សម្រាប់ការដំឡើង Helm Repo សម្រាប់ Helm 2 - ក៏គាំទ្រការផ្ទៀងផ្ទាត់មូលដ្ឋានផងដែរ។ អ្នកអាចប្រើការផ្ទៀងផ្ទាត់មូលដ្ឋានប្រសិនបើវាងាយស្រួលជាង និងស្ងាត់ជាង។

វាក៏មានកម្មវិធីជំនួយផងដែរ។ មួក-gcsដែលអនុញ្ញាតឱ្យអ្នកធ្វើជាម្ចាស់ផ្ទះ Chart Repos នៅលើ Google Cloud Storage ។ នេះពិតជាងាយស្រួល ដំណើរការល្អ និងមានសុវត្ថិភាពណាស់ ពីព្រោះយន្តការដែលបានពិពណ៌នាទាំងអស់ត្រូវបានកែច្នៃឡើងវិញ។

ប្រសិនបើអ្នកបើក HTTPS ឬ TLS ប្រើ mTLS និងបើកការផ្ទៀងផ្ទាត់មូលដ្ឋានដើម្បីកាត់បន្ថយហានិភ័យបន្ថែមទៀត អ្នកនឹងទទួលបានបណ្តាញទំនាក់ទំនងដែលមានសុវត្ថិភាពជាមួយ Helm CLI និង Chart Repo ។

gRPC API

ជំហានបន្ទាប់គឺមានសារៈសំខាន់ខ្លាំងណាស់ - ដើម្បីការពារ Tiller ដែលមានទីតាំងនៅក្នុងចង្កោម ហើយនៅលើដៃម្ខាង ម៉ាស៊ីនមេ ម៉្យាងវិញទៀតវាចូលប្រើសមាសភាគផ្សេងទៀត ហើយព្យាយាមធ្វើពុតជានរណាម្នាក់។

ដូចដែលខ្ញុំបាននិយាយរួចមកហើយថា Tiller គឺជាសេវាកម្មដែលបង្ហាញ gRPC អតិថិជន Helm មករកវាតាមរយៈ gRPC ។ តាមលំនាំដើម ជាការពិត TLS ត្រូវបានបិទ។ ហេតុអ្វីបានជានេះត្រូវបានធ្វើរួចជាសំណួរដែលអាចជជែកវែកញែកបាន វាហាក់ដូចជាខ្ញុំដើម្បីសម្រួលការដំឡើងនៅពេលចាប់ផ្តើម។

សម្រាប់ការផលិត និងសូម្បីតែដំណាក់កាល ខ្ញុំសូមណែនាំឱ្យបើក TLS នៅលើ gRPC ។

តាមគំនិតរបស់ខ្ញុំ មិនដូច mTLS សម្រាប់តារាងទេ នេះគឺសមរម្យនៅទីនេះ ហើយត្រូវបានធ្វើយ៉ាងសាមញ្ញ - បង្កើតហេដ្ឋារចនាសម្ព័ន្ធ PQI បង្កើតវិញ្ញាបនបត្រ បើកដំណើរការ Tiller ផ្ទេរវិញ្ញាបនបត្រកំឡុងពេលចាប់ផ្តើម។ បន្ទាប់ពីនេះ អ្នកអាចប្រតិបត្តិពាក្យបញ្ជា Helm ទាំងអស់ ដោយបង្ហាញខ្លួនអ្នកជាមួយនឹងវិញ្ញាបនបត្រដែលបានបង្កើត និងសោឯកជន។

វិធីនេះអ្នកនឹងការពារខ្លួនអ្នកពីសំណើទាំងអស់ទៅកាន់ Tiller ពីខាងក្រៅចង្កោម។

ដូច្នេះ យើងបានធានានូវបណ្តាញតភ្ជាប់ទៅ Tiller យើងបានពិភាក្សារួចហើយអំពី RBAC និងកែសម្រួលសិទ្ធិរបស់ Kubernetes apiserver ដោយកាត់បន្ថយដែនដែលវាអាចធ្វើអន្តរកម្មបាន។

មួកការពារ

សូមក្រឡេកមើលដ្យាក្រាមចុងក្រោយ។ វាជាស្ថាបត្យកម្មដូចគ្នាដែលមានព្រួញដូចគ្នា។

ឥឡូវនេះការតភ្ជាប់ទាំងអស់អាចត្រូវបានគូរដោយពណ៌បៃតងដោយសុវត្ថិភាព៖

សម្រាប់ Chart Repo យើងប្រើ TLS ឬ mTLS និងការផ្ទៀងផ្ទាត់មូលដ្ឋាន។
mTLS សម្រាប់ Tiller ហើយវាត្រូវបានលាតត្រដាងជាសេវាកម្ម gRPC ជាមួយ TLS យើងប្រើវិញ្ញាបនបត្រ។
ចង្កោមប្រើគណនីសេវាកម្មពិសេសជាមួយតួនាទី និងតួនាទីចង។

យើងបានធានាសុវត្ថិភាពចង្កោមយ៉ាងខ្លាំង ប៉ុន្តែអ្នកឆ្លាតម្នាក់បាននិយាយថា៖

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

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

ប្រាក់រង្វាន់

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

នៅក្នុងឃ្លាំង github.com/helm/charts ឥឡូវនេះមានគំនូសតាងប្រហែល 300 និងស្ទ្រីមពីរ៖ ស្ថេរភាព និងកន្លែងភ្ញាស់។ អ្នកណាដែលបរិច្ចាគដឹងយ៉ាងច្បាស់ថាវាលំបាកប៉ុណ្ណាក្នុងការចេញពីកន្លែងភ្ញាស់ទៅស្ថិរភាព ហើយវាងាយស្រួលប៉ុណ្ណាក្នុងការហោះចេញពីលំនឹង។ ទោះយ៉ាងណាក៏ដោយ នេះមិនមែនជាឧបករណ៍ដ៏ល្អបំផុតដើម្បីស្វែងរកតារាងសម្រាប់ Prometheus និងអ្វីផ្សេងទៀតដែលអ្នកចូលចិត្តនោះទេ សម្រាប់ហេតុផលសាមញ្ញមួយ - វាមិនមែនជាវិបផតថលដែលអ្នកអាចស្វែងរកកញ្ចប់បានយ៉ាងងាយស្រួលនោះទេ។

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

សាកល្បង hub.helm.sh ហើយតោះអភិវឌ្ឍវាទាំងអស់គ្នា។ សេវាកម្មនេះស្ថិតនៅក្រោមគម្រោង Helm ហើយអ្នកថែមទាំងអាចរួមចំណែកដល់ UI របស់វា ប្រសិនបើអ្នកជាអ្នកអភិវឌ្ឍន៍ផ្នែកខាងមុខ ហើយគ្រាន់តែចង់កែលម្អរូបរាង។

ខ្ញុំក៏ចង់ទាក់ទាញចំណាប់អារម្មណ៍របស់អ្នកផងដែរ។ បើកការរួមបញ្ចូល API Broker សេវាកម្ម. វាស្តាប់ទៅដូចជាពិបាក និងមិនច្បាស់លាស់ ប៉ុន្តែវាដោះស្រាយបញ្ហាដែលមនុស្សគ្រប់គ្នាជួបប្រទះ។ ខ្ញុំសូមពន្យល់ជាមួយឧទាហរណ៍ដ៏សាមញ្ញមួយ។

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

អ្នកផ្សេងទៀតដូចជាពួកយើងនៅ Chainstack ប្រើមូលដ្ឋានទិន្នន័យដែលបានគ្រប់គ្រងដូចជា MySQL ឬ PostgreSQL សម្រាប់ម៉ាស៊ីនមេរបស់ពួកគេ។ នោះហើយជាមូលហេតុដែលមូលដ្ឋានទិន្នន័យរបស់យើងមានទីតាំងនៅកន្លែងណាមួយនៅក្នុងពពក។

ប៉ុន្តែបញ្ហាមួយកើតឡើង៖ យើងត្រូវភ្ជាប់សេវាកម្មរបស់យើងជាមួយមូលដ្ឋានទិន្នន័យ បង្កើតរសជាតិមូលដ្ឋានទិន្នន័យ ផ្ទេរព័ត៌មានសម្ងាត់ និងគ្រប់គ្រងវាដោយរបៀបណា។ ទាំងអស់នេះជាធម្មតាត្រូវបានធ្វើឡើងដោយដៃដោយអ្នកគ្រប់គ្រងប្រព័ន្ធ ឬអ្នកអភិវឌ្ឍន៍។ ហើយវាមិនមានបញ្ហាអ្វីទេនៅពេលដែលមានកម្មវិធីតិចតួច។ នៅពេលដែលមានច្រើន អ្នកត្រូវការបន្សំ។ មានអ្នកច្រូតបែបនេះ - វាគឺជាសេវាកម្មឈ្មួញកណ្តាល។ វាអនុញ្ញាតឱ្យអ្នកប្រើកម្មវិធីជំនួយពិសេសសម្រាប់ចង្កោមពពកសាធារណៈ និងបញ្ជាទិញធនធានពីអ្នកផ្តល់សេវាតាមរយៈ Broker ដូចជាប្រសិនបើវាជា API ។ ដើម្បីធ្វើដូចនេះអ្នកអាចប្រើឧបករណ៍ Kubernetes ដើម។

វាសាមញ្ញណាស់។ អ្នកអាចសួរឧទាហរណ៍ Managed MySQL នៅក្នុង Azure ជាមួយនឹងកម្រិតមូលដ្ឋាន (វាអាចត្រូវបានកំណត់រចនាសម្ព័ន្ធ)។ ដោយប្រើ Azure API មូលដ្ឋានទិន្នន័យនឹងត្រូវបានបង្កើត និងរៀបចំសម្រាប់ប្រើប្រាស់។ អ្នកមិនចាំបាច់ជ្រៀតជ្រែកជាមួយនេះទេ កម្មវិធីជំនួយគឺទទួលខុសត្រូវចំពោះបញ្ហានេះ។ ឧទាហរណ៍ OSBA (កម្មវិធីជំនួយ Azure) នឹងត្រឡប់លិខិតបញ្ជាក់ទៅសេវាកម្ម ហើយបញ្ជូនវាទៅ Helm ។ អ្នកនឹងអាចប្រើ WordPress ជាមួយពពក MySQL ដោយមិនដោះស្រាយជាមួយមូលដ្ឋានទិន្នន័យដែលបានគ្រប់គ្រងទាល់តែសោះ ហើយមិនបារម្ភអំពីសេវាពេញលេញខាងក្នុង។

យើងអាចនិយាយបានថា Helm ដើរតួជាកាវដែលនៅលើដៃម្ខាងអនុញ្ញាតឱ្យអ្នកដាក់សេវា ហើយម្យ៉ាងវិញទៀតប្រើប្រាស់ធនធានរបស់អ្នកផ្តល់សេវាពពក។

អ្នកអាចសរសេរកម្មវិធីជំនួយផ្ទាល់ខ្លួនរបស់អ្នក ហើយប្រើរឿងទាំងមូលនេះនៅក្នុងបរិវេណ។ បន្ទាប់មក អ្នកនឹងមានកម្មវិធីជំនួយផ្ទាល់ខ្លួនរបស់អ្នកសម្រាប់អ្នកផ្តល់សេវា Cloud របស់ក្រុមហ៊ុន។ ខ្ញុំសូមផ្តល់អនុសាសន៍ឱ្យសាកល្បងវិធីសាស្រ្តនេះ ជាពិសេសប្រសិនបើអ្នកមានមាត្រដ្ឋានធំ ហើយចង់ដាក់ពង្រាយ dev, staging ឬហេដ្ឋារចនាសម្ព័ន្ធទាំងមូលយ៉ាងឆាប់រហ័សសម្រាប់មុខងារមួយ។ វានឹងធ្វើឱ្យជីវិតកាន់តែងាយស្រួលសម្រាប់ប្រតិបត្តិការរបស់អ្នក ឬ DevOps ។

ការរកឃើញមួយទៀតដែលខ្ញុំបានលើកឡើងរួចហើយគឺ កម្មវិធីជំនួយ Helm-gcsដែលអនុញ្ញាតឱ្យអ្នកប្រើ Google-buckets (កន្លែងផ្ទុកវត្ថុ) ដើម្បីរក្សាទុកគំនូសតាង Helm ។

អ្នកត្រូវការតែពាក្យបញ្ជាបួនដើម្បីចាប់ផ្តើមប្រើវា:

ដំឡើងកម្មវិធីជំនួយ;
ផ្តួចផ្តើមវា;
កំណត់ផ្លូវទៅកាន់ធុងទឹក ដែលមានទីតាំងនៅ gcp;
បោះពុម្ពតារាងតាមវិធីស្តង់ដារ។

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

ជម្មើសជំនួស

Helm មិនមែនជាដំណោះស្រាយគ្រប់គ្រងសេវាកម្មតែមួយនោះទេ។ មានសំណួរជាច្រើនអំពីវា ដែលប្រហែលជាមូលហេតុដែលកំណែទី 3 លេចឡើងយ៉ាងឆាប់រហ័ស។ ជាការពិតណាស់មានជម្រើសជំនួស។

ទាំងនេះអាចជាដំណោះស្រាយឯកទេស ឧទាហរណ៍ Ksonnet ឬ Metaparticle ។ អ្នកអាចប្រើឧបករណ៍គ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធបុរាណរបស់អ្នក (Ansible, Terraform, Chef ។ល។) សម្រាប់គោលបំណងដូចគ្នាដែលខ្ញុំបាននិយាយ។

ទីបំផុតមានដំណោះស្រាយ ក្របខ័ណ្ឌប្រតិបត្តិករដែលប្រជាប្រិយភាពរបស់ពួកគេកំពុងកើនឡើង។

Operator Framework គឺជាជម្រើសកំពូលដែលត្រូវពិចារណា។

វាមានដើមកំណើតនៅ CNCF និង Kubernetes ។ ប៉ុន្តែឧបសគ្គចំពោះការចូលគឺមានច្រើនជាងអ្នកត្រូវសរសេរកម្មវិធីច្រើនជាង ហើយពណ៌នាបង្ហាញតិចជាង។

មាន addons ផ្សេងៗដូចជា Draft, Scaffold ។ ពួកគេធ្វើឱ្យជីវិតកាន់តែងាយស្រួល ជាឧទាហរណ៍ ពួកគេសម្រួលដល់វដ្តនៃការផ្ញើ និងបើកដំណើរការ Helm សម្រាប់អ្នកអភិវឌ្ឍន៍ដើម្បីដាក់ពង្រាយបរិយាកាសសាកល្បង។ ខ្ញុំនឹងហៅពួកគេថាជាអ្នកផ្តល់អំណាច។

នេះជាគំនូសតាងដែលមើលឃើញពីកន្លែងដែលអ្វីៗទាំងអស់ស្ថិតនៅ។

នៅលើអ័ក្ស x គឺជាកម្រិតនៃការគ្រប់គ្រងផ្ទាល់ខ្លួនរបស់អ្នកលើអ្វីដែលកំពុងកើតឡើង នៅលើអ័ក្ស y គឺជាកម្រិតនៃភាពដើមរបស់ Kubernetes ។ Helm កំណែ 2 ធ្លាក់នៅកន្លែងណាមួយនៅកណ្តាល។ នៅក្នុងកំណែទី 3 មិនធំសម្បើមទេ ប៉ុន្តែទាំងការគ្រប់គ្រង និងកម្រិតនៃភាពដើមត្រូវបានធ្វើឱ្យប្រសើរឡើង។ ដំណោះស្រាយនៅកម្រិត Ksonnet នៅតែទាបជាងសូម្បីតែ Helm 2។ ទោះជាយ៉ាងណាក៏ដោយ ពួកគេមានតម្លៃមើលដើម្បីដឹងថាមានអ្វីផ្សេងទៀតនៅក្នុងពិភពលោកនេះ។ ជាការពិតណាស់ កម្មវិធីគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធរបស់អ្នកនឹងស្ថិតនៅក្រោមការគ្រប់គ្រងរបស់អ្នក ប៉ុន្តែវាពិតជាមិនមានដើមកំណើតពី Kubernetes នោះទេ។

Operator Framework មានដើមកំណើតពី Kubernetes យ៉ាងពិតប្រាកដ ហើយអនុញ្ញាតឱ្យអ្នកគ្រប់គ្រងវាកាន់តែឆើតឆាយ និងឆ្លាតវៃ (ប៉ុន្តែត្រូវចាំអំពីកម្រិតចូល)។ ផ្ទុយទៅវិញ នេះគឺសមរម្យសម្រាប់កម្មវិធីឯកទេស និងការបង្កើតការគ្រប់គ្រងសម្រាប់វា ជាជាងម៉ាស៊ីនច្រូតកាត់សម្រាប់វេចខ្ចប់កម្មវិធីមួយចំនួនធំដោយប្រើ Helm។

ឧបករណ៍ពង្រីកគ្រាន់តែកែលម្អការគ្រប់គ្រងបន្តិចបន្តួច បំពេញបន្ថែមលំហូរការងារ ឬកាត់ជ្រុងនៅលើបំពង់ CI/CD។

អនាគតរបស់ Helm

ដំណឹងល្អគឺថា Helm 3 នឹងមកដល់។ កំណែអាល់ហ្វានៃ Helm 3.0.0-alpha.2 ត្រូវបានចេញផ្សាយរួចហើយ អ្នកអាចសាកល្បងវាបាន។ វាមានស្ថេរភាពណាស់ ប៉ុន្តែមុខងារនៅមានកម្រិតនៅឡើយ។

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

នៅពេលដែល Helm 2 ត្រូវបានបង្កើតឡើង ដែលនៅជុំវិញពេលវេលានៃ Kubernetes 1.8 ឬសូម្បីតែមុននេះ គំនិតជាច្រើនគឺមិនទាន់ពេញវ័យ។ ជាឧទាហរណ៍ គោលគំនិត CRD ឥឡូវនេះកំពុងត្រូវបានអនុវត្តយ៉ាងសកម្ម ហើយ Helm នឹង ប្រើ CRDដើម្បីរក្សាទុករចនាសម្ព័ន្ធ។ វាអាចប្រើតែម៉ាស៊ីនភ្ញៀវ និងមិនរក្សាផ្នែកម៉ាស៊ីនមេ។ ដូច្នោះហើយ ប្រើពាក្យបញ្ជា Kubernetes ដើម ដើម្បីធ្វើការជាមួយរចនាសម្ព័ន្ធ និងធនធាន។ នេះគឺជាជំហានដ៏ធំមួយឆ្ពោះទៅមុខ។

នឹងលិចឡើង ការគាំទ្រសម្រាប់ឃ្លាំង OCI ដើម (គំនិតផ្តួចផ្តើមបើកកុងតឺន័រ) ។ នេះគឺជាគំនិតផ្តួចផ្តើមដ៏ធំមួយ ហើយ Helm ចាប់អារម្មណ៍ជាចម្បង ដើម្បីបង្ហោះតារាងរបស់វា។ វាមកដល់ចំណុចដែលឧទាហរណ៍ Docker Hub គាំទ្រស្តង់ដារ OCI ជាច្រើន។ ខ្ញុំមិនស្មានទេ ប៉ុន្តែប្រហែលជាអ្នកផ្តល់ឃ្លាំង Docker បុរាណនឹងចាប់ផ្តើមផ្តល់ឱ្យអ្នកនូវឱកាសដើម្បីធ្វើជាម្ចាស់ផ្ទះតារាង Helm របស់អ្នក។

រឿងចម្រូងចម្រាសសម្រាប់ខ្ញុំគឺ Lua គាំទ្រជាម៉ាស៊ីនគំរូសម្រាប់សរសេរស្គ្រីប។ ខ្ញុំមិនមែនជាអ្នកគាំទ្រដ៏ធំរបស់ Lua ទេ ប៉ុន្តែនេះនឹងជាមុខងារស្រេចចិត្តទាំងស្រុង។ ខ្ញុំបានពិនិត្យវា 3 ដង - ការប្រើ Lua នឹងមិនចាំបាច់ទេ។ ដូច្នេះហើយ អ្នកដែលចង់ប្រើ Lua អ្នកដែលចូលចិត្ត Go ចូលរួមជំរុំដ៏ធំរបស់យើង ហើយប្រើ go-tmpl សម្រាប់រឿងនេះ។

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

នឹងត្រូវធ្វើការឡើងវិញយ៉ាងខ្លាំង គំរូដែលជំរុញដោយព្រឹត្តិការណ៍. វាត្រូវបានពិពណ៌នាដោយគំនិតរួចហើយ។ សូមក្រឡេកមើលសាខា Helm 3 ហើយអ្នកនឹងឃើញចំនួនព្រឹត្តិការណ៍ និងទំពក់ និងរបស់ផ្សេងទៀតត្រូវបានបន្ថែម ដែលនឹងធ្វើឱ្យមានភាពសាមញ្ញ ហើយម្យ៉ាងវិញទៀត បន្ថែមការគ្រប់គ្រងលើដំណើរការដាក់ពង្រាយ និងប្រតិកម្មចំពោះពួកគេ។

Helm 3 នឹងកាន់តែសាមញ្ញ សុវត្ថិភាព និងរីករាយជាង មិនមែនដោយសារតែយើងមិនចូលចិត្ត Helm 2 នោះទេ ប៉ុន្តែដោយសារតែ Kubernetes កាន់តែជឿនលឿនជាងមុន។ ដូច្នោះហើយ Helm អាចប្រើប្រាស់ការអភិវឌ្ឍន៍របស់ Kubernetes និងបង្កើតអ្នកគ្រប់គ្រងដ៏ល្អសម្រាប់ Kubernetes នៅលើវា។

ដំណឹងល្អមួយទៀតគឺនោះ។ DevOpsConf Alexander Khayorov នឹងប្រាប់អ្នកថា តើធុងអាចមានសុវត្ថិភាពបានទេ? ចូរយើងរំលឹកអ្នកថា សន្និសីទស្តីពីការរួមបញ្ចូលនៃការអភិវឌ្ឍន៍ ការធ្វើតេស្ត និងដំណើរការប្រតិបត្តិការនឹងប្រព្រឹត្តទៅនៅទីក្រុងម៉ូស្គូ ថ្ងៃទី 30 ខែកញ្ញានិងថ្ងៃទី 1 ខែតុលា. អ្នកនៅតែអាចធ្វើបានរហូតដល់ថ្ងៃទី 20 ខែសីហា ដាក់ស្នើរបាយការណ៍មួយ ហើយប្រាប់យើងអំពីបទពិសោធន៍របស់អ្នកជាមួយនឹងដំណោះស្រាយ មួយក្នុងចំណោមជាច្រើន។ ភារកិច្ចនៃវិធីសាស្រ្ត DevOps ។

តាមដានប៉ុស្តិ៍ត្រួតពិនិត្យសន្និសីទ និងព័ត៌មាននៅ ព្រឹត្តិបត្រ и ឆានែលទូរលេខ.

ប្រភព: www.habr.com

មួកសុវត្ថិភាព