បទពិសោធន៍របស់យើងក្នុងការអភិវឌ្ឍន៍កម្មវិធីបញ្ជា CSI នៅក្នុង Kubernetes សម្រាប់ Yandex.Cloud

យើងមានសេចក្តីសោមនស្សរីករាយក្នុងការប្រកាសថា Flan កំពុងពង្រីកការរួមចំណែករបស់ខ្លួនចំពោះឧបករណ៍ប្រភពបើកចំហសម្រាប់ Kubernetes ដោយការចេញផ្សាយ កំណែអាល់ហ្វានៃកម្មវិធីបញ្ជា CSI (ចំណុចប្រទាក់ផ្ទុកកុងតឺន័រ) សម្រាប់ Yandex.Cloud ។

ប៉ុន្តែមុនពេលបន្តទៅព័ត៌មានលម្អិតនៃការអនុវត្ត ចូរយើងឆ្លើយសំណួរថាហេតុអ្វីបានជាវាចាំបាច់នៅពេល Yandex មានសេវាកម្មរួចហើយ សេវាកម្មគ្រប់គ្រងសម្រាប់ Kubernetes.

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

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

នៅក្នុងក្រុមហ៊ុនរបស់យើង ចាប់តាំងពីការចាប់ផ្តើមនៃការប្រើប្រាស់ Kubernetes នៅក្នុងការផលិត (ឧទាហរណ៍ជាច្រើនឆ្នាំមកនេះ) យើងបាននិងកំពុងបង្កើតឧបករណ៍ផ្ទាល់ខ្លួនរបស់យើង (deckhouse) ដែលតាមវិធីនេះ យើងក៏មានគម្រោងនឹងធ្វើឱ្យមានក្នុងពេលឆាប់ៗនេះជាគម្រោង Open Source . ដោយមានជំនួយរបស់វា យើងកំណត់រចនាសម្ព័ន្ធ និងកំណត់រចនាសម្ព័ន្ធក្រុមរបស់យើងទាំងអស់ដោយស្មើភាពគ្នា ហើយបច្ចុប្បន្នមានច្រើនជាង 100 នៃពួកវារួចហើយ លើការកំណត់រចនាសម្ព័ន្ធផ្នែករឹងជាច្រើន និងនៅក្នុងសេវាកម្មពពកដែលមានទាំងអស់។

ចង្កោមដែលប្រើ deckhouse មានសមាសធាតុទាំងអស់ដែលចាំបាច់សម្រាប់ប្រតិបត្តិការ៖ តុល្យភាព ការត្រួតពិនិត្យជាមួយតារាងងាយស្រួល រង្វាស់ និងការជូនដំណឹង ការផ្ទៀងផ្ទាត់អ្នកប្រើប្រាស់តាមរយៈអ្នកផ្តល់សេវាខាងក្រៅសម្រាប់ការចូលប្រើផ្ទាំងគ្រប់គ្រងទាំងអស់ ហើយដូច្នេះនៅលើ។ វាគ្មានចំណុចណាក្នុងការដំឡើងចង្កោម "បូមឡើង" បែបនេះនៅក្នុងដំណោះស្រាយដែលបានគ្រប់គ្រងនោះទេ ព្រោះជារឿយៗវាមិនអាចទៅរួច ឬនឹងនាំឱ្យមានតម្រូវការបិទសមាសធាតុពាក់កណ្តាល។

NB៖ នេះជាបទពិសោធន៍របស់យើង ហើយវាពិតជាជាក់លាក់ណាស់។ យើងមិនមានវិធីដែលណែនាំថាអ្នកគ្រប់គ្នាគួរតែដាក់ពង្រាយ Kubernetes clusters ដោយខ្លួនឯងជាជាងប្រើដំណោះស្រាយដែលត្រៀមរួចជាស្រេចនោះទេ។ ដោយវិធីនេះ យើងមិនមានបទពិសោធន៍ពិតប្រាកដក្នុងប្រតិបត្តិការ Kubernetes ពី Yandex ហើយយើងនឹងមិនផ្តល់ការវាយតម្លៃណាមួយនៃសេវាកម្មនេះនៅក្នុងអត្ថបទនេះទេ។

តើវាជាអ្វី ហើយសម្រាប់អ្នកណា?

ដូច្នេះ យើងបាននិយាយរួចមកហើយអំពីវិធីសាស្រ្តទំនើបក្នុងការផ្ទុកនៅក្នុង Kubernetes៖ តើ CSI ដំណើរការយ៉ាងដូចម្តេច? и របៀបដែលសហគមន៍បានមក ទៅនឹងវិធីសាស្រ្តនេះ។

បច្ចុប្បន្ននេះ អ្នកផ្តល់សេវាពពកធំជាច្រើនបានបង្កើតកម្មវិធីបញ្ជាសម្រាប់ការប្រើប្រាស់ថាសពពករបស់ពួកគេជាបរិមាណជាប់លាប់នៅក្នុង Kubernetes ។ ប្រសិនបើអ្នកផ្គត់ផ្គង់មិនមានកម្មវិធីបញ្ជាបែបនេះទេ ប៉ុន្តែមុខងារចាំបាច់ទាំងអស់ត្រូវបានផ្តល់តាមរយៈ API នោះគ្មានអ្វីរារាំងអ្នកពីការអនុវត្តកម្មវិធីបញ្ជាដោយខ្លួនឯងនោះទេ។ នេះជាអ្វីដែលបានកើតឡើងជាមួយ Yandex.Cloud ។

យើងយកជាមូលដ្ឋានសម្រាប់ការអភិវឌ្ឍន៍ កម្មវិធីបញ្ជា CSI សម្រាប់ DigitalOcean cloud និងគំនិតពីរបីពី កម្មវិធីបញ្ជាសម្រាប់ GCPចាប់តាំងពីអន្តរកម្មជាមួយ API នៃពពកទាំងនេះ (Google និង Yandex) មានភាពស្រដៀងគ្នាមួយចំនួន។ ជាពិសេស API និង ជីភីភីនិងនៅ Yandex ត្រឡប់វត្ថុមួយ។ Operation ដើម្បីតាមដានស្ថានភាពនៃប្រតិបត្តិការដែលដំណើរការយូរ (ឧទាហរណ៍ ការបង្កើតថាសថ្មី)។ ដើម្បីធ្វើអន្តរកម្មជាមួយ Yandex.Cloud API សូមប្រើ Yandex.Cloud Go SDK.

លទ្ធផលនៃការងារដែលបានធ្វើ ចេញផ្សាយនៅលើ GitHub ហើយប្រហែលជាមានប្រយោជន៍សម្រាប់អ្នកដែលប្រើប្រាស់ការដំឡើង Kubernetes ផ្ទាល់ខ្លួនរបស់ពួកគេនៅលើម៉ាស៊ីននិម្មិត Yandex.Cloud (ប៉ុន្តែមិនមែនជាចង្កោមដែលបានគ្រប់គ្រងរួចរាល់) ហើយចង់ប្រើ (បញ្ជាទិញ) ថាសតាមរយៈ CSI ។

Реализация

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

បច្ចុប្បន្នអ្នកបើកបរគាំទ្រមុខងារដូចខាងក្រោមៈ

• បញ្ជាទិញថាសនៅក្នុងតំបន់ទាំងអស់នៃចង្កោមយោងទៅតាម topology នៃ nodes ក្នុង cluster;
• ការដកឌីសដែលបានបញ្ជាពីមុនចេញ;
• ផ្លាស់ប្តូរទំហំក្រៅបណ្តាញសម្រាប់ថាស (Yandex.Cloud មិនគាំទ្រ បង្កើនថាសដែលត្រូវបានម៉ោនទៅម៉ាស៊ីននិម្មិត) ។ សម្រាប់ព័ត៌មានអំពីរបៀបដែលអ្នកបើកបរត្រូវកែប្រែ ដើម្បីកែប្រែទំហំដោយមិនមានការឈឺចាប់តាមដែលអាចធ្វើទៅបាន សូមមើលខាងក្រោម។

នៅពេលអនាគត យើងគ្រោងនឹងអនុវត្តការគាំទ្រសម្រាប់ការបង្កើត និងលុបរូបថតថាស។

ការលំបាកចម្បងនិងវិធីដើម្បីយកឈ្នះវា។

កង្វះសមត្ថភាពក្នុងការបង្កើនឌីសក្នុងពេលវេលាជាក់ស្តែងនៅក្នុង Yandex.Cloud API គឺជាការកំណត់ដែលធ្វើឱ្យមានភាពស្មុគស្មាញដល់ប្រតិបត្តិការផ្លាស់ប្តូរទំហំសម្រាប់ PV (កម្រិតសំឡេងជាប់រហូត): ក្នុងករណីនេះ ចាំបាច់ត្រូវបញ្ឈប់កម្មវិធីដែលប្រើថាស។ ហើយនេះអាចបណ្តាលឱ្យកម្មវិធីឈប់ដំណើរការ

នេះបើយោងតាម លក្ខណៈបច្ចេកទេសរបស់ CSIប្រសិនបើឧបករណ៍បញ្ជា CSI រាយការណ៍ថាវាអាចប្តូរទំហំថាសបានតែ "ក្រៅបណ្តាញ" (VolumeExpansion.OFFLINE) បន្ទាប់មកដំណើរការនៃការបង្កើនឌីសគួរតែដំណើរការដូចនេះ៖

ប្រសិនបើកម្មវិធីជំនួយមានតែ VolumeExpansion.OFFLINE សមត្ថភាពពង្រីក និងកម្រិតសំឡេងត្រូវបានបោះពុម្ពផ្សាយ ឬមាននៅលើថ្នាំងនៅពេលនោះ។ ControllerExpandVolume ត្រូវតែហៅតែបន្ទាប់ពី៖

• កម្មវិធីជំនួយមានឧបករណ៍បញ្ជា PUBLISH_UNPUBLISH_VOLUME សមត្ថភាព និង ControllerUnpublishVolume ត្រូវបានហៅដោយជោគជ័យ។

ឬ​ផ្សេង​ទៀត

• កម្មវិធីជំនួយមិនមានឧបករណ៍បញ្ជាទេ។ PUBLISH_UNPUBLISH_VOLUME សមត្ថភាព កម្មវិធីជំនួយមានថ្នាំង STAGE_UNSTAGE_VOLUME សមត្ថភាព, និង NodeUnstageVolume ត្រូវបានបញ្ចប់ដោយជោគជ័យ។

ឬ​ផ្សេង​ទៀត

• កម្មវិធីជំនួយមិនមានឧបករណ៍បញ្ជាទេ។ PUBLISH_UNPUBLISH_VOLUME សមត្ថភាព ឬថ្នាំង STAGE_UNSTAGE_VOLUME សមត្ថភាព, និង NodeUnpublishVolume បានបញ្ចប់ដោយជោគជ័យ។

នេះមានន័យថា អ្នកត្រូវផ្ដាច់ថាសចេញពីម៉ាស៊ីននិម្មិត មុនពេលពង្រីកវា។

ទោះយ៉ាងណាក៏ដោយជាអកុសល ការអនុវត្ត ការបញ្ជាក់ CSI តាមរយៈ sidecars មិនបំពេញតាមតម្រូវការទាំងនេះទេ៖

• នៅក្នុងធុងចំហៀង csi-attacherដែលគួរតែទទួលខុសត្រូវចំពោះវត្តមាននៃគម្លាតដែលត្រូវការរវាងម៉ោន មុខងារនេះមិនត្រូវបានអនុវត្តក្នុងការផ្លាស់ប្តូរទំហំក្រៅបណ្តាញទេ។ ការពិភាក្សាអំពីរឿងនេះត្រូវបានចាប់ផ្តើម នៅទីនេះ.
• តើ​អ្វី​ទៅ​ជា​ធុង​ចំហៀង​ក្នុង​បរិបទ​នេះ? កម្មវិធីជំនួយ CSI ខ្លួនវាមិនធ្វើអន្តរកម្មជាមួយ Kubernetes API ទេ ប៉ុន្តែគ្រាន់តែឆ្លើយតបទៅនឹងការហៅទូរសព្ទ gRPC ដែលផ្ញើទៅវាដោយធុងចំហៀង។ ចុងក្រោយ កំពុងត្រូវបានអភិវឌ្ឍ ដោយសហគមន៍ Kubernetes ។

ក្នុងករណីរបស់យើង (កម្មវិធីជំនួយ CSI) ប្រតិបត្តិការនៃការបង្កើនឌីសមើលទៅដូចនេះ៖

1. យើង​ទទួល​បាន​ការ​ហៅ​ទូរសព្ទ gRPC ControllerExpandVolume;
2. យើងកំពុងព្យាយាមបង្កើនឌីសនៅក្នុង API ប៉ុន្តែយើងទទួលបានកំហុសអំពីភាពមិនអាចទៅរួចនៃប្រតិបត្តិការដោយសារតែថាសត្រូវបានម៉ោន។
3. យើងរក្សាទុកឧបករណ៍កំណត់អត្តសញ្ញាណថាសនៅក្នុងផែនទីដែលមានថាសដែលប្រតិបត្តិការកើនឡើងចាំបាច់ត្រូវអនុវត្ត។ ខាងក្រោមនេះ សម្រាប់ភាពសង្ខេប យើងនឹងហៅផែនទីនេះថាជា volumeResizeRequired;
4. យកផតដែលប្រើថាសចេញដោយដៃ។ Kubernetes នឹងចាប់ផ្តើមវាឡើងវិញ។ ដូច្នេះថាថាសមិនមានពេលវេលាដើម្បីម៉ោន (ControllerPublishVolume) មុនពេលបញ្ចប់ប្រតិបត្តិការបង្កើននៅពេលព្យាយាមម៉ោន យើងពិនិត្យមើលថាឌីសដែលបានផ្តល់ឱ្យនៅតែស្ថិតក្នុង volumeResizeRequired និងត្រឡប់កំហុសមួយ;
5. កម្មវិធីបញ្ជា CSI ព្យាយាមធ្វើប្រតិបត្តិការផ្លាស់ប្តូរទំហំឡើងវិញ។ ប្រសិនបើប្រតិបត្តិការបានជោគជ័យ បន្ទាប់មកយកថាសចេញពី volumeResizeRequired;
6. ដោយសារតែ លេខសម្គាល់ថាសបាត់ពី volumeResizeRequired, ControllerPublishVolume ឆ្លងកាត់ដោយជោគជ័យ ថាសត្រូវបានម៉ោន ផតចាប់ផ្តើម។

អ្វីគ្រប់យ៉ាងមើលទៅសាមញ្ញគ្រប់គ្រាន់ ប៉ុន្តែដូចតែងតែមានកំហុស។ ពង្រីកថាស ឧបករណ៍ផ្លាស់ប្តូរខាងក្រៅដែលក្នុងករណីមានកំហុសកំឡុងពេលប្រតិបត្តិការ ប្រើជួរ ជាមួយនឹងការកើនឡើងអិចស្ប៉ូណង់ស្យែលនៃពេលវេលាអស់ពេលរហូតដល់ 1000 វិនាទី៖

func DefaultControllerRateLimiter() RateLimiter {
  return NewMaxOfRateLimiter(
  NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),
  // 10 qps, 100 bucket size.  This is only for retry speed and its only the overall factor (not per item)
  &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
  )
}

នេះអាចបណ្តាលឱ្យប្រតិបត្តិការពង្រីកថាសត្រូវបានបន្តរយៈពេល 15+ នាទី ហើយដូច្នេះ ផតដែលត្រូវគ្នាមិនអាចប្រើបានទេ។

ជម្រើសតែមួយគត់ដែលងាយស្រួល និងគ្មានការឈឺចាប់បានអនុញ្ញាតឱ្យយើងកាត់បន្ថយពេលវេលារងចាំដ៏មានសក្តានុពលគឺការប្រើប្រាស់កំណែខាងក្រៅរបស់យើងជាមួយនឹងដែនកំណត់ពេលវេលាអតិបរមា។ ក្នុងរយៈពេល 5 វិនាទី:

workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)

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

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

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

• ដាក់ទង់ --allow-privileged កំណត់ទៅតម្លៃ true សម្រាប់ម៉ាស៊ីនមេ API និង kubelet;
• រួមបញ្ចូល --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true សម្រាប់ម៉ាស៊ីនមេ API និង kubelet;
• ការបន្តពូជភ្នំ (ការបន្តពូជភ្នំ) ត្រូវតែបើកនៅលើចង្កោម។ នៅពេលប្រើ Docker ដេមិនត្រូវតែកំណត់រចនាសម្ព័ន្ធដើម្បីអនុញ្ញាតឱ្យម៉ោនដែលបានចែករំលែក។

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

សម្រាប់អ្នកបើកបរដើម្បីធ្វើការអ្នកនឹងត្រូវការដូចខាងក្រោម:

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

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

ការគាំទ្របន្ថែមទៀត

ជាលទ្ធផល យើងចង់កត់សម្គាល់ថា យើងបានអនុវត្តកម្មវិធីបញ្ជា CSI នេះមិនមែនដោយសារបំណងប្រាថ្នាដ៏អស្ចារ្យក្នុងការសរសេរកម្មវិធីដ៏រីករាយនៅក្នុង Go នោះទេ ប៉ុន្តែដោយសារតែតម្រូវការបន្ទាន់នៅក្នុងក្រុមហ៊ុន។ វាហាក់បីដូចជាមិនមានប្រយោជន៍សម្រាប់យើងក្នុងការថែរក្សាការអនុវត្តផ្ទាល់របស់យើងទេ ដូច្នេះប្រសិនបើ Yandex បង្ហាញចំណាប់អារម្មណ៍ និងសម្រេចចិត្តបន្តគាំទ្រអ្នកបើកបរ យើងនឹងរីករាយក្នុងការផ្ទេរឃ្លាំងទៅពួកគេ។

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

PS

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

• «កម្មវិធីជំនួយកម្រិតសំឡេងសម្រាប់ការផ្ទុក Kubernetes៖ ពី Flexvolume ទៅ CSI»
• «យើងយល់ពីចំណុចប្រទាក់ផ្ទុកកុងតឺន័រ (នៅក្នុង Kubernetes និងមិនត្រឹមតែប៉ុណ្ណោះ)»
• «តើវាងាយស្រួល និងងាយស្រួលក្នុងការរៀបចំចង្កោម Kubernetes ទេ? ប្រកាស​ប្រតិបត្តិករ addon»
• «ការពង្រីក និងបន្ថែម Kubernetes (របាយការណ៍ទូទៅ និងវីដេអូ)"។

ប្រភព: www.habr.com