បញ្ហាជាមួយ DNS នៅក្នុង Kubernetes ។ សាកសពសាធារណៈ

ចំណាំ ការបកប្រែ៖ នេះ​ជា​ការ​បកប្រែ​នៃ​ការ​ធ្វើ​កោសល្យវិច័យ​សាធារណៈ​ពី​ប្លុក​វិស្វកម្ម​របស់​ក្រុមហ៊ុន ពិសេស. វាពិពណ៌នាអំពីបញ្ហាជាមួយ conntrack នៅក្នុងចង្កោម Kubernetes ដែលនាំឱ្យមានការផ្អាកមួយផ្នែកនៃសេវាកម្មផលិតកម្មមួយចំនួន។

អត្ថបទនេះអាចមានប្រយោជន៍សម្រាប់អ្នកដែលចង់ស្វែងយល់បន្ថែមបន្តិចអំពីសាកសពក្រោយការស្លាប់ ឬការពារបញ្ហា DNS ដែលអាចកើតមាននាពេលអនាគត។

នេះមិនមែនជា DNS ទេ។
វាមិនអាចជា DNS បានទេ។
វាជា DNS

បន្តិចអំពីសាកសព និងដំណើរការនៅក្នុង Preply

សាកសពពិពណ៌នាអំពីដំណើរការខុសប្រក្រតី ឬព្រឹត្តិការណ៍មួយចំនួននៅក្នុងផលិតកម្ម។ សាកសពក្រោយការស្លាប់រួមមានការកំណត់ពេលវេលានៃព្រឹត្តិការណ៍ ការពិពណ៌នាអំពីផលប៉ះពាល់របស់អ្នកប្រើប្រាស់ មូលហេតុឫសគល់ សកម្មភាពដែលបានធ្វើឡើង និងមេរៀនដែលបានរៀន។

ស្វែងរក SRE

នៅក្នុងកិច្ចប្រជុំប្រចាំសប្តាហ៍ជាមួយភីហ្សា ក្នុងចំណោមក្រុមបច្ចេកទេស យើងចែករំលែកព័ត៌មានផ្សេងៗ។ ផ្នែកមួយដ៏សំខាន់បំផុតនៃកិច្ចប្រជុំបែបនេះគឺ សាកសពក្រោយសាកសព ដែលភាគច្រើនត្រូវបានអមដោយការបង្ហាញជាមួយស្លាយ និងការវិភាគស៊ីជម្រៅបន្ថែមទៀតអំពីឧប្បត្តិហេតុ។ ទោះ​បី​យើង​មិន​ទះ​ដៃ​ក្រោយ​ការ​ស្លាប់​ក៏​ដោយ ក៏​យើង​ព្យាយាម​បង្កើត​វប្បធម៌​«គ្មាន​កំហុស» (វប្បធម៌គ្មានកំហុស) យើងជឿថាការសរសេរ និងការធ្វើបទបង្ហាញអំពីសាកសពអាចជួយយើង (និងអ្នកផ្សេងទៀត) ការពារឧប្បត្តិហេតុស្រដៀងគ្នានេះនាពេលអនាគត ដែលជាមូលហេតុដែលយើងចែករំលែកវា។

បុគ្គលដែលចូលរួមក្នុងឧប្បត្តិហេតុមួយគួរតែមានអារម្មណ៍ថាពួកគេអាចនិយាយយ៉ាងលម្អិតដោយមិនខ្លាចការដាក់ទណ្ឌកម្ម ឬការសងសឹក។ អត់បន្ទោសទេ! ការ​សរសេរ​សំបុត្រ​មិន​មែន​ជា​ការ​ដាក់​ទោស​ទេ ប៉ុន្តែ​ជា​ឱកាស​សិក្សា​សម្រាប់​ក្រុមហ៊ុន​ទាំង​មូល។

Keep CALMS & DevOps: S គឺសម្រាប់ការចែករំលែក

បញ្ហាជាមួយ DNS នៅក្នុង Kubernetes ។ សាកសព

កាលបរិច្ឆេទ: 28.02.2020

អ្នកនិពន្ធ៖ Amet U., Andrey S., Igor K., Alexey P.

ស្ថានភាព៖ ចប់

សង្ខេប: ភាពមិនមាន DNS មួយផ្នែក (26 នាទី) សម្រាប់សេវាកម្មមួយចំនួននៅក្នុងចង្កោម Kubernetes

ឥទ្ធិពល៖ ព្រឹត្តិការណ៍ចំនួន 15000 បានបាត់បង់សម្រាប់សេវាកម្ម A, B និង C

ដើមហេតុ: Kube-proxy មិនអាចលុបធាតុចាស់ចេញពីតារាង conntrack បានត្រឹមត្រូវទេ ដូច្នេះសេវាកម្មមួយចំនួននៅតែព្យាយាមភ្ជាប់ទៅផតដែលមិនមាន

E0228 20:13:53.795782       1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...

កេះ៖ ដោយសារការផ្ទុកទាបនៅក្នុងចង្កោម Kubernetes CoreDNS-autoscaler បានកាត់បន្ថយចំនួនផតនៅក្នុងការដាក់ពង្រាយពីបីទៅពីរ

ជាដំណោះស្រាយ: ការដាក់ពង្រាយកម្មវិធីបន្ទាប់បានផ្តួចផ្តើមបង្កើតថ្នាំងថ្មី CoreDNS-autoscaler បានបន្ថែមផតបន្ថែមទៀតដើម្បីបម្រើចង្កោម ដែលបង្កឱ្យមានការសរសេរឡើងវិញនៃតារាង conntrack ។

ការរកឃើញ៖ ការត្រួតពិនិត្យ Prometheus បានរកឃើញកំហុស 5xx មួយចំនួនធំសម្រាប់សេវាកម្ម A, B និង C ហើយបានចាប់ផ្តើមការហៅទៅកាន់វិស្វករដែលកំពុងបំពេញកាតព្វកិច្ច

កំហុស 5xx នៅក្នុង Kibana

សកម្មភាព

ផលប៉ះពាល់
វាយ
ទទួលខុសត្រូវ
គោលបំណង

បិទដំណើរការកម្មវិធីកំណត់ទំហំស្វ័យប្រវត្តិសម្រាប់ CoreDNS
រារាំង
អាម៉េត យូ.
DEVOPS-695

ដំឡើងម៉ាស៊ីនមេ DNS ឃ្លាំងសម្ងាត់
ថយចុះ
អតិបរមា V.
DEVOPS-665

រៀបចំការត្រួតពិនិត្យ conntrack
រារាំង
អាម៉េត យូ.
DEVOPS-674

មេរៀនដែលបានរៀន

អ្វីដែលដំណើរការល្អ៖

• ការត្រួតពិនិត្យដំណើរការបានល្អ។ ការឆ្លើយតបគឺលឿន និងរៀបចំ
• យើងមិនបានឈានដល់ដែនកំណត់ណាមួយនៅលើថ្នាំងទេ។

តើមានអ្វីខុស៖

• មិនទាន់ដឹងមូលហេតុពិតប្រាកដ ស្រដៀងនឹង កំហុសជាក់លាក់ នៅ​ក្នុង​ការ​ជាប់​គាំង
• សកម្មភាពទាំងអស់កែតែលទ្ធផល មិនមែនមូលហេតុដើម (កំហុស)
• យើងបានដឹងហើយថា មិនយូរមិនឆាប់ យើងអាចមានបញ្ហាជាមួយ DNS ប៉ុន្តែយើងមិនបានផ្តល់អាទិភាពដល់កិច្ចការនោះទេ។

កន្លែងដែលយើងមានសំណាង៖

• ការដាក់ពង្រាយបន្ទាប់ត្រូវបានបង្កឡើងដោយ CoreDNS-autoscaler ដែលសរសេរជាន់ពីលើតារាង conntrack
• កំហុសនេះប៉ះពាល់តែសេវាកម្មមួយចំនួនប៉ុណ្ណោះ។

បន្ទាត់ពេលវេលា (EET)

Время
ផលប៉ះពាល់

22:13
CoreDNS-autoscaler បានកាត់បន្ថយចំនួន pods ពីបីទៅពីរ

22:18
វិស្វករដែលបំពេញកាតព្វកិច្ចបានចាប់ផ្តើមទទួលការហៅទូរស័ព្ទពីប្រព័ន្ធត្រួតពិនិត្យ

22:21
វិស្វករដែលកំពុងបំពេញភារកិច្ចបានចាប់ផ្តើមស្វែងរកមូលហេតុនៃកំហុស។

22:39
វិស្វករ​ដែល​ទទួល​បន្ទុក​បាន​ចាប់​ផ្តើម​ត្រឡប់​សេវាកម្ម​ចុង​ក្រោយ​បំផុត​មួយ​ទៅ​កំណែ​មុន។

22:40
កំហុស 5xx ឈប់លេចឡើង ស្ថានភាពមានស្ថេរភាព

• ពេលវេលាដើម្បីរកឱ្យឃើញ៖ 4 នាទី
• ពេលវេលាមុនពេលធ្វើសកម្មភាព៖ 21 នាទី
• ពេលវេលាដើម្បីជួសជុល៖ 1 នាទី

បន្ថែម

• កំណត់ហេតុ CoreDNS៖

  I0228 20:13:53.507780       1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2

• តំណភ្ជាប់ទៅ Kibana (កាត់), Grafana (កាត់)
• កន្លែងដែល Linux conntrack មិនមែនជាមិត្តរបស់អ្នកទៀតទេ
• kube-proxy Subtleties៖ បំបាត់កំហុស ការកំណត់ការតភ្ជាប់បណ្តោះអាសន្នឡើងវិញ
• ការអស់ពេលស្វែងរក DNS និង Racy conntrack

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

របៀបដែលកុងតាក់ដំណើរការ

លទ្ធផល

នេះគឺជាឧទាហរណ៍មួយនៃសាកសពក្រោយការស្លាប់របស់យើងជាមួយនឹងតំណភ្ជាប់មានប្រយោជន៍មួយចំនួន។ ជាពិសេសនៅក្នុងអត្ថបទនេះ យើងចែករំលែកព័ត៌មានដែលអាចមានប្រយោជន៍ដល់ក្រុមហ៊ុនផ្សេងៗ។ នោះហើយជាមូលហេតុដែលយើងមិនខ្លាចក្នុងការធ្វើខុស ហើយនោះជាមូលហេតុដែលយើងធ្វើឱ្យការស្លាប់មួយរបស់យើងជាសាធារណៈ។ ខាង​ក្រោម​នេះ​ជា​សព​សាធារណៈ​គួរ​ឲ្យ​ចាប់​អារម្មណ៍​ជាង​នេះ៖

• GitLab៖ Postmortem នៃការដាច់ប្រព័ន្ធទិន្នន័យថ្ងៃទី 31 ខែមករា
• Dropbox: ការដាច់ចរន្តអគ្គិសនីក្រោយការស្លាប់
• Spotify: ទំនាក់ទំនងស្នេហា / ស្អប់របស់ Spotify ជាមួយ DNS
• អ្នកផ្សេងទៀតជាច្រើនមកពី ខ្លឹមសារនេះ។ និងឃ្លាំង រឿងរ៉ាវបរាជ័យ Kubernetes
• ផងដែរ ឧទាហរណ៍ សាកសពសាធារណៈជាមួយ SRE Book

ប្រភព: www.habr.com