🥇 Kubernetes៖ ហេតុអ្វីបានជាវាសំខាន់ម៉្លេះក្នុងការកំណត់រចនាសម្ព័ន្ធការគ្រប់គ្រងធនធានប្រព័ន្ធ?

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

អ្នកត្រូវចាប់ផ្តើមជាមួយនឹងប្រភេទនៃធនធានសំខាន់ៗដែលមាននៅក្នុងប្រព័ន្ធ - ជាការពិតណាស់នេះគឺជាពេលវេលាដំណើរការនិង RAM ។ នៅក្នុង k8s manifests ប្រភេទធនធានទាំងនេះត្រូវបានវាស់ជាឯកតាដូចខាងក្រោម៖

ស៊ីភីយូ - នៅក្នុងស្នូល
RAM - ជាបៃ

លើសពីនេះទៅទៀត សម្រាប់ធនធាននីមួយៗ វាអាចកំណត់តម្រូវការពីរប្រភេទ - សំណើ и ដែនកំណត់. សំណើ - ពិពណ៌នាអំពីតម្រូវការអប្បបរមាសម្រាប់ធនធានឥតគិតថ្លៃនៃថ្នាំងដើម្បីដំណើរការកុងតឺន័រ (និងផតទាំងមូល) ខណៈពេលដែលដែនកំណត់កំណត់ដែនកំណត់រឹងលើធនធានដែលមានសម្រាប់កុងតឺន័រ។

វាជាការសំខាន់ក្នុងការយល់ថា manifest មិនចាំបាច់កំណត់យ៉ាងច្បាស់នូវប្រភេទទាំងពីរនោះទេ ប៉ុន្តែអាកប្បកិរិយានឹងមានដូចខាងក្រោម៖

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

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

ជួរដែនកំណត់ — ពិពណ៌នាអំពីគោលការណ៍រឹតបន្តឹងនៅកម្រិតកុងតឺន័រ/ផតនៅក្នុង ns ហើយត្រូវការដើម្បីពិពណ៌នាអំពីការរឹតបន្តឹងលំនាំដើមនៅលើកុងតឺន័រ/ផត ក៏ដូចជាការពារការបង្កើតធុងផ្ទុក/ផត (ឬផ្ទុយមកវិញ) កំណត់ចំនួនរបស់ពួកគេ និងកំណត់ភាពខុសគ្នាដែលអាចកើតមាននៅក្នុងតម្លៃនៅក្នុងដែនកំណត់និងសំណើ
សម្រង់ធនធាន - ពិពណ៌នាអំពីគោលការណ៍រឹតបន្តឹងជាទូទៅសម្រាប់កុងតឺន័រទាំងអស់នៅក្នុង ns ហើយត្រូវបានប្រើជាក្បួនដើម្បីកំណត់ធនធានក្នុងចំណោមបរិស្ថាន (មានប្រយោជន៍នៅពេលដែលបរិស្ថានមិនត្រូវបានកំណត់យ៉ាងតឹងរ៉ឹងនៅកម្រិតថ្នាំង)

ខាងក្រោមនេះជាឧទាហរណ៍នៃការបង្ហាញដែលកំណត់កម្រិតធនធាន៖

នៅកម្រិតធុងជាក់លាក់៖
```
containers:
- name: app-nginx
  image: nginx
  resources:
    requests:
      memory: 1Gi
    limits:
      cpu: 200m
```
ទាំងនោះ។ ក្នុងករណីនេះ ដើម្បីដំណើរការកុងតឺន័រជាមួយ nginx អ្នកនឹងត្រូវការយ៉ាងហោចណាស់ 1G នៃ RAM ឥតគិតថ្លៃ និងស៊ីភីយូ 0.2 នៅលើថ្នាំង ខណៈពេលដែលកុងតឺន័រភាគច្រើនអាចប្រើប្រាស់ស៊ីភីយូ 0.2 និង RAM ដែលមានទាំងអស់នៅលើថ្នាំង។
នៅកម្រិតចំនួនគត់ ns៖
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: nxs-test
spec:
  hard:
    requests.cpu: 300m
    requests.memory: 1Gi
    limits.cpu: 700m
    limits.memory: 2Gi
```
ទាំងនោះ។ ផលបូកនៃធុងសំណើទាំងអស់នៅក្នុង ns លំនាំដើមមិនអាចលើសពី 300m សម្រាប់ស៊ីភីយូ និង 1G សម្រាប់ OP ហើយផលបូកនៃដែនកំណត់ទាំងអស់គឺ 700m សម្រាប់ស៊ីភីយូ និង 2G សម្រាប់ OP ។
ដែនកំណត់លំនាំដើមសម្រាប់កុងតឺន័រក្នុង ns៖
```
apiVersion: v1
kind: LimitRange
metadata:
  name: nxs-limit-per-container
spec:
 limits:
   - type: Container
     defaultRequest:
       cpu: 100m
       memory: 1Gi
     default:
       cpu: 1
       memory: 2Gi
     min:
       cpu: 50m
       memory: 500Mi
     max:
       cpu: 2
       memory: 4Gi
```
ទាំងនោះ។ នៅក្នុងចន្លោះឈ្មោះលំនាំដើមសម្រាប់កុងតឺន័រទាំងអស់ សំណើនឹងត្រូវបានកំណត់ទៅ 100m សម្រាប់ CPU និង 1G សម្រាប់ OP ដែនកំណត់ - 1 CPU និង 2G ។ ក្នុងពេលជាមួយគ្នានេះ ដែនកំណត់ក៏ត្រូវបានកំណត់ផងដែរលើតម្លៃដែលអាចធ្វើបាននៅក្នុងសំណើ/ដែនកំណត់សម្រាប់ CPU (50m < x < 2) និង RAM (500M < x < 4G) ។
ការរឹតបន្តឹងកម្រិត Pod៖
```
apiVersion: v1
kind: LimitRange
metadata:
 name: nxs-limit-pod
spec:
 limits:
 - type: Pod
   max:
     cpu: 4
     memory: 1Gi
```
ទាំងនោះ។ សម្រាប់ផតនីមួយៗនៅក្នុង ns លំនាំដើមនឹងមានដែនកំណត់ 4 vCPU និង 1G ។

ឥឡូវនេះខ្ញុំចង់ប្រាប់អ្នកពីគុណសម្បត្តិដែលកំណត់ការរឹតបន្តឹងទាំងនេះអាចផ្តល់ឱ្យយើង។

ផ្ទុកយន្តការតុល្យភាពរវាងថ្នាំង

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

ការច្រោះ
ជួរ

ទាំងនោះ។ យោងតាមគោលការណ៍ដែលបានពិពណ៌នា ថ្នាំងត្រូវបានជ្រើសរើសដំបូង ដែលវាអាចដំណើរការផតផតដោយផ្អែកលើសំណុំ ព្យាករណ៍ (រួមទាំងការពិនិត្យមើលថាតើថ្នាំងមានធនធានគ្រប់គ្រាន់ដើម្បីដំណើរការផត - PodFitsResources) ហើយបន្ទាប់មកសម្រាប់ថ្នាំងនីមួយៗនេះ យោងតាម អាទិភាព ពិន្ទុត្រូវបានផ្តល់រង្វាន់ (រួមទាំងធនធានឥតគិតថ្លៃកាន់តែច្រើនដែលថ្នាំងមាន ពិន្ទុកាន់តែច្រើនវាត្រូវបានចាត់តាំង - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) ហើយផតត្រូវបានបើកដំណើរការនៅលើថ្នាំងដែលមានពិន្ទុច្រើនបំផុត (ប្រសិនបើថ្នាំងជាច្រើនបំពេញលក្ខខណ្ឌនេះក្នុងពេលតែមួយ បន្ទាប់មក មួយចៃដន្យត្រូវបានជ្រើសរើស) ។

ក្នុងពេលជាមួយគ្នានេះអ្នកត្រូវយល់ថាកម្មវិធីកំណត់ពេលនៅពេលវាយតម្លៃធនធានដែលមាននៃថ្នាំងត្រូវបានដឹកនាំដោយទិន្នន័យដែលត្រូវបានរក្សាទុកក្នុង etcd - i.e. សម្រាប់បរិមាណនៃធនធានដែលបានស្នើសុំ/កំណត់នៃផតនីមួយៗដែលដំណើរការលើថ្នាំងនេះ ប៉ុន្តែមិនមែនសម្រាប់ការប្រើប្រាស់ធនធានពិតប្រាកដនោះទេ។ ព័ត៌មាននេះអាចទទួលបានពីលទ្ធផលពាក្យបញ្ជា kubectl describe node $NODEឧទាហរណ៍:

# kubectl describe nodes nxs-k8s-s1
..
Non-terminated Pods:         (9 in total)
  Namespace                  Name                                         CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
  ---------                  ----                                         ------------  ----------  ---------------  -------------  ---
  ingress-nginx              nginx-ingress-controller-754b85bf44-qkt2t    0 (0%)        0 (0%)      0 (0%)           0 (0%)         233d
  kube-system                kube-flannel-26bl4                           150m (0%)     300m (1%)   64M (0%)         500M (1%)      233d
  kube-system                kube-proxy-exporter-cb629                    0 (0%)        0 (0%)      0 (0%)           0 (0%)         233d
  kube-system                kube-proxy-x9fsc                             0 (0%)        0 (0%)      0 (0%)           0 (0%)         233d
  kube-system                nginx-proxy-k8s-worker-s1                    25m (0%)      300m (1%)   32M (0%)         512M (1%)      233d
  nxs-monitoring             alertmanager-main-1                          100m (0%)     100m (0%)   425Mi (1%)       25Mi (0%)      233d
  nxs-logging                filebeat-lmsmp                               100m (0%)     0 (0%)      100Mi (0%)       200Mi (0%)     233d
  nxs-monitoring             node-exporter-v4gdq                          112m (0%)     122m (0%)   200Mi (0%)       220Mi (0%)     233d
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests           Limits
  --------           --------           ------
  cpu                487m (3%)          822m (5%)
  memory             15856217600 (2%)  749976320 (3%)
  ephemeral-storage  0 (0%)             0 (0%)

នៅទីនេះយើងឃើញផតទាំងអស់ដំណើរការលើថ្នាំងជាក់លាក់មួយ ក៏ដូចជាធនធានដែលផតនីមួយៗស្នើសុំ។ ហើយនេះគឺជាអ្វីដែលកំណត់ហេតុកម្មវិធីកំណត់ពេលមើលទៅនៅពេលដែល cronjob-cron-events-1573793820-xt6q9 pod ត្រូវបានបើកដំណើរការ (ព័ត៌មាននេះនឹងបង្ហាញនៅក្នុងកំណត់ហេតុកម្មវិធីកំណត់ពេលនៅពេលអ្នកកំណត់កម្រិតនៃការកត់ត្រាទី 10 នៅក្នុងអាគុយម៉ង់ពាក្យបញ្ជាចាប់ផ្តើម -v=10):

កំណត់ហេតុ

I1115 07:57:21.637791       1 scheduling_queue.go:908] About to try and schedule pod nxs-stage/cronjob-cron-events-1573793820-xt6q9                                                                                                                                           
I1115 07:57:21.637804       1 scheduler.go:453] Attempting to schedule pod: nxs-stage/cronjob-cron-events-1573793820-xt6q9                                                                                                                                                    
I1115 07:57:21.638285       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s5 is allowed, Node is running only 16 out of 110 Pods.                                                                               
I1115 07:57:21.638300       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s6 is allowed, Node is running only 20 out of 110 Pods.                                                                               
I1115 07:57:21.638322       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s3 is allowed, Node is running only 20 out of 110 Pods.                                                                               
I1115 07:57:21.638322       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s4 is allowed, Node is running only 17 out of 110 Pods.                                                                               
I1115 07:57:21.638334       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, Node is running only 16 out of 110 Pods.                                                                              
I1115 07:57:21.638365       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s12 is allowed, Node is running only 9 out of 110 Pods.                                                                               
I1115 07:57:21.638334       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s11 is allowed, Node is running only 11 out of 110 Pods.                                                                              
I1115 07:57:21.638385       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s1 is allowed, Node is running only 19 out of 110 Pods.                                                                               
I1115 07:57:21.638402       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s2 is allowed, Node is running only 21 out of 110 Pods.                                                                               
I1115 07:57:21.638383       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, Node is running only 16 out of 110 Pods.                                                                               
I1115 07:57:21.638335       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, Node is running only 18 out of 110 Pods.                                                                               
I1115 07:57:21.638408       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s13 is allowed, Node is running only 8 out of 110 Pods.                                                                               
I1115 07:57:21.638478       1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, existing pods anti-affinity terms satisfied.                                                                         
I1115 07:57:21.638505       1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, existing pods anti-affinity terms satisfied.                                                                          
I1115 07:57:21.638577       1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, existing pods anti-affinity terms satisfied.                                                                          
I1115 07:57:21.638583       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s7 is allowed, Node is running only 25 out of 110 Pods.                                                                               
I1115 07:57:21.638932       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 9        
I1115 07:57:21.638946       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 8           
I1115 07:57:21.638961       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: BalancedResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 9        
I1115 07:57:21.638971       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7        
I1115 07:57:21.638975       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: LeastResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 8           
I1115 07:57:21.638990       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7           
I1115 07:57:21.639022       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: TaintTolerationPriority, Score: (10)                                                                                                        
I1115 07:57:21.639030       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: TaintTolerationPriority, Score: (10)                                                                                                         
I1115 07:57:21.639034       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: TaintTolerationPriority, Score: (10)                                                                                                         
I1115 07:57:21.639041       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: NodeAffinityPriority, Score: (0)                                                                                                            
I1115 07:57:21.639053       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: NodeAffinityPriority, Score: (0)                                                                                                             
I1115 07:57:21.639059       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: NodeAffinityPriority, Score: (0)                                                                                                             
I1115 07:57:21.639061       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: InterPodAffinityPriority, Score: (0)                                                                                                                   
I1115 07:57:21.639063       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)                                                                                                                   
I1115 07:57:21.639073       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: InterPodAffinityPriority, Score: (0)                                                                                                                    
I1115 07:57:21.639077       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)                                                                                                                    
I1115 07:57:21.639085       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: InterPodAffinityPriority, Score: (0)                                                                                                                    
I1115 07:57:21.639088       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)                                                                                                                    
I1115 07:57:21.639103       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)                                                                                                         
I1115 07:57:21.639109       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)                                                                                                          
I1115 07:57:21.639114       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)                                                                                                          
I1115 07:57:21.639127       1 generic_scheduler.go:781] Host nxs-k8s-s10 => Score 100037                                                                                                                                                                            
I1115 07:57:21.639150       1 generic_scheduler.go:781] Host nxs-k8s-s8 => Score 100034                                                                                                                                                                             
I1115 07:57:21.639154       1 generic_scheduler.go:781] Host nxs-k8s-s9 => Score 100037                                                                                                                                                                             
I1115 07:57:21.639267       1 scheduler_binder.go:269] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10"                                                                                                               
I1115 07:57:21.639286       1 scheduler_binder.go:279] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10": all PVCs bound and nothing to do                                                                             
I1115 07:57:21.639333       1 factory.go:733] Attempting to bind cronjob-cron-events-1573793820-xt6q9 to nxs-k8s-s10

នៅទីនេះយើងឃើញថាដំបូងឡើយ កម្មវិធីកំណត់ពេលត្រង និងបង្កើតបញ្ជីថ្នាំង 3 ដែលវាអាចត្រូវបានចាប់ផ្តើម (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10) ។ បន្ទាប់មកវាគណនាពិន្ទុដោយផ្អែកលើប៉ារ៉ាម៉ែត្រជាច្រើន (រួមទាំង BalancedResourceAllocation, LeastResourceAllocation) សម្រាប់ថ្នាំងទាំងនេះនីមួយៗដើម្បីកំណត់ថ្នាំងដែលសមស្របបំផុត។ ទីបំផុត ផតត្រូវបានកំណត់ពេលនៅលើថ្នាំងដែលមានចំនួនពិន្ទុខ្ពស់បំផុត (នៅទីនេះថ្នាំងពីរក្នុងពេលតែមួយមានចំនួនពិន្ទុដូចគ្នា 100037 ដូច្នេះចៃដន្យមួយត្រូវបានជ្រើសរើស - nxs-k8s-s10) ។

សេចក្តីសន្និដ្ឋាន៖ ប្រសិនបើ node ដំណើរការ pods ដែលមិនមានការកំណត់ នោះសម្រាប់ k8s (តាមទស្សនៈនៃការប្រើប្រាស់ធនធាន) វានឹងស្មើនឹងប្រសិនបើមិនមាន pods បែបនេះនៅលើ node ទាល់តែសោះ។ ដូច្នេះ ប្រសិនបើអ្នកមាន pod មួយជាមួយនឹងដំណើរការដ៏ក្រៀមក្រំ (ឧទាហរណ៍ wowza) ហើយគ្មានការរឹតបន្តឹងណាមួយត្រូវបានកំណត់សម្រាប់វាទេ នោះស្ថានភាពអាចនឹងកើតឡើងនៅពេលដែលផតនេះពិតជាស៊ីធនធានទាំងអស់របស់ថ្នាំង ប៉ុន្តែសម្រាប់ k8s ថ្នាំងនេះ ត្រូវបានចាត់ទុកថាមិនមានផ្ទុក ហើយវានឹងត្រូវបានផ្តល់រង្វាន់ដូចគ្នានៃពិន្ទុនៅពេលដាក់ចំណាត់ថ្នាក់ (យ៉ាងជាក់លាក់នៅក្នុងពិន្ទុដែលវាយតម្លៃធនធានដែលមាន) ជាថ្នាំងដែលមិនមានផតដែលធ្វើការ ដែលនៅទីបំផុតអាចនាំឱ្យមានការចែកចាយបន្ទុកមិនស្មើគ្នារវាងថ្នាំង។

ការបណ្តេញចេញរបស់ Pod

ដូចដែលអ្នកដឹង pod នីមួយៗត្រូវបានចាត់ថ្នាក់មួយក្នុងចំណោម 3 QoS classes:

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

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

ធានា: -៤០
ការខិតខំប្រឹងប្រែងល្អបំផុត: 1000
អាចផ្ទុះបាន។: min(អតិបរមា(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

ទាំងនោះ។ ជាមួយនឹងអាទិភាពដូចគ្នា kubelet នឹងបណ្តេញ pods ជាដំបូងជាមួយនឹងការខិតខំប្រឹងប្រែងល្អបំផុត QoS class ពី node ។

សេចក្តីសន្និដ្ឋាន៖ ប្រសិនបើអ្នកចង់កាត់បន្ថយលទ្ធភាពនៃការបណ្តេញផតដែលចង់បានចេញពីថ្នាំងក្នុងករណីខ្វះធនធានលើវា បន្ទាប់មករួមជាមួយអាទិភាព អ្នកក៏ត្រូវយកចិត្តទុកដាក់លើការកំណត់សំណើ/ដែនកំណត់សម្រាប់វា។

យន្តការសម្រាប់ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិផ្តេកនៃកម្មវិធី pods (HPA)

នៅពេលដែលភារកិច្ចគឺដើម្បីបង្កើន និងបន្ថយចំនួនផតដោយស្វ័យប្រវត្តិ អាស្រ័យលើការប្រើប្រាស់ធនធាន (ប្រព័ន្ធ - CPU/RAM ឬអ្នកប្រើប្រាស់ - rps) ដូចជាអង្គភាព k8s ដូចជា HPA (ឧបករណ៍វាស់ស្ទង់ស្វ័យប្រវត្តិ Pod ផ្ដេក)។ ក្បួនដោះស្រាយមានដូចខាងក្រោម៖

ការអានបច្ចុប្បន្ននៃធនធានដែលបានសង្កេតត្រូវបានកំណត់ (CurrentMetricValue)
តម្លៃដែលចង់បានសម្រាប់ធនធានត្រូវបានកំណត់ (desiredMetricValue) ដែលសម្រាប់ធនធានប្រព័ន្ធត្រូវបានកំណត់ដោយប្រើសំណើ
ចំនួនចម្លងបច្ចុប្បន្នត្រូវបានកំណត់ (currentReplicas)
រូបមន្តខាងក្រោមគណនាចំនួនចម្លងដែលចង់បាន (desiredReplicas)
desiredReplicas = [CurrentReplicas * (currentMetricValue / desiredMetricValue)]

ក្នុងករណីនេះ ការធ្វើមាត្រដ្ឋាននឹងមិនកើតឡើងនៅពេលដែលមេគុណ (currentMetricValue / desiredMetricValue) នៅជិត 1 (ក្នុងករណីនេះ យើងអាចកំណត់កំហុសដែលអាចអនុញ្ញាតបានដោយខ្លួនឯង តាមលំនាំដើមវាគឺ 0.1)។

សូមក្រឡេកមើលរបៀបដែល hpa ដំណើរការដោយប្រើឧទាហរណ៍នៃកម្មវិធីសាកល្បងកម្មវិធី (ពិពណ៌នាថាជាការដាក់ពង្រាយ) ដែលវាចាំបាច់ក្នុងការផ្លាស់ប្តូរចំនួននៃការចម្លងអាស្រ័យលើការប្រើប្រាស់ស៊ីភីយូ៖

ការបង្ហាញកម្មវិធី

kind: Deployment
apiVersion: apps/v1beta2
metadata:
name: app-test
spec:
selector:
matchLabels:
app: app-test
replicas: 2
template:
metadata:
labels:
app: app-test
spec:
containers:
- name: nginx
image: registry.nixys.ru/generic-images/nginx
imagePullPolicy: Always
resources:
requests:
cpu: 60m
ports:
- name: http
containerPort: 80
- name: nginx-exporter
image: nginx/nginx-prometheus-exporter
resources:
requests:
cpu: 30m
ports:
- name: nginx-exporter
containerPort: 9113
args:
- -nginx.scrape-uri
- http://127.0.0.1:80/nginx-status

ទាំងនោះ។ យើងឃើញថា ផតកម្មវិធីត្រូវបានបើកដំណើរការដំបូងក្នុងឧទាហរណ៍ពីរ ដែលនីមួយៗមានកុងតឺន័រ nginx និង nginx-exporter ចំនួនពីរ សម្រាប់នីមួយៗដែលបានបញ្ជាក់ សំណើ សម្រាប់ CPU ។

HPA Manifesto
```
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: app-test-hpa
spec:
maxReplicas: 10
minReplicas: 2
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: app-test
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 30
```
ទាំងនោះ។ យើងបានបង្កើត hpa ដែលនឹងត្រួតពិនិត្យ Deployment app-test និងកែតម្រូវចំនួន pods ជាមួយនឹងកម្មវិធីដោយផ្អែកលើសូចនាករ cpu (យើងរំពឹងថា pod គួរតែប្រើប្រាស់ 30% នៃ CPU ដែលវាស្នើសុំ) ជាមួយនឹងចំនួននៃការចម្លងគឺស្ថិតនៅក្នុង ជួរ 2-10 ។

ឥឡូវនេះសូមមើលយន្តការនៃប្រតិបត្តិការ hpa ប្រសិនបើយើងអនុវត្តបន្ទុកទៅមួយនៃ hearths:
```
 # kubectl top pod
NAME                                                   CPU(cores)   MEMORY(bytes)
app-test-78559f8f44-pgs58            101m         243Mi
app-test-78559f8f44-cj4jz            4m           240Mi
```

សរុបមកយើងមានដូចខាងក្រោម៖

តម្លៃដែលចង់បាន (desiredMetricValue) - យោងតាមការកំណត់ hpa យើងមាន 30%
តម្លៃបច្ចុប្បន្ន (currentMetricValue) - សម្រាប់ការគណនា អ្នកគ្រប់គ្រង-គ្រប់គ្រងគណនាតម្លៃមធ្យមនៃការប្រើប្រាស់ធនធានក្នុង % i.e. តាមលក្ខខណ្ឌធ្វើដូចខាងក្រោមៈ
1. ទទួលបានតម្លៃដាច់ខាតនៃ pod metrics ពី metric server, i.e. ១០១ម និង ៤ម
2. គណនាតម្លៃដាច់ខាតជាមធ្យម i.e. (101m + 4m) / 2 = 53m
3. ទទួលបានតម្លៃដាច់ខាតសម្រាប់ការប្រើប្រាស់ធនធានដែលចង់បាន (សម្រាប់នេះ សំណើរបស់ធុងទាំងអស់ត្រូវបានបូកសរុប) 60m + 30m = 90m
4. គណនាភាគរយមធ្យមនៃការប្រើប្រាស់ស៊ីភីយូដែលទាក់ទងនឹងការស្នើសុំផត, ឧ. 53m / 90m * 100% = 59%

ឥឡូវនេះយើងមានអ្វីគ្រប់យ៉ាងដែលយើងត្រូវកំណត់ថាតើយើងត្រូវការផ្លាស់ប្តូរចំនួននៃការចម្លង ដើម្បីធ្វើដូច្នេះ យើងគណនាមេគុណ៖

ratio = 59% / 30% = 1.96

ទាំងនោះ។ ចំនួននៃការចម្លងគួរតែត្រូវបានកើនឡើង ~ 2 ដងនិងចំនួនទៅ [2 * 1.96] = 4 ។

សេចក្តីសន្និដ្ឋាន: ដូចដែលអ្នកអាចឃើញដើម្បីឱ្យយន្តការនេះដំណើរការលក្ខខណ្ឌចាំបាច់មួយគឺវត្តមាននៃសំណើសម្រាប់ធុងទាំងអស់នៅក្នុងផតដែលបានសង្កេត។

យន្តការសម្រាប់ធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិផ្ដេកនៃថ្នាំង (Cluster Autoscaler)

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

ក្នុងករណីនេះ ប្រសិនបើអ្នកផ្តល់សេវាមាន IaaS/PaaS ដែលត្រូវគ្នា (ឧទាហរណ៍ GKE/GCE, AKS, EKS ។ល។) ឧបករណ៍ដូចជា Node Autoscaler. វាអនុញ្ញាតឱ្យអ្នកកំណត់ចំនួនអតិបរមា និងអប្បបរមានៃថ្នាំងនៅក្នុងចង្កោម ហើយកែសម្រួលចំនួនថ្នាំងបច្ចុប្បន្នដោយស្វ័យប្រវត្តិ (ដោយការហៅទៅកាន់ API នៃអ្នកផ្តល់សេវាពពក ដើម្បីបញ្ជាទិញ/យកថ្នាំងចេញ) នៅពេលដែលមានការខ្វះខាតធនធាននៅក្នុងចង្កោម និងផត។ មិនអាចកំណត់ពេលវេលាបាន (ស្ថិតក្នុងស្ថានភាពកំពុងរង់ចាំ)។

សេចក្តីសន្និដ្ឋាន: ដើម្បីអាចធ្វើមាត្រដ្ឋានថ្នាំងដោយស្វ័យប្រវត្តិ វាចាំបាច់ក្នុងការកំណត់សំណើនៅក្នុងធុងផត ដូច្នេះ k8s អាចវាយតម្លៃបន្ទុកនៅលើថ្នាំងបានត្រឹមត្រូវ ហើយរាយការណ៍ថាមិនមានធនធាននៅក្នុងចង្កោមដើម្បីបើកដំណើរការផតបន្ទាប់ទេ។

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

វាគួរតែត្រូវបានកត់សម្គាល់ថាការកំណត់ដែនកំណត់ធនធានកុងតឺន័រមិនមែនជាតម្រូវការសម្រាប់កម្មវិធីដើម្បីដំណើរការដោយជោគជ័យនោះទេប៉ុន្តែវានៅតែប្រសើរជាងក្នុងការធ្វើដូច្នេះសម្រាប់ហេតុផលដូចខាងក្រោមៈ

សម្រាប់ប្រតិបត្តិការត្រឹមត្រូវបន្ថែមទៀតនៃកម្មវិធីកំណត់ពេលក្នុងលក្ខខណ្ឌនៃតុល្យភាពបន្ទុករវាងថ្នាំង k8s
ដើម្បីកាត់បន្ថយលទ្ធភាពនៃព្រឹត្តិការណ៍ "ការបណ្តេញចេញ" កើតឡើង
សម្រាប់ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិផ្ដេកនៃកម្មវិធី pods (HPA) ដើម្បីដំណើរការ
សម្រាប់ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិផ្ដេកនៃថ្នាំង (Cluster Autoscaling) សម្រាប់អ្នកផ្ដល់ពពក

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

ប្រភព: www.habr.com

Kubernetes៖ ហេតុអ្វីបានជាវាមានសារៈសំខាន់ខ្លាំងណាស់ក្នុងការកំណត់រចនាសម្ព័ន្ធការគ្រប់គ្រងធនធានប្រព័ន្ធ?