ក្មេងស្រីនៅលើម៉ូតូ។ រូបភាព freepik ។និមិត្តសញ្ញា Nomad ពី ហាសស៊ីកូប

Kubernetes គឺជាសត្វស្វាកុងតឺន័រ 300 គីឡូក្រាម។ វាដំណើរការនៅក្នុងប្រព័ន្ធកុងតឺន័រធំជាងគេមួយចំនួននៅលើពិភពលោក ប៉ុន្តែវាមកក្នុងតម្លៃថ្លៃ។

ជាពិសេសមានតម្លៃថ្លៃសម្រាប់ក្រុមតូចៗដែលត្រូវចំណាយពេលច្រើនលើការគាំទ្រ និងខ្សែកោងការរៀនសូត្រដ៏ចោត។ សម្រាប់​ក្រុម​របស់​យើង​ដែល​មាន​គ្នា​បួន​នាក់​នេះ​គឺ​លើស​ពី​នេះ​ពេក។ ហេតុដូច្នេះហើយ យើងបានចាប់ផ្តើមស្វែងរកជម្រើសផ្សេងទៀត ហើយបានធ្លាក់ក្នុងអន្លង់ស្នេហ៍ Nomad.

តើ​អ្នក​ចង់បាន​អ្វី

ក្រុមរបស់យើងរក្សានូវសេវាកម្មត្រួតពិនិត្យ និងវិភាគការអនុវត្តធម្មតាមួយចំនួន៖ ចំណុចបញ្ចប់ API សម្រាប់ម៉ែត្រដែលសរសេរក្នុង Go, Prometheus exports, logparers ដូចជា Logstash និង ហ្គូលុម។ក៏ដូចជាមូលដ្ឋានទិន្នន័យដូចជា InfluxDB ឬ Elasticsearch ។ សេវាកម្មទាំងនេះនីមួយៗដំណើរការនៅក្នុងកុងតឺន័រផ្ទាល់ខ្លួនរបស់វា។ យើង​ត្រូវ​ការ​ប្រព័ន្ធ​សាមញ្ញ​ដើម្បី​រក្សា​វា​ឱ្យ​ដំណើរការ​ទាំង​អស់។

យើងចាប់ផ្តើមជាមួយនឹងបញ្ជីនៃតម្រូវការសម្រាប់ការរៀបចំកុងតឺន័រ៖

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

លើសពីនេះ រឿងខាងក្រោមនឹងល្អ ប៉ុន្តែមិនចាំបាច់បន្ថែម៖

• ការសម្គាល់ម៉ាស៊ីនដោយសមត្ថភាពរបស់ពួកគេ (ឧទាហរណ៍ ម៉ាស៊ីនសម្គាល់ជាមួយថាសលឿនសម្រាប់សេវា I/O ធ្ងន់)។
• សមត្ថភាពក្នុងការដំណើរការសេវាកម្មដោយឯករាជ្យពីអ្នករៀបចំវង់ភ្លេង (ឧទាហរណ៍ កំឡុងពេលអភិវឌ្ឍ)។
• កន្លែងទូទៅដើម្បីចែករំលែកការកំណត់រចនាសម្ព័ន្ធ និងអាថ៌កំបាំង។
• ចំណុចបញ្ចប់សម្រាប់ម៉ែត្រ និងកំណត់ហេតុ។

ហេតុអ្វីបានជា Kubernetes មិនមែនសម្រាប់យើង

ខណៈពេលដែលកំពុងបង្កើតគំរូជាមួយ Kubernetes យើងកត់សំគាល់ថាយើងចាប់ផ្តើមបន្ថែមស្រទាប់ស្មុគ្រស្មាញកាន់តែច្រើនឡើងៗ ដែលយើងពឹងផ្អែកទាំងស្រុង។

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

លើសពីនេះ ប្រព័ន្ធអេកូឡូស៊ី Kubernetes កំពុងវិវឌ្ឍន៍យ៉ាងឆាប់រហ័ស។ វាត្រូវការពេលវេលា និងថាមពលច្រើនដើម្បីបន្តធ្វើបច្ចុប្បន្នភាពជាមួយការអនុវត្តល្អបំផុត និងឧបករណ៍ចុងក្រោយបំផុត។ Kubectl, minikube, kubeadm, helm, tiller, kops, oc - បញ្ជីបន្តនិងបន្ត។ មិនមែន​ឧបករណ៍​ទាំង​អស់​នេះ​ត្រូវ​ការ​ដើម្បី​ចាប់​ផ្តើម​ទេ ប៉ុន្តែ​អ្នក​មិន​ដឹង​ថា​អ្នក​នឹង​ត្រូវ​ការ​អ្វី​ទេ ដូច្នេះ​អ្នក​ត្រូវ​ដឹង​ពី​អ្វី​គ្រប់​យ៉ាង។ ដោយ​សារ​តែ​នេះ ខ្សែ​កោង​នៃ​ការ​រៀន​សូត្រ​មាន​ភាព​ចោត​ខ្លាំង។

ពេលណាត្រូវប្រើ Kubernetes

មនុស្សជាច្រើននៅក្នុងក្រុមហ៊ុនរបស់យើងប្រើប្រាស់ Kubernetes ហើយពិតជារីករាយជាមួយវា។ វត្ថុទាំងនេះត្រូវបានគ្រប់គ្រងដោយ Google ឬ Amazon ដែលមានធនធានគាំទ្រគ្រប់គ្រាន់។

Kubernetes មកជាមួយ លក្ខណៈពិសេសអស្ចារ្យដែលធ្វើឱ្យការរៀបចំកុងតឺន័រខ្នាតធំអាចគ្រប់គ្រងបានជាងមុន៖

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

សំណួរគឺ តើអ្នកពិតជាត្រូវការលក្ខណៈពិសេសទាំងអស់នេះមែនទេ? អ្នក​មិន​អាច​គ្រាន់​តែ​ពឹង​ផ្អែក​លើ abstractions; អ្នកត្រូវស្វែងរកអ្វីដែលកំពុងកើតឡើងនៅក្រោមក្រណាត់.

ក្រុមរបស់យើងផ្តល់សេវាកម្មភាគច្រើនពីចម្ងាយ (ដោយសារតែការតភ្ជាប់យ៉ាងជិតស្និទ្ធទៅនឹងហេដ្ឋារចនាសម្ព័ន្ធស្នូល) ដូច្នេះយើងមិនចង់លើកចង្កោម Kubernetes ផ្ទាល់ខ្លួនរបស់យើងទេ។ យើងគ្រាន់តែចង់ផ្តល់សេវាកម្ម។

មិនរួមបញ្ចូលថ្ម

Nomad គឺជា 20% orchestration ដែលផ្តល់ឱ្យ 80% នៃអ្វីដែលត្រូវការ។ អ្វីទាំងអស់ដែលវាធ្វើគឺគ្រប់គ្រងការដាក់ពង្រាយ។ Nomad យកចិត្តទុកដាក់លើការដាក់ពង្រាយ ចាប់ផ្តើមកុងតឺន័រឡើងវិញ ក្នុងករណីមានកំហុស... ហើយនោះជាវា។

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

ខ្ញុំគិតថា Nomad បានរកឃើញការសម្របសម្រួលដ៏ល្អឥតខ្ចោះរវាងភាពងាយស្រួលនៃការប្រើប្រាស់ និងអត្ថប្រយោជន៍។ វាល្អសម្រាប់សេវាកម្មឯករាជ្យតូច។ ប្រសិនបើអ្នកត្រូវការការគ្រប់គ្រងបន្ថែមទៀត អ្នកនឹងត្រូវលើកពួកគេដោយខ្លួនឯង ឬប្រើវិធីសាស្រ្តផ្សេង។ nomad គឺ គ្រាន់តែ អ្នកភ្លេង។

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

ប្រព័ន្ធអេកូ Nomad រួមបញ្ចូលគ្នាយ៉ាងរលុង

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

template {
  data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}"
EOH

  destination = "secrets/file.env"
  env         = true
}

នៅទីនេះយើងអានគន្លឹះ service/geo-api/log-verbosity ពីកុងស៊ុល និងក្នុងដំណើរការការងារ យើងតំណាងឱ្យវាជាមួយនឹងការប្រែប្រួលបរិស្ថាន LOG_LEVEL. យើងក៏បង្ហាញគន្លឹះផងដែរ។ secret/geo-api-key ពី Vault as API_KEY. សាមញ្ញ​តែ​ខ្លាំង!

ដោយសារតែភាពសាមញ្ញរបស់វា Nomad អាចពង្រីកបានយ៉ាងងាយស្រួលជាមួយនឹងសេវាកម្មផ្សេងទៀតតាមរយៈ API ។ ឧទាហរណ៍ ស្លាកការងារត្រូវបានគាំទ្រ។ យើងដាក់ស្លាកសេវាកម្មទាំងអស់ជាមួយនឹងម៉ែត្រជាមួយនឹងស្លាក trv-metrics. វិធីនេះ Prometheus ងាយស្រួលស្វែងរកសេវាកម្មទាំងនេះតាមរយៈកុងស៊ុល ហើយពិនិត្យចំណុចបញ្ចប់តាមកាលកំណត់ /metrics សម្រាប់ទិន្នន័យថ្មី។ ដូចគ្នានេះដែរអាចត្រូវបានធ្វើឧទាហរណ៍សម្រាប់កំណត់ហេតុដោយប្រើ ឡូកូ.

មានឧទាហរណ៍ជាច្រើនទៀតនៃការពង្រីក៖

• ដំណើរការការងារ Jenkins ដោយប្រើទំពក់ ហើយកុងស៊ុលតាមដានការងារ Nomad ដែលត្រូវបានដាក់ឱ្យប្រើប្រាស់ឡើងវិញ នៅពេលដែលការកំណត់រចនាសម្ព័ន្ធសេវាកម្មផ្លាស់ប្តូរ។
• Ceph បន្ថែមប្រព័ន្ធឯកសារចែកចាយទៅ Nomad ។
• fabio សម្រាប់តុល្យភាពបន្ទុក។

ទាំងអស់នេះអនុញ្ញាតឱ្យ អភិវឌ្ឍហេដ្ឋារចនាសម្ព័ន្ធសរីរាង្គ ដោយគ្មានឯកសារយោងពិសេសចំពោះអ្នកលក់។

ការព្រមានដោយយុត្តិធម៌

គ្មានប្រព័ន្ធណាល្អឥតខ្ចោះទេ។ ខ្ញុំ​មិន​ណែនាំ​អ្នក​ឱ្យ​ណែនាំ​លក្ខណៈ​ពិសេស​ថ្មី​បំផុត​ក្នុង​ការ​ផលិត​ភ្លាមៗ​ទេ។ ប្រាកដណាស់ មានកំហុស និងមុខងារដែលបាត់ ប៉ុន្តែក៏អនុវត្តដូចគ្នាចំពោះ Kubernetes ដែរ។

បើប្រៀបធៀបទៅនឹង Kubernetes សហគមន៍ Nomad មិនធំនោះទេ។ Kubernetes មាន commits ប្រហែល 75 រួចហើយ និងអ្នករួមចំណែក 000 ខណៈពេលដែល Nomad មានប្រហែល 2000 commits និង 14 contributors។ វានឹងពិបាកសម្រាប់ Nomad ដើម្បីតាមទាន់ Kubernetes ក្នុងល្បឿន ប៉ុន្តែវាប្រហែលជាមិនចាំបាច់ទេ! វាជាប្រព័ន្ធឯកទេសជាង ហើយសហគមន៍តូចជាងនេះក៏មានន័យថាសំណើទាញរបស់អ្នកទំនងជាត្រូវបានកត់សម្គាល់ និងទទួលយកជាង Kubernetes ។

សង្ខេប

Takeaway៖ កុំប្រើ Kubernetes ដោយសារតែអ្នកផ្សេងទៀតកំពុងធ្វើវា។ វាយតម្លៃតម្រូវការរបស់អ្នកដោយប្រុងប្រយ័ត្ន ហើយពិនិត្យមើលថាតើឧបករណ៍ណាដែលចំណេញច្រើនជាង។

ប្រសិនបើអ្នកគ្រោងនឹងដាក់ពង្រាយសេវាកម្មដូចគ្នាច្រើននៅលើហេដ្ឋារចនាសម្ព័ន្ធខ្នាតធំ នោះ Kubernetes គឺជាជម្រើសដ៏ល្អ។ គ្រាន់តែដឹងអំពីភាពស្មុគស្មាញបន្ថែម និងថ្លៃដើមដំណើរការ។ ការចំណាយមួយចំនួនអាចត្រូវបានជៀសវាងដោយប្រើបរិស្ថាន Kubernetes ដែលបានគ្រប់គ្រងដូចជា ម៉ាស៊ីន Google Kubernetes ឬ ក្រុមហ៊ុន Amazon EX.

ប្រសិនបើអ្នកគ្រាន់តែស្វែងរកអ្នកវង់ភ្លេងដ៏រឹងមាំដែលងាយស្រួលក្នុងការថែទាំ និងពង្រីក ហេតុអ្វីមិនផ្តល់ឱ្យ Nomad សាកល្បង? អ្នកប្រហែលជាភ្ញាក់ផ្អើលថាតើវានឹងនាំអ្នកទៅឆ្ងាយប៉ុណ្ណា។

ប្រសិនបើ Kubernetes គឺដូចជាឡាន Nomad គឺជាម៉ូតូស្កូតឺ។ ពេលខ្លះអ្នកត្រូវការមួយ ហើយពេលខ្លះទៀត។ អ្នកទាំងពីរមានសិទ្ធិមាន។

ប្រភព: www.habr.com