ኩበርኔትስ፡ የስርዓት ሃብት አስተዳደርን ማዋቀር በጣም አስፈላጊ የሆነው ለምንድነው?

እንደ ደንቡ ፣ ለትክክለኛው እና ለተረጋጋ አሠራሩ ለትግበራው የወሰኑ ሀብቶችን ሁል ጊዜ ማቅረብ ያስፈልጋል። ግን ብዙ መተግበሪያዎች በተመሳሳይ ኃይል ላይ ቢሰሩስ? ለእያንዳንዳቸው አነስተኛውን አስፈላጊ ሀብቶች እንዴት ማቅረብ እንደሚቻል? የሀብት ፍጆታን እንዴት መገደብ ይቻላል? በአንጓዎች መካከል ያለውን ጭነት በትክክል እንዴት ማሰራጨት ይቻላል? የአፕሊኬሽኑ ጭነት ቢጨምር አግዳሚው የመለኪያ ዘዴ እንዴት እንደሚሰራ እንዴት ማረጋገጥ ይቻላል?

ኩበርኔትስ፡ የስርዓት ሃብት አስተዳደርን ማዋቀር በጣም አስፈላጊ የሆነው ለምንድነው?

በስርዓቱ ውስጥ ምን ዓይነት ዋና ዋና ሀብቶች እንዳሉ መጀመር ያስፈልግዎታል - ይህ በእርግጥ ፕሮሰሰር ጊዜ እና ራም ነው። በ k8s ውስጥ እነዚህ የንብረት ዓይነቶች በሚከተሉት ክፍሎች ይለካሉ፡

  • ሲፒዩ - ኮሮች ውስጥ
  • RAM - በባይት

ከዚህም በላይ ለእያንዳንዱ መገልገያ ሁለት ዓይነት መስፈርቶችን ማዘጋጀት ይቻላል - ጥያቄዎች и ገደቦች. ጥያቄዎች - መያዣዎችን ለማስኬድ የመስቀለኛ መንገድ የነፃ ሀብቶች ዝቅተኛ መስፈርቶችን (እና በአጠቃላይ ፖድ) ይገልፃል ፣ ገደቦች በማጠራቀሚያው ላይ በሚገኙ ሀብቶች ላይ ከባድ ገደብ ያዘጋጃሉ።

አንጸባራቂው ሁለቱንም ዓይነቶች በግልፅ መግለጽ እንደሌለበት መረዳት አስፈላጊ ነው፣ ነገር ግን ባህሪው እንደሚከተለው ይሆናል።

  • የግብአት ወሰን ብቻ በግልፅ ከተገለፀ፣የዚህ ሃብት ጥያቄዎች በራስ-ሰር ከገደቦች ጋር እኩል የሆነ ዋጋ ይወስዳል (ይህንን ገላጭ አካላት በመደወል ማረጋገጥ ይችላሉ።) እነዚያ። እንደ እውነቱ ከሆነ, ኮንቴይነሩ ለማሄድ በሚያስፈልገው ተመሳሳይ መጠን ላይ ብቻ የተገደበ ይሆናል.
  • ለሀብት ጥያቄዎች በግልፅ ከተገለጹ፣ በዚህ ሃብት ላይ ምንም ከፍተኛ ገደቦች አልተዘጋጁም - ማለትም። መያዣው በእራሱ መስቀለኛ መንገድ ሀብቶች ብቻ የተገደበ ነው.

እንዲሁም በአንድ የተወሰነ መያዣ ደረጃ ላይ ብቻ ሳይሆን በስም ቦታ ደረጃ የሚከተሉትን አካላት በመጠቀም የንብረት አስተዳደርን ማዋቀር ይቻላል ።

  • ገደብ ክልል - በመያዣው / በፖድ ደረጃ ላይ ያለውን የእገዳ ፖሊሲ በ ns ውስጥ ይገልፃል እና በመያዣው / ፖድ ላይ ያለውን ነባሪ ገደቦችን ለመግለጽ እና እንዲሁም ግልጽ የሆኑ ወፍራም ኮንቴይነሮች / ፖዶች (ወይም በተቃራኒው) እንዳይፈጠሩ ለመከላከል ያስፈልጋል ፣ ቁጥራቸውን ይገድቡ እና በእሴቶቹ ገደቦች እና ጥያቄዎች ውስጥ ሊኖር የሚችለውን ልዩነት ይወስኑ
  • ResourceQuotas - በአጠቃላይ በ ns ውስጥ ለሚገኙ ሁሉም ኮንቴይነሮች የእገዳ ፖሊሲን ይግለጹ እና እንደ ደንቡ በአከባቢው መካከል ሀብቶችን ለመገደብ ጥቅም ላይ ይውላል (አካባቢዎች በመስቀለኛ ደረጃ ላይ በጥብቅ ካልተከለሉ ጠቃሚ)

የሚከተሉት የሃብት ገደቦችን የሚያዘጋጁ የገለጻ ማሳያዎች ምሳሌዎች ናቸው።

  • በልዩ መያዣ ደረጃ;

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

    እነዚያ። በዚህ አጋጣሚ ኮንቴይነሩን በ nginx ለማስኬድ ቢያንስ 1ጂ ነፃ ራም እና 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 ውስጥ ያሉት የሁሉም የጥያቄ ኮንቴይነሮች ድምር ለሲፒዩ እና 300ጂ ለOP ከ1ሜ መብለጥ አይችልም የሁሉም ገደብ ድምር ለሲፒዩ 700ሜ እና 2ጂ ለ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

    እነዚያ። በነባሪው የስም ቦታ ለሁሉም ኮንቴይነሮች ጥያቄ ወደ 100ሜ ለሲፒዩ እና 1ጂ ለ OP፣ ገደብ - 1 ሲፒዩ እና 2ጂ ይቀናበራል። በተመሳሳይ ጊዜ ለሲፒዩ (50m <x <2) እና RAM (500M < x < 4G) ሊሆኑ በሚችሉ እሴቶች ላይ ገደብ ተቀምጧል።

  • የፖድ-ደረጃ ገደቦች፡-

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

    እነዚያ። ለእያንዳንዱ ፖድ በነባሪ ns የ 4 vCPU እና 1G ገደብ ይኖረዋል።

አሁን እነዚህን ገደቦች ማዘጋጀት ምን ጥቅሞች እንደሚሰጡን ልነግርዎ እፈልጋለሁ።

በአንጓዎች መካከል የማመጣጠን ዘዴን ይጫኑ

እንደሚያውቁት የ k8s ክፍል እንደ አንጓዎች መካከል ፖድዎችን ለማሰራጨት ሃላፊነት አለበት የጊዜ ሰሌዳ ሰሪ, በተወሰነ ስልተ ቀመር መሰረት የሚሰራ. ለማስጀመር በጣም ጥሩውን መስቀለኛ መንገድ በሚመርጡበት ጊዜ ይህ ስልተ ቀመር በሁለት ደረጃዎች ውስጥ ያልፋል።

  1. ማጣራት
  2. ደረጃ

እነዚያ። በተገለፀው ፖሊሲ መሰረት, በስብስብ ላይ በመመስረት ፖድ ማስጀመር የሚቻልባቸው ኖዶች መጀመሪያ ላይ ተመርጠዋል ይተነብያል (መስቀለኛ መንገድ ፖድውን ለማስኬድ በቂ ሀብቶች እንዳሉት ማረጋገጥን ጨምሮ - PodFitsResources)፣ እና ከዚያ ለእያንዳንዱ እነዚህ አንጓዎች፣ እንደሚለው ቅድሚያ የሚሰጣቸውን ነገሮች ነጥቦች ተሰጥተዋል (የአንድ መስቀለኛ መንገድ የበለጠ ነፃ ሀብቶችን ጨምሮ ፣ ብዙ ነጥቦች ይመደባሉ - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) እና ፖድ በመስቀለኛ መንገድ ላይ በጣም ብዙ ነጥቦችን ይጀምራል (ብዙ አንጓዎች ይህንን ሁኔታ በአንድ ጊዜ ካሟሉ ፣ ከዚያ አንድ በዘፈቀደ ይመረጣል) .

በተመሳሳይ ጊዜ መርሐግብር አውጪው የመስቀለኛ መንገድ ያሉትን ሀብቶች ሲገመግም በ etcd ውስጥ በተከማቸ መረጃ እንደሚመራ መረዳት ያስፈልግዎታል - ማለትም. በዚህ መስቀለኛ መንገድ ላይ ለሚሰራው የእያንዳንዱ ፖድ ምንጭ ለተጠየቀው/ገደብ፣ ለትክክለኛው የሃብት ፍጆታ ግን አይደለም። ይህ መረጃ ከትዕዛዝ ውፅዓት ሊገኝ ይችላል 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%)

እዚህ ሁሉም ፖድዎች በአንድ የተወሰነ መስቀለኛ መንገድ ላይ ሲሰሩ እና እንዲሁም እያንዳንዱ ፖድ የሚጠይቃቸውን ሀብቶች እንመለከታለን. እና ክሮንጆብ-ክሮን-ክስተቶች-1573793820-xt6q9 ፖድ ሲጀመር የፕሮግራም ሰሪ ምዝግብ ማስታወሻዎች ምን እንደሚመስሉ እነሆ (ይህ መረጃ 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).

መደምደሚያ: አንድ መስቀለኛ መንገድ ምንም ገደብ ያልተዘጋጀባቸው ፖድዎች ቢሰራ, ከዚያም ለ k8s (ከሀብት ፍጆታ አንጻር) ይህ በዚህ መስቀለኛ መንገድ ላይ እንደዚህ ያሉ ፖዶች ከሌሉ ጋር እኩል ይሆናል. ስለዚህ, እርስዎ, ሁኔታዊ, ሆዳምነት ያለው ሂደት (ለምሳሌ, wowza) ያለው ፖድ ካለዎት እና ለእሱ ምንም ገደቦች ካልተቀመጡ, ይህ ፖድ በእውነቱ ሁሉንም የመስቀለኛ ሃብቶችን ሲበላ ሁኔታ ሊፈጠር ይችላል, ነገር ግን ለ k8s ይህ መስቀለኛ መንገድ. እንዳልተጫነ ይቆጠራል እና ደረጃ ሲወጣ ተመሳሳይ የነጥብ ብዛት ይሸለማል (ትክክለኛውን ያሉትን ሀብቶች በሚገመግመው ነጥብ) እንደ መስቀለኛ መንገድ የሚሰራ ፓድ የሌለው ነው ፣ ይህም በመጨረሻ በአንጓዎች መካከል ያለውን ጭነት ወደ ሚዛናዊ ያልሆነ ስርጭት ሊያመራ ይችላል።

የፖድ ማስወጣት

እንደሚታወቀው እያንዳንዱ ፖድ ከ3 QoS ክፍሎች ውስጥ አንዱን ይመደባል፡-

  1. ዋስትና ተሰጥቶታል። - በፖዳው ውስጥ ላለው እያንዳንዱ መያዣ ለማህደረ ትውስታ እና ለሲፒዩ ጥያቄ እና ገደብ ሲገለጽ ይመደባል ፣ እና እነዚህ እሴቶች መዛመድ አለባቸው
  2. ሊፈነዳ የሚችል - በፖድ ውስጥ ቢያንስ አንድ ኮንቴይነር ጥያቄ እና ገደብ አለው፣ ከጥያቄ ጋር < ወሰን
  3. ምርጥ ጥረት - በፖድ ውስጥ አንድ ኮንቴይነር በማይኖርበት ጊዜ የሃብት ውስንነት

በተመሳሳይ ጊዜ, አንድ መስቀለኛ መንገድ የሃብት እጥረት (ዲስክ, ማህደረ ትውስታ) ሲያጋጥመው ኩቤሌት የፖድ እና የ QoS ክፍልን ቅድሚያ ግምት ውስጥ በማስገባት በተለየ ስልተ-ቀመር መሰረት ደረጃ መስጠት እና ማስወጣት ይጀምራል. ለምሳሌ ፣ ስለ RAM እየተነጋገርን ከሆነ ፣ ከዚያ በ QoS ክፍል ላይ በመመስረት ፣ ነጥቦች በሚከተለው መርህ መሠረት ይሰጣሉ ።

  • የተረጋገጠ-998
  • ምርጥ ጥረት: 1000
  • ሊፈነዳ የሚችል: ደቂቃ (ከፍተኛ (2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes)፣ 999)

እነዚያ። በተመሳሳዩ ቅድሚያ, ኩቤሌቱ በመጀመሪያ ከፍተኛ ጥረት QoS ክፍልን ከመስቀለኛ መንገዱ ያስወጣል.

መደምደሚያ: የሚፈለገውን ፖድ በላዩ ላይ የሃብት እጥረት በሚኖርበት ጊዜ ከአንጓው ውስጥ የማስወጣት እድልን ለመቀነስ ከፈለጉ ከቅድሚያው ጋር ፣ እንዲሁም ለእሱ ጥያቄውን / ገደቡን ለማዘጋጀት ጥንቃቄ ማድረግ አለብዎት ።

የአፕሊኬሽን ፖድስ (HPA) አግድም አውቶማቲካሊንግ ሜካኒዝም

ስራው በሃብት አጠቃቀም (ስርዓት - ሲፒዩ/ራም ወይም ተጠቃሚ - rps) ላይ በመመስረት የፖዳዎችን ቁጥር በራስ-ሰር መጨመር እና መቀነስ ሲቻል የ k8s አካል እንደ HPA (አግድም ፖድ አውቶስካለር)። ስልተ ቀመር የሚከተለው ነው።

  1. አሁን ያሉት የተስተዋሉ ሀብቶች ንባቦች ተወስነዋል (currentMetricValue)
  2. ለሀብቱ የሚፈለጉት እሴቶች ተወስነዋል (desiredMetricValue)፣ ለስርዓት ሃብቶች የሚዘጋጁት ጥያቄን በመጠቀም ነው።
  3. የአሁኑ ቅጂዎች ብዛት ተወስኗል (የአሁኑ ቅጂዎች)
  4. የሚከተለው ፎርሙላ የሚፈለገውን የተባዙ ብዛት ያሰላል (desiredReplicas)
    የሚፈለግReplicas = [ currentReplicas * ( currentMetricValue / wantedMetricValue)]

በዚህ ሁኔታ የመለኪያ ልኬት (currentMetricValue / wantedMetricValue) ወደ 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 መያዣዎችን ይይዛሉ ፣ ለእያንዳንዳቸው የተወሰነ። ጥያቄዎች ለሲፒዩ.

  • የ 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

    እነዚያ። የDeployment መተግበሪያ-ፈተናውን የሚከታተል እና በሲፒዩ አመልካች ላይ በመመስረት የፖድ ቁጥርን ከመተግበሪያው ጋር የሚያስተካክል hpa ፈጠርን (ፖዱ የሚፈልገውን ሲፒዩ 30 በመቶውን እንዲወስድ እንጠብቃለን) የተባዙት ብዛት በ ውስጥ ነው። ከ2-10 ያለው ክልል.

    አሁን፣ በአንዱ ምድጃዎች ላይ ሸክምን ከተጠቀምን የ hpa Operation ዘዴን እንመልከት፡-

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

በጠቅላላው የሚከተለው አለን:

  • የሚፈለገው እሴት (desiredMetricValue) - በ hpa ቅንብሮች መሠረት 30% አለን።
  • የአሁኑ ዋጋ (currentMetricValue) - ለስሌት, ተቆጣጣሪ-አስተዳዳሪ በ% ውስጥ ያለውን የንብረት ፍጆታ አማካይ ዋጋ ያሰላል, ማለትም. በሁኔታዊ ሁኔታ የሚከተሉትን ያደርጋል:
    1. ፍጹም የፖድ መለኪያዎችን ከሜትሪክ አገልጋዩ ይቀበላል፣ i.e. 101ሜ እና 4ሜ
    2. አማካይ ፍፁም እሴት ያሰላል፣ ማለትም (101ሜ + 4ሜ) / 2 = 53ሜ
    3. ለሚፈለገው የሃብት ፍጆታ ፍፁም ዋጋን ያገኛል (ለዚህም የሁሉም ኮንቴይነሮች ጥያቄዎች ተጠቃለዋል) 60m + 30m = 90m
    4. ከጥያቄው ፖድ አንፃር አማካይ የሲፒዩ ፍጆታ መቶኛ ያሰላል፣ i.e. 53ሜ/90ሜ * 100% = 59%

አሁን የተባዛዎችን ቁጥር መለወጥ እንዳለብን ለመወሰን የሚያስፈልገንን ሁሉ አግኝተናል, ይህንን ለማድረግ, ኮፊሸን እናሰላለን:

ratio = 59% / 30% = 1.96

እነዚያ። የተባዛዎች ብዛት ~ 2 ጊዜ እና መጠኑ ወደ [2 * 1.96] = 4 መጨመር አለበት።

ማጠቃለያ: እንደሚመለከቱት, ይህ ዘዴ እንዲሠራ, አስፈላጊው ሁኔታ በሚታየው ፖድ ውስጥ የሁሉም መያዣዎች ጥያቄዎች መገኘት ነው.

የአንጓዎች አግድም አውቶማቲክ መለኪያ ዘዴ (ክላስተር አውቶማቲክ)

በጭነት መጨናነቅ ወቅት በሲስተሙ ላይ ያለውን አሉታዊ ተጽእኖ ለማስወገድ የተዋቀረ hpa መኖሩ በቂ አይደለም. ለምሳሌ ፣ በ hpa ተቆጣጣሪው ሥራ አስኪያጅ ውስጥ ባለው ቅንጅቶች መሠረት ፣ የተባዙ ብዛት በ 2 ጊዜ መጨመር እንዳለበት ይወስናል ፣ ግን አንጓዎቹ እንደዚህ ያሉ በርካታ ፓዶችን ለማስኬድ ነፃ ሀብቶች የላቸውም (ማለትም መስቀለኛ መንገዱ ይህንን ማቅረብ አይችልም) የተጠየቁ ሀብቶች ወደ ጥያቄው ፖድ) እና እነዚህ ፖድዎች ወደ በመጠባበቅ ላይ ወዳለው ሁኔታ ይቀየራሉ።

በዚህ አጋጣሚ፣ አቅራቢው ተዛማጅ IaaS/PaaS (ለምሳሌ GKE/GCE፣ AKS፣ EKS፣ ወዘተ) ካለው፣ እንደ መሳሪያ መስቀለኛ አውቶማቲክ. በክላስተር ውስጥ ከፍተኛውን እና ዝቅተኛውን የአንጓዎች ብዛት እንዲያዘጋጁ እና አሁን ያለውን የኖዶች ብዛት (የደመና አቅራቢውን ኤፒአይ በመደወል መስቀለኛ መንገድን ለማዘዝ/በማስወገድ) እንዲያስተካክሉ ይፈቅድልዎታል በክላስተር እና በፖዳዎች ውስጥ የሃብት እጥረት ሲኖር። መርሐግብር ማስያዝ አይቻልም (በመጠባበቅ ላይ ያሉ)።

ማጠቃለያ: ኖዶችን አውቶማቲክ ለማድረግ በፖድ ኮንቴይነሮች ውስጥ ጥያቄዎችን ማዘጋጀት አስፈላጊ ነው k8s በመስቀለኛ መንገድ ላይ ያለውን ጭነት በትክክል መገምገም እና በዚህ መሠረት በክላስተር ውስጥ ቀጣዩን ፖድ ለማስጀመር ምንም ሀብቶች እንደሌሉ ሪፖርት ያድርጉ ።

መደምደሚያ

አፕሊኬሽኑ በተሳካ ሁኔታ እንዲሠራ የመያዣ ሀብቶች ገደቦችን ማቀናበር አስፈላጊ እንዳልሆነ ልብ ሊባል ይገባል ፣ ግን አሁንም በሚከተሉት ምክንያቶች ይህንን ማድረጉ የተሻለ ነው ።

  1. በ k8s አንጓዎች መካከል ካለው ጭነት ማመጣጠን አንፃር የጊዜ ሰሌዳውን የበለጠ ትክክለኛ አሠራር ለማግኘት
  2. የ"ፖድ ማስወጣት" ክስተት የመከሰት እድልን ለመቀነስ
  3. የአፕሊኬሽን ፖድስ (HPA) አግድም አውቶማቲክን ለመሥራት
  4. ለደመና አቅራቢዎች የአንጓዎች አግድም ራስ-ስኬል (Cluster Autoscaling)

በብሎጋችን ላይ ሌሎች ጽሑፎችን ያንብቡ፡-

ምንጭ: hab.com

አስተያየት ያክሉ