ProHoster > බ්ලොග් > පරිපාලනය > Kubernetes: පද්ධති සම්පත් කළමනාකරණය පිහිටුවීම එතරම් වැදගත් වන්නේ ඇයි?

Kubernetes: පද්ධති සම්පත් කළමනාකරණය පිහිටුවීම එතරම් වැදගත් වන්නේ ඇයි?

රීතියක් ලෙස, එහි නිවැරදි සහ ස්ථාවර ක්‍රියාකාරිත්වය සඳහා යෙදුමකට කැප වූ සම්පත් සංචිතයක් සැපයීමේ අවශ්‍යතාවය සැමවිටම පවතී. නමුත් යෙදුම් කිහිපයක් එකම බලයකින් ක්‍රියාත්මක වන්නේ නම් කුමක් කළ යුතුද? ඒ සෑම එකක්ම අවම අවශ්‍ය සම්පත් ලබා දෙන්නේ කෙසේද? ඔබට සම්පත් පරිභෝජනය සීමා කළ හැක්කේ කෙසේද? නෝඩ් අතර බර නිවැරදිව බෙදා හරින්නේ කෙසේද? යෙදුම් භාරය වැඩි වුවහොත් තිරස් පරිමාණ යාන්ත්‍රණය ක්‍රියා කරන බව සහතික කරන්නේ කෙසේද?

Kubernetes: පද්ධති සම්පත් කළමනාකරණය පිහිටුවීම එතරම් වැදගත් වන්නේ ඇයි?

පද්ධතියේ පවතින ප්‍රධාන සම්පත් වර්ග මොනවාදැයි ඔබ ආරම්භ කළ යුතුය - මෙය ඇත්ත වශයෙන්ම ප්‍රොසෙසර කාලය සහ RAM වේ. k8s හි මෙම සම්පත් වර්ග පහත ඒකක වලින් මනිනු ලැබේ:

  • CPU - හරය තුළ
  • RAM - බයිට් වලින්

එපමණක් නොව, සෑම සම්පතක් සඳහාම අවශ්‍යතා වර්ග දෙකක් සැකසිය හැකිය - ඉල්ලීම් и සීමාවන්. ඉල්ලීම් - බහාලුමක් (සහ සමස්තයක් ලෙස පොඩ්) ක්‍රියාත්මක කිරීම සඳහා නෝඩයක නිදහස් සම්පත් සඳහා අවම අවශ්‍යතා විස්තර කරන අතර, සීමාවන් බහාලුමට ඇති සම්පත් මත දැඩි සීමාවක් සකසයි.

මැනිෆෙස්ටයට වර්ග දෙකම පැහැදිලිව නිර්වචනය කිරීමට අවශ්‍ය නොවන බව වටහා ගැනීම වැදගත්ය, නමුත් හැසිරීම පහත පරිදි වනු ඇත:

  • සම්පතක සීමාවන් පමණක් පැහැදිලිව දක්වා තිබේ නම්, මෙම සම්පත සඳහා වන ඉල්ලීම් ස්වයංක්‍රීයව සීමාවන්ට සමාන අගයක් ගනී (ඔබට විස්තර කරන ආයතන ඇමතීමෙන් මෙය සත්‍යාපනය කළ හැක). එම. ඇත්ත වශයෙන්ම, කන්ටේනරය ධාවනය කිරීමට අවශ්‍ය සම්පත් ප්‍රමාණයටම සීමා වේ.
  • සම්පතක් සඳහා ඉල්ලීම් පමණක් පැහැදිලිව දක්වා තිබේ නම්, මෙම සම්පත සඳහා ඉහළ සීමාවන් සකසා නොමැත - i.e. කන්ටේනරය සීමා වන්නේ නෝඩයේම සම්පත් වලින් පමණි.

නිශ්චිත බහාලුම් මට්ටමින් පමණක් නොව, පහත සඳහන් ආයතන භාවිතා කරමින් නාම අවකාශ මට්ටමින් ද සම්පත් කළමනාකරණය වින්‍යාසගත කළ හැකිය:

  • LimitRange — ns හි බහාලුම්/පොඩ් මට්ටමින් සීමා කිරීමේ ප්‍රතිපත්තිය විස්තර කරන අතර බහාලුම්/පොඩ් මත පෙරනිමි සීමාවන් විස්තර කිරීමට මෙන්ම, පැහැදිලිවම මේදය සහිත බහාලුම්/පොඩ් (හෝ අනෙක් අතට) සෑදීම වැළැක්වීම සඳහා අවශ්‍ය වේ, ඒවායේ සංඛ්‍යාව සීමා කරන්න. සහ සීමාවන් සහ ඉල්ලීම්වල අගයන්හි ඇති විය හැකි වෙනස තීරණය කරන්න
  • සම්පත් කෝටා - ns හි ඇති සියලුම බහාලුම් සඳහා පොදුවේ සීමා කිරීමේ ප්‍රතිපත්තිය විස්තර කරන අතර, රීතියක් ලෙස, පරිසරයන් අතර සම්පත් සීමා කිරීමට භාවිතා කරයි (පරිසරය නෝඩ් මට්ටමින් දැඩි ලෙස වෙන් කර නොමැති විට ප්‍රයෝජනවත් වේ)

සම්පත් සීමාවන් සකසන මැනිෆෙස්ට් වල උදාහරණ පහත දැක්වේ:

  • නිශ්චිත බහාලුම් මට්ටමින්:

    containers:
- name: app-nginx
  image: nginx
  resources:
    requests:
      memory: 1Gi
    limits:
      cpu: 200m

    එම. මෙම අවස්ථාවේදී, nginx සමඟ කන්ටේනරයක් ධාවනය කිරීම සඳහා, ඔබට අවම වශයෙන් 1G නොමිලේ RAM සහ 0.2 CPU නෝඩය මත අවශ්‍ය වනු ඇත, බොහෝ විට බහාලුමට CPU 0.2 සහ node හි ඇති සියලුම 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 හි ඇති සියලුම ඉල්ලීම් බහාලුම්වල එකතුව CPU සඳහා 300m සහ OP සඳහා 1G නොඉක්මවිය යුතු අතර, සියලු සීමාවේ එකතුව CPU සඳහා 700m සහ OP සඳහා 2G වේ.

  • 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

    එම. සියලුම බහාලුම් සඳහා පෙරනිමි නාම අවකාශයේ, ඉල්ලීම CPU සඳහා 100m සහ OP සඳහා 1G ලෙස සකසනු ඇත, සීමාව - 1 CPU සහ 2G. ඒ අතරම, CPU (50m < x < 2) සහ RAM (500M < x < 4G) සඳහා ඉල්ලීම්/සීමාව තුළ ඇති විය හැකි අගයන් සඳහාද සීමාවක් සකසා ඇත.

  • පොඩ් මට්ටමේ සීමා කිරීම් ns:

    apiVersion: v1
kind: LimitRange
metadata:
 name: nxs-limit-pod
spec:
 limits:
 - type: Pod
   max:
     cpu: 4
     memory: 1Gi

    එම. පෙරනිමියේ ඇති සෑම පොඩ් එකක් සඳහාම 4 vCPU සහ 1G සීමාවක් ඇත.

දැන් මම ඔබට කියන්න කැමතියි මෙම සීමා කිරීම් අපට ලබා දිය හැකි වාසි මොනවාද.

නෝඩ් අතර සමතුලිත යාන්ත්‍රණය පැටවීම

ඔබ දන්නා පරිදි, නෝඩ් අතර කරල් බෙදා හැරීම සඳහා k8s සංරචකය වගකිව යුතුය උපලේඛකයා, නිශ්චිත ඇල්ගොරිතමයකට අනුව ක්රියා කරයි. දියත් කිරීමට ප්‍රශස්ත නෝඩය තෝරාගැනීමේදී මෙම ඇල්ගොරිතම අදියර දෙකක් හරහා ගමන් කරයි:

  1. පෙරහන්
  2. පරාසයක

එම. විස්තර කර ඇති ප්‍රතිපත්තියට අනුව, කට්ටලයක් මත පදනම්ව පොඩ් එකක් දියත් කළ හැකි නෝඩ් මුලින් තෝරා ගනු ලැබේ පුරෝකථනය කරයි (පොඩ් - 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 පොඩ් දියත් කළ විට උපලේඛන ලොග කෙබඳුද යන්න මෙන්න (මෙම තොරතුරු උපලේඛන ලොගයේ දිස් වනු ඇත, දියත් කිරීමේ විධානයේ -v=10 විධානයේ 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). පසුව එය වඩාත් සුදුසු නෝඩය තීරණය කිරීම සඳහා මෙම එක් එක් නෝඩ් සඳහා පරාමිති කිහිපයක් (ශේෂිත සම්පත් වෙන් කිරීම, අවම සම්පත් වෙන් කිරීම ඇතුළුව) මත පදනම්ව ලකුණු ගණනය කරයි. අවසාන වශයෙන්, පොඩ් එක වැඩිම ලකුණු සංඛ්‍යාවක් සහිත නෝඩය මත සැලසුම් කර ඇත (මෙහි නෝඩ් දෙකකට එකවර ලකුණු 100037 සමාන වේ, එබැවින් අහඹු එකක් තෝරා ඇත - nxs-k8s-s10).

නිගමනය: නෝඩයක් කිසිදු සීමාවක් සකසා නොමැති කරල් ධාවනය කරන්නේ නම්, k8s සඳහා (සම්පත් පරිභෝජනයේ දෘෂ්ටි කෝණයෙන්) මෙය මෙම නෝඩයේ එවැනි කරල් කිසිවක් නොතිබුණාක් මෙන් සමාන වේ. එමනිසා, ඔබට, කොන්දේසි සහිතව, කෑදර ක්‍රියාවලියක් සහිත පොඩ් එකක් තිබේ නම් (උදාහරණයක් ලෙස, wowza) සහ ඒ සඳහා කිසිදු සීමාවක් සකසා නොමැති නම්, මෙම පොඩ් එක ඇත්ත වශයෙන්ම නෝඩයේ සියලුම සම්පත් අනුභව කරන විට තත්වයක් ඇතිවිය හැකිය, නමුත් k8s සඳහා මෙම නෝඩය බාන ලද ලෙස සලකනු ලබන අතර, වැඩ කරන කරල් නොමැති නෝඩයක් ලෙස ශ්‍රේණිගත කිරීමේදී (හරියටම පවතින සම්පත් තක්සේරු කරන ලකුණු වලින්) එයට සමාන ලකුණු සංඛ්‍යාවක් පිරිනමනු ලැබේ, එය අවසානයේ නෝඩ් අතර බර අසමාන ලෙස බෙදා හැරීමට හේතු විය හැක.

පොඩ්ගේ නෙරපා හැරීම

ඔබ දන්නා පරිදි, සෑම පොඩ් එකකටම QoS පන්ති 3න් එකක් පවරා ඇත:

  1. සහතික කර ඇත - මතකය සහ cpu සඳහා ඉල්ලීමක් සහ සීමාවක් නියම කර ඇති විට පොඩ් එකෙහි එක් එක් බහාලුම් සඳහා පවරනු ලබන අතර, මෙම අගයන් ගැලපිය යුතුය.
  2. පුපුරා යා හැකි - අඩුම තරමින් පෝඩ් එකේ එක් බහාලුමක් හෝ ඉල්ලීමක් සහ සීමාවක් ඇත, ඉල්ලීම < සීමාව සමඟ
  3. හොඳම උත්සාහය - පොඩ්ඩේ එක කන්ටේනරයක් වත් සම්පත් සීමිත නොවන විට

ඒ අතරම, නෝඩයක් සම්පත් හිඟයක් (තැටිය, මතකය) අත්විඳින විට, kubelet පොඩ් සහ එහි QoS පන්තියේ ප්‍රමුඛතාවය සැලකිල්ලට ගන්නා විශේෂිත ඇල්ගොරිතමයකට අනුව කරල් ශ්‍රේණිගත කිරීමට සහ ඉවත් කිරීමට පටන් ගනී. උදාහරණයක් ලෙස, අපි RAM ගැන කතා කරන්නේ නම්, QoS පන්තිය මත පදනම්ව, පහත සඳහන් මූලධර්මය අනුව ලකුණු ලබා දෙනු ලැබේ:

  • සහතික කර ඇත:-998
  • හොඳම උත්සාහය: 1000
  • පුපුරා යා හැකි: අවම(උපරිම(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

එම. එම ප්‍රමුඛතාවය ඇතිව, kubelet විසින් ප්‍රථමයෙන්ම නෝඩයෙන් QoS පන්තියේ හොඳම උත්සාහයෙන් කරල් ඉවත් කරනු ඇත.

නිගමනය: ඔබට අවශ්‍ය පොඩ් එක නෝඩයෙන් ඉවත් කිරීමේ සම්භාවිතාව අඩු කිරීමට අවශ්‍ය නම්, ප්‍රමුඛතාවය සමඟ, ඔබ ඒ සඳහා ඉල්ලීම/සීමාව සැකසීම ගැනද සැලකිලිමත් විය යුතුය.

යෙදුම් කරල් (HPA) තිරස් ස්වයං පරිමාණය සඳහා යාන්ත්‍රණය

කාර්යය සම්පත් භාවිතය (පද්ධතිය - CPU/RAM හෝ පරිශීලක - rps) මත පදනම්ව ස්වයංක්‍රීයව කරල් ගණන වැඩි කිරීම සහ අඩු කිරීම වන විට, එවැනි k8s ආයතනයක් එච්.ඒ.ඒ. (තිරස් Pod Autoscaler). එහි ඇල්ගොරිතම පහත පරිදි වේ:

  1. නිරීක්ෂණය කරන ලද සම්පතෙහි වත්මන් කියවීම් තීරණය කරනු ලැබේ (වත්මන්මිතික අගය)
  2. සම්පත් සඳහා අපේක්ෂිත අගයන් තීරණය කරනු ලැබේ (අවශ්‍යMetricValue), ඒවා පද්ධති සම්පත් සඳහා ඉල්ලීම භාවිතයෙන් සකසා ඇත
  3. වත්මන් අනුරූ සංඛ්‍යාව තීරණය වේ (වර්තමාන අනුරූ)
  4. පහත සූත්‍රය අපේක්ෂිත අනුරූ ගණන ගණනය කරයි (අවශ්‍ය අනුරුව)
    අභිමත අනුරූ = [ වත්මන් අනුරූ * ( වත්මන් මෙට්‍රික් අගය / අපේක්ෂිත මෙට්‍රික් අගය )]

මෙම අවස්ථාවෙහිදී, සංගුණකය (වත්මන් මෙට්‍රික් අගය / අපේක්ෂිත මෙට්‍රික් අගය) 1 ට ආසන්න වූ විට පරිමාණය සිදු නොවේ (මෙම අවස්ථාවේදී, අපට අවසර ලත් දෝෂය අප විසින්ම සැකසිය හැකිය; පෙරනිමියෙන් එය 0.1 වේ).

යෙදුම්-පරීක්ෂණ යෙදුමේ උදාහරණය භාවිතා කරමින් hpa ක්‍රියා කරන ආකාරය බලමු (නිර්මාණය කිරීම ලෙස විස්තර කර ඇත), එහිදී CPU පරිභෝජනය අනුව අනුරූ ගණන වෙනස් කිරීම අවශ්‍ය වේ:

  • යෙදුම් මැනිෆෙස්ටය

    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 ප්‍රකාශනය

    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 අධීක්ෂණය කරන අතර cpu දර්ශකය මත පදනම්ව යෙදුම සමඟ පොඩ් ගණන නියාමනය කරයි (පොඩ් එය ඉල්ලා සිටින CPU වලින් 30% ක් පරිභෝජනය කළ යුතු යැයි අපි අපේක්ෂා කරමු), අනුරූ ගණන සමඟ. 2-10 පරාසයේ.

    දැන්, අපි එක් උදුනකට බරක් යොදන්නේ නම් hpa ක්‍රියාකාරිත්වයේ යාන්ත්‍රණය දෙස බලමු:

     # kubectl top pod
NAME                                                   CPU(cores)   MEMORY(bytes)
app-test-78559f8f44-pgs58            101m         243Mi
app-test-78559f8f44-cj4jz            4m           240Mi

සමස්තයක් වශයෙන් අපට පහත සඳහන් දේ ඇත:

  • අපේක්ෂිත අගය (අවශ්‍යMetricValue) - hpa සැකසුම් අනුව, අපට 30% ඇත
  • වත්මන් අගය (currentMetricValue) - ගණනය කිරීම සඳහා, පාලක-කළමනාකරු % හි සම්පත් පරිභෝජනයේ සාමාන්ය අගය ගණනය කරයි, i.e. කොන්දේසි සහිතව පහත සඳහන් දේ කරයි:
    1. මෙට්‍රික් සේවාදායකයෙන් පොඩ් මෙට්‍රික්වල නිරපේක්ෂ අගයන් ලබා ගනී, i.e. මීටර් 101 සහ මීටර් 4
    2. සාමාන්‍ය නිරපේක්ෂ අගය ගණනය කරයි, i.e. (101m + 4m) / 2 = 53m
    3. අපේක්ෂිත සම්පත් පරිභෝජනය සඳහා නිරපේක්ෂ අගය ලබා ගනී (මේ සඳහා, සියලුම බහාලුම්වල ඉල්ලීම් සාරාංශ කර ඇත) 60m + 30m = 90m
    4. ඉල්ලීම් පොඩ් එකට සාපේක්ෂව CPU පරිභෝජනයේ සාමාන්‍ය ප්‍රතිශතය ගණනය කරයි, i.e. 53m / 90m * 100% = 59%

දැන් අපට අනුරූ ගණන වෙනස් කළ යුතුද යන්න තීරණය කිරීමට අවශ්‍ය සියල්ල අප සතුව ඇත; මෙය සිදු කිරීම සඳහා, අපි සංගුණකය ගණනය කරමු:

ratio = 59% / 30% = 1.96

එම. අනුරූ ගණන ~2 ගුණයකින් වැඩි කළ යුතු අතර ප්‍රමාණය [2 * 1.96] = 4 දක්වා වැඩි කළ යුතුය.

නිගමනය: ඔබට පෙනෙන පරිදි, මෙම යාන්ත්‍රණය ක්‍රියාත්මක වීමට නම්, අවශ්‍ය කොන්දේසියක් වන්නේ නිරීක්ෂණය කරන ලද පොඩ්ඩයේ සියලුම බහාලුම් සඳහා ඉල්ලීම් තිබීමයි.

නෝඩ් වල තිරස් ස්වයං පරිමාණය සඳහා යාන්ත්‍රණය (Cluster Autoscaler)

බර වැඩිවීමේදී පද්ධතියට සිදුවන negative ණාත්මක බලපෑම උදාසීන කිරීම සඳහා, වින්‍යාසගත hpa තිබීම ප්‍රමාණවත් නොවේ. උදාහරණයක් ලෙස, hpa පාලක කළමනාකරු තුළ ඇති සැකසුම් වලට අනුව, අනුපිටපත් ගණන 2 ගුණයකින් වැඩි කළ යුතු බව තීරණය කරයි, නමුත් නෝඩ් වලට එවැනි පොඩ් ගණනක් ධාවනය කිරීමට නොමිලේ සම්පත් නොමැත (එනම් නෝඩයට සැපයිය නොහැක. ඉල්ලීම් පොඩ් වෙත සම්පත් ඉල්ලා ඇත) සහ මෙම පොඩ් පොරොත්තු තත්ත්වයට මාරු වේ.

මෙම අවස්ථාවේදී, සැපයුම්කරුට අනුරූප IaaS/PaaS (උදාහරණයක් ලෙස, GKE/GCE, AKS, EKS, ආදිය) තිබේ නම්, වැනි මෙවලමක් Node Autoscaler. පොකුරේ සහ කරල්වල සම්පත් හිඟයක් ඇති විට, පොකුරේ උපරිම සහ අවම නෝඩ් ගණන සැකසීමට සහ වත්මන් නෝඩ් ගණන (නෝඩයක් ඇණවුම් කිරීමට / ඉවත් කිරීමට Cloud provider API ඇමතීමෙන්) ස්වයංක්‍රීයව සකස් කිරීමට එය ඔබට ඉඩ සලසයි. උපලේඛනගත කළ නොහැක (පොරොත්තු තත්වයේ ඇත).

නිගමනය: නෝඩ් ස්වයංක්‍රීයව පරිමාණය කිරීමට හැකිවීම සඳහා, k8s හට නෝඩ් වල බර නිවැරදිව තක්සේරු කිරීමට හැකි වන පරිදි පොඩ් බහාලුම්වල ඉල්ලීම් සැකසීම අවශ්‍ය වන අතර ඒ අනුව ඊළඟ පොඩ් එක දියත් කිරීමට පොකුරේ සම්පත් නොමැති බව වාර්තා කරයි.

නිගමනය

යෙදුම සාර්ථකව ක්‍රියාත්මක වීමට බහාලුම් සම්පත් සීමාවන් සැකසීම අවශ්‍ය නොවන බව සටහන් කළ යුතුය, නමුත් පහත හේතූන් මත එසේ කිරීම වඩා හොඳය:

  1. k8s නෝඩ් අතර බර තුලනය අනුව උපලේඛකයේ වඩාත් නිවැරදි ක්‍රියාකාරිත්වය සඳහා
  2. "පොඩ් ඉවත් කිරීමේ" සිදුවීමක් සිදුවීමේ සම්භාවිතාව අඩු කිරීමට
  3. වැඩ කිරීමට යෙදුම් කරල් (HPA) තිරස් ස්වයං පරිමාණය කිරීම සඳහා
  4. වලාකුළු සපයන්නන් සඳහා නෝඩ් (Cluster Autoscaling) තිරස් ස්වයං පරිමාණය සඳහා

අපගේ බ්ලොග් අඩවියේ වෙනත් ලිපිද කියවන්න:

මූලාශ්රය: www.habr.com

අදහස් එක් කරන්න