ការពង្រីក និងបន្ថែម Kubernetes (របាយការណ៍ទូទៅ និងវីដេអូ)

ថ្ងៃទី 8 ខែមេសានៅក្នុងសន្និសីទ Saint HighLoad++ 2019ជាផ្នែកមួយនៃផ្នែក "DevOps និងប្រតិបត្តិការ" របាយការណ៍ "ការពង្រីក និងបំពេញបន្ថែម Kubernetes" ត្រូវបានផ្តល់ឱ្យ ក្នុងការបង្កើតដែលបុគ្គលិកបីនាក់នៃក្រុមហ៊ុន Flant បានចូលរួម។ នៅក្នុងវា យើងនិយាយអំពីស្ថានភាពជាច្រើនដែលយើងចង់ពង្រីក និងបំពេញបន្ថែមសមត្ថភាពរបស់ Kubernetes ប៉ុន្តែសម្រាប់យើងមិនបានរកឃើញដំណោះស្រាយដែលត្រៀមរួចជាស្រេច និងសាមញ្ញនោះទេ។ យើងមានដំណោះស្រាយចាំបាច់នៅក្នុងទម្រង់នៃគម្រោងប្រភពបើកចំហ ហើយសុន្ទរកថានេះក៏ត្រូវបានឧទ្ទិសដល់ពួកគេផងដែរ។

តាមប្រពៃណីយើងរីករាយក្នុងការបង្ហាញ វីដេអូនៃរបាយការណ៍ (៥០ នាទី ផ្តល់ព័ត៌មានច្រើនជាងអត្ថបទ) និងសេចក្តីសង្ខេបសំខាន់ក្នុងទម្រង់ជាអត្ថបទ។ ទៅ!

ស្នូល និងការបន្ថែមនៅក្នុង K8s

Kubernetes កំពុងផ្លាស់ប្តូរឧស្សាហកម្ម និងវិធីសាស្រ្តក្នុងការគ្រប់គ្រងដែលត្រូវបានបង្កើតឡើងជាយូរមកហើយ៖

• សូមអរគុណដល់គាត់ អរូបីយើងលែងដំណើរការជាមួយគោលគំនិតដូចជាការដំឡើង config ឬដំណើរការ command (Chef, Ansible...) ប៉ុន្តែប្រើការដាក់ជាក្រុមនៃ containers សេវាកម្ម។ល។
• យើងអាចរៀបចំកម្មវិធីដោយមិនគិតពី nuances នៃកម្មវិធី គេហទំព័រជាក់លាក់ដែលនឹងត្រូវបានដាក់ឱ្យដំណើរការ៖ ដែកទទេ ពពកនៃអ្នកផ្តល់សេវា ជាដើម។
• ជាមួយនឹង K8s អ្នកមិនដែលមានលទ្ធភាពចូលប្រើច្រើនជាងនេះទេ។ ការអនុវត្តល្អបំផុត លើការរៀបចំហេដ្ឋារចនាសម្ព័ន្ធ៖ បច្ចេកទេសធ្វើមាត្រដ្ឋាន ការព្យាបាលដោយខ្លួនឯង ការអត់ឱនចំពោះកំហុស។ល។

ទោះជាយ៉ាងណាក៏ដោយ អ្វីគ្រប់យ៉ាងគឺមិនរលូននោះទេ៖ Kubernetes ក៏បាននាំយកបញ្ហាប្រឈមថ្មីរបស់ខ្លួនផងដែរ។

Kubernetes មិនមាន គឺជាការបញ្ចូលគ្នាដែលដោះស្រាយបញ្ហាទាំងអស់របស់អ្នកប្រើប្រាស់ទាំងអស់។ ស្នូល Kubernetes ទទួលខុសត្រូវចំពោះតែសំណុំនៃមុខងារចាំបាច់អប្បបរមាដែលមាននៅក្នុង រាល់ ចង្កោម៖

ស្នូល Kubernetes កំណត់សំណុំមូលដ្ឋាននៃ primitives សម្រាប់ការដាក់ជាក្រុមនៃកុងតឺន័រ ការគ្រប់គ្រងចរាចរណ៍ និងដូច្នេះនៅលើ។ យើងបាននិយាយអំពីពួកគេនៅក្នុងលម្អិតបន្ថែមទៀតនៅក្នុង របាយការណ៍ 2 ឆ្នាំមុន.

ម៉្យាងវិញទៀត K8s ផ្តល់ឱកាសដ៏អស្ចារ្យដើម្បីពង្រីកមុខងារដែលមាន ដែលជួយបិទអ្នកដទៃ - ជាក់លាក់ - តម្រូវការអ្នកប្រើប្រាស់។ ការបន្ថែមទៅលើ Kubernetes គឺជាទំនួលខុសត្រូវរបស់អ្នកគ្រប់គ្រងចង្កោម ដែលត្រូវតែដំឡើង និងកំណត់រចនាសម្ព័ន្ធអ្វីគ្រប់យ៉ាងដែលចាំបាច់ដើម្បីឱ្យក្រុមរបស់ពួកគេ "នៅក្នុងរូបរាងត្រឹមត្រូវ" [ដើម្បីដោះស្រាយបញ្ហាជាក់លាក់របស់ពួកគេ] ។ តើការបន្ថែមទាំងនេះជាអ្វី? សូមក្រឡេកមើលឧទាហរណ៍មួយចំនួន។

ឧទាហរណ៍នៃកម្មវិធីបន្ថែម

ដោយបានដំឡើង Kubernetes យើងប្រហែលជាភ្ញាក់ផ្អើលដែលបណ្តាញដែលចាំបាច់សម្រាប់អន្តរកម្មរបស់ pods ទាំងក្នុង node និង node មិនដំណើរការដោយខ្លួនឯងទេ។ ខឺណែល Kubernetes មិនធានាការតភ្ជាប់ចាំបាច់ទេ ផ្ទុយទៅវិញ វាកំណត់បណ្តាញ ចំណុចប្រទាក់ (CNI) សម្រាប់កម្មវិធីបន្ថែមភាគីទីបី។ យើងត្រូវដំឡើងកម្មវិធីបន្ថែមមួយក្នុងចំណោមកម្មវិធីបន្ថែមទាំងនេះ ដែលនឹងទទួលខុសត្រូវចំពោះការកំណត់រចនាសម្ព័ន្ធបណ្តាញ។

ឧទាហរណ៍ជិតស្និទ្ធគឺដំណោះស្រាយផ្ទុកទិន្នន័យ (ថាសមូលដ្ឋាន ឧបករណ៍ទប់ស្កាត់បណ្តាញ Ceph...)។ ដំបូងពួកគេស្ថិតនៅក្នុងស្នូលប៉ុន្តែជាមួយនឹងការមកដល់ CSI ស្ថានភាពផ្លាស់ប្តូរទៅជាអ្វីដែលស្រដៀងនឹងអ្វីដែលបានពិពណ៌នារួចហើយ៖ ចំណុចប្រទាក់គឺនៅក្នុង Kubernetes ហើយការអនុវត្តរបស់វាគឺនៅក្នុងម៉ូឌុលភាគីទីបី។

ឧទាហរណ៍ផ្សេងទៀតរួមមាន:

• Ingress- ឧបករណ៍បញ្ជា (សូមមើលការពិនិត្យឡើងវិញរបស់ពួកគេនៅក្នុង អត្ថបទថ្មីៗរបស់យើង។).
• អ្នកគ្រប់គ្រងវិញ្ញាបនប័ត្រ:

  

• ប្រតិបត្តិករ គឺជាថ្នាក់ទាំងមូលនៃកម្មវិធីបន្ថែម (ដែលរួមបញ្ចូលអ្នកគ្រប់គ្រងវិញ្ញាបនប័ត្រដែលបានលើកឡើង) ពួកគេកំណត់បុព្វបទ និងឧបករណ៍បញ្ជា។ តក្កវិជ្ជានៃការងាររបស់ពួកគេត្រូវបានកំណត់ដោយការស្រមើលស្រមៃរបស់យើងតែប៉ុណ្ណោះ ហើយអនុញ្ញាតឱ្យយើងបង្វែរសមាសធាតុហេដ្ឋារចនាសម្ព័ន្ធដែលត្រៀមរួចជាស្រេច (ឧទាហរណ៍ DBMS) ទៅជាបុព្វកាល ដែលងាយស្រួលធ្វើការជាមួយ (ជាងសំណុំនៃធុង និងការកំណត់របស់វា)។ ប្រតិបត្តិករមួយចំនួនធំត្រូវបានសរសេរ - ទោះបីជាពួកគេជាច្រើនមិនទាន់រួចរាល់សម្រាប់ការផលិតក៏ដោយ វាគ្រាន់តែជាបញ្ហានៃពេលវេលាប៉ុណ្ណោះ៖

  

• ម៉ែត្រ - រូបភាពមួយទៀតនៃរបៀបដែល Kubernetes បានបំបែកចំណុចប្រទាក់ (Metrics API) ពីការអនុវត្ត (កម្មវិធីបន្ថែមភាគីទីបីដូចជាអាដាប់ទ័រ Prometheus ភ្នាក់ងារចង្កោម Datadog ... ) ។
• សម្រាប់ ការត្រួតពិនិត្យ និងស្ថិតិដែលជាកន្លែងដែលនៅក្នុងការអនុវត្តមិនត្រឹមតែត្រូវការ Prometheus និង Grafanaប៉ុន្តែក៏មាន kube-state-metrics, node-exporter ជាដើម។

ហើយនេះមិនមែនជាបញ្ជីពេញលេញនៃការបន្ថែមទេ... ឧទាហរណ៍៖ នៅក្រុមហ៊ុន Flant យើងដំឡើងបច្ចុប្បន្ន 29 ការបន្ថែម (ដែលទាំងអស់បង្កើតវត្ថុ Kubernetes សរុបចំនួន 249) ។ និយាយឱ្យសាមញ្ញ យើងមិនអាចឃើញជីវិតរបស់ចង្កោមដោយគ្មានការបន្ថែមទេ។

ស្វ័យប្រវត្តិកម្ម

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

1. មានការចុះបញ្ជីឯកជន (ឧ. ទាមទារការចូល) ដែលមានរូបភាពសម្រាប់កម្មវិធី។ វាត្រូវបានសន្មត់ថាផតនីមួយៗត្រូវបានផ្តល់អាថ៌កំបាំងពិសេសដែលអនុញ្ញាតឱ្យមានការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវនៅក្នុងបញ្ជីឈ្មោះ។ ភារកិច្ចរបស់យើងគឺដើម្បីធានាថាអាថ៌កំបាំងនេះត្រូវបានរកឃើញនៅក្នុង namespace ដូច្នេះ pods អាចទាញយករូបភាព។ វាអាចមានកម្មវិធីជាច្រើន (ដែលនីមួយៗត្រូវការអាថ៌កំបាំង) ហើយវាមានប្រយោជន៍ក្នុងការធ្វើបច្ចុប្បន្នភាពអាថ៌កំបាំងដោយខ្លួនឯងជាទៀងទាត់ ដូច្នេះជម្រើសនៃការដាក់អាថ៌កំបាំងដោយដៃត្រូវបានលុបចោល។ នេះជាកន្លែងដែលប្រតិបត្តិករមកជួយសង្គ្រោះ៖ យើងបង្កើតឧបករណ៍បញ្ជាដែលនឹងរង់ចាំឱ្យចន្លោះឈ្មោះលេចឡើង ហើយផ្អែកលើព្រឹត្តិការណ៍នេះនឹងបន្ថែមអាថ៌កំបាំងទៅចន្លោះឈ្មោះ។
2. អនុញ្ញាតឱ្យចូលប្រើលំនាំដើមពី pods ទៅអ៊ីនធឺណិតត្រូវបានហាមឃាត់។ ប៉ុន្តែពេលខ្លះវាអាចត្រូវបានទាមទារ៖ វាជាឡូជីខលសម្រាប់យន្តការអនុញ្ញាតការចូលដំណើរការដើម្បីដំណើរការយ៉ាងសាមញ្ញ ដោយមិនតម្រូវឱ្យមានជំនាញជាក់លាក់ ឧទាហរណ៍ដោយវត្តមាននៃស្លាកជាក់លាក់នៅក្នុង namespace ។ តើប្រតិបត្តិករអាចជួយយើងនៅទីនេះដោយរបៀបណា? ឧបករណ៍បញ្ជាត្រូវបានបង្កើតឡើងដែលរង់ចាំឱ្យស្លាកបង្ហាញនៅក្នុង namespace និងបន្ថែមគោលការណ៍សមរម្យសម្រាប់ការចូលប្រើអ៊ីនធឺណិត។
3. ស្ថានភាពស្រដៀងគ្នា៖ ឧបមាថាយើងត្រូវបន្ថែមអ្វីមួយ ស្អុយរលួយប្រសិនបើវាមានស្លាកស្រដៀងគ្នា (ជាមួយនឹងប្រភេទមួយចំនួននៃបុព្វបទ)។ សកម្មភាពជាមួយប្រតិបត្តិករគឺជាក់ស្តែង...

នៅក្នុងចង្កោមណាមួយ កិច្ចការទម្លាប់ត្រូវតែត្រូវបានដោះស្រាយ និង សិទ្ធិ នេះអាចត្រូវបានធ្វើដោយប្រើប្រតិបត្តិករ។

សរុបមករឿងទាំងអស់ដែលបានពិពណ៌នា យើងបានសន្និដ្ឋានថា សម្រាប់ការងារប្រកបដោយផាសុកភាពនៅក្នុង Kubernetes ដែលអ្នកត្រូវការ: ក) ដំឡើងកម្មវិធីបន្ថែម, ខ) អភិវឌ្ឍប្រតិបត្តិករ (សម្រាប់ដោះស្រាយកិច្ចការរដ្ឋបាលប្រចាំថ្ងៃ)។

តើធ្វើដូចម្តេចដើម្បីសរសេរសេចក្តីថ្លែងការណ៍សម្រាប់ Kubernetes?

ជាទូទៅគ្រោងការណ៍គឺសាមញ្ញ:

... ប៉ុន្តែបន្ទាប់មកវាប្រែថា:

• Kubernetes API គឺជារឿងមិនសំខាន់ដែលចំណាយពេលច្រើនដើម្បីធ្វើជាម្ចាស់។
• ការសរសេរកម្មវិធីក៏មិនមែនសម្រាប់មនុស្សគ្រប់គ្នាដែរ (ភាសា Go ត្រូវបានជ្រើសរើសជាភាសាដែលពេញចិត្ត ពីព្រោះវាមានក្របខ័ណ្ឌពិសេសសម្រាប់វា - ប្រតិបត្តិករ SDK);
• ស្ថានភាពគឺស្រដៀងគ្នាជាមួយនឹងក្របខ័ណ្ឌខ្លួនឯង។

បន្ទាត់ខាងក្រោម: ដើម្បីសរសេរឧបករណ៍បញ្ជា (ប្រតិបត្តិករ) ត្រូវតែ ចំណាយធនធានសំខាន់ៗ ដើម្បីសិក្សាសម្ភារៈ។ នេះនឹងត្រូវបានរាប់ជាសុចរិតសម្រាប់ប្រតិបត្តិករ "ធំ" - និយាយថាសម្រាប់ MySQL DBMS ។ ប៉ុន្តែប្រសិនបើយើងចងចាំឧទាហរណ៍ដែលបានពិពណ៌នាខាងលើ (លាតត្រដាងអាថ៌កំបាំង ការចូលប្រើបណ្តាញអ៊ីនធឺណេត...) ដែលយើងក៏ចង់ធ្វើបានត្រឹមត្រូវ នោះយើងនឹងយល់ថា កិច្ចខិតខំប្រឹងប្រែងដែលបានចំណាយនឹងលើសពីលទ្ធផលដែលយើងត្រូវការឥឡូវនេះ៖

ជាទូទៅ វិបត្តិកើតឡើង៖ ចំណាយធនធានច្រើន ហើយស្វែងរកឧបករណ៍ត្រឹមត្រូវសម្រាប់ការសរសេរសេចក្តីថ្លែងការណ៍ ឬធ្វើវាតាមរបៀបចាស់ (ប៉ុន្តែលឿន)។ ដើម្បីដោះស្រាយវា - ដើម្បីស្វែងរកការសម្របសម្រួលរវាងភាពខ្លាំងទាំងនេះ - យើងបានបង្កើតគម្រោងផ្ទាល់ខ្លួនរបស់យើង៖ ប្រតិបត្តិករសែល (សូមមើលរបស់គាត់ផងដែរ។ សេចក្តីប្រកាសថ្មីៗនេះ នៅលើមជ្ឈមណ្ឌល).

ប្រតិបត្តិករសែល

តើគាត់ធ្វើការយ៉ាងដូចម្តេច? ចង្កោមមានផតដែលមាន Go binary ជាមួយ shell-operator ។ នៅជាប់វាគឺជាសំណុំ ទំពក់ (ព័ត៌មានលម្អិតបន្ថែមអំពីពួកគេ - សូមមើលខាងក្រោម). ប្រតិបត្តិករសែលខ្លួនឯងជាវជាក់លាក់ ព្រឹត្តិការណ៍ នៅក្នុង Kubernetes API នៅពេលដែលវាបើកដំណើរការទំពក់ដែលត្រូវគ្នា។

តើ​ប្រតិបត្តិករ​សែលហ្វី​ដឹង​ដោយ​របៀប​ណា​ដែល​ទំពក់​ត្រូវ​ហៅ​ទៅ​លើ​ព្រឹត្តិការណ៍​មួយ​ណា? ព័ត៌មាននេះត្រូវបានបញ្ជូនទៅសែល-ប្រតិបត្តិករដោយទំពក់ដោយខ្លួនឯង ហើយពួកគេធ្វើវាយ៉ាងសាមញ្ញបំផុត។

ទំពក់គឺជាស្គ្រីប Bash ឬឯកសារដែលអាចប្រតិបត្តិបានផ្សេងទៀតដែលទទួលយកអាគុយម៉ង់តែមួយ --config និងឆ្លើយតបជាមួយ JSON ។ ក្រោយមកទៀតកំណត់ថាតើវត្ថុណាដែលចាប់អារម្មណ៍ចំពោះវា ហើយព្រឹត្តិការណ៍ណាមួយ (សម្រាប់វត្ថុទាំងនេះ) គួរតែត្រូវបានឆ្លើយតបទៅ៖

ខ្ញុំនឹងបង្ហាញពីការអនុវត្តនៅលើសែល - ប្រតិបត្តិករនៃឧទាហរណ៍មួយរបស់យើង - decomposing អាថ៌កំបាំងសម្រាប់ការចូលទៅកាន់បញ្ជីឈ្មោះឯកជនជាមួយនឹងរូបភាពកម្មវិធី។ វាមានពីរដំណាក់កាល។

ការអនុវត្ត៖ 1. សរសេរទំពក់

ដំបូងបង្អស់នៅក្នុងទំពក់យើងនឹងដំណើរការ --configដោយបង្ហាញថាយើងចាប់អារម្មណ៍លើ namespaces ហើយជាពិសេសគឺពេលនៃការបង្កើតរបស់ពួកគេ៖

[[ $1 == "--config" ]] ; then
  cat << EOF
{
  "onKubernetesEvent": [
    {
      "kind": "namespace",
      "event": ["add"]
    }
  ]
}
EOF
…

តើតក្កវិជ្ជានឹងមើលទៅដូចអ្វី? ក៏សាមញ្ញណាស់៖

…
else
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  kubectl create -n ${createdNamespace} -f - << EOF
Kind: Secret
...
EOF
fi

ជំហាន​ដំបូង​គឺ​ត្រូវ​រក​ឱ្យ​ឃើញ​ថា namespace មួយ​ណា​ត្រូវ​បាន​បង្កើត​ឡើង ហើយ​ទីពីរ​គឺ​ត្រូវ​បង្កើត​វា​ដោយ​ប្រើ kubectl អាថ៌កំបាំងសម្រាប់លំហឈ្មោះនេះ។

ការអនុវត្ត៖ 2. ការប្រមូលផ្តុំរូបភាព

អ្វីដែលនៅសល់គឺត្រូវបញ្ជូនទំពក់ដែលបានបង្កើតទៅសែល - ប្រតិបត្តិករ - របៀបធ្វើវា? Shell-operator ខ្លួនវាមកជារូបភាព Docker ដូច្នេះភារកិច្ចរបស់យើងគឺត្រូវបន្ថែមទំពក់ទៅថតពិសេសនៅក្នុងរូបភាពនេះ៖

FROM flant/shell-operator:v1.0.0-beta.1
ADD my-handler.sh /hooks

អ្វីដែលនៅសល់គឺត្រូវប្រមូលផ្តុំវាហើយរុញវា៖

$ docker build -t registry.example.com/my-operator:v1 .
$ docker push registry.example.com/my-operator:v1

ការប៉ះចុងក្រោយគឺត្រូវដាក់ពង្រាយរូបភាពទៅកាន់ចង្កោម។ ដើម្បីធ្វើដូចនេះសូមសរសេរ ការដាក់ពង្រាយ:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1 # 1
      serviceAccountName: my-operator              # 2

មានចំណុចពីរដែលត្រូវយកចិត្តទុកដាក់៖

1. ការចង្អុលបង្ហាញនៃរូបភាពដែលបានបង្កើតថ្មី;
2. នេះគឺជាសមាសធាតុប្រព័ន្ធដែល (យ៉ាងតិច) ត្រូវការសិទ្ធិក្នុងការជាវព្រឹត្តិការណ៍នៅក្នុង Kubernetes និងដើម្បីបែងចែកការសម្ងាត់ទៅកាន់ namespaces ដូច្នេះយើងបង្កើត ServiceAccount (និងសំណុំនៃច្បាប់) សម្រាប់ទំពក់។

លទ្ធផល - យើងបានដោះស្រាយបញ្ហារបស់យើង។ សាច់ញាតិ សម្រាប់ Kubernetes តាមរបៀបដែលបង្កើតប្រតិបត្តិករសម្រាប់ការបំបែកអាថ៌កំបាំង។

មុខងារសែល-ប្រតិបត្តិករផ្សេងទៀត។

ដើម្បីកំណត់វត្ថុនៃប្រភេទដែលអ្នកបានជ្រើសរើសដែលទំពក់នឹងដំណើរការជាមួយ, ពួកគេអាចត្រូវបានត្រងជ្រើសរើសដោយយោងទៅតាមស្លាកជាក់លាក់ (ឬការប្រើប្រាស់ matchExpressions):

"onKubernetesEvent": [
  {
    "selector": {
      "matchLabels": {
        "foo": "bar",
       },
       "matchExpressions": [
         {
           "key": "allow",
           "operation": "In",
           "values": ["wan", "warehouse"],
         },
       ],
     }
     …
  }
]

បានផ្តល់ យន្តការផ្តាច់មុខដែល - ដោយប្រើតម្រង jq - អនុញ្ញាតឱ្យអ្នកបំលែងវត្ថុ JSON ធំទៅជាវត្ថុតូចៗដែលមានតែប៉ារ៉ាម៉ែត្រទាំងនោះដែលនៅសល់ដែលយើងចង់តាមដានការផ្លាស់ប្តូរ។

នៅពេលដែលទំពក់ត្រូវបានហៅ ប្រតិបត្តិករសែលឆ្លងកាត់វា។ ទិន្នន័យវត្ថុដែលអាចត្រូវបានប្រើសម្រាប់តម្រូវការណាមួយ។

ព្រឹត្តិការណ៍ដែលកេះទំពក់មិនត្រូវបានកំណត់ចំពោះព្រឹត្តិការណ៍ Kubernetes ទេ៖ ប្រតិបត្តិករសែលផ្តល់ការគាំទ្រសម្រាប់ ហៅទំពក់តាមពេលវេលា (ស្រដៀងទៅនឹង crontab នៅក្នុងកម្មវិធីកំណត់ពេលប្រពៃណី) ក៏ដូចជាព្រឹត្តិការណ៍ពិសេសមួយ។ ពេលចាប់ផ្តើម. ព្រឹត្តិការណ៍ទាំងអស់នេះអាចត្រូវបានបញ្ចូលគ្នា និងកំណត់ទៅទំពក់ដូចគ្នា។

និងលក្ខណៈពិសេសពីរទៀតរបស់សែល-ប្រតិបត្តិករ៖

1. វា​ដំណើរការ អសមកាល. ចាប់តាំងពីព្រឹត្តិការណ៍ Kubernetes (ដូចជាវត្ថុដែលកំពុងត្រូវបានបង្កើត) ត្រូវបានទទួល ព្រឹត្តិការណ៍ផ្សេងទៀត (ដូចជាវត្ថុដូចគ្នាដែលកំពុងត្រូវបានលុប) អាចកើតឡើងនៅក្នុងចង្កោម ហើយទំពក់ត្រូវទទួលខុសត្រូវចំពោះបញ្ហានេះ។ ប្រសិនបើទំពក់ត្រូវបានប្រតិបត្តិដោយមានកំហុស នោះតាមលំនាំដើមវានឹងមាន ហៅម្តងទៀត រហូតដល់ការបញ្ចប់ដោយជោគជ័យ (ឥរិយាបថនេះអាចផ្លាស់ប្តូរបាន)។
2. វានាំចេញ ម៉ែត្រ សម្រាប់ Prometheus ដែលអ្នកអាចយល់ថាតើ shell-operator ដំណើរការឬអត់ ស្វែងយល់ពីចំនួនកំហុសសម្រាប់ទំពក់នីមួយៗ និងទំហំជួរបច្ចុប្បន្ន។

ដើម្បីសង្ខេបផ្នែកនៃរបាយការណ៍នេះ៖

ការដំឡើងកម្មវិធីបន្ថែម

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

យើងបានចាប់ផ្តើមធ្វើការជាមួយ Kubernetes ជាមួយនឹងចង្កោមជាច្រើន ដែលជាការបន្ថែមតែមួយគត់គឺ Ingress ។ វាត្រូវការដើម្បីដំឡើងខុសៗគ្នានៅក្នុងចង្កោមនីមួយៗ ហើយយើងបានបង្កើតការកំណត់រចនាសម្ព័ន្ធ YAML ជាច្រើនសម្រាប់បរិស្ថានផ្សេងៗគ្នា៖ ដែកទទេ AWS...

ដោយសារមានចង្កោមកាន់តែច្រើន វាមានការកំណត់រចនាសម្ព័ន្ធកាន់តែច្រើន។ លើសពីនេះ យើងបានកែលម្អការកំណត់រចនាសម្ព័ន្ធទាំងនេះដោយខ្លួនពួកគេផ្ទាល់ ដែលជាលទ្ធផលដែលពួកវាប្រែជាខុសពីធម្មតា៖

ដើម្បី​ដាក់​អ្វី​គ្រប់​យ៉ាង​តាម​លំដាប់ យើង​ចាប់​ផ្ដើម​ដោយ​ស្គ្រីប (install-ingress.sh) ដែលបានយកជាអំណះអំណាងនៃប្រភេទនៃចង្កោមដែលយើងនឹងដាក់ពង្រាយ បានបង្កើតការកំណត់រចនាសម្ព័ន្ធ YAML ចាំបាច់ ហើយបានបញ្ជូនវាទៅ Kubernetes ។

សរុបមក មាគ៌ាបន្ថែមទៀតរបស់យើង និងហេតុផលដែលទាក់ទងនឹងវាមានដូចខាងក្រោម៖

• ដើម្បីធ្វើការជាមួយការកំណត់រចនាសម្ព័ន្ធ YAML ម៉ាស៊ីនគំរូគឺត្រូវបានទាមទារ (នៅដំណាក់កាលដំបូងនេះគឺសាមញ្ញ sed);
• ជាមួយនឹងការកើនឡើងនៃចំនួនចង្កោម តម្រូវការសម្រាប់ការធ្វើបច្ចុប្បន្នភាពដោយស្វ័យប្រវត្តិបានមក (ដំណោះស្រាយដំបូងបំផុតគឺត្រូវដាក់ស្គ្រីបនៅក្នុង Git ធ្វើបច្ចុប្បន្នភាពវាដោយប្រើ cron ហើយដំណើរការវា);
• ស្គ្រីបស្រដៀងគ្នាត្រូវបានទាមទារសម្រាប់ Prometheus (install-prometheus.sh) ទោះបីជាយ៉ាងណាក៏ដោយ វាគួរឱ្យកត់សម្គាល់សម្រាប់ការពិតដែលថាវាត្រូវការទិន្នន័យបញ្ចូលច្រើន ក៏ដូចជាការផ្ទុករបស់ពួកគេ (តាមរបៀបដ៏ល្អ - កណ្តាល និងនៅក្នុងចង្កោម) ហើយទិន្នន័យមួយចំនួន (ពាក្យសម្ងាត់) អាចនឹងត្រូវបានបង្កើតដោយស្វ័យប្រវត្តិ:

  

• ហានិភ័យនៃការដាក់ចេញនូវអ្វីដែលខុសចំពោះការកើនឡើងនៃចំនួនចង្កោមកំពុងកើនឡើងឥតឈប់ឈរ ដូច្នេះយើងដឹងថាអ្នកដំឡើង (ឧ. ស្គ្រីបពីរ៖ សម្រាប់ Ingress និង Prometheus) ដំណាក់កាលគឺត្រូវការជាចាំបាច់ (សាខាជាច្រើននៅក្នុង Git, crons ជាច្រើនដើម្បីធ្វើបច្ចុប្បន្នភាពពួកវានៅក្នុងការដែលត្រូវគ្នា: ចង្កោមដែលមានស្ថេរភាព ឬសាកល្បង);
• с kubectl apply វាបានក្លាយទៅជាការលំបាកក្នុងការធ្វើការជាមួយព្រោះវាមិនមែនជាការប្រកាស និងអាចបង្កើតបានតែវត្ថុប៉ុណ្ណោះ ប៉ុន្តែមិនធ្វើការសម្រេចចិត្តលើស្ថានភាព/លុបពួកវា។
• យើងបាត់មុខងារមួយចំនួនដែលយើងមិនបានអនុវត្តនៅពេលនោះ៖
  • ការគ្រប់គ្រងពេញលេញលើលទ្ធផលនៃការធ្វើបច្ចុប្បន្នភាពចង្កោម,
  • ការកំណត់ដោយស្វ័យប្រវត្តិនៃប៉ារ៉ាម៉ែត្រមួយចំនួន (បញ្ចូលសម្រាប់ស្គ្រីបដំឡើង) ដោយផ្អែកលើទិន្នន័យដែលអាចទទួលបានពីចង្កោម (ការរកឃើញ)
  • ការអភិវឌ្ឍន៍ឡូជីខលរបស់វាក្នុងទម្រង់នៃការរកឃើញជាបន្តបន្ទាប់។

យើងបានអនុវត្តបទពិសោធន៍ដែលប្រមូលបានទាំងអស់នេះនៅក្នុងក្របខ័ណ្ឌនៃគម្រោងផ្សេងទៀតរបស់យើង - addon-operator.

Addon-ប្រតិបត្តិករ

វាត្រូវបានផ្អែកលើ shell-operator ដែលបានរៀបរាប់រួចហើយ។ ប្រព័ន្ធទាំងមូលមើលទៅដូចនេះ៖

ខាងក្រោមនេះត្រូវបានបន្ថែមទៅទំពក់សែល-ប្រតិបត្តិករ៖

• ការផ្ទុកតម្លៃ,
• គំនូសតាងមួកសុវត្ថិភាព,
• សមាសភាគនោះ។ ត្រួតពិនិត្យហាងតម្លៃ ហើយ - ក្នុងករណីមានការផ្លាស់ប្តូរណាមួយ - សុំឱ្យ Helm រមៀលតារាងឡើងវិញ។

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

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

ឥឡូវនេះ នៅពេលដែលមានអ្វីមួយកើតឡើងនៅក្នុង Kubernetes យើងអាចប្រតិកម្មចំពោះវាដោយប្រើទំពក់សកល ហើយផ្លាស់ប្តូរអ្វីមួយនៅក្នុងហាងសកល។ ការផ្លាស់ប្តូរនេះនឹងត្រូវបានកត់សម្គាល់ ហើយនឹងធ្វើឱ្យម៉ូឌុលទាំងអស់នៅក្នុងចង្កោមត្រូវបានដាក់ឱ្យដំណើរការ៖

គ្រោងការណ៍នេះបំពេញតម្រូវការទាំងអស់សម្រាប់ការដំឡើងកម្មវិធីបន្ថែមដែលត្រូវបានបញ្ជាក់ខាងលើ៖

• Helm មានទំនួលខុសត្រូវចំពោះគំរូ និងការប្រកាស។
• បញ្ហានៃការអាប់ដេតដោយស្វ័យប្រវត្តិត្រូវបានដោះស្រាយដោយប្រើទំពក់សាកល ដែលចូលទៅបញ្ជីឈ្មោះតាមកាលវិភាគ ហើយប្រសិនបើវាឃើញរូបភាពប្រព័ន្ធថ្មីនៅទីនោះ រមៀលវាចេញ (ឧ. "ខ្លួនវា")។
• ការរក្សាទុកការកំណត់នៅក្នុងចង្កោមត្រូវបានអនុវត្តដោយប្រើ ConfigMapដែលមានទិន្នន័យចម្បងសម្រាប់ការផ្ទុក (នៅពេលចាប់ផ្តើមពួកវាត្រូវបានផ្ទុកទៅក្នុងកន្លែងផ្ទុក)។
• បញ្ហាជាមួយការបង្កើតពាក្យសម្ងាត់ ការរកឃើញ និងការរកឃើញជាបន្តបន្ទាប់ត្រូវបានដោះស្រាយដោយប្រើទំពក់។
• ដំណាក់កាលត្រូវបានសម្រេចដោយអរគុណចំពោះស្លាកដែល Docker គាំទ្រចេញពីប្រអប់។
• លទ្ធផលត្រូវបានត្រួតពិនិត្យដោយប្រើម៉ែត្រដែលយើងអាចយល់ពីស្ថានភាព។

ប្រព័ន្ធទាំងមូលនេះត្រូវបានអនុវត្តជាទម្រង់ប្រព័ន្ធគោលពីរតែមួយនៅក្នុង Go ដែលត្រូវបានគេហៅថា addon-operator ។ នេះធ្វើឱ្យដ្យាក្រាមមើលទៅសាមញ្ញជាងមុន៖

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

"Flant" ប្រើ addon-operator នៅលើ 70+ ចង្កោម Kubernetes ។ ស្ថានភាព​បច្ចុប្បន្ន - កំណែអាល់ហ្វា. ឥឡូវនេះយើងកំពុងរៀបចំឯកសារដើម្បីចេញផ្សាយបេតា ប៉ុន្តែសម្រាប់ពេលនេះនៅក្នុងឃ្លាំង ឧទាហរណ៍ដែលមានដោយផ្អែកលើមូលដ្ឋានដែលអ្នកអាចបង្កើត addon ផ្ទាល់ខ្លួនរបស់អ្នក។

តើខ្ញុំអាចទទួលបានម៉ូឌុលសម្រាប់ addon-operator នៅឯណា? ការបោះផ្សាយបណ្ណាល័យរបស់យើងគឺជាដំណាក់កាលបន្ទាប់សម្រាប់យើង យើងមានគម្រោងធ្វើវានៅរដូវក្តៅ។

វីដេអូ និងស្លាយ

វីដេអូពីការសម្តែង (~៤៧ នាទី)៖

បទបង្ហាញនៃរបាយការណ៍៖

PS

របាយការណ៍ផ្សេងទៀតនៅលើប្លក់របស់យើង៖

• «មូលដ្ឋានទិន្នន័យ និង Kubernetes» (Dmitry Stolyarov; ថ្ងៃទី 8 ខែវិច្ឆិកាឆ្នាំ 2018 នៅលើ HighLoad ++);
• «ការត្រួតពិនិត្យ និង Kubernetes» (Dmitry Stolyarov; 28 ឧសភា 2018 នៅ RootConf);
• «CI/CD ការអនុវត្តល្អបំផុតជាមួយ Kubernetes និង GitLab» (Dmitry Stolyarov; ថ្ងៃទី 7 ខែវិច្ឆិកាឆ្នាំ 2017 នៅលើ HighLoad ++);
• «បទពិសោធន៍របស់យើងជាមួយ Kubernetes ក្នុងគម្រោងតូចៗ» (Dmitry Stolyarov; ថ្ងៃទី 6 ខែមិថុនា ឆ្នាំ 2017 នៅ RootConf).

អ្នកក៏អាចចាប់អារម្មណ៍លើការបោះពុម្ពខាងក្រោម៖

• «ការណែនាំសែល-ប្រតិបត្តិករ៖ ការបង្កើតប្រតិបត្តិករសម្រាប់ Kubernetes កាន់តែងាយស្រួលជាងមុន"។

ប្រភព: www.habr.com