ការខកខានចំនួនប្រាំនៅពេលដាក់ពង្រាយកម្មវិធីដំបូងនៅលើ Kubernetes

បរាជ័យដោយ Aris-Dreamer

មនុស្សជាច្រើនជឿថាវាគ្រប់គ្រាន់ហើយក្នុងការផ្ទេរកម្មវិធីទៅ Kubernetes (ទាំងប្រើ Helm ឬដោយដៃ) ហើយពួកគេនឹងសប្បាយចិត្ត។ ប៉ុន្តែវាមិនសាមញ្ញនោះទេ។

ក្រុមការងារ ដំណោះស្រាយពពក Mail.ru បកប្រែអត្ថបទដោយវិស្វករ DevOps Julian Gindi ។ គាត់ចែករំលែកពីភាពលំបាកដែលក្រុមហ៊ុនរបស់គាត់ជួបប្រទះក្នុងដំណើរការចំណាកស្រុក ដើម្បីកុំឱ្យអ្នកដើរលើតុងរួចដូចគ្នា។

ជំហាន​ទី​មួយ៖ ការ​កំណត់​ការ​ស្នើ​សុំ​ផត និង​ដែន​កំណត់

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

សំណើ Pod - នេះគឺជាតម្លៃចម្បងដែលប្រើដោយអ្នកកំណត់ពេលដើម្បីដាក់ pod ឱ្យល្អបំផុត។

ពី ឯកសារ Kubernetes៖ ជំហាន​ត្រង​កំណត់​សំណុំ​ថ្នាំង​ដែល​អាច​កំណត់​កាលវិភាគ។ ឧទាហរណ៍ តម្រង PodFitsResources ពិនិត្យមើលថាតើថ្នាំងមានធនធានគ្រប់គ្រាន់ដើម្បីបំពេញសំណើធនធានជាក់លាក់របស់ pod ដែរឬទេ។

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

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

ដែនកំណត់ Pod - នេះគឺជាដែនកំណត់កាន់តែច្បាស់សម្រាប់ផត។ វាតំណាងឱ្យចំនួនអតិបរមានៃធនធានដែលចង្កោមនឹងបែងចែកទៅកុងតឺន័រ។

ជាថ្មីម្តងទៀតពី ឯកសារផ្លូវការ៖ ប្រសិនបើកុងតឺន័រមានដែនកំណត់អង្គចងចាំ 4 GiB នោះ kubelet (និងរយៈពេលដំណើរការកុងតឺន័រ) នឹងបង្ខំវា។ ពេលវេលាដំណើរការមិនអនុញ្ញាតឱ្យកុងតឺន័រប្រើប្រាស់លើសពីដែនកំណត់ធនធានដែលបានបញ្ជាក់នោះទេ។ ឧទាហរណ៍ នៅពេលដំណើរការនៅក្នុងកុងតឺន័រព្យាយាមប្រើច្រើនជាងចំនួនអង្គចងចាំដែលអនុញ្ញាត ខឺណែលប្រព័ន្ធនឹងបញ្ចប់ដំណើរការជាមួយនឹងកំហុស "អស់អង្គចងចាំ" (OOM) ។

កុងតឺន័រតែងតែអាចប្រើប្រាស់ធនធានច្រើនជាងអ្វីដែលបានបញ្ជាក់នៅក្នុងសំណើធនធាន ប៉ុន្តែមិនអាចប្រើប្រាស់លើសពីការកំណត់ក្នុងដែនកំណត់នោះទេ។ តម្លៃនេះពិបាកក្នុងការកំណត់ត្រឹមត្រូវ ប៉ុន្តែវាមានសារៈសំខាន់ខ្លាំងណាស់។

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

ជាអកុសល ខ្ញុំមិនអាចផ្តល់ការណែនាំជាក់លាក់អំពីតម្លៃដែលត្រូវកំណត់បានទេ ប៉ុន្តែយើងខ្លួនយើងប្រកាន់ខ្ជាប់នូវច្បាប់ខាងក្រោម៖

1. ដោយប្រើឧបករណ៍សាកល្បងផ្ទុក យើងក្លែងធ្វើកម្រិតមូលដ្ឋាននៃចរាចរណ៍ និងតាមដានការប្រើប្រាស់ធនធានផត (អង្គចងចាំ និងខួរក្បាល)។
2. យើងកំណត់សំណើរបស់ pod ទៅតម្លៃទាបតាមអំពើចិត្ត (ជាមួយនឹងដែនកំណត់ធនធានប្រហែល 5 ដងនៃតម្លៃនៃសំណើ) ហើយសង្កេត។ នៅពេលដែលសំណើមានកម្រិតទាបពេក ដំណើរការមិនអាចចាប់ផ្តើមបានទេ ដែលជារឿយៗបណ្តាលឱ្យមានកំហុសពេលដំណើរការ Go ​​អាថ៌កំបាំង។

ចំណាំថាដែនកំណត់ធនធានខ្ពស់ធ្វើឱ្យការកំណត់កាលវិភាគកាន់តែពិបាក ពីព្រោះផតត្រូវការថ្នាំងគោលដៅដែលមានធនធានគ្រប់គ្រាន់។

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

ជំហានទីពីរ៖ រៀបចំការធ្វើតេស្តភាពរស់រវើក និងត្រៀមខ្លួនជាស្រេច

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

ភាពរស់រវើក បង្ហាញថាតើកុងតឺន័រកំពុងដំណើរការឬអត់។ ប្រសិនបើវាបរាជ័យ kubelet សម្លាប់កុងតឺន័រ ហើយគោលការណ៍ចាប់ផ្តើមឡើងវិញត្រូវបានបើកសម្រាប់វា។ ប្រសិនបើកុងតឺន័រមិនត្រូវបានបំពាក់ជាមួយនឹងការស៊ើបអង្កេត Liveness នោះស្ថានភាពលំនាំដើមនឹងទទួលបានជោគជ័យ - នេះជាអ្វីដែលវានិយាយនៅក្នុង ឯកសារ Kubernetes.

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

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

នៅក្រុមហ៊ុនរបស់យើង ការធ្វើតេស្ត Liveness ពិនិត្យមើលសមាសធាតុស្នូលនៃកម្មវិធី ទោះបីជាទិន្នន័យ (ឧទាហរណ៍ ពីឃ្លាំងទិន្នន័យពីចម្ងាយ ឬឃ្លាំងសម្ងាត់) មិនអាចចូលប្រើបានពេញលេញក៏ដោយ។

យើង​បាន​កំណត់​រចនាសម្ព័ន្ធ​កម្មវិធី​ដោយ​មាន​ចំណុច​បញ្ចប់ "សុខភាព" ដែល​គ្រាន់តែ​ត្រឡប់​លេខ​កូដ​ឆ្លើយតប​ចំនួន 200។ នេះ​ជា​ការ​បង្ហាញ​ថា​ដំណើរការ​កំពុង​ដំណើរការ និង​អាច​ដំណើរការ​សំណើ​បាន (ប៉ុន្តែ​មិន​ទាន់​មាន​ចរាចរណ៍)។

គំរូ។ ការត្រៀមខ្លួន។ បង្ហាញថាតើកុងតឺន័ររួចរាល់ដើម្បីបម្រើសំណើ។ ប្រសិនបើការស៊ើបអង្កេតការត្រៀមខ្លួនបរាជ័យ ឧបករណ៍បញ្ជាចំណុចបញ្ចប់នឹងដកអាសយដ្ឋាន IP របស់ផត ចេញពីចំណុចបញ្ចប់នៃសេវាកម្មទាំងអស់ដែលត្រូវគ្នានឹងផត។ នេះក៏ត្រូវបានបញ្ជាក់នៅក្នុងឯកសារ Kubernetes ផងដែរ។

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

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

ប្រសិនបើអ្នកសម្រេចចិត្តសួរមូលដ្ឋានទិន្នន័យដើម្បីសាកល្បងការត្រៀមខ្លួននៃកម្មវិធីរបស់អ្នក សូមប្រាកដថាវាមានតម្លៃថោកតាមដែលអាចធ្វើទៅបាន។ ចូរយើងទទួលយកសំណើនេះ៖

SELECT small_item FROM table LIMIT 1

នេះជាឧទាហរណ៍អំពីរបៀបដែលយើងកំណត់តម្លៃទាំងពីរនេះនៅក្នុង Kubernetes៖

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

អ្នកអាចបន្ថែមជម្រើសកំណត់រចនាសម្ព័ន្ធបន្ថែមមួយចំនួន៖

• initialDelaySeconds - តើប៉ុន្មានវិនាទីនឹងឆ្លងកាត់រវាងការបើកដំណើរការកុងតឺន័រ និងការចាប់ផ្តើមនៃគំរូ។
• periodSeconds - ចន្លោះពេលរង់ចាំរវាងការរត់គំរូ។
• timeoutSeconds - ចំនួន​វិនាទី​បន្ទាប់​ពី​នោះ​អង្គភាព​ត្រូវ​បាន​ចាត់​ទុក​ថា​មាន​អាសន្ន។ ការអស់ពេលទៀងទាត់។
• failureThreshold - ចំនួននៃការបរាជ័យនៃការធ្វើតេស្ត មុនពេលសញ្ញាចាប់ផ្តើមឡើងវិញត្រូវបានផ្ញើទៅកាន់ផត។
• successThreshold - ចំនួននៃការស៊ើបអង្កេតដែលទទួលបានជោគជ័យមុនពេល pod ចូលទៅក្នុងស្ថានភាពរួចរាល់ (បន្ទាប់ពីការបរាជ័យនៅពេលដែល pod ចាប់ផ្តើមឬងើបឡើងវិញ) ។

ជំហានទីបី៖ រៀបចំគោលការណ៍បណ្តាញលំនាំដើមសម្រាប់ផត

Kubernetes មានសណ្ឋានដីបណ្តាញ "ផ្ទះល្វែង" តាមលំនាំដើម ផតទាំងអស់ទាក់ទងដោយផ្ទាល់ជាមួយគ្នាទៅវិញទៅមក។ ក្នុងករណីខ្លះនេះមិនគួរឱ្យចង់បានទេ។

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

ជាឧទាហរណ៍ ខាងក្រោមនេះគឺជាគោលការណ៍សាមញ្ញមួយ ដែលបដិសេធរាល់ចរាចរណ៍ចូលសម្រាប់ទំហំឈ្មោះជាក់លាក់មួយ៖

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

ការមើលឃើញនៃការកំណត់រចនាសម្ព័ន្ធនេះ៖

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
ព័ត៌មានលម្អិតបន្ថែម នៅទីនេះ.

ជំហានទីបួន៖ ឥរិយាបថផ្ទាល់ខ្លួនដោយប្រើទំពក់ និងកុងតឺន័រ init

គោលដៅចម្បងមួយរបស់យើងគឺដើម្បីផ្តល់នូវការដាក់ឱ្យប្រើប្រាស់ទៅកាន់ Kubernetes ដោយគ្មានពេលសម្រាកសម្រាប់អ្នកអភិវឌ្ឍន៍។ នេះ​ជា​ការ​លំបាក​ព្រោះ​មាន​ជម្រើស​ជា​ច្រើន​សម្រាប់​ការ​បិទ​កម្មវិធី​និង​ការ​បង្កើន​ធនធាន​ដែល​ពួកគេ​បាន​ប្រើ។

ការលំបាកជាពិសេសបានកើតឡើងជាមួយ Nginx. យើងបានកត់សម្គាល់ឃើញថា នៅពេលដែលផតទាំងនេះត្រូវបានដាក់ឱ្យប្រើប្រាស់ជាបន្តបន្ទាប់ ការតភ្ជាប់សកម្មត្រូវបានទម្លាក់មុនពេលបញ្ចប់ដោយជោគជ័យ។

បន្ទាប់ពីការស្រាវជ្រាវយ៉ាងទូលំទូលាយតាមអ៊ីនធឺណិត វាប្រែថា Kubernetes មិនរង់ចាំការតភ្ជាប់ Nginx ឱ្យអស់មុននឹងបញ្ចប់ផតនោះទេ។ ដោយប្រើទំពក់មុនឈប់ យើងបានអនុវត្តមុខងារខាងក្រោម ហើយបានកម្ចាត់ចោលទាំងស្រុងនូវពេលវេលារងចាំ៖

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

ប៉ុន្តែ nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

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

គ្រោងការណ៍ទូទៅមួយទៀតគឺការចូលប្រើអាថ៌កំបាំងនៅក្នុងកុងតឺន័រ init ដែលផ្តល់ព័ត៌មានបញ្ជាក់អត្តសញ្ញាណទាំងនោះទៅម៉ូឌុលមេ ដែលការពារការចូលដំណើរការសម្ងាត់ដោយគ្មានការអនុញ្ញាតពីម៉ូឌុលកម្មវិធីសំខាន់ដោយខ្លួនឯង។

ដូចធម្មតា ដកស្រង់ចេញពីឯកសារ៖ Init containers ដំណើរការកូដផ្ទាល់ខ្លួន ឬឧបករណ៍ប្រើប្រាស់ដោយសុវត្ថិភាព ដែលនឹងកាត់បន្ថយសុវត្ថិភាពនៃរូបភាពធុងកម្មវិធី។ ដោយរក្សាឧបករណ៍ដែលមិនចាំបាច់ដាច់ដោយឡែក អ្នកកំណត់ផ្ទៃវាយប្រហារនៃរូបភាពកុងតឺន័រកម្មវិធី។

ជំហានទីប្រាំ៖ កំណត់រចនាសម្ព័ន្ធខឺណែល

ជាចុងក្រោយ សូមនិយាយអំពីបច្ចេកទេសកាន់តែទំនើប។

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

ទោះយ៉ាងណាក៏ដោយ Kubernetes អនុញ្ញាតឱ្យអ្នកដំណើរការកុងតឺន័រដែលមានសិទ្ធិដែលផ្លាស់ប្តូរប៉ារ៉ាម៉ែត្រខឺណែលសម្រាប់តែផតជាក់លាក់ប៉ុណ្ណោះ។ នេះជាអ្វីដែលយើងធ្លាប់ផ្លាស់ប្តូរចំនួនអតិបរមានៃការតភ្ជាប់ដែលបើកចំហរ៖

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

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

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

ខណៈពេលដែល Kubernetes ហាក់ដូចជាដំណោះស្រាយដែលត្រៀមរួចជាស្រេចចេញពីប្រអប់នោះ មានជំហានសំខាន់ៗមួយចំនួនដែលអ្នកត្រូវធ្វើ ដើម្បីរក្សាកម្មវិធីរបស់អ្នកឱ្យដំណើរការយ៉ាងរលូន។

ឆ្លងកាត់ការធ្វើចំណាកស្រុក Kubernetes របស់អ្នក វាមានសារៈសំខាន់ណាស់ក្នុងការអនុវត្តតាម "វដ្តនៃការធ្វើតេស្តផ្ទុក"៖ បើកដំណើរការកម្មវិធី សាកល្បងផ្ទុកវា សង្កេតមើលមាត្រដ្ឋាន និងឥរិយាបថនៃការធ្វើមាត្រដ្ឋាន កែតម្រូវការកំណត់ដោយផ្អែកលើទិន្នន័យនោះ បន្ទាប់មកធ្វើវដ្តម្តងទៀត។

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

តែងតែសួរខ្លួនឯងនូវសំណួរទាំងនេះ៖

1. តើកម្មវិធីប្រើប្រាស់ធនធានប៉ុន្មាន ហើយបរិមាណនេះនឹងផ្លាស់ប្តូរយ៉ាងដូចម្តេច?
2. តើតម្រូវការធ្វើមាត្រដ្ឋានពិតប្រាកដគឺជាអ្វី? តើកម្មវិធីនឹងគ្រប់គ្រងចរាចរណ៍ជាមធ្យមប៉ុន្មាន? ចុះ​ចរាចរណ៍​ខ្លាំង​វិញ?
3. តើសេវាកម្មត្រូវការធ្វើមាត្រដ្ឋានផ្ដេកញឹកញាប់ប៉ុណ្ណា? តើ​ផត​ថ្មី​ត្រូវ​នាំ​ចូល​អ៊ីនធឺណិត​លឿន​ប៉ុណ្ណា​ដើម្បី​ទទួល​បាន​ចរាចរណ៍?
4. តើ​ការ​បិទ​ទ្វារ​បាន​ត្រឹម​ត្រូវ​ដោយ​របៀប​ណា? តើនេះចាំបាច់ទាល់តែសោះ? តើ​វា​អាច​សម្រេច​បាន​ការ​ដាក់​ពង្រាយ​ដោយ​គ្មាន​ពេល​វេលា​ទេ?
5. តើអ្នកអាចកាត់បន្ថយហានិភ័យសុវត្ថិភាព និងកម្រិតការខូចខាតពីផតឃែរដែលត្រូវបានសម្របសម្រួលដោយរបៀបណា? តើសេវាកម្មណាមួយមានការអនុញ្ញាត ឬការចូលប្រើដែលពួកគេមិនត្រូវការ?

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

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

តើមានអ្វីទៀតដែលត្រូវអាន៖

1. ការអនុវត្តល្អបំផុត និងការអនុវត្តល្អបំផុតសម្រាប់ការដំណើរការកុងតឺន័រ និង Kubernetes នៅក្នុងបរិយាកាសផលិតកម្ម.
2. ឧបករណ៍មានប្រយោជន៍ 90+ សម្រាប់ Kubernetes៖ ការដាក់ពង្រាយ ការគ្រប់គ្រង ការត្រួតពិនិត្យ សុវត្ថិភាព និងច្រើនទៀត.
3. ប៉ុស្តិ៍របស់យើងនៅជុំវិញ Kubernetes នៅក្នុង Telegram.

ប្រភព: www.habr.com