🥇Kubernetes ដំណើរផ្សងព្រេង Dailymotion៖ ការបង្កើតហេដ្ឋារចនាសម្ព័ន្ធក្នុងពពក + នៅនឹងកន្លែង

ចំណាំ។ បកប្រែ៖ Dailymotion គឺជាសេវាកម្មបង្ហោះវីដេអូដ៏ធំបំផុតមួយរបស់ពិភពលោក ដូច្នេះហើយបានជាអ្នកប្រើប្រាស់ Kubernetes គួរឱ្យកត់សម្គាល់។ នៅក្នុងសម្ភារៈនេះ ស្ថាបត្យករប្រព័ន្ធ David Donchez ចែករំលែកលទ្ធផលនៃការបង្កើតវេទិកាផលិតកម្មរបស់ក្រុមហ៊ុនដោយផ្អែកលើ K8s ដែលបានចាប់ផ្តើមជាមួយនឹងការដំឡើងពពកនៅក្នុង GKE ហើយបានបញ្ចប់ជាដំណោះស្រាយកូនកាត់ ដែលអនុញ្ញាតឱ្យមានពេលវេលាឆ្លើយតបកាន់តែប្រសើរ និងការសន្សំលើថ្លៃដើមហេដ្ឋារចនាសម្ព័ន្ធ។

ការសម្រេចចិត្តបង្កើត Core API ឡើងវិញ Dailymotion ។ កាលពីបីឆ្នាំមុន យើងចង់បង្កើតវិធីដែលមានប្រសិទ្ធភាពជាងមុនក្នុងការបង្ហោះកម្មវិធី និងធ្វើឱ្យវាកាន់តែងាយស្រួល ដំណើរការក្នុងការអភិវឌ្ឍន៍ និងផលិតកម្ម. ចំពោះគោលបំណងនេះ យើងបានសម្រេចចិត្តប្រើវេទិការវង់កុងតឺន័រ ហើយជ្រើសរើស Kubernetes ដោយធម្មជាតិ។

ហេតុអ្វីបានជាវាមានតម្លៃបង្កើតវេទិកាផ្ទាល់ខ្លួនរបស់អ្នកដោយផ្អែកលើ Kubernetes?

API កម្រិតផលិតកម្មក្នុងពេលមិនប្រើ Google Cloud

រដូវក្តៅឆ្នាំ 2016

កាលពីបីឆ្នាំមុន ភ្លាមៗបន្ទាប់ពី Dailymotion ត្រូវបានទិញដោយ Vivendiក្រុមវិស្វកររបស់យើងផ្តោតលើគោលដៅសកលមួយ៖ ដើម្បីបង្កើតផលិតផល Dailymotion ថ្មីទាំងស្រុង។

ដោយផ្អែកលើការវិភាគរបស់យើងអំពីធុង ដំណោះស្រាយ orchestration និងបទពិសោធន៍កន្លងមករបស់យើង យើងជឿជាក់ថា Kubernetes គឺជាជម្រើសដ៏ត្រឹមត្រូវ។ អ្នកអភិវឌ្ឍន៍មួយចំនួនមានការយល់ដឹងអំពីគោលគំនិតជាមូលដ្ឋានរួចហើយ និងដឹងពីរបៀបប្រើប្រាស់វា ដែលជាអត្ថប្រយោជន៍ដ៏ធំសម្រាប់ការផ្លាស់ប្តូរហេដ្ឋារចនាសម្ព័ន្ធ។

តាមទស្សនៈវិស័យហេដ្ឋារចនាសម្ព័ន្ធ ប្រព័ន្ធដ៏មានអានុភាព និងអាចបត់បែនបានត្រូវបានទាមទារ ដើម្បីរៀបចំកម្មវិធីប្រភេទថ្មីនៃកម្មវិធីមូលដ្ឋានលើពពក។ យើងបានជ្រើសរើសស្នាក់នៅលើពពកនៅដើមដំបូងនៃការធ្វើដំណើររបស់យើង ដូច្នេះយើងអាចបង្កើតវេទិកាក្នុងបរិវេណដ៏រឹងមាំបំផុតដែលអាចធ្វើទៅបានដោយសន្តិភាពនៃចិត្ត។ យើងបានសម្រេចចិត្តដាក់ឱ្យប្រើប្រាស់កម្មវិធីរបស់យើងដោយប្រើ Google Kubernetes Engine ទោះបីជាយើងដឹងថាមិនយូរមិនឆាប់ យើងនឹងផ្លាស់ទៅមជ្ឈមណ្ឌលទិន្នន័យផ្ទាល់ខ្លួនរបស់យើង និងអនុវត្តយុទ្ធសាស្ត្រកូនកាត់។

ហេតុអ្វីបានជាអ្នកជ្រើសរើស GKE?

យើងបានធ្វើជម្រើសនេះជាចម្បងសម្រាប់ហេតុផលបច្ចេកទេស។ លើសពីនេះទៀត វាត្រូវការក្នុងការផ្តល់នូវហេដ្ឋារចនាសម្ព័ន្ធយ៉ាងឆាប់រហ័សដែលបំពេញតម្រូវការអាជីវកម្មរបស់ក្រុមហ៊ុន។ យើងមានតម្រូវការមួយចំនួនសម្រាប់ការបង្ហោះកម្មវិធី ដូចជាការចែកចាយតាមភូមិសាស្ត្រ ការធ្វើមាត្រដ្ឋាន និងការអត់ឱនចំពោះកំហុស។

ចង្កោម GKE នៅក្នុង Dailymotion

ដោយសារ Dailymotion គឺជាវេទិកាវីដេអូដែលមាននៅទូទាំងពិភពលោក យើងពិតជាចង់កែលម្អគុណភាពនៃសេវាកម្មដោយកាត់បន្ថយពេលវេលារង់ចាំ (ភាពយឺតយ៉ាវ)... ពីមុន API របស់យើង។ មានតែនៅទីក្រុងប៉ារីសប៉ុណ្ណោះ ដែលជាការប្រសើរបំផុត។ ខ្ញុំចង់អាចរៀបចំកម្មវិធីមិនត្រឹមតែនៅអឺរ៉ុបប៉ុណ្ណោះទេ ប៉ុន្តែក៏នៅអាស៊ី និងអាមេរិកដែរ។

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

លើសពីនេះ សេវាកម្មបណ្តាញ និងឧបករណ៍ផ្ទុកតុល្យភាពពី Google Cloud ធ្វើការងារបានយ៉ាងល្អ។ ពួកគេគ្រាន់តែអនុញ្ញាតឱ្យអ្នកប្រើអាស័យដ្ឋាន IP សាធារណៈតាមអំពើចិត្តពីតំបន់នីមួយៗ ហើយពិធីការ BGP ដ៏អស្ចារ្យបានយកចិត្តទុកដាក់លើអ្វីដែលនៅសល់ (ឧ. បញ្ជូនអ្នកប្រើប្រាស់ទៅកាន់ចង្កោមដែលនៅជិតបំផុត)។ ជាក់ស្តែង ក្នុងករណីមានការបរាជ័យ ចរាចរណ៍នឹងទៅកាន់តំបន់ផ្សេងទៀតដោយស្វ័យប្រវត្តិ ដោយមិនមានការអន្តរាគមន៍ពីមនុស្សឡើយ។

តាមដានតុល្យភាពផ្ទុក Google

វេទិការបស់យើងក៏ប្រើ GPUs ខ្លាំងផងដែរ។ Google Cloud អនុញ្ញាតឱ្យអ្នកប្រើពួកវាយ៉ាងមានប្រសិទ្ធភាពដោយផ្ទាល់នៅក្នុងចង្កោម Kubernetes ។

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

ជាលទ្ធផល យើងអាចចាប់ផ្តើមទទួលបានចរាចរណ៍ផលិតកម្មនៅលើហេដ្ឋារចនាសម្ព័ន្ធ Google Cloud ត្រឹមតែ 6 ខែបន្ទាប់ពីការចាប់ផ្តើមការងារ។

ទោះបីជាយ៉ាងណាក៏ដោយ ទោះបីជាមានគុណសម្បត្តិមួយចំនួនក៏ដោយ ការធ្វើការជាមួយអ្នកផ្តល់សេវាពពកត្រូវបានផ្សារភ្ជាប់ជាមួយនឹងការចំណាយជាក់លាក់ ដែលអាចកើនឡើងអាស្រ័យលើបន្ទុក។ នោះហើយជាមូលហេតុដែលយើងវិភាគដោយប្រុងប្រយ័ត្ននូវសេវាកម្មដែលបានគ្រប់គ្រងនីមួយៗដែលយើងបានប្រើ ដោយសង្ឃឹមថានឹងអាចអនុវត្តពួកវានៅក្នុងបរិវេណនាពេលអនាគត។ ជាការពិត ការអនុវត្តចង្កោមមូលដ្ឋានបានចាប់ផ្តើមនៅចុងឆ្នាំ 2016 ហើយយុទ្ធសាស្ត្រកូនកាត់ត្រូវបានផ្តួចផ្តើមឡើងក្នុងពេលតែមួយ។

បើកដំណើរការវេទិការៀបចំកុងតឺន័រក្នុងស្រុក Dailymotion

រដូវស្លឹកឈើជ្រុះឆ្នាំ 2016

នៅក្នុងលក្ខខណ្ឌនៅពេលដែលជង់ទាំងមូលបានត្រៀមរួចរាល់សម្រាប់ការផលិត ហើយដំណើរការលើ API បន្តវាដល់ពេលដែលត្រូវផ្តោតទៅលើក្រុមក្នុងតំបន់។

នៅពេលនោះ អ្នកប្រើប្រាស់កំពុងមើលវីដេអូច្រើនជាង 3 ពាន់លានរៀងរាល់ខែ។ ជាការពិតណាស់ យើងមានបណ្តាញចែកចាយខ្លឹមសារដ៏ទូលំទូលាយរបស់យើងអស់រយៈពេលជាច្រើនឆ្នាំ។ យើងចង់ទាញយកប្រយោជន៍ពីកាលៈទេសៈនេះ ហើយដាក់ពង្រាយក្រុម Kubernetes នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យដែលមានស្រាប់។

ហេដ្ឋារចនាសម្ព័ន្ធរបស់ Dailymotion មានម៉ាស៊ីនមេជាង 2,5 ពាន់នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យចំនួនប្រាំមួយ។ ពួកគេទាំងអស់ត្រូវបានកំណត់រចនាសម្ព័ន្ធដោយប្រើ Saltstack ។ យើងចាប់ផ្តើមរៀបចំរូបមន្តចាំបាច់ទាំងអស់សម្រាប់បង្កើតមេ និងថ្នាំងកម្មករ ក៏ដូចជាចង្កោម etcd ។

ផ្នែកបណ្តាញ

បណ្តាញរបស់យើងត្រូវបានបញ្ជួនទាំងស្រុង។ ម៉ាស៊ីនមេនីមួយៗផ្សព្វផ្សាយ IP របស់ខ្លួននៅលើបណ្តាញដោយប្រើ Exabgp ។ យើងបានប្រៀបធៀបកម្មវិធីជំនួយបណ្តាញជាច្រើន ហើយតែមួយគត់ដែលបំពេញតម្រូវការទាំងអស់ (ដោយសារវិធីសាស្រ្ត L3 ដែលបានប្រើ) គឺ កាលីកូ។. វាសមឥតខ្ចោះទៅនឹងគំរូហេដ្ឋារចនាសម្ព័ន្ធបណ្តាញដែលមានស្រាប់។

ដោយសារយើងចង់ប្រើធាតុហេដ្ឋារចនាសម្ព័ន្ធដែលមានទាំងអស់នោះ រឿងដំបូងដែលយើងត្រូវធ្វើគឺស្វែងរកឧបករណ៍ប្រើប្រាស់បណ្តាញដែលដាំដុះនៅផ្ទះរបស់យើង (ប្រើលើម៉ាស៊ីនមេទាំងអស់): ប្រើវាដើម្បីផ្សាយពាណិជ្ជកម្មជួរអាសយដ្ឋាន IP នៅលើបណ្តាញជាមួយថ្នាំង Kubernetes ។ យើងបានអនុញ្ញាតឱ្យ Calico កំណត់អាសយដ្ឋាន IP ទៅកាន់ផត ប៉ុន្តែមិនបាន និងនៅតែមិនប្រើវាសម្រាប់វគ្គ BGP នៅលើឧបករណ៍បណ្តាញ។ តាមពិត ការកំណត់ផ្លូវត្រូវបានគ្រប់គ្រងដោយ Exabgp ដែលផ្សាយពាណិជ្ជកម្មបណ្តាញរងដែលប្រើដោយ Calico ។ នេះអនុញ្ញាតឱ្យយើងទៅដល់ pod ណាមួយពីបណ្តាញខាងក្នុង (និងជាពិសេសពី load balancers) ។

របៀបដែលយើងគ្រប់គ្រងចរាចរណ៍ចូល

ដើម្បីប្តូរទិសសំណើចូលទៅកាន់សេវាកម្មដែលចង់បាន វាត្រូវបានសម្រេចចិត្តប្រើ Ingress Controller ដោយសារការរួមបញ្ចូលរបស់វាជាមួយនឹងធនធានចូល Kubernetes ។

កាលពីបីឆ្នាំមុន nginx-ingress-controller គឺជាឧបករណ៍បញ្ជាដែលមានភាពចាស់ទុំបំផុត៖ Nginx មានតាំងពីយូរយារណាស់មកហើយ ហើយត្រូវបានគេស្គាល់ថាសម្រាប់ស្ថេរភាព និងដំណើរការរបស់វា។

នៅក្នុងប្រព័ន្ធរបស់យើង យើងបានសម្រេចចិត្តដាក់ឧបករណ៍បញ្ជានៅលើម៉ាស៊ីនមេ 10-Gigabit blade ដែលឧទ្ទិស។ ឧបករណ៍បញ្ជានីមួយៗត្រូវបានភ្ជាប់ទៅចំណុចបញ្ចប់ kube-apiserver នៃចង្កោមដែលត្រូវគ្នា។ ម៉ាស៊ីនមេទាំងនេះក៏បានប្រើ Exabgp ដើម្បីផ្សាយពាណិជ្ជកម្មអាសយដ្ឋាន IP សាធារណៈ ឬឯកជនផងដែរ។ បណ្តាញ topology របស់យើងអនុញ្ញាតឱ្យយើងប្រើ BGP ពីឧបករណ៍បញ្ជាទាំងនេះដើម្បីបញ្ជូនចរាចរទាំងអស់ដោយផ្ទាល់ទៅកាន់ pods ដោយមិនចាំបាច់ប្រើសេវាកម្មដូចជា NodePort នោះទេ។ វិធីសាស្រ្តនេះជួយជៀសវាងចរាចរណ៍ផ្តេករវាងថ្នាំង និងបង្កើនប្រសិទ្ធភាព។

ចលនាចរាចរណ៍ពីអ៊ីនធឺណិតទៅផត

ឥឡូវនេះយើងយល់អំពីវេទិកាកូនកាត់របស់យើង យើងអាចស្វែងយល់កាន់តែស៊ីជម្រៅទៅក្នុងដំណើរការធ្វើចំណាកស្រុកដោយខ្លួនឯង។

ការធ្វើចំណាកស្រុកនៃចរាចរណ៍ពី Google Cloud ទៅហេដ្ឋារចនាសម្ព័ន្ធ Dailymotion

រដូវស្លឹកឈើជ្រុះឆ្នាំ 2018

បន្ទាប់ពីជិតពីរឆ្នាំនៃការសាងសង់ ការធ្វើតេស្ត និងការលៃតម្រូវ ទីបំផុតយើងមានជង់ Kubernetes ពេញលេញដែលត្រៀមរួចជាស្រេចដើម្បីទទួលយកចរាចរណ៍មួយចំនួន។

យុទ្ធសាស្ត្រកំណត់ផ្លូវបច្ចុប្បន្នគឺសាមញ្ញណាស់ ប៉ុន្តែគ្រប់គ្រាន់ដើម្បីបំពេញតម្រូវការ។ បន្ថែមពីលើ IPs សាធារណៈ (នៅលើ Google Cloud និង Dailymotion) AWS Route 53 ត្រូវបានប្រើដើម្បីកំណត់គោលការណ៍ និងបញ្ជូនអ្នកប្រើប្រាស់ទៅកាន់ចង្កោមនៃជម្រើសរបស់យើង។

ឧទាហរណ៍គោលការណ៍កំណត់ផ្លូវដោយប្រើផ្លូវលេខ 53

ជាមួយនឹង Google Cloud វាមានភាពងាយស្រួលនៅពេលដែលយើងចែករំលែក IP តែមួយនៅទូទាំងចង្កោមទាំងអស់ ហើយអ្នកប្រើប្រាស់ត្រូវបានបញ្ជូនបន្តទៅកាន់ចង្កោម GKE ដែលនៅជិតបំផុត។ សម្រាប់ក្រុមរបស់យើង បច្ចេកវិទ្យាគឺខុសគ្នា ដោយសារ IPs របស់ពួកគេខុសគ្នា។

ក្នុងអំឡុងពេលនៃការធ្វើចំណាកស្រុក យើងបានស្វែងរកការបញ្ជូនបន្តសំណើក្នុងតំបន់ទៅកាន់ក្រុមដែលសមស្រប និងវាយតម្លៃអត្ថប្រយោជន៍នៃវិធីសាស្រ្តនេះ។

ដោយសារចង្កោម GKE របស់យើងត្រូវបានកំណត់រចនាសម្ព័ន្ធដោយស្វ័យប្រវត្តិដោយប្រើមាត្រដ្ឋានផ្ទាល់ខ្លួន ពួកវាធ្វើមាត្រដ្ឋានឡើង/ចុះដោយផ្អែកលើចរាចរណ៍ចូល។

ក្នុងរបៀបធម្មតា ចរាចរណ៍ក្នុងតំបន់ទាំងអស់ត្រូវបានតម្រង់ទៅចង្កោមមូលដ្ឋាន ហើយ GKE បម្រើជាទុនបម្រុងក្នុងករណីមានបញ្ហា (ការពិនិត្យសុខភាពត្រូវបានអនុវត្តតាមផ្លូវ 53)។

...

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

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

អ្នកក៏អាចចាប់អារម្មណ៍លើការបង្ហោះ Dailymotion ថ្មីៗផ្សេងទៀតអំពី Kubernetes ផងដែរ។ វាត្រូវបានឧទ្ទិសដល់ការដាក់ឱ្យប្រើប្រាស់កម្មវិធីជាមួយ Helm នៅលើចង្កោម Kubernetes ជាច្រើន និង ត្រូវបានបោះពុម្ពផ្សាយ ប្រហែលមួយខែមុន។

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

ប្រភព: www.habr.com

ដំណើរផ្សងព្រេង Kubernetes Dailymotion៖ បង្កើតហេដ្ឋារចនាសម្ព័ន្ធនៅក្នុងពពក + បរិវេណ