តើ Kafka នៅលើ Kubernetes ល្អទេ?

ជំរាបសួរ, Habr!

នៅពេលមួយយើងជាអ្នកដំបូងដែលណែនាំប្រធានបទទៅកាន់ទីផ្សាររុស្ស៊ី កាកាកា។ និងបន្ត បទ សម្រាប់ការអភិវឌ្ឍន៍របស់វា។ ជាពិសេសយើងបានរកឃើញប្រធានបទនៃអន្តរកម្មរវាង Kafka និង Kubernetes. អាចសង្កេតបាន (និងប្រុងប្រយ័ត្ន) អត្ថបទ ប្រធានបទនេះត្រូវបានបោះពុម្ពផ្សាយនៅលើប្លុក Confluent ត្រឡប់មកវិញនៅក្នុងខែតុលាឆ្នាំមុនក្រោមការនិពន្ធរបស់ Gwen Shapira ។ ថ្ងៃនេះ យើងចង់ទាញចំណាប់អារម្មណ៍របស់អ្នកទៅអត្ថបទថ្មីមួយទៀតពីខែមេសា ដោយ Johann Gyger ដែលទោះបីជាមិនមានសញ្ញាសួរនៅក្នុងចំណងជើងក៏ដោយ ក៏ពិនិត្យមើលប្រធានបទក្នុងលក្ខណៈសំខាន់ជាង ដោយភ្ជាប់មកជាមួយអត្ថបទដែលមានតំណភ្ជាប់គួរឱ្យចាប់អារម្មណ៍។ សូមអភ័យទោសឱ្យពួកយើងនូវការបកប្រែដោយឥតគិតថ្លៃនៃ "ស្វាវឹកវរ" ប្រសិនបើអ្នកអាចធ្វើបាន!

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

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

ម្យ៉ាងវិញទៀត Kafka ដើរតួជាមូលដ្ឋានទិន្នន័យចែកចាយ។ ដូច្នេះនៅពេលធ្វើការអ្នកត្រូវដោះស្រាយជាមួយរដ្ឋហើយវាមានទម្ងន់ធ្ងន់ជាងសេវាមីក្រូ។ Kubernetes គាំទ្រការផ្ទុករដ្ឋ ប៉ុន្តែដូចដែល Kelsey Hightower ចង្អុលបង្ហាញនៅក្នុងធ្វីតពីរ ពួកគេគួរតែត្រូវបានដោះស្រាយដោយប្រុងប្រយ័ត្ន៖

មនុស្សមួយចំនួនមានអារម្មណ៍ថា ប្រសិនបើអ្នករមៀល Kubernetes ទៅក្នុងបន្ទុកការងារដែលមានលក្ខណៈរដ្ឋ វានឹងក្លាយជាមូលដ្ឋានទិន្នន័យដែលគ្រប់គ្រងយ៉ាងពេញលេញដែលប្រជែងនឹង RDS ។ នេះ​គឺ​ខុស។ ប្រហែលជា ប្រសិនបើអ្នកប្រឹងប្រែងគ្រប់គ្រាន់ បន្ថែមសមាសធាតុបន្ថែម និងទាក់ទាញក្រុមវិស្វករ SRE អ្នកនឹងអាចបង្កើត RDS នៅលើ Kubernetes បាន។

ខ្ញុំតែងតែណែនាំថាអ្នកគ្រប់គ្នាអនុវត្តការប្រុងប្រយ័ត្នខ្លាំងនៅពេលដំណើរការបន្ទុកការងារនៅលើ Kubernetes ។ មនុស្សភាគច្រើនដែលសួរថា "តើខ្ញុំអាចដំណើរការបន្ទុកការងារនៅលើ Kubernetes បានទេ" មិនមានបទពិសោធន៍គ្រប់គ្រាន់ជាមួយ Kubernetes ហើយជារឿយៗជាមួយនឹងបន្ទុកការងារដែលពួកគេកំពុងសួរ។

ដូច្នេះ តើអ្នកគួរដំណើរការ Kafka នៅលើ Kubernetes ទេ? សំណួរប្រឆាំង៖ តើ Kafka នឹងដំណើរការប្រសើរជាងបើគ្មាន Kubernetes ទេ? នោះហើយជាមូលហេតុដែលខ្ញុំចង់គូសបញ្ជាក់នៅក្នុងអត្ថបទនេះអំពីរបៀបដែល Kafka និង Kubernetes បំពេញគ្នាទៅវិញទៅមក ហើយតើភាពលំបាកអ្វីខ្លះអាចមកជាមួយការបញ្ចូលគ្នារវាងពួកគេ។

ពេលវេលានៃការបញ្ចប់

ចូរនិយាយអំពីរឿងជាមូលដ្ឋាន - បរិយាកាសពេលដំណើរការដោយខ្លួនឯង។

ដំណើរការ

ឈ្មួញកណ្តាល Kafka គឺងាយស្រួលប្រើ CPU ។ TLS អាចណែនាំអំពីការចំណាយលើសមួយចំនួន។ ទោះជាយ៉ាងណាក៏ដោយ អតិថិជន Kafka ប្រហែលជាស៊ីភីយូច្រើន ប្រសិនបើពួកគេប្រើការអ៊ិនគ្រីប ប៉ុន្តែវាមិនប៉ះពាល់ដល់ឈ្មួញកណ្តាលទេ។

អង្គចងចាំ

ឈ្មួញកណ្តាល Kafka ស៊ីការចងចាំ។ ទំហំផ្ទុក JVM ជាធម្មតាត្រូវបានកំណត់ត្រឹម 4-5 GB ប៉ុន្តែអ្នកក៏នឹងត្រូវការអង្គចងចាំប្រព័ន្ធច្រើនផងដែរ ចាប់តាំងពី Kafka ប្រើឃ្លាំងសម្ងាត់ទំព័រយ៉ាងខ្លាំង។ នៅក្នុង Kubernetes កំណត់ធនធានកុងតឺន័រ និងដែនកំណត់សំណើស្របតាម។

ឃ្លាំងផ្ទុកទិន្នន័យ

ការផ្ទុកទិន្នន័យនៅក្នុងកុងតឺន័រគឺមានភាពច្របូកច្របល់ - ទិន្នន័យត្រូវបានបាត់បង់នៅពេលចាប់ផ្តើមឡើងវិញ។ សម្រាប់ទិន្នន័យ Kafka អ្នកអាចប្រើកម្រិតសំឡេង emptyDirហើយឥទ្ធិពលនឹងស្រដៀងគ្នា៖ ទិន្នន័យឈ្មួញកណ្តាលរបស់អ្នកនឹងបាត់បង់បន្ទាប់ពីបញ្ចប់។ សាររបស់អ្នកនៅតែអាចត្រូវបានរក្សាទុកនៅលើឈ្មួញកណ្តាលផ្សេងទៀតជាការចម្លង។ ដូច្នេះបន្ទាប់ពីការចាប់ផ្តើមឡើងវិញ ឈ្មួញកណ្តាលដែលបរាជ័យត្រូវតែចម្លងទិន្នន័យទាំងអស់ជាមុនសិន ហើយដំណើរការនេះអាចចំណាយពេលច្រើន។

នេះជាមូលហេតុដែលអ្នកគួរតែប្រើការផ្ទុកទិន្នន័យរយៈពេលវែង។ អនុញ្ញាតឱ្យវាជាការផ្ទុករយៈពេលវែងដែលមិនមែនជាមូលដ្ឋានជាមួយប្រព័ន្ធឯកសារ XFS ឬច្បាស់ជាងនេះទៅទៀត ext4 ។ កុំប្រើ NFS ។ ខ្ញុំ​ព្រមាន​អ្នក។ កំណែ NFS v3 ឬ v4 នឹងមិនដំណើរការទេ។ សរុបមក ឈ្មួញកណ្តាល Kafka នឹងគាំងប្រសិនបើវាមិនអាចលុបថតទិន្នន័យបានទេ ដោយសារបញ្ហា "ប្តូរឈ្មោះល្ងង់" នៅក្នុង NFS ។ ប្រសិនបើខ្ញុំមិនទាន់បានបញ្ចុះបញ្ចូលអ្នកនៅឡើយទេ សូមប្រុងប្រយ័ត្នបំផុត។ អានអត្ថបទនេះ។. កន្លែងផ្ទុកទិន្នន័យគួរតែមិនមែនជាមូលដ្ឋាន ដូច្នេះ Kubernetes អាចជ្រើសរើសថ្នាំងថ្មីបានកាន់តែមានភាពបត់បែនបន្ទាប់ពីចាប់ផ្តើមឡើងវិញ ឬផ្លាស់ប្តូរទីតាំង។

បណ្តាញ

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

ការកំណត់​រចនាសម្ព័ន្ធ

ការបង្ហាញជាទៀងទាត់

គេហទំព័រ Kubernetes មាន ការណែនាំល្អណាស់ អំពីរបៀបកំណត់រចនាសម្ព័ន្ធ ZooKeeper ដោយប្រើ manifests ។ ដោយសារ ZooKeeper គឺជាផ្នែកមួយនៃ Kafka នេះគឺជាកន្លែងដ៏ល្អមួយដើម្បីចាប់ផ្តើមស្គាល់ពីគំនិត Kubernetes ដែលអនុវត្តនៅទីនេះ។ នៅពេលដែលអ្នកយល់ពីវា អ្នកអាចប្រើគោលគំនិតដូចគ្នាជាមួយនឹងចង្កោម Kafka ។

• ក្រោម។៖ ផតគឺជាឯកតាដែលអាចដាក់ពង្រាយបានតូចបំផុតនៅក្នុង Kubernetes ។ ផតមានផ្ទុកបន្ទុកការងាររបស់អ្នក ហើយផតផ្ទាល់ត្រូវនឹងដំណើរការនៅក្នុងចង្កោមរបស់អ្នក។ ផតមានធុងមួយ ឬច្រើន។ ម៉ាស៊ីនមេ ZooKeeper នីមួយៗនៅក្នុងក្រុម ហើយឈ្មួញកណ្តាលនីមួយៗនៅក្នុងចង្កោម Kafka នឹងដំណើរការនៅក្នុងផតដាច់ដោយឡែកមួយ។
• សំណុំ​រដ្ឋ៖ StatefulSet គឺជាវត្ថុ Kubernetes ដែលគ្រប់គ្រងបន្ទុកការងារដែលមានរដ្ឋច្រើន ហើយបន្ទុកការងារបែបនេះទាមទារការសម្របសម្រួល។ StatefulSets ផ្តល់ការធានាទាក់ទងនឹងការបញ្ជាទិញផត និងភាពប្លែករបស់វា។
• សេវាកម្មគ្មានក្បាល៖ សេវាកម្មអនុញ្ញាតឱ្យអ្នកដក pods ចេញពីអតិថិជនដោយប្រើឈ្មោះឡូជីខល។ Kubernetes ក្នុងករណីនេះទទួលខុសត្រូវចំពោះតុល្យភាពបន្ទុក។ ទោះជាយ៉ាងណាក៏ដោយ នៅពេលដំណើរការបន្ទុកការងារដែលមានសភាពដូចជា ZooKeeper និង Kafka អតិថិជនត្រូវទាក់ទងជាមួយឧទាហរណ៍ជាក់លាក់មួយ។ នេះគឺជាកន្លែងដែលសេវាគ្មានក្បាលមកងាយស្រួល៖ ក្នុងករណីនេះអតិថិជននឹងនៅតែមានឈ្មោះឡូជីខល ប៉ុន្តែអ្នកនឹងមិនចាំបាច់ទាក់ទងផតដោយផ្ទាល់ទេ។
• បរិមាណផ្ទុករយៈពេលវែង៖ បរិមាណទាំងនេះគឺចាំបាច់ដើម្បីកំណត់រចនាសម្ព័ន្ធការផ្ទុកជាប់លាប់ប្លុកដែលមិនមែនជាមូលដ្ឋានដែលបានរៀបរាប់ខាងលើ។

នៅលើ យូលៀន ផ្តល់នូវសំណុំទូលំទូលាយនៃការបង្ហាញដើម្បីជួយអ្នកចាប់ផ្តើមជាមួយ Kafka នៅលើ Kubernetes ។

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

Helm គឺជាកម្មវិធីគ្រប់គ្រងកញ្ចប់សម្រាប់ Kubernetes ដែលអាចប្រៀបធៀបទៅនឹងកម្មវិធីគ្រប់គ្រងកញ្ចប់ OS ដូចជា yum, apt, Homebrew ឬ Chocolatey ។ វាធ្វើឱ្យមានភាពងាយស្រួលក្នុងការដំឡើងកញ្ចប់កម្មវិធីដែលបានកំណត់ជាមុនដែលបានពិពណ៌នានៅក្នុងតារាង Helm ។ គំនូសតាង Helm ដែលបានជ្រើសរើសយ៉ាងល្អធ្វើឱ្យកិច្ចការដ៏លំបាកនៃរបៀបកំណត់ប៉ារ៉ាម៉ែត្រទាំងអស់ឱ្យបានត្រឹមត្រូវដើម្បីប្រើ Kafka នៅលើ Kubernetes ងាយស្រួល។ មានដ្យាក្រាម Kafka ជាច្រើន៖ កន្លែងផ្លូវការមានទីតាំងនៅ នៅក្នុងលក្ខខណ្ឌ incubatorមានមួយមកពី ច្របូកច្របល់, មួយបន្ថែមទៀត - ពី Bitnami.

ប្រតិបត្តិករ

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

នៅក្នុងបញ្ជី ប្រតិបត្តិករដ៏អស្ចារ្យ ប្រតិបត្តិករពីរសម្រាប់ Kafka ត្រូវបានលើកឡើង។ ម្នាក់​ក្នុង​ចំ​នោម​ពួកគេ - ស្ទ្រីមហ្សី. ជាមួយនឹង Strimzi វាងាយស្រួលក្នុងការធ្វើឱ្យក្រុម Kafka របស់អ្នកឡើង ហើយដំណើរការក្នុងរយៈពេលប៉ុន្មាននាទី។ ស្ទើរតែគ្មានការកំណត់រចនាសម្ព័ន្ធត្រូវបានទាមទារ លើសពីនេះ ប្រតិបត្តិករខ្លួនវាផ្តល់នូវលក្ខណៈពិសេសល្អមួយចំនួន ឧទាហរណ៍ ការអ៊ិនគ្រីប TLS ពីចំណុចមួយទៅចំណុចនៅក្នុងចង្កោម។ Confluent ក៏ផ្តល់ផងដែរ។ ប្រតិបត្តិករផ្ទាល់ខ្លួន.

ផលិតភាព

វាមានសារៈសំខាន់ណាស់ក្នុងការសាកល្បងដំណើរការដោយធ្វើការប្រៀបធៀបឧទាហរណ៍ Kafka របស់អ្នក។ ការធ្វើតេស្តបែបនេះនឹងជួយអ្នករកឃើញការស្ទះសក្តានុពលមុនពេលមានបញ្ហាកើតឡើង។ ជាសំណាងល្អ Kafka ផ្តល់ឧបករណ៍សាកល្បងដំណើរការពីររួចហើយ៖ kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. ប្រើពួកវាយ៉ាងសកម្ម។ សម្រាប់ជាឯកសារយោង អ្នកអាចយោងទៅលើលទ្ធផលដែលបានពិពណ៌នានៅក្នុង ប្រកាសនេះ។ Jay Kreps ឬផ្តោតលើ ការពិនិត្យឡើងវិញនេះ។ Amazon MSK ដោយ Stéphane Maarek។

ប្រតិបត្តិការ

ការត្រួតពិនិត្យ

តម្លាភាពនៅក្នុងប្រព័ន្ធគឺមានសារៈសំខាន់ខ្លាំងណាស់ - បើមិនដូច្នេះទេអ្នកនឹងមិនយល់ពីអ្វីដែលកំពុងកើតឡើងនៅក្នុងវាទេ។ សព្វ​ថ្ងៃ​នេះ​មាន​កញ្ចប់​ឧបករណ៍​រឹង​មួយ​ដែល​ផ្ដល់​ការ​ត្រួត​ពិនិត្យ​ផ្អែក​តាម​ម៉ែត្រ​ក្នុង​រចនាប័ទ្ម​ដើម​នៃ​ពពក។ ឧបករណ៍ពេញនិយមពីរសម្រាប់គោលបំណងនេះគឺ Prometheus និង Grafana ។ Prometheus អាចប្រមូលម៉ែត្រពីដំណើរការ Java ទាំងអស់ (Kafka, Zookeeper, Kafka Connect) ដោយប្រើឧបករណ៍នាំចេញ JMX - តាមវិធីសាមញ្ញបំផុត។ ប្រសិនបើអ្នកបន្ថែមម៉ែត្រ cAdvisor អ្នកអាចយល់កាន់តែច្បាស់អំពីរបៀបដែលធនធានត្រូវបានប្រើប្រាស់នៅក្នុង Kubernetes ។

Strimzi មានឧទាហរណ៍ដ៏ងាយស្រួលនៃផ្ទាំងគ្រប់គ្រង Grafana សម្រាប់ Kafka ។ វា​មើល​ឃើញ​ម៉ែត្រ​សំខាន់ៗ ឧទាហរណ៍​អំពី​ផ្នែក​ដែល​មិន​បាន​ចម្លង ឬ​ផ្នែក​ដែល​គ្មាន​អ៊ីនធឺណិត។ អ្វីគ្រប់យ៉ាងគឺច្បាស់ណាស់នៅទីនោះ។ ម៉ែត្រទាំងនេះត្រូវបានបំពេញបន្ថែមដោយការប្រើប្រាស់ធនធាន និងព័ត៌មានអំពីការអនុវត្ត ក៏ដូចជាសូចនាករស្ថេរភាព។ ដូច្នេះ​អ្នក​ទទួល​បាន​ការ​ត្រួតពិនិត្យ​ចង្កោម Kafka មូលដ្ឋាន​ដោយ​គ្មាន​អ្វី​សោះ!

ប្រភព: streamzi.io/docs/master/#kafka_dashboard

វាជាការល្អក្នុងការបំពេញបន្ថែមទាំងអស់នេះជាមួយនឹងការត្រួតពិនិត្យអតិថិជន (ម៉ែត្រនៅលើអ្នកប្រើប្រាស់ និងអ្នកផលិត) ក៏ដូចជាការត្រួតពិនិត្យភាពយឺតយ៉ាវ (សម្រាប់វាមាន Burrow) និងការត្រួតពិនិត្យពីចុងដល់ចប់ - សម្រាប់ការប្រើប្រាស់នេះ។ ម៉ូនីទ័រ Kafka.

ការកាប់ឈើ

ការកត់ត្រាគឺជាកិច្ចការសំខាន់មួយទៀត។ ត្រូវប្រាកដថាធុងទាំងអស់នៅក្នុងការដំឡើង Kafka របស់អ្នកត្រូវបានចូល stdout и stderrហើយត្រូវប្រាកដថា ចង្កោម Kubernetes របស់អ្នកប្រមូលផ្តុំកំណត់ហេតុទាំងអស់ទៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធនៃការកត់ត្រាកណ្តាល ឧ. Elasticsearch.

ការត្រួតពិនិត្យមុខងារ

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

កំពុងចេញផ្សាយបច្ចុប្បន្នភាព

StatefulSets គាំទ្រការធ្វើបច្ចុប្បន្នភាពដោយស្វ័យប្រវត្តិ៖ ប្រសិនបើអ្នកជ្រើសរើសយុទ្ធសាស្ត្រ RollingUpdate នីមួយៗនៅក្រោម Kafka នឹងត្រូវបានអាប់ដេតជាវេន។ តាមវិធីនេះ ពេលវេលារងចាំអាចត្រូវបានកាត់បន្ថយមកត្រឹមសូន្យ។

ការធ្វើមាត្រដ្ឋាន

ការធ្វើមាត្រដ្ឋានចង្កោម Kafka មិនមែនជាកិច្ចការងាយស្រួលនោះទេ។ ទោះជាយ៉ាងណាក៏ដោយ Kubernetes ធ្វើឱ្យវាមានភាពងាយស្រួលក្នុងការធ្វើមាត្រដ្ឋាន pods ទៅនឹងចំនួនជាក់លាក់នៃការចម្លង ដែលមានន័យថាអ្នកអាចកំណត់យ៉ាងច្បាស់នូវឈ្មួញកណ្តាល Kafka ជាច្រើនតាមដែលអ្នកចូលចិត្ត។ អ្វីដែលពិបាកបំផុតក្នុងករណីនេះគឺការចាត់តាំងផ្នែកឡើងវិញបន្ទាប់ពីធ្វើមាត្រដ្ឋានឡើងលើ ឬមុនពេលធ្វើមាត្រដ្ឋានចុះក្រោម។ ជាថ្មីម្តងទៀត Kubernetes នឹងជួយអ្នកក្នុងកិច្ចការនេះ។

រដ្ឋបាល

កិច្ចការដែលទាក់ទងនឹងការគ្រប់គ្រងចង្កោម Kafka របស់អ្នក ដូចជាការបង្កើតប្រធានបទ និងការចាត់តាំងផ្នែកឡើងវិញ អាចត្រូវបានអនុវត្តដោយប្រើស្គ្រីបសែលដែលមានស្រាប់ដោយបើកចំណុចប្រទាក់បន្ទាត់ពាក្យបញ្ជានៅក្នុងផតផតរបស់អ្នក។ ទោះជាយ៉ាងណាក៏ដោយដំណោះស្រាយនេះគឺមិនស្រស់ស្អាតខ្លាំងណាស់។ Strimzi គាំទ្រការគ្រប់គ្រងប្រធានបទដោយប្រើប្រតិបត្តិករផ្សេង។ មានបន្ទប់ខ្លះសម្រាប់កែលម្អនៅទីនេះ។

Резервноекопированиеивосстановление

ឥឡូវនេះភាពអាចរកបាននៃ Kafka ក៏អាស្រ័យលើភាពអាចរកបាននៃ Kubernetes ផងដែរ។ ប្រសិនបើចង្កោម Kubernetes របស់អ្នកបរាជ័យ នោះនៅក្នុងសេណារីយ៉ូដ៏អាក្រក់បំផុត ចង្កោម Kafka របស់អ្នកក៏នឹងបរាជ័យដែរ។ យោងទៅតាមច្បាប់របស់ Murphy នេះពិតជានឹងកើតឡើង ហើយអ្នកនឹងបាត់បង់ទិន្នន័យ។ ដើម្បីកាត់បន្ថយហានិភ័យប្រភេទនេះ មានគំនិតបម្រុងទុកដ៏ល្អ។ អ្នកអាចប្រើ MirrorMaker ជម្រើសមួយទៀតគឺប្រើ S3 សម្រាប់រឿងនេះ ដូចដែលបានពិពណ៌នានៅក្នុងនេះ។ ប្រកាស ពី Zalando ។

សេចក្តីសន្និដ្ឋាន

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

ប្រភព: www.habr.com