គន្លឹះអនុវត្ត Kubernetes ប្រាំបួន

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

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

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

1. ត្រួតពិនិត្យក្រុម និងធនធានកម្មវិធី

វិធីសាស្រ្តមួយក្នុងចំណោមវិធីសាស្ត្រសាមញ្ញបំផុត ប៉ុន្តែមានប្រសិទ្ធភាពគឺការណែនាំអំពីសំណើ/ដែនកំណត់។ បែងចែកកម្មវិធីដោយ namespaces និង namespaces ដោយក្រុមអភិវឌ្ឍន៍។ មុនពេលដាក់ឱ្យប្រើប្រាស់ កំណត់តម្លៃកម្មវិធីសម្រាប់ការប្រើប្រាស់ពេលវេលាដំណើរការ អង្គចងចាំ និងការផ្ទុកមិនទៀងទាត់។

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

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

លើសពីនេះទៀតដោយមានជំនួយ limitranges នៅពេលចាប់ផ្តើម អ្នកអាចកំណត់តម្លៃធនធានសម្រាប់កុងតឺន័រ - អប្បបរមា អតិបរមា និងលំនាំដើម៖

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

កុំភ្លេចកំណត់ធនធាន namespace ដូច្នេះក្រុមមួយមិនអាចគ្រប់គ្រងធនធានទាំងអស់នៃចង្កោមបានទេ៖

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

ដូចដែលអាចមើលឃើញពីការពិពណ៌នា resourcequotasប្រសិនបើក្រុម ops ចង់ដាក់ពង្រាយ pods ដែលនឹងប្រើប្រាស់ស៊ីភីយូ 10 ផ្សេងទៀត អ្នកកំណត់ពេលនឹងមិនអនុញ្ញាតទេ ហើយនឹងបោះកំហុសមួយ៖

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

ដើម្បីដោះស្រាយបញ្ហាបែបនេះអ្នកអាចសរសេរឧបករណ៍ឧទាហរណ៍ដូចជា នេះអាចរក្សាទុក និងប្រព្រឹត្តិកម្មស្ថានភាពនៃធនធានពាក្យបញ្ជា។

2. ជ្រើសរើសទំហំផ្ទុកឯកសារល្អបំផុត

នៅទីនេះខ្ញុំចង់ប៉ះលើប្រធានបទនៃភាគបន្ត និងប្រព័ន្ធរងនៃឌីសនៃថ្នាំងកម្មករ Kubernetes ។ ខ្ញុំសង្ឃឹមថាគ្មាននរណាម្នាក់ប្រើ "Cube" នៅលើ HDD ក្នុងការផលិតនោះទេ ប៉ុន្តែពេលខ្លះ SSD ធម្មតាមិនគ្រប់គ្រាន់ទៀតទេ។ យើងជួបប្រទះបញ្ហាដែលកំណត់ហេតុកំពុងសម្លាប់ថាសដោយសារប្រតិបត្តិការ I/O ហើយមិនមានដំណោះស្រាយច្រើនទេ៖

• ប្រើ SSDs ដែលមានប្រសិទ្ធភាពខ្ពស់ ឬប្តូរទៅ NVMe (ប្រសិនបើអ្នកគ្រប់គ្រងផ្នែករឹងផ្ទាល់ខ្លួនរបស់អ្នក)។

• កាត់បន្ថយកម្រិតនៃការកាប់ឈើ។

• ធ្វើសមតុល្យ "ឆ្លាតវៃ" នៃផតដែលរំលោភលើថាស (podAntiAffinity).

អេក្រង់ខាងលើបង្ហាញពីអ្វីដែលកើតឡើងនៅក្រោម nginx-ingress-controller ទៅកាន់ថាស នៅពេលដែលការចូលដំណើរការ logs ត្រូវបានបើក (~12 ពាន់កំណត់ហេតុ/វិនាទី)។ លក្ខខណ្ឌនេះអាចនាំឱ្យមានការរិចរិលនៃកម្មវិធីទាំងអស់នៅលើថ្នាំងនេះ។

សម្រាប់ PV, alas, ខ្ញុំមិនបានព្យាយាមអ្វីគ្រប់យ៉ាង ទស្សនៈ បរិមាណជាប់លាប់។ ប្រើជម្រើសដ៏ល្អបំផុតដែលសាកសមនឹងអ្នក។ ជាប្រវត្តិសាស្ត្រ វាបានកើតឡើងនៅក្នុងប្រទេសរបស់យើងដែលផ្នែកតូចមួយនៃសេវាកម្មត្រូវការបរិមាណ RWX ហើយតាំងពីយូរយារណាស់មកហើយ ពួកគេបានចាប់ផ្តើមប្រើប្រាស់កន្លែងផ្ទុក NFS សម្រាប់កិច្ចការនេះ។ ថោកហើយ... គ្រប់គ្រាន់ហើយ។ ពិតណាស់ គាត់ និងខ្ញុំបានញ៉ាំអី - ជូនពរអ្នក ប៉ុន្តែយើងបានរៀនកែវា ហើយក្បាលរបស់ខ្ញុំមិនឈឺទៀតទេ។ ហើយប្រសិនបើអាចធ្វើបាន សូមផ្លាស់ទីទៅកន្លែងផ្ទុកវត្ថុ S3 ។

3. ប្រមូលរូបភាពដែលបានកែលម្អ

វាជាការល្អបំផុតក្នុងការប្រើរូបភាពដែលកែលម្អកុងតឺន័រ ដើម្បីឱ្យ Kubernetes អាចទាញយកពួកវាបានលឿនជាងមុន និងដំណើរការពួកវាកាន់តែមានប្រសិទ្ធភាព។ 

Optimized មានន័យថារូបភាព៖

• មានកម្មវិធីតែមួយ ឬអនុវត្តមុខងារតែមួយ។

• ទំហំតូច ពីព្រោះរូបភាពធំត្រូវបានបញ្ជូនកាន់តែអាក្រក់នៅលើបណ្តាញ។

• មានចំណុចបញ្ចប់នៃសុខភាព និងការត្រៀមខ្លួនដែលអនុញ្ញាតឱ្យ Kubernetes ធ្វើសកម្មភាពក្នុងព្រឹត្តិការណ៍នៃការឈប់សម្រាក។

• ប្រើប្រព័ន្ធប្រតិបត្តិការដែលងាយស្រួលប្រើក្នុងកុងតឺន័រ (ដូចជា Alpine ឬ CoreOS) ដែលមានភាពធន់នឹងកំហុសក្នុងការកំណត់រចនាសម្ព័ន្ធ។

• ប្រើការបង្កើតពហុដំណាក់កាល ដូច្នេះអ្នកអាចដាក់ឱ្យប្រើតែកម្មវិធីដែលបានចងក្រងប៉ុណ្ណោះ មិនមែនប្រភពដែលភ្ជាប់មកជាមួយនោះទេ។

មានឧបករណ៍ និងសេវាកម្មជាច្រើនដែលអនុញ្ញាតឱ្យអ្នកត្រួតពិនិត្យ និងបង្កើនប្រសិទ្ធភាពរូបភាពភ្លាមៗ។ វាមានសារៈសំខាន់ណាស់ក្នុងការរក្សាពួកវាឱ្យទាន់សម័យជានិច្ច និងធ្វើតេស្តដើម្បីសុវត្ថិភាព។ ជាលទ្ធផលអ្នកទទួលបាន៖

1. កាត់បន្ថយការផ្ទុកបណ្តាញនៅលើចង្កោមទាំងមូល។

2. កាត់បន្ថយពេលវេលាចាប់ផ្តើមកុងតឺន័រ។

3. ទំហំតូចជាងនៃការចុះបញ្ជី Docker ទាំងមូលរបស់អ្នក។

4. ប្រើឃ្លាំងសម្ងាត់ DNS

ប្រសិនបើយើងនិយាយអំពីការផ្ទុកខ្ពស់ នោះជីវិតគឺអាក្រក់ណាស់ដោយមិនចាំបាច់លៃតម្រូវប្រព័ន្ធ DNS របស់ចង្កោមនោះទេ។ មានពេលមួយ អ្នកអភិវឌ្ឍន៍ Kubernetes បានគាំទ្រដំណោះស្រាយ kube-dns របស់ពួកគេ។ វាក៏ត្រូវបានអនុវត្តនៅទីនេះផងដែរ ប៉ុន្តែកម្មវិធីនេះមិនត្រូវបានសម្រួលជាពិសេស និងមិនផលិតដំណើរការដែលត្រូវការ ទោះបីជាវាហាក់ដូចជាកិច្ចការសាមញ្ញក៏ដោយ។ បន្ទាប់មក coredns បានបង្ហាញខ្លួន ដែលយើងប្តូរទៅ ហើយមិនមានទុក្ខព្រួយ ក្រោយមកវាបានក្លាយជាសេវា DNS លំនាំដើមនៅក្នុង K8s ។ នៅចំណុចខ្លះយើងបានកើនឡើងដល់ 40 ពាន់ rps ទៅប្រព័ន្ធ DNS ហើយដំណោះស្រាយនេះក៏មិនគ្រប់គ្រាន់ដែរ។ ប៉ុន្តែដោយសំណាង Nodelocaldns បានចេញមក aka node local cache, aka NodeLocal DNSCache.

ហេតុអ្វីបានជាយើងប្រើវា? មានកំហុសនៅក្នុងខឺណែលលីនុច ដែលនៅពេលដែលការហៅច្រើនតាមរយៈ NAT conntrack លើ UDP នាំឱ្យមានលក្ខខណ្ឌនៃការប្រណាំងសម្រាប់ធាតុនៅក្នុងតារាង conntrack ហើយផ្នែកនៃចរាចរតាមរយៈ NAT ត្រូវបានបាត់បង់ (រាល់ការធ្វើដំណើរតាមរយៈសេវាកម្មគឺ NAT) ។ Nodelocaldns ដោះស្រាយបញ្ហានេះដោយកម្ចាត់ NAT និងដំឡើងកំណែការតភ្ជាប់ទៅ TCP ដើម្បីបញ្ចូល DNS ក៏ដូចជាការរក្សាទុកសំណួរ DNS ខាងលើក្នុងមូលដ្ឋាន (រួមទាំងឃ្លាំងសម្ងាត់អវិជ្ជមានរយៈពេល 5 វិនាទី)។

5. ធ្វើមាត្រដ្ឋាន pods ផ្ដេកនិងបញ្ឈរដោយស្វ័យប្រវត្តិ

តើអ្នកអាចនិយាយដោយទំនុកចិត្តថាសេវាមីក្រូរបស់អ្នកទាំងអស់បានត្រៀមរួចរាល់សម្រាប់ការកើនឡើងពីរទៅបីដងទេ? តើធ្វើដូចម្តេចដើម្បីបែងចែកធនធានឱ្យបានត្រឹមត្រូវទៅកម្មវិធីរបស់អ្នក? ការរក្សាផតពីរបីដែលដំណើរការលើសពីបន្ទុកការងារអាចនឹងលែងត្រូវការតទៅទៀត ប៉ុន្តែការរក្សាវាឱ្យត្រលប់ក្រោយវិញ ដំណើរការហានិភ័យនៃពេលវេលារងចាំពីការកើនឡើងភ្លាមៗនៃចរាចរណ៍ទៅកាន់សេវាកម្ម។ សេវាកម្មដូចជា ឧបករណ៍វាស់ស្ទង់ស្វ័យប្រវត្តិ Pod ផ្ដេក и Vertical Pod Autoscaler.

VPA អនុញ្ញាតឱ្យអ្នកបង្កើនសំណើ/ដែនកំណត់នៃធុងរបស់អ្នកដោយស្វ័យប្រវត្តិនៅក្នុងផត អាស្រ័យលើការប្រើប្រាស់ជាក់ស្តែង។ តើវាអាចមានប្រយោជន៍យ៉ាងដូចម្តេច? ប្រសិនបើអ្នកមានផតដែលមិនអាចធ្វើមាត្រដ្ឋានផ្ដេកដោយហេតុផលមួយចំនួន (ដែលមិនគួរឱ្យទុកចិត្តទាំងស្រុង) នោះអ្នកអាចព្យាយាមប្រគល់ការផ្លាស់ប្តូរធនធានរបស់វាទៅ VPA ។ លក្ខណៈពិសេសរបស់វាគឺជាប្រព័ន្ធណែនាំដោយផ្អែកលើទិន្នន័យប្រវត្តិសាស្រ្ត និងបច្ចុប្បន្នពី metric-server ដូច្នេះប្រសិនបើអ្នកមិនចង់ផ្លាស់ប្តូរសំណើ/ដែនកំណត់ដោយស្វ័យប្រវត្តិទេ អ្នកអាចតាមដានធនធានដែលបានណែនាំសម្រាប់កុងតឺន័ររបស់អ្នក និងបង្កើនប្រសិទ្ធភាពការកំណត់ដើម្បីរក្សាទុក CPU និង ការចងចាំនៅក្នុងចង្កោម។

រូបភាពបានមកពី https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

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

ឧទាហរណ៍ ខាងក្រោមនេះជាការកំណត់ផតធម្មតា៖

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

ម៉ាស៊ីនណែនាំកំណត់ថាកម្មវិធីរបស់អ្នកត្រូវការស៊ីភីយូ 300m និង 500Mi ដើម្បីដំណើរការបានត្រឹមត្រូវ។ អ្នកនឹងទទួលបានការកំណត់ដូចខាងក្រោមៈ

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

ដូចដែលបានរៀបរាប់ខាងលើ នេះគឺជាការធ្វើមាត្រដ្ឋានតាមសមាមាត្រដោយផ្អែកលើសមាមាត្រសំណើ/ដែនកំណត់ក្នុងការបង្ហាញ៖

• CPU: 200m → 300m: សមាមាត្រ 1:1.75;

• អង្គចងចាំ៖ 250Mi → 500Mi: សមាមាត្រ 1:2 ។

ទាក់ទងនឹង HPAបន្ទាប់មកយន្តការនៃប្រតិបត្តិការកាន់តែមានតម្លាភាព។ មាត្រដ្ឋានដូចជា CPU និងអង្គចងចាំត្រូវបានកម្រិត ហើយប្រសិនបើមធ្យមភាគនៃការចម្លងទាំងអស់លើសពីកម្រិតកំណត់ កម្មវិធីនេះត្រូវបានធ្វើមាត្រដ្ឋានដោយ +1 រងរហូតដល់តម្លៃធ្លាក់ចុះក្រោមកម្រិត ឬរហូតដល់ចំនួនអតិបរមានៃការចម្លងត្រូវបានឈានដល់។

រូបភាពបានមកពី https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

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

6. កុំភ្លេចអំពី Node Affinity និង Pod Affinity

មិនមែនគ្រប់ថ្នាំងទាំងអស់ដំណើរការលើផ្នែករឹងដូចគ្នាទេ ហើយមិនមែនផតទាំងអស់ត្រូវដំណើរការកម្មវិធីដែលពឹងផ្អែកលើកុំព្យូទ័រនោះទេ។ Kubernetes អនុញ្ញាតឱ្យអ្នកកំណត់ឯកទេសនៃ nodes និង pods ដោយប្រើ Node Affinity и ភាពស្និទ្ធស្នាលរបស់ផត.

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

ឧបមាថាអ្នកមានថ្នាំងពីរ៖ មួយជាមួយ CPUType=HIGHFREQ និងមួយចំនួនធំនៃស្នូលល្បឿនលឿន, មួយផ្សេងទៀតជាមួយ MemoryType=HIGHMEMORY អង្គចងចាំកាន់តែច្រើន និងដំណើរការលឿនជាងមុន។ មធ្យោបាយងាយស្រួលបំផុតគឺកំណត់ការដាក់ពង្រាយទៅថ្នាំង HIGHFREQដោយបន្ថែមទៅផ្នែក spec ឧបករណ៍ជ្រើសរើសនេះ៖

…
nodeSelector:
	CPUType: HIGHFREQ

វិធី​ដែល​ថ្លៃ​ជាង និង​ជាក់លាក់​ក្នុង​ការ​ធ្វើ​បែប​នេះ​គឺ​ត្រូវ​ប្រើ nodeAffinity នៅក្នុងវាល affinity аздела spec. មានជម្រើសពីរ៖

• requiredDuringSchedulingIgnoredDuringExecution៖ ការកំណត់រឹង (កម្មវិធីកំណត់ពេលនឹងដាក់ពង្រាយ pods តែនៅលើថ្នាំងជាក់លាក់ (និងកន្លែងផ្សេងទៀតទេ));

• preferredDuringSchedulingIgnoredDuringExecution៖ ការកំណត់ទន់ (កម្មវិធីកំណត់ពេលនឹងព្យាយាមដាក់ពង្រាយទៅកាន់ថ្នាំងជាក់លាក់ ហើយប្រសិនបើវាបរាជ័យ វានឹងព្យាយាមដាក់ពង្រាយទៅកាន់ថ្នាំងដែលមានបន្ទាប់)។

អ្នកអាចបញ្ជាក់វាក្យសម្ព័ន្ធជាក់លាក់សម្រាប់ការគ្រប់គ្រងស្លាកថ្នាំង ដូចជា In, NotIn, Exists, DoesNotExist, Gt ឬ Lt. ទោះជាយ៉ាងណាក៏ដោយ សូមចាំថាវិធីសាស្ត្រស្មុគ្រស្មាញនៅក្នុងបញ្ជីវែងនៃស្លាកនឹងបន្ថយល្បឿនក្នុងការសម្រេចចិត្តក្នុងស្ថានភាពធ្ងន់ធ្ងរ។ នៅក្នុងពាក្យផ្សេងទៀតរក្សាវាឱ្យសាមញ្ញ។

ដូចដែលបានរៀបរាប់ខាងលើ Kubernetes អនុញ្ញាតឱ្យអ្នកកំណត់ភាពស្និទ្ធស្នាលនៃផតថលបច្ចុប្បន្ន។ នោះ​គឺ អ្នក​អាច​ធ្វើ​ឱ្យ​ប្រាកដ​ថា​ pods ជាក់លាក់​ធ្វើការ​ជាមួយ​គ្នា​នឹង​ pods ផ្សេង​ទៀត​ក្នុង​តំបន់​ដែល​អាច​ប្រើ​បាន​ដូចគ្នា​ (ពាក់ព័ន្ធ​នឹង​ clouds) ឬ nodes ។

В podAffinity វាល affinity аздела spec វាលដូចគ្នាគឺអាចរកបានដូចនៅក្នុងករណីនៃ nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. ភាពខុសគ្នាតែមួយគត់គឺថា matchExpressions នឹងចង pods ទៅ node ដែលកំពុងដំណើរការ pods ជាមួយ label នោះ។

Kubernetes ក៏ផ្តល់កន្លែងមួយផងដែរ។ podAntiAffinityដែលផ្ទុយមកវិញ វាមិនភ្ជាប់ផតផតទៅនឹងថ្នាំងដែលមានផតជាក់លាក់ទេ។

អំពីកន្សោម nodeAffinity ដំបូន្មានដូចគ្នាអាចត្រូវបានផ្តល់ឱ្យ៖ ព្យាយាមរក្សាច្បាប់សាមញ្ញ និងសមហេតុសមផល កុំព្យាយាមផ្ទុកលើសទម្ងន់កំណត់ដោយច្បាប់ស្មុគស្មាញ។ វាងាយស្រួលណាស់ក្នុងការបង្កើតច្បាប់ដែលនឹងមិនផ្គូផ្គងលក្ខខណ្ឌនៃចង្កោម បង្កើតការផ្ទុកមិនចាំបាច់នៅលើកម្មវិធីកំណត់ពេល និងកាត់បន្ថយដំណើរការទាំងមូល។

7. តិះដៀល & ការអត់ឱន

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

យន្តការនៃភាពមិនស្អាត - ច្បាប់ហាមឃាត់ - ជួយក្នុងរឿងនេះ។ ជាឧទាហរណ៍ ក្នុងសេណារីយ៉ូមួយចំនួន អ្នកអាចហាមឃាត់ថ្នាំងមួយចំនួនពីការដំណើរការផត។ ដើម្បីអនុវត្តស្នាមប្រឡាក់ទៅថ្នាំងជាក់លាក់មួយ អ្នកត្រូវប្រើជម្រើស taint នៅ kubectl ។ បញ្ជាក់​គន្លឹះ​និង​តម្លៃ​ហើយ​បន្ទាប់​មក​ខូច​ដូច​ជា​ NoSchedule ឬ NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

គួរកត់សំគាល់ផងដែរថា យន្តការស្នាមប្រឡាក់គាំទ្រផលប៉ះពាល់សំខាន់ៗចំនួនបី៖ NoSchedule, NoExecute и PreferNoSchedule.

• NoSchedule មានន័យថាសម្រាប់ពេលនេះនឹងមិនមានធាតុដែលត្រូវគ្នានៅក្នុងការបញ្ជាក់ pod ទេ។ tolerationsវា​នឹង​មិន​អាច​ត្រូវ​បាន​គេ​ដាក់​ពង្រាយ​នៅ​លើ node (ក្នុង​ឧទាហរណ៍​នេះ node10).

• PreferNoSchedule - កំណែសាមញ្ញ NoSchedule. ក្នុងករណីនេះ កម្មវិធីកំណត់ពេលនឹងព្យាយាមមិនបែងចែក pods ដែលមិនមានធាតុដែលត្រូវគ្នា។ tolerations ក្នុងមួយ node ប៉ុន្តែនេះមិនមែនជាការកំណត់ពិបាកទេ។ ប្រសិនបើមិនមានធនធាននៅក្នុងចង្កោមទេនោះ ផតស៍នឹងចាប់ផ្តើមដាក់ពង្រាយនៅលើថ្នាំងនេះ។

• NoExecute - ឥទ្ធិពលនេះជំរុញឱ្យមានការជម្លៀសភ្លាមៗនៃផតដែលមិនមានធាតុដែលត្រូវគ្នា tolerations.

គួរឱ្យចាប់អារម្មណ៍ ឥរិយាបថនេះអាចត្រូវបានលុបចោលដោយប្រើយន្តការអត់ឱន។ វាងាយស្រួលនៅពេលដែលមានថ្នាំង "ហាមឃាត់" ហើយអ្នកគ្រាន់តែត្រូវដាក់សេវាហេដ្ឋារចនាសម្ព័ន្ធនៅលើវា។ តើត្រូវធ្វើដូចម្តេច? អនុញ្ញាត​ឱ្យ​តែ​ផតឃែរ​ទាំងនោះ​ដែល​មាន​ការ​អត់ឱន​សមរម្យ។

នេះជាអ្វីដែលការបញ្ជាក់របស់ pod នឹងមើលទៅ៖

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

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

8. កំណត់អាទិភាពនៃការដាក់ពង្រាយ Pod

ដោយ​សារ​តែ​អ្នក​មាន pods ដែល​ត្រូវ​បាន​កំណត់​ទៅ nodes មិន​មាន​ន័យ​ថា pods ទាំងអស់​ត្រូវ​តែ​ត្រូវ​បាន​ចាត់​ទុក​ជា​អាទិភាព​ដូច​គ្នា​នោះ​ទេ។ ឧទាហរណ៍ អ្នក​ប្រហែល​ជា​ចង់​ដាក់​ពង្រាយ pods មួយ​ចំនួន​មុន​អ្នក​ផ្សេង។

Kubernetes ផ្តល់នូវវិធីផ្សេងគ្នាដើម្បីកំណត់រចនាសម្ព័ន្ធ Pod Priority និង Preemption ។ ការកំណត់មានផ្នែកជាច្រើន៖ វត្ថុ PriorityClass និងការពិពណ៌នាវាល priorityClassName នៅក្នុងការបញ្ជាក់ pod ។ តោះមើលឧទាហរណ៍៖

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

យើងបង្កើត PriorityClassផ្តល់ឱ្យវានូវឈ្មោះ ការពិពណ៌នា និងតម្លៃ។ ខ្ពស់ជាងនេះ valueអាទិភាពកាន់តែខ្ពស់។ តម្លៃអាចជាចំនួនគត់ 32 ប៊ីតតិចជាង ឬស្មើនឹង 1។ តម្លៃខ្ពស់ជាងនេះត្រូវបានបម្រុងទុកសម្រាប់ប្រព័ន្ធបេសកកម្មសំខាន់ៗដែលជាទូទៅមិនអាចកំណត់ទុកជាមុនបានទេ។ ការផ្លាស់ទីលំនៅនឹងកើតឡើងលុះត្រាតែផតដែលមានអទិភាពខ្ពស់មិនមានកន្លែងសម្រាប់បង្វិល នោះផតមួយចំនួនពីថ្នាំងជាក់លាក់មួយនឹងត្រូវបានជម្លៀសចេញ។ ប្រសិនបើយន្តការនេះរឹងពេកសម្រាប់អ្នក អ្នកអាចបន្ថែមជម្រើស preemptionPolicy: Neverហើយបន្ទាប់មកនឹងមិនមានការកក់ទុកជាមុនទេ ផតនឹងឈរជាជួរមុនគេ ហើយរង់ចាំអ្នកកំណត់ពេលស្វែងរកធនធានឥតគិតថ្លៃសម្រាប់វា។

បន្ទាប់​មក យើង​បង្កើត​ផត​មួយ​ដែល​យើង​បង្ហាញ​ឈ្មោះ priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority
          

អ្នកអាចបង្កើតថ្នាក់អាទិភាពជាច្រើនតាមដែលអ្នកចូលចិត្ត ទោះបីជាវាត្រូវបានណែនាំមិនឱ្យយកទៅឆ្ងាយជាមួយវាក៏ដោយ (និយាយថា ដាក់កម្រិតខ្លួនអ្នកឱ្យទាប មធ្យម និងខ្ពស់)។

ដូច្នេះ បើចាំបាច់ អ្នកអាចបង្កើនប្រសិទ្ធភាពនៃការដាក់ពង្រាយសេវាកម្មសំខាន់ៗដូចជា nginx-ingress-controller, coredns ជាដើម។

9. បង្កើនប្រសិទ្ធភាពចង្កោម ETCD

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

សូមចងចាំថាការបង្កើនចំនួនសមាជិកច្រើនពេកនៅក្នុងចង្កោមអាចបង្កើនការអត់ឱនចំពោះកំហុសដោយចំណាយលើការអនុវត្ត អ្វីគ្រប់យ៉ាងគួរតែស្ថិតក្នុងកម្រិតមធ្យម។

ប្រសិនបើយើងនិយាយអំពីការដំឡើងសេវាកម្មនោះ មានការណែនាំមួយចំនួន៖

1. មានផ្នែករឹងល្អ ដោយផ្អែកលើទំហំនៃចង្កោម (អ្នកអាចអាន នៅទីនេះ).

2. កែប្រែប៉ារ៉ាម៉ែត្រមួយចំនួន ប្រសិនបើអ្នកបានរីករាលដាលចង្កោមរវាង DCs មួយគូ ឬបណ្តាញ និងឌីសរបស់អ្នកទុកជាច្រើនដែលអ្នកចង់បាន (អ្នកអាចអាន នៅទីនេះ).

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

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

ប្រភព: www.habr.com