ការផ្លាស់ប្តូរ Tinder ទៅ Kubernetes

ចំណាំ។ បកប្រែ៖ បុគ្គលិកនៃសេវាកម្ម Tinder ដ៏ល្បីល្បាញលើពិភពលោកថ្មីៗនេះបានចែករំលែកព័ត៌មានលម្អិតបច្ចេកទេសមួយចំនួននៃការផ្ទេរហេដ្ឋារចនាសម្ព័ន្ធរបស់ពួកគេទៅកាន់ Kubernetes ។ ដំណើរការនេះបានចំណាយពេលជិត 8 ឆ្នាំ ហើយជាលទ្ធផលនៅក្នុងការចាប់ផ្តើមនៃវេទិកាទ្រង់ទ្រាយធំមួយនៅលើ K200s ដែលមានសេវាកម្ម 48 ដែលរៀបចំនៅលើ XNUMX ពាន់កុងតឺន័រ។ តើវិស្វករ Tinder ជួបប្រទះការលំបាកអ្វីខ្លះ ហើយតើពួកគេទទួលបានលទ្ធផលអ្វីខ្លះ? សូមអានការបកប្រែនេះ។

ហេតុអ្វី?

ជិតពីរឆ្នាំមុន Tinder បានសម្រេចចិត្តផ្លាស់ប្តូរវេទិការបស់ខ្លួនទៅ Kubernetes ។ Kubernetes នឹងអនុញ្ញាតឱ្យក្រុម Tinder ផ្ទុក និងផ្លាស់ទីទៅផលិតកម្មដោយមានការខិតខំប្រឹងប្រែងតិចតួចតាមរយៈការដាក់ពង្រាយដែលមិនអាចផ្លាស់ប្តូរបាន។ (ការដាក់ពង្រាយដែលមិនអាចផ្លាស់ប្តូរបាន). ក្នុងករណីនេះ ការជួបប្រជុំគ្នានៃកម្មវិធី ការដាក់ឱ្យប្រើប្រាស់របស់ពួកគេ និងហេដ្ឋារចនាសម្ព័ន្ធខ្លួនឯងនឹងត្រូវបានកំណត់យ៉ាងពិសេសដោយកូដ។

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

ដំណើរការបានប្រែទៅជាពិបាក។ ក្នុងអំឡុងពេលនៃការធ្វើចំណាកស្រុករបស់យើងនៅដើមឆ្នាំ 2019 ចង្កោម Kubernetes បានឈានដល់កម្រិតដ៏សំខាន់ ហើយយើងបានចាប់ផ្តើមជួបប្រទះបញ្ហាផ្សេងៗដោយសារតែបរិមាណចរាចរណ៍ ទំហំចង្កោម និង DNS ។ នៅតាមផ្លូវ យើងបានដោះស្រាយបញ្ហាគួរឱ្យចាប់អារម្មណ៍ជាច្រើនទាក់ទងនឹងការផ្ទេរសេវា 200 និងការថែរក្សាចង្កោម Kubernetes ដែលមាន 1000 nodes, 15000 pods និង 48000 កុងតឺន័រដែលកំពុងដំណើរការ។

តើធ្វើដូចម្តេច?

ចាប់តាំងពីខែមករា ឆ្នាំ 2018 មក យើងបានឆ្លងកាត់ដំណាក់កាលជាច្រើននៃការធ្វើចំណាកស្រុក។ យើងបានចាប់ផ្តើមដោយការរក្សាទុកសេវាកម្មរបស់យើងទាំងអស់ និងដាក់ឱ្យប្រើប្រាស់ពួកវាទៅកាន់ Kubernetes សាកល្បងបរិស្ថានពពក។ ចាប់ពីខែតុលា យើងបានចាប់ផ្តើមផ្ទេរសេវាកម្មដែលមានស្រាប់ទាំងអស់ទៅជា Kubernetes តាមវិធីសាស្ដ្រ។ នៅខែមីនាឆ្នាំបន្ទាប់ យើងបានបញ្ចប់ការធ្វើចំណាកស្រុក ហើយឥឡូវនេះវេទិកា Tinder ដំណើរការទាំងស្រុងលើ Kubernetes ។

ការកសាងរូបភាពសម្រាប់ Kubernetes

យើង​មាន​ឃ្លាំង​កូដ​ប្រភព​ជាង 30 សម្រាប់​សេវា​មីក្រូ​ដែល​ដំណើរការ​លើ​ចង្កោម Kubernetes។ កូដនៅក្នុងឃ្លាំងទាំងនេះត្រូវបានសរសេរជាភាសាផ្សេងៗគ្នា (ឧទាហរណ៍ Node.js, Java, Scala, Go) ជាមួយនឹងបរិស្ថានពេលដំណើរការច្រើនសម្រាប់ភាសាដូចគ្នា។

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

រូបភាពទី 1-1 ។ ដំណើរការសាងសង់តាមស្តង់ដារតាមរយៈ Builder container

ដើម្បីសម្រេចបាននូវភាពស៊ីសង្វាក់គ្នាអតិបរមារវាងពេលរត់ (បរិស្ថានពេលដំណើរការ) ដំណើរការសាងសង់ដូចគ្នាត្រូវបានប្រើកំឡុងពេលអភិវឌ្ឍ និងសាកល្បង។ យើងបានប្រឈមមុខនឹងបញ្ហាប្រឈមដ៏គួរឱ្យចាប់អារម្មណ៍មួយ៖ យើងត្រូវបង្កើតវិធីមួយដើម្បីធានាបាននូវភាពស៊ីសង្វាក់នៃបរិយាកាសសាងសង់នៅទូទាំងវេទិកាទាំងមូល។ ដើម្បីសម្រេចបាននូវដំណើរការដំឡើងទាំងអស់ត្រូវបានអនុវត្តនៅខាងក្នុងធុងពិសេស។ ការសាងសង់.

ការអនុវត្តកុងតឺន័ររបស់គាត់តម្រូវឱ្យមានបច្ចេកទេស Docker កម្រិតខ្ពស់។ Builder ទទួលមរតកលេខសម្គាល់អ្នកប្រើប្រាស់ក្នុងតំបន់ និងអាថ៌កំបាំង (ដូចជា SSH key, AWS credentials ។ល។) តម្រូវឱ្យចូលប្រើឃ្លាំង Tinder ឯកជន។ វាភ្ជាប់ថតមូលដ្ឋានដែលមានប្រភពដើម្បីរក្សាទុកវត្ថុបុរាណដែលបង្កើតដោយធម្មជាតិ។ វិធីសាស្រ្តនេះធ្វើអោយប្រសើរឡើងនូវការអនុវត្តព្រោះវាលុបបំបាត់តម្រូវការក្នុងការចម្លងវត្ថុបុរាណរវាងកុងតឺន័រ Builder និងម៉ាស៊ីន។ វត្ថុបុរាណដែលបានរក្សាទុកអាចប្រើឡើងវិញបានដោយមិនចាំបាច់កំណត់រចនាសម្ព័ន្ធបន្ថែម។

សម្រាប់សេវាកម្មមួយចំនួន យើងត្រូវបង្កើតកុងតឺន័រមួយទៀត ដើម្បីគូសផែនទីបរិយាកាសចងក្រងទៅនឹងបរិយាកាសពេលដំណើរការ (ឧទាហរណ៍ បណ្ណាល័យ bcrypt Node.js បង្កើតវត្ថុបុរាណប្រព័ន្ធគោលពីរជាក់លាក់អំឡុងពេលដំឡើង)។ ក្នុងអំឡុងពេលដំណើរការចងក្រង តម្រូវការអាចប្រែប្រួលរវាងសេវាកម្ម ហើយ Dockerfile ចុងក្រោយត្រូវបានចងក្រងភ្លាមៗ។

ស្ថាបត្យកម្ម និងការផ្លាស់ប្តូរចង្កោម Kubernetes

ការគ្រប់គ្រងទំហំចង្កោម

យើងបានសម្រេចចិត្តប្រើ kube-aws សម្រាប់ការដាក់ពង្រាយចង្កោមដោយស្វ័យប្រវត្តិនៅលើឧទាហរណ៍ Amazon EC2 ។ នៅដើមដំបូង អ្វីគ្រប់យ៉ាងដំណើរការនៅក្នុងថ្នាំងទូទៅមួយ។ យើងបានដឹងយ៉ាងឆាប់រហ័សនូវតម្រូវការក្នុងការបំបែកបន្ទុកតាមទំហំ និងប្រភេទឧទាហរណ៍ ដើម្បីប្រើប្រាស់ធនធានឱ្យកាន់តែមានប្រសិទ្ធភាព។ តក្កវិជ្ជាគឺថាការដំណើរការ pods ពហុខ្សែស្រឡាយដែលបានផ្ទុកជាច្រើនបានប្រែទៅជាអាចព្យាករណ៍បានច្រើនជាងនៅក្នុងលក្ខខណ្ឌនៃការអនុវត្តជាងការរួមរស់របស់ពួកគេជាមួយនឹងចំនួនដ៏ធំនៃ pods តែមួយ។

នៅទីបញ្ចប់យើងបានដោះស្រាយលើ៖

• m5.4x ធំ - សម្រាប់ការត្រួតពិនិត្យ (Prometheus);
• c5.4x ធំ - សម្រាប់បន្ទុកការងារ Node.js (បន្ទុកការងារតែមួយខ្សែ);
• c5.2x ធំ - សម្រាប់ Java និង Go (បន្ទុកការងារពហុខ្សែ);
• c5.4x ធំ - សម្រាប់ផ្ទាំងបញ្ជា (3 ថ្នាំង) ។

ការធ្វើចំណាកស្រុក

ជំហានត្រៀមរៀបចំមួយសម្រាប់ការធ្វើចំណាកស្រុកពីហេដ្ឋារចនាសម្ព័ន្ធចាស់ទៅកាន់ Kubernetes គឺត្រូវប្តូរទិសទំនាក់ទំនងផ្ទាល់ដែលមានស្រាប់រវាងសេវាកម្មទៅកាន់ឧបករណ៍តុល្យភាពបន្ទុកថ្មី (Elastic Load Balancers (ELB))។ ពួកវាត្រូវបានបង្កើតឡើងនៅលើបណ្តាញរងជាក់លាក់នៃពពកឯកជននិម្មិត (VPC)។ បណ្តាញរងនេះត្រូវបានភ្ជាប់ទៅ Kubernetes VPC ។ នេះអនុញ្ញាតឱ្យយើងផ្លាស់ប្តូរម៉ូឌុលបន្តិចម្តង ៗ ដោយមិនគិតពីលំដាប់ជាក់លាក់នៃភាពអាស្រ័យនៃសេវាកម្ម។

ចំណុចបញ្ចប់ទាំងនេះត្រូវបានបង្កើតឡើងដោយប្រើសំណុំទម្ងន់នៃកំណត់ត្រា DNS ដែលមាន CNAMEs ចង្អុលទៅ ELB ថ្មីនីមួយៗ។ ដើម្បីប្តូរ យើងបានបន្ថែមធាតុថ្មីដែលចង្អុលទៅ ELB ថ្មីនៃសេវាកម្ម Kubernetes ដែលមានទម្ងន់ 0។ បន្ទាប់មកយើងកំណត់ Time To Live (TTL) នៃធាតុកំណត់ទៅ 0។ បន្ទាប់ពីនេះ ទម្ងន់ចាស់ និងថ្មីគឺ កែតម្រូវយឺតៗ ហើយនៅទីបំផុត 100% នៃបន្ទុកត្រូវបានបញ្ជូនទៅម៉ាស៊ីនមេថ្មី។ បន្ទាប់ពីការប្តូរត្រូវបានបញ្ចប់ តម្លៃ TTL ត្រឡប់ទៅកម្រិតដែលសមស្របជាងមុន។

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

មេរៀន

ដែនកំណត់នៃក្រណាត់បណ្តាញ

នៅព្រឹកព្រលឹមថ្ងៃទី 8 ខែមករា ឆ្នាំ 2019 វេទិកា Tinder បានគាំងដោយមិននឹកស្មានដល់។ ជាការឆ្លើយតបទៅនឹងការកើនឡើងដែលមិនពាក់ព័ន្ធនៃភាពយឺតយ៉ាវរបស់វេទិកានៅព្រឹកនោះ ចំនួនផត និងថ្នាំងនៅក្នុងចង្កោមបានកើនឡើង។ វាបណ្តាលឱ្យឃ្លាំងសម្ងាត់ ARP អស់នៅលើថ្នាំងទាំងអស់របស់យើង។

មានជម្រើសលីនុចបីដែលទាក់ទងនឹងឃ្លាំងសម្ងាត់ ARP៖

(ប្រភព)

gc_thresh3 - នេះគឺជាដែនកំណត់ពិបាក។ រូបរាងនៃធាតុ "ការហៀរលើតារាងអ្នកជិតខាង" នៅក្នុងកំណត់ហេតុមានន័យថាសូម្បីតែបន្ទាប់ពីការប្រមូលសំរាមសមកាលកម្ម (GC) មិនមានកន្លែងគ្រប់គ្រាន់នៅក្នុងឃ្លាំងសម្ងាត់ ARP ដើម្បីរក្សាទុកធាតុជិតខាងនោះទេ។ ក្នុងករណីនេះ ខឺណែលគ្រាន់តែបោះចោលកញ្ចប់ព័ត៌មានទាំងស្រុង។

យើង​ប្រើ Flannel ជាក្រណាត់បណ្តាញនៅក្នុង Kubernetes ។ កញ្ចប់ត្រូវបានបញ្ជូនតាម VXLAN ។ VXLAN គឺជាផ្លូវរូងក្រោមដី L2 ដែលបានលើកឡើងនៅលើបណ្តាញ L3 ។ បច្ចេកវិទ្យានេះប្រើប្រាស់ MAC-in-UDP (MAC Address-in-User Datagram Protocol) encapsulation និងអនុញ្ញាតឱ្យពង្រីកផ្នែកបណ្តាញ Layer 2 ។ ពិធីការដឹកជញ្ជូននៅលើបណ្តាញមជ្ឈមណ្ឌលទិន្នន័យរូបវន្តគឺ IP បូក UDP ។

រូបភាព 2–1 ។ ដ្យាក្រាម Flannel (ប្រភព)

រូបភាពទី 2-2 ។ កញ្ចប់ VXLAN (ប្រភព)

ថ្នាំងកម្មករ Kubernetes នីមួយៗបែងចែកចន្លោះអាសយដ្ឋាននិម្មិតជាមួយនឹងរបាំង /24 ពីប្លុក / 9 ធំជាង។ សម្រាប់ថ្នាំងនីមួយៗនេះគឺ មធ្យោបាយ ធាតុមួយនៅក្នុងតារាងនាំផ្លូវ ធាតុមួយនៅក្នុងតារាង ARP (នៅលើចំណុចប្រទាក់ flannel.1) និងធាតុមួយនៅក្នុងតារាងប្តូរ (FDB) ។ ពួកវាត្រូវបានបន្ថែមជាលើកដំបូងដែលថ្នាំងកម្មករត្រូវបានចាប់ផ្តើម ឬរាល់ពេលដែលថ្នាំងថ្មីត្រូវបានរកឃើញ។

លើសពីនេះ ការទំនាក់ទំនង node-pod (ឬ pod-pod) ទីបំផុតឆ្លងកាត់ចំណុចប្រទាក់ eth0 (ដូចបង្ហាញក្នុងដ្យាក្រាម Flannel ខាងលើ)។ នេះបណ្តាលឱ្យមានធាតុបន្ថែមនៅក្នុងតារាង ARP សម្រាប់ប្រភព និងម៉ាស៊ីនគោលដៅដែលត្រូវគ្នា។

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

នៅពេលបរាជ័យ មាន 605 ថ្នាំងនៅក្នុងចង្កោម។ សម្រាប់ហេតុផលដែលបានរៀបរាប់ខាងលើ នេះគឺគ្រប់គ្រាន់ដើម្បីយកឈ្នះលើសារៈសំខាន់ gc_thresh3ដែលជាលំនាំដើម។ នៅពេលវាកើតឡើង មិនត្រឹមតែកញ្ចប់ព័ត៌មានចាប់ផ្តើមធ្លាក់ចុះប៉ុណ្ណោះទេ ប៉ុន្តែទំហំអាសយដ្ឋាននិម្មិត Flannel ទាំងមូលដែលមានរបាំង /24 បាត់ពីតារាង ARP ។ ការទំនាក់ទំនង Node-pod និងសំណួរ DNS ត្រូវបានរំខាន (DNS ត្រូវបានបង្ហោះនៅក្នុងចង្កោម អាននៅពេលក្រោយក្នុងអត្ថបទនេះសម្រាប់ព័ត៌មានលម្អិត)។

ដើម្បីដោះស្រាយបញ្ហានេះអ្នកត្រូវបង្កើនតម្លៃ gc_thresh1, gc_thresh2 и gc_thresh3 ហើយចាប់ផ្តើម Flannel ឡើងវិញ ដើម្បីចុះឈ្មោះបណ្តាញដែលបាត់ម្តងទៀត។

ការធ្វើមាត្រដ្ឋាន DNS ដែលមិនបានរំពឹងទុក

ក្នុងអំឡុងពេលដំណើរការផ្លាស់ប្តូរ យើងបានប្រើប្រាស់ DNS យ៉ាងសកម្មដើម្បីគ្រប់គ្រងចរាចរណ៍ និងផ្ទេរសេវាកម្មបន្តិចម្តងៗពីហេដ្ឋារចនាសម្ព័ន្ធចាស់ទៅ Kubernetes ។ យើងកំណត់តម្លៃ TTL ទាបសម្រាប់ RecordSets ដែលពាក់ព័ន្ធនៅក្នុង Route53។ នៅពេលដែលហេដ្ឋារចនាសម្ព័ន្ធចាស់កំពុងដំណើរការលើករណី EC2 ការកំណត់រចនាសម្ព័ន្ធអ្នកដោះស្រាយរបស់យើងបានចង្អុលទៅ Amazon DNS ។ យើងបានទទួលយកវាសម្រាប់ការអនុញ្ញាត ហើយផលប៉ះពាល់នៃ TTL ទាបមកលើសេវាកម្មរបស់យើង និងសេវាកម្ម Amazon (ដូចជា DynamoDB) មិនត្រូវបានគេកត់សំគាល់ទេ។

នៅពេលដែលយើងផ្លាស់ប្តូរសេវាកម្មទៅ Kubernetes យើងបានរកឃើញថា DNS កំពុងដំណើរការសំណើ 250 ពាន់ក្នុងមួយវិនាទី។ ជាលទ្ធផល កម្មវិធីបានចាប់ផ្តើមជួបប្រទះនឹងការអស់ពេលថេរ និងធ្ងន់ធ្ងរសម្រាប់សំណួរ DNS ។ វាបានកើតឡើងទោះបីជាមានការខិតខំប្រឹងប្រែងមិនគួរឱ្យជឿដើម្បីបង្កើនប្រសិទ្ធភាព និងប្តូរអ្នកផ្តល់ DNS ទៅ CoreDNS (ដែលនៅពេលផ្ទុកខ្ពស់បំផុតឈានដល់ 1000 pods ដែលដំណើរការលើ 120 cores)។

ខណៈពេលដែលការស្រាវជ្រាវអំពីមូលហេតុ និងដំណោះស្រាយដែលអាចកើតមានផ្សេងទៀត យើងបានរកឃើញ អត្ថបទដោយពណ៌នាអំពីលក្ខខណ្ឌនៃការប្រណាំងដែលប៉ះពាល់ដល់ក្របខ័ណ្ឌតម្រងកញ្ចប់ព័ត៌មាន តម្រងអ៊ីនធឺណិត នៅក្នុងលីនុច។ ការអស់ពេលដែលយើងសង្កេតឃើញ គួបផ្សំជាមួយនឹងការកើនឡើង insert_failed នៅក្នុងចំណុចប្រទាក់ Flannel គឺស្របជាមួយនឹងការរកឃើញនៃអត្ថបទ។

បញ្ហាកើតឡើងនៅដំណាក់កាលនៃការបកប្រែអាសយដ្ឋានបណ្តាញប្រភព និងទិសដៅ (SNAT និង DNAT) និងការបញ្ចូលជាបន្តបន្ទាប់ទៅក្នុងតារាង ត្រួតត្រា. ដំណោះស្រាយមួយក្នុងចំណោមដំណោះស្រាយដែលបានពិភាក្សាផ្ទៃក្នុង និងស្នើដោយសហគមន៍គឺដើម្បីផ្លាស់ទី DNS ទៅថ្នាំងកម្មករខ្លួនឯង។ ក្នុងករណី​នេះ:

• SNAT មិន​ត្រូវ​ការ​ទេ ព្រោះ​ចរាចរណ៍​ស្ថិត​នៅ​ក្នុង​ថ្នាំង។ វាមិនចាំបាច់ត្រូវបានបញ្ជូនតាមរយៈចំណុចប្រទាក់ទេ។ eth0.
• DNAT មិន​ត្រូវ​ការ​ទេ ព្រោះ IP ទិសដៅ​គឺ​ស្ថិត​នៅ​ក្នុង​មូលដ្ឋាន​ចំពោះ​ថ្នាំង ហើយ​មិន​មែន​ជា​ការ​ជ្រើសរើស​ដោយ​ចៃដន្យ​តាម​ច្បាប់ iptables.

យើងបានសម្រេចចិត្តប្រកាន់ខ្ជាប់នូវវិធីសាស្រ្តនេះ។ CoreDNS ត្រូវបានដាក់ពង្រាយជា DaemonSet នៅក្នុង Kubernetes ហើយយើងបានអនុវត្តម៉ាស៊ីនមេ DNS មូលដ្ឋាននៅក្នុង ដំណោះស្រាយ ។conf pod នីមួយៗដោយកំណត់ទង់ --cluster-dns ពាក្យបញ្ជា គូប . ដំណោះស្រាយនេះមានប្រសិទ្ធភាពសម្រាប់ការអស់ពេល DNS ។

ទោះជាយ៉ាងណាក៏ដោយ យើងនៅតែឃើញការបាត់បង់កញ្ចប់ព័ត៌មាន និងការកើនឡើងនៅក្នុងបញ្ជរ insert_failed នៅក្នុងចំណុចប្រទាក់ Flannel ។ វាបានបន្តបន្ទាប់ពីដំណោះស្រាយត្រូវបានអនុវត្ត ពីព្រោះយើងអាចលុបបំបាត់ SNAT និង/ឬ DNAT សម្រាប់តែចរាចរ DNS ប៉ុណ្ណោះ។ លក្ខខណ្ឌនៃការប្រណាំងត្រូវបានរក្សាទុកសម្រាប់ប្រភេទចរាចរណ៍ផ្សេងទៀត។ ជាសំណាងល្អ ភាគច្រើននៃកញ្ចប់ព័ត៌មានរបស់យើងគឺ TCP ហើយប្រសិនបើមានបញ្ហាកើតឡើង ពួកគេត្រូវបានបញ្ជូនឡើងវិញយ៉ាងសាមញ្ញ។ យើងនៅតែព្យាយាមស្វែងរកដំណោះស្រាយសមរម្យសម្រាប់ចរាចរណ៍គ្រប់ប្រភេទ។

ការប្រើប្រេសិតសម្រាប់តុល្យភាពការផ្ទុកកាន់តែប្រសើរ

នៅពេលដែលយើងផ្លាស់ប្តូរសេវាកម្ម backend ទៅ Kubernetes យើងចាប់ផ្តើមទទួលរងពីការផ្ទុកមិនមានតុល្យភាពរវាងផត។ យើងបានរកឃើញថា HTTP Keepalive បណ្តាលឱ្យការតភ្ជាប់ ELB ព្យួរនៅលើផតដែលត្រៀមរួចជាស្រេចដំបូងនៃការដាក់ពង្រាយនីមួយៗ។ ដូច្នេះ ចរាចរណ៍ភាគច្រើនបានឆ្លងកាត់ភាគរយតូចមួយនៃផតឃែរដែលមាន។ ដំណោះស្រាយដំបូងដែលយើងបានសាកល្បងគឺកំណត់ MaxSurge ដល់ 100% លើការដាក់ពង្រាយថ្មីសម្រាប់សេណារីយ៉ូដែលអាក្រក់បំផុត។ ឥទ្ធិពល​បាន​ប្រែ​ក្លាយ​ទៅ​ជា​មិន​សំខាន់ និង​មិន​អាច​សន្យា​បាន​ក្នុង​លក្ខខណ្ឌ​នៃ​ការ​ដាក់​ពង្រាយ​ធំ​ជាង។

ដំណោះស្រាយមួយទៀតដែលយើងបានប្រើគឺដើម្បីបង្កើនការស្នើសុំធនធានសិប្បនិម្មិតសម្រាប់សេវាកម្មសំខាន់ៗ។ ក្នុងករណីនេះ ផតដែលដាក់នៅក្បែរនោះ នឹងមានកន្លែងច្រើនសម្រាប់ធ្វើសមយុទ្ធ បើប្រៀបធៀបទៅនឹងផតធំៗផ្សេងទៀត។ វានឹងមិនដំណើរការក្នុងរយៈពេលយូរទេ ព្រោះវានឹងត្រូវខ្ជះខ្ជាយធនធាន។ លើសពីនេះ កម្មវិធី Node របស់យើងគឺ single-threaded ហើយតាមនោះ អាចប្រើស្នូលតែមួយប៉ុណ្ណោះ។ ដំណោះស្រាយពិតប្រាកដតែមួយគត់គឺត្រូវប្រើតុល្យភាពបន្ទុកប្រសើរជាងមុន។

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

យើងបានបង្កើតនូវការកំណត់រចនាសម្ព័ន្ធដូចខាងក្រោម៖ មានរថយន្តចំហៀង Envoy សម្រាប់ផតនីមួយៗ និងផ្លូវតែមួយ ហើយភ្ជាប់ចង្កោមទៅកុងតឺន័រតាមច្រក។ ដើម្បីកាត់បន្ថយការធ្លាក់សក្ដានុពល និងរក្សាកាំតូចមួយ យើងបានប្រើប្រាស់កងនាវានៃ Envoy front-proxy pods មួយក្នុងមួយ Availability Zone (AZ) សម្រាប់សេវាកម្មនីមួយៗ។ ពួកគេពឹងផ្អែកលើម៉ាស៊ីនស្វែងរកសេវាដ៏សាមញ្ញមួយ ដែលសរសេរដោយវិស្វកររបស់យើងម្នាក់ ដែលគ្រាន់តែត្រឡប់បញ្ជីនៃផតនៅក្នុង AZ នីមួយៗសម្រាប់សេវាកម្មដែលបានផ្តល់ឱ្យ។

បន្ទាប់មក បេសកជនផ្នែកសេវាកម្មបានប្រើយន្តការស្វែងរកសេវានេះជាមួយនឹងចង្កោម និងផ្លូវឡើងលើមួយ។ យើងកំណត់ការអស់ពេលគ្រប់គ្រាន់ បង្កើនការកំណត់ឧបករណ៍បំប្លែងសៀគ្វីទាំងអស់ និងបានបន្ថែមការកំណត់រចនាសម្ព័ន្ធការព្យាយាមម្តងទៀតតិចតួចបំផុត ដើម្បីជួយដល់ការបរាជ័យតែមួយដង និងធានាឱ្យមានការដាក់ឱ្យប្រើប្រាស់ដោយរលូន។ យើងបានដាក់ TCP ELB នៅពីមុខបេសកជននៃសេវាកម្មទាំងនេះ។ ទោះបីជា Keepalive ពីស្រទាប់ប្រូកស៊ីចម្បងរបស់យើងត្រូវបានជាប់គាំងនៅលើ Envoy pods មួយចំនួនក៏ដោយ ក៏ពួកគេនៅតែអាចគ្រប់គ្រងបន្ទុកបានប្រសើរជាងមុន ហើយត្រូវបានកំណត់រចនាសម្ព័ន្ធដើម្បីឱ្យមានតុល្យភាពតាមរយៈ least_request នៅក្នុង backend ។

សម្រាប់ការដាក់ឱ្យប្រើប្រាស់ យើងបានប្រើទំពក់ preStop នៅលើកម្មវិធីទាំងពីរ pods និង sidecar pods។ ទំពក់បានបង្ករឱ្យមានកំហុសក្នុងការត្រួតពិនិត្យស្ថានភាពនៃចំណុចបញ្ចប់នៃអ្នកគ្រប់គ្រងដែលមានទីតាំងនៅលើកុងតឺន័ររថយន្តចំហៀង ហើយបានចូលគេងមួយសន្ទុះ ដើម្បីអនុញ្ញាតឱ្យការតភ្ជាប់សកម្មបញ្ចប់។

ហេតុផលមួយក្នុងចំណោមហេតុផលដែលយើងអាចធ្វើចលនាបានលឿនគឺដោយសារតែរង្វាស់លម្អិតដែលយើងអាចបញ្ចូលយ៉ាងងាយស្រួលទៅក្នុងការដំឡើង Prometheus ធម្មតា។ វាអនុញ្ញាតឱ្យយើងមើលឃើញយ៉ាងច្បាស់នូវអ្វីដែលកំពុងកើតឡើង ខណៈពេលដែលយើងកែសម្រួលប៉ារ៉ាម៉ែត្រនៃការកំណត់រចនាសម្ព័ន្ធ និងចរាចរចែកចាយឡើងវិញ។

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

រូបភាពទី 3–1 ។ ការបញ្ចូលគ្នានៃស៊ីភីយូនៃសេវាកម្មមួយក្នុងអំឡុងពេលការផ្លាស់ប្តូរទៅជា Envoy

លទ្ធផលចុងក្រោយ

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

នៅពេលដែលតម្រូវការសម្រាប់សមត្ថភាពបន្ថែមបានកើតឡើងលើហេដ្ឋារចនាសម្ព័ន្ធចាស់ យើងត្រូវរង់ចាំជាច្រើននាទីសម្រាប់ករណី EC2 ថ្មីដើម្បីចាប់ផ្តើម។ ឥឡូវនេះកុងតឺន័រចាប់ផ្តើមដំណើរការ ហើយចាប់ផ្តើមដំណើរការចរាចរណ៍ក្នុងរយៈពេលប៉ុន្មានវិនាទី ជំនួសឱ្យនាទី។ ការកំណត់ពេលដាក់ធុងច្រើននៅលើឧទាហរណ៍ EC2 តែមួយក៏ផ្តល់នូវការប្រមូលផ្តុំផ្តេកដែលប្រសើរឡើងផងដែរ។ ជាលទ្ធផល យើងព្យាករណ៍ពីការថយចុះគួរឱ្យកត់សម្គាល់នៃការចំណាយ EC2019 ក្នុងឆ្នាំ 2 បើប្រៀបធៀបទៅនឹងឆ្នាំមុន។

ការធ្វើចំណាកស្រុកចំណាយពេលជិតពីរឆ្នាំ ប៉ុន្តែយើងបានបញ្ចប់វានៅខែមីនា ឆ្នាំ 2019។ បច្ចុប្បន្ន វេទិកា Tinder ដំណើរការទាំងស្រុងលើចង្កោម Kubernetes ដែលមានសេវាកម្ម 200, 1000 nodes, 15 pods និង 000 កុងតឺន័រដែលកំពុងដំណើរការ។ ហេដ្ឋារចនាសម្ព័ន្ធមិនមែនជាដែនតែមួយគត់នៃក្រុមប្រតិបត្តិការទៀតទេ។ វិស្វកររបស់យើងទាំងអស់ចែករំលែកនូវទំនួលខុសត្រូវនេះ និងគ្រប់គ្រងដំណើរការនៃការបង្កើត និងដាក់ពង្រាយកម្មវិធីរបស់ពួកគេដោយប្រើលេខកូដតែប៉ុណ្ណោះ។

PS ពីអ្នកបកប្រែ

សូមអានអត្ថបទមួយចំនួននៅលើប្លក់របស់យើងផងដែរ៖

• «Kubernetes រឿងជោគជ័យក្នុងផលិតកម្ម។ ផ្នែកទី 1៖ 4200 hearths និង TessMaster ពី eBay"។
• «Kubernetes រឿងជោគជ័យក្នុងផលិតកម្ម។ ផ្នែកទី 2៖ Concur និង SAP"។
• «Kubernetes រឿងជោគជ័យក្នុងផលិតកម្ម។ ផ្នែកទី 3៖ GitHub"។
• «Kubernetes រឿងជោគជ័យក្នុងផលិតកម្ម។ ផ្នែកទី 4៖ SoundCloud (ដោយ Prometheus)"។
• «Kubernetes រឿងជោគជ័យក្នុងផលិតកម្ម។ ផ្នែកទី 5៖ ធនាគារឌីជីថល Monzo"។
• «Kubernetes រឿងជោគជ័យក្នុងផលិតកម្ម។ ផ្នែកទី 6៖ BlaBlaCar ។"។
• «Kubernetes រឿងជោគជ័យក្នុងផលិតកម្ម។ ផ្នែកទី 7៖ BlackRock"។
• «Kubernetes រឿងជោគជ័យក្នុងផលិតកម្ម។ ផ្នែកទី 8៖ ក្រុមហ៊ុន Huawei"។
• «Kubernetes រឿងជោគជ័យក្នុងផលិតកម្ម។ ផ្នែកទី 9៖ ចង្កោម CERN និង 210 K8s"។
• «Kubernetes រឿងជោគជ័យក្នុងផលិតកម្ម។ ផ្នែកទី 10៖ Reddit"។

ប្រភព: www.habr.com