🥇 ដៃរបស់យើងមិនមែនសម្រាប់អផ្សុក៖ ស្ដារចង្កោម Rook ក្នុង K8s

Мы បានប្រាប់រួចហើយរបៀបដែល/ហេតុអ្វីបានជាយើងចូលចិត្ត Rook៖ វាជួយសម្រួលការងារយ៉ាងសំខាន់ជាមួយការផ្ទុកនៅក្នុងចង្កោម Kubernetes ។ ទោះជាយ៉ាងណាក៏ដោយជាមួយនឹងភាពសាមញ្ញនេះមកការលំបាកមួយចំនួន។ យើងសង្ឃឹមថាសម្ភារៈថ្មីនឹងជួយយើងឱ្យយល់កាន់តែច្បាស់ពីភាពស្មុគស្មាញបែបនេះ មុនពេលពួកគេបង្ហាញខ្លួនឯង។

ដើម្បីធ្វើឱ្យវាកាន់តែគួរឱ្យចាប់អារម្មណ៍ក្នុងការអានសូមចាប់ផ្តើមជាមួយ ផលវិបាក បញ្ហាសម្មតិកម្មនៅក្នុងចង្កោម។

"អ្វីៗត្រូវបានបាត់បង់!"

ស្រមៃថាអ្នកបានកំណត់រចនាសម្ព័ន្ធ និងបើកដំណើរការ Rook នៅក្នុងចង្កោម K8s របស់អ្នក វាពេញចិត្តអ្នកជាមួយនឹងការងាររបស់វា ប៉ុន្តែនៅពេល "អស្ចារ្យ" មួយចំនួនកើតឡើងដូចខាងក្រោម៖

ផតថលថ្មីមិនអាចភ្ជាប់រូបភាព RBD ពី Ceph បានទេ។
ក្រុមដូចជា lsblk и df កុំដំណើរការលើថ្នាំង Kubernetes ។ នេះមានន័យថាដោយស្វ័យប្រវត្តិ៖ "មានអ្វីមួយខុសប្រក្រតី" ជាមួយនឹងរូបភាព RBD ដែលបានដំឡើងនៅលើថ្នាំង។ ខ្ញុំមិនអាចអានពួកវាបានទេ ដែលបង្ហាញថាម៉ូនីទ័រមិនអាចប្រើបាន...
បាទ/ចាស មិនមានម៉ូនីទ័រធ្វើការនៅក្នុងចង្កោមទេ។ ជាងនេះទៅទៀត មិនមានសូម្បីតែផតដែលមាន OSD ឬ MGR pods ទេ។

តើផតថលត្រូវបានបើកដំណើរការនៅពេលណា? rook-ceph-operator? មិនយូរប៉ុន្មានគាត់ត្រូវបានគេដាក់ពង្រាយ។ ហេតុអ្វី? Rook-operator បានសម្រេចចិត្តបង្កើត cluster ថ្មីមួយ... តើយើងអាចស្ដារប្រតិបត្តិការរបស់ cluster និងទិន្នន័យនៅក្នុងវាឡើងវិញដោយរបៀបណា?

ជាដំបូង អនុញ្ញាតឱ្យធ្វើដំណើរដ៏វែងឆ្ងាយ និងគួរឱ្យចាប់អារម្មណ៍ ដោយធ្វើការស៊ើបអង្កេតប្រកបដោយការគិតទៅលើ "ខាងក្នុង" នៃ Rook និងការស្ដារឡើងវិញជាជំហានៗនៃសមាសធាតុរបស់វា។ ជាការពិតណាស់ មានវិធីត្រឹមត្រូវខ្លីជាង៖ ការប្រើការបម្រុងទុក។ ដូចដែលអ្នកបានដឹងហើយថា Admin ចែកចេញជាពីរប្រភេទគឺ អ្នកដែលមិនបានធ្វើការ Backup និងអ្នកដែលធ្វើរួចហើយ... ប៉ុន្តែបន្ថែមទៀតលើបញ្ហានេះបន្ទាប់ពីការស៊ើបអង្កេត។

ការអនុវត្តតិចតួច ឬផ្លូវវែងឆ្ងាយ

សូមក្រឡេកមើលជុំវិញ និងស្ដារម៉ូនីទ័រឡើងវិញ

ដូច្នេះសូមក្រឡេកមើលបញ្ជីនៃ ConfigMap៖ មានអ្វីដែលចាំបាច់សម្រាប់ការកក់ទុក rook-ceph-config и rook-config-override. ពួកវាលេចឡើងនៅពេលដាក់ពង្រាយក្រុមដោយជោគជ័យ។

NB៖ នៅក្នុងកំណែថ្មីបន្ទាប់ពីការទទួលយក PR នេះ។, ConfigMaps លែងជាសូចនាករនៃភាពជោគជ័យនៃការដាក់ពង្រាយចង្កោម។

ដើម្បីអនុវត្តសកម្មភាពបន្ថែមទៀត យើងត្រូវការការចាប់ផ្ដើមឡើងវិញយ៉ាងខ្លាំងនៃម៉ាស៊ីនមេទាំងអស់ដែលបានដំឡើងរូបភាព RBD (ls /dev/rbd*) វាត្រូវតែធ្វើតាមរយៈ sysrq (ឬ "នៅលើជើង" ទៅមជ្ឈមណ្ឌលទិន្នន័យ) ។ តម្រូវការនេះត្រូវបានបង្កឡើងដោយភារកិច្ចនៃការអាន់ម៉ោន RBDs ដែលបានម៉ោន ដែលការចាប់ផ្ដើមឡើងវិញតាមស្តង់ដារនឹងមិនដំណើរការទេ (វានឹងមិនជោគជ័យក្នុងការព្យាយាមអាន់ម៉ោនពួកវាជាធម្មតាទេ)។

រោងមហោស្រពចាប់ផ្តើមដោយព្យួរមួយ ហើយចង្កោម Ceph ចាប់ផ្តើមជាមួយនឹងម៉ូនីទ័រ។ សូមក្រឡេកមើលពួកគេ។

Rook ដំឡើងធាតុដូចខាងក្រោមនៅក្នុងផតម៉ូនីទ័រ៖

Volumes:
 rook-ceph-config:
   Type:      ConfigMap (a volume populated by a ConfigMap)
   Name:      rook-ceph-config
 rook-ceph-mons-keyring:
   Type:        Secret (a volume populated by a Secret)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Type:          HostPath (bare host directory volume)
   Path:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Type:          HostPath (bare host directory volume)
   Path:          /var/lib/rook/mon-a/data
Mounts:
  /etc/ceph from rook-ceph-config (ro)
  /etc/ceph/keyring-store/ from rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a from ceph-daemon-data (rw)
  /var/log/ceph from rook-ceph-log (rw)

តោះមើលអ្វីដែលជាអាថ៌កំបាំង rook-ceph-mons-keyring:

kind: Secret
data:
 keyring: LongBase64EncodedString=

យើងឌិកូដ និងទទួលបានសោធម្មតាដែលមានសិទ្ធិសម្រាប់អ្នកគ្រប់គ្រង និងអ្នកត្រួតពិនិត្យ៖

[mon.]
       key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
       caps mon = "allow *"
[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

ចូរយើងចងចាំ។ ឥឡូវនេះសូមក្រឡេកមើលសោរដោយសម្ងាត់ rook-ceph-admin-keyring:

kind: Secret
data:
 keyring: anotherBase64EncodedString=

តើមានអ្វីនៅក្នុងនោះ?

[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

ដូចគ្នា តោះមើលបន្ថែមទៀត... នៅទីនេះ ជាឧទាហរណ៍ អាថ៌កំបាំង rook-ceph-mgr-a-keyring:

[mgr.a]
       key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       caps mon = "allow *"
       caps mds = "allow *"
       caps osd = "allow *"

យើងបញ្ចប់ការស្វែងរកអាថ៌កំបាំងមួយចំនួនទៀតនៅក្នុង ConfigMap rook-ceph-mon:

kind: Secret
data:
 admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
 cluster-name: a3ViZS1yb29r
 fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg==
 mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==

ហើយនេះគឺជាបញ្ជីដំបូងដែលមាន keyrings ដែលអាថ៌កំបាំងទាំងអស់ដែលបានពិពណ៌នាខាងលើបានមកពី។

ដូចដែលត្រូវបានគេស្គាល់ (សូមមើល dataDirHostPath в ឯកសារ) Rook រក្សាទុកទិន្នន័យបែបនេះជាពីរកន្លែង។ ដូច្នេះ ចូរយើងចូលទៅកាន់ nodes ដើម្បីមើល keyrings ដែលមានទីតាំងនៅក្នុង directories ដែលត្រូវបានម៉ោននៅក្នុង pods ជាមួយនឹង monitors និង OSDs។ ដើម្បីធ្វើដូចនេះយើងរកឃើញនៅលើថ្នាំង /var/lib/rook/mon-a/data/keyring ហើយយើងនឹងឃើញ៖

# cat /var/lib/rook/mon-a/data/keyring
[mon.]
       key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg==
       caps mon = "allow *"

ភ្លាមៗ នៅទីនេះអាថ៌កំបាំងប្រែទៅជាខុសគ្នា - មិនដូចនៅក្នុង ConfigMap ទេ។

ចុះអ្នកគ្រប់គ្រងសោរវិញ? យើងក៏មានវាផងដែរ៖

# cat /var/lib/rook/kube-rook/client.admin.keyring
[client.admin]
       key = AXAbR19d8GGSMUBN+FyYwEqGI1aZizGcJlHMLgx= 
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

នេះគឺជាកន្លែងដែលបញ្ហាស្ថិតនៅ។ ភាពមិនប្រក្រតីមួយចំនួនបានកើតឡើង៖ ចង្កោមត្រូវបានបង្កើតឡើងវិញ... ប៉ុន្តែការពិតវាមិនមែនទេ។

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

យកសោពីម៉ូនីទ័រពីឯកសារ /var/lib/rook/mon-a/data/keyring (ឬពីការបម្រុងទុក);
ផ្លាស់ប្តូរសោដោយសម្ងាត់ rook-ceph-mons-keyring;
ចុះឈ្មោះ keyring ពីអ្នកគ្រប់គ្រង និងម៉ូនីទ័រក្នុង ConfigMap rook-ceph-mon;
ដោះឧបករណ៍បញ្ជា pod ជាមួយម៉ូនីទ័រ។

អព្ភូតហេតុនឹងមិនយូរប៉ុន្មានទេក្នុងការមកដល់: ម៉ូនីទ័រនឹងលេចឡើងហើយចាប់ផ្តើម។ ហ៊ឺ ការចាប់ផ្តើមមួយត្រូវបានធ្វើឡើង!

តោះស្តារ OSD ឡើងវិញ

តោះទៅផត rook-operator៖ បញ្ហាប្រឈម ceph mon dump បង្ហាញថាម៉ូនីទ័រទាំងអស់នៅនឹងកន្លែង និង ceph -s - ថាពួកគេស្ថិតនៅក្នុងកូរ៉ុម។ ទោះយ៉ាងណាក៏ដោយ ប្រសិនបើអ្នកក្រឡេកមើលដើមឈើ OSD (ceph osd tree) យើងនឹងឃើញអ្វីដែលចម្លែកនៅក្នុងវា៖ OSDs បានចាប់ផ្តើមលេចឡើង ប៉ុន្តែពួកវានៅទទេ។ វាប្រែថាពួកគេក៏ត្រូវការដើម្បីស្តារឡើងវិញដូចម្ដេចដែរ។ ប៉ុន្តែធ្វើយ៉ាងម៉េច?

ក្នុងពេលនេះ ConfigMaps ផ្ទុកនូវអ្វីដែលយើងត្រូវការច្រើន។ rook-ceph-config и rook-config-overrideក៏ដូចជា ConfigMaps ជាច្រើនទៀតដែលមានឈ្មោះដូចជា rook-ceph-osd-$nodename-config. តោះមើលពួកគេ៖

kind: ConfigMap
data:
 osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'

អ្វីៗគឺខុស គ្រប់យ៉ាងលាយឡំ!

ចូរធ្វើមាត្រដ្ឋាន pods ប្រតិបត្តិករទៅសូន្យ លុប pods ដាក់ពង្រាយដែលបានបង្កើតចេញពី OSD ហើយជួសជុល ConfigMaps ទាំងនេះ។ ប៉ុន្តែកន្លែងដែលត្រូវយកវា? ត្រឹមត្រូវ។ ផែនទី OSD តាមថ្នាំង?

ចូរយើងព្យាយាមជីកចូលទៅក្នុងថតម្តងទៀត /mnt/osd[1-2] នៅ knots - ដោយសង្ឃឹមថាយើងអាចចាប់យកអ្វីមួយនៅទីនោះ។
នៅក្នុងកាតាឡុក /mnt/osd1 មាន 2 ថតរង៖ osd0 и osd16. លេខចុងក្រោយគឺពិតជា ID ដែលត្រូវបានចង្អុលបង្ហាញនៅក្នុង ConfigMap (16)?
តោះពិនិត្យមើលទំហំហើយមើល osd0 ច្រើនទៀត osd16.

យើងឈានដល់ការសន្និដ្ឋាននោះ។ osd0 - នេះគឺជា OSD ដែលត្រូវការដែលត្រូវបានចង្អុលបង្ហាញ /mnt/osd1 នៅក្នុង ConfigMap (បន្ទាប់ពីទាំងអស់យើងប្រើ ថតដែលមានមូលដ្ឋានលើ osd.)

មួយជំហានម្តងៗ យើងពិនិត្យថ្នាំងទាំងអស់ និងកែសម្រួល ConfigMaps ។ បន្ទាប់ពីការណែនាំទាំងអស់ អ្នកអាចបើកដំណើរការប្រតិបត្តិករ pod Rook ហើយអានកំណត់ហេតុរបស់វា។ ហើយអ្វីគ្រប់យ៉ាងអំពីពួកគេគឺអស្ចារ្យណាស់:

ខ្ញុំជាប្រតិបត្តិករចង្កោម;
ខ្ញុំបានរកឃើញថាសនៅលើថ្នាំង;
ខ្ញុំបានរកឃើញម៉ូនីទ័រ;
ម៉ូនីទ័របានក្លាយជាមិត្ត, i.e. បានបង្កើតកូរ៉ុមមួយ;
ខ្ញុំចាប់ផ្តើមដាក់ពង្រាយ OSD...

តោះចូលទៅក្នុងផ្នែកប្រតិបត្តិករ Rook ម្តងទៀត ហើយពិនិត្យមើលភាពរឹងមាំរបស់ចង្កោម... បាទ យើងខុសបន្តិចជាមួយនឹងការសន្និដ្ឋានអំពីឈ្មោះ OSD នៅលើថ្នាំងមួយចំនួន! គ្មានបញ្ហាទេ៖ យើងបានកែ ConfigMaps ម្តងទៀត លុបថតដែលមិនចាំបាច់ចេញពី OSDs ថ្មី ហើយមកដល់ស្ថានភាពដែលរង់ចាំជាយូរមកហើយ HEALTH_OK!

តោះមកមើលរូបភាពក្នុងអាងទឹកទាំងអស់គ្នា៖

# rbd ls -p kube
pvc-9cfa2a98-b878-437e-8d57-acb26c7118fb
pvc-9fcc4308-0343-434c-a65f-9fd181ab103e
pvc-a6466fea-bded-4ac7-8935-7c347cff0d43
pvc-b284d098-f0fc-420c-8ef1-7d60e330af67
pvc-b6d02124-143d-4ce3-810f-3326cfa180ae
pvc-c0800871-0749-40ab-8545-b900b83eeee9
pvc-c274dbe9-1566-4a33-bada-aabeb4c76c32
…

អ្វីគ្រប់យ៉ាងគឺនៅនឹងកន្លែង - ចង្កោមត្រូវបានរក្សាទុក!

ខ្ញុំខ្ជិលធ្វើការបម្រុងទុក ឬវិធីរហ័ស

ប្រសិនបើការបម្រុងទុកត្រូវបានបង្កើតឡើងសម្រាប់ Rook នោះនីតិវិធីនៃការស្តារឡើងវិញកាន់តែសាមញ្ញ ហើយដំណើរការទៅដូចខាងក្រោម៖

យើងធ្វើមាត្រដ្ឋានដាក់ពង្រាយប្រតិបត្តិករ Rook ទៅសូន្យ។
យើងដកការដាក់ពង្រាយទាំងអស់ លើកលែងតែប្រតិបត្តិករ Rook ។
យើងស្ដារអាថ៌កំបាំង និង ConfigMap ទាំងអស់ពីការបម្រុងទុក។
ការស្ដារមាតិកានៃថត /var/lib/rook/mon-* នៅលើថ្នាំង;
យើងស្តារ (ប្រសិនបើអ្នកភ្លាមៗបាត់បង់) CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
ចូរធ្វើមាត្រដ្ឋានឡើងវិញនូវប្រតិបត្តិករ Rook នៃការដាក់ពង្រាយទៅជា 1 ។

ជំនួយមានប្រយោជន៍

ធ្វើការបម្រុងទុក!

ហើយដើម្បីជៀសវាងស្ថានភាពនៅពេលដែលអ្នកត្រូវការស្តារឡើងវិញពីពួកគេ:

មុនពេលដំណើរការទ្រង់ទ្រាយធំជាមួយចង្កោម ដែលពាក់ព័ន្ធនឹងការចាប់ផ្ដើមម៉ាស៊ីនមេឡើងវិញ សូមធ្វើមាត្រដ្ឋានប្រតិបត្តិករ Rook ដល់សូន្យ ដើម្បីកុំឱ្យវាធ្វើរឿងដែលមិនចាំបាច់។
ទៅកាន់អ្នកឃ្លាំមើលជាមុន បន្ថែម nodeAffinity.
យកចិត្តទុកដាក់ចំពោះបឋម កំណត់ការអស់ពេល ROOK_MON_HEALTHCHECK_INTERVAL и ROOK_MON_OUT_TIMEOUT.

ជំនួសឱ្យការសន្និដ្ឋានមួយ

វាគ្មានចំណុចអ្វីទេក្នុងការជជែកវែកញែកថា Rook ដែលជា "ស្រទាប់" បន្ថែម (នៅក្នុងគ្រោងការណ៍ទាំងមូលនៃការរៀបចំការផ្ទុកនៅក្នុង Kubernetes) ទាំងការសម្រួលបានច្រើន និងបន្ថែមភាពស្មុគស្មាញថ្មី និងបញ្ហាសក្តានុពលនៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធ។ រឿងតែមួយគត់ដែលត្រូវធ្វើគឺធ្វើឱ្យមានតុល្យភាព និងជាជម្រើសដែលមានការជូនដំណឹងរវាងហានិភ័យទាំងនេះ ហើយនៅលើដៃម្ខាង និងអត្ថប្រយោជន៍ដែលការសម្រេចចិត្តនាំមកនៅក្នុងករណីជាក់លាក់របស់អ្នក។

ដោយវិធីនេះថ្មីៗនេះនៅក្នុងឯកសារ Rook ត្រូវបានបន្ថែម ផ្នែក "ទទួលយកចង្កោម Rook Ceph ដែលមានស្រាប់ចូលទៅក្នុងចង្កោម Kubernetes ថ្មី"។ វាពិពណ៌នាលម្អិតបន្ថែមទៀតអំពីអ្វីដែលត្រូវធ្វើ ដើម្បីផ្លាស់ទីទិន្នន័យដែលមានស្រាប់ទៅកាន់ចង្កោម Kubernetes ថ្មី ឬដើម្បីស្ដារប្រតិបត្តិការនៃចង្កោមដែលបានដួលរលំដោយហេតុផលមួយឬផ្សេងទៀត។