🥇Kubernetes: ເປັນຫຍັງມັນຈຶ່ງສຳຄັນຫຼາຍໃນການຕັ້ງຄ່າການຈັດການຊັບພະຍາກອນຂອງລະບົບ?

ຕາມກົດລະບຽບ, ມີຄວາມຕ້ອງການທີ່ຈະສະຫນອງຊັບພະຍາກອນທີ່ອຸທິດຕົນເພື່ອຄໍາຮ້ອງສະຫມັກສໍາລັບການປະຕິບັດງານທີ່ຖືກຕ້ອງແລະຫມັ້ນຄົງຂອງມັນ. ແຕ່ຈະເປັນແນວໃດຖ້າຄໍາຮ້ອງສະຫມັກຈໍານວນຫນຶ່ງກໍາລັງເຮັດວຽກຢູ່ໃນພະລັງງານດຽວກັນ? ເຮັດແນວໃດເພື່ອໃຫ້ແຕ່ລະຄົນມີຊັບພະຍາກອນທີ່ຈໍາເປັນຂັ້ນຕ່ໍາ? ເຈົ້າສາມາດຈໍາກັດການບໍລິໂພກຊັບພະຍາກອນໄດ້ແນວໃດ? ວິທີການແຈກຢາຍການໂຫຼດລະຫວ່າງ nodes ຢ່າງຖືກຕ້ອງ? ວິທີການຮັບປະກັນກົນໄກການປັບຂະຫນາດຕາມແນວນອນເຮັດວຽກຖ້າການໂຫຼດຂອງແອັບພລິເຄຊັນເພີ່ມຂຶ້ນ?

ທ່ານຈໍາເປັນຕ້ອງເລີ່ມຕົ້ນດ້ວຍປະເພດຂອງຊັບພະຍາກອນຕົ້ນຕໍທີ່ມີຢູ່ໃນລະບົບ - ນີ້, ແນ່ນອນ, ແມ່ນເວລາຂອງໂປເຊດເຊີແລະ RAM. ໃນ k8s manifests ປະເພດຊັບພະຍາກອນເຫຼົ່ານີ້ຖືກວັດແທກຢູ່ໃນຫນ່ວຍງານຕໍ່ໄປນີ້:

CPU - ໃນ cores
RAM - ໃນ bytes

ຍິ່ງໄປກວ່ານັ້ນ, ສໍາລັບແຕ່ລະຊັບພະຍາກອນມັນເປັນໄປໄດ້ທີ່ຈະກໍານົດສອງປະເພດຂອງຄວາມຕ້ອງການ - ການຮ້ອງຂໍ и ຂໍ້ຈໍາກັດ. ການຮ້ອງຂໍ - ອະທິບາຍຄວາມຕ້ອງການຂັ້ນຕ່ໍາສໍາລັບຊັບພະຍາກອນຟຣີຂອງ node ເພື່ອດໍາເນີນການ container (ແລະ pod ທັງຫມົດ), ໃນຂະນະທີ່ກໍານົດຂອບເຂດຈໍາກັດຍາກກ່ຽວກັບຊັບພະຍາກອນທີ່ມີຢູ່ໃນ container.

ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະເຂົ້າໃຈວ່າ manifest ບໍ່ຈໍາເປັນຕ້ອງກໍານົດທັງສອງປະເພດຢ່າງຊັດເຈນ, ແຕ່ພຶດຕິກໍາຈະເປັນດັ່ງຕໍ່ໄປນີ້:

ຖ້າພຽງແຕ່ກໍານົດຂອບເຂດຈໍາກັດຂອງຊັບພະຍາກອນຢ່າງຈະແຈ້ງ, ການຮ້ອງຂໍສໍາລັບຊັບພະຍາກອນນີ້ຈະເອົາມູນຄ່າເທົ່າກັບການຈໍາກັດໂດຍອັດຕະໂນມັດ (ທ່ານສາມາດກວດສອບນີ້ໂດຍການໂທຫາຫນ່ວຍງານອະທິບາຍ). ເຫຼົ່ານັ້ນ. ໃນຄວາມເປັນຈິງ, ຕູ້ຄອນເທນເນີຈະຖືກຈໍາກັດໃນປະລິມານດຽວກັນຂອງຊັບພະຍາກອນທີ່ມັນຕ້ອງການເພື່ອດໍາເນີນການ.
ຖ້າພຽງແຕ່ຄໍາຮ້ອງຂໍຖືກລະບຸຢ່າງຊັດເຈນສໍາລັບຊັບພະຍາກອນ, ຫຼັງຈາກນັ້ນບໍ່ມີຂໍ້ຈໍາກັດດ້ານເທິງຖືກກໍານົດໄວ້ໃນຊັບພະຍາກອນນີ້ - i.e. container ໄດ້ຖືກຈໍາກັດພຽງແຕ່ໂດຍຊັບພະຍາກອນຂອງ node ຕົວຂອງມັນເອງ.

ມັນຍັງເປັນໄປໄດ້ທີ່ຈະກໍາຫນົດຄ່າການຄຸ້ມຄອງຊັບພະຍາກອນບໍ່ພຽງແຕ່ຢູ່ໃນລະດັບຂອງຖັງສະເພາະ, ແຕ່ຍັງຢູ່ໃນລະດັບ namespace ໂດຍໃຊ້ຫນ່ວຍງານດັ່ງຕໍ່ໄປນີ້:

ຂອບເຂດຈໍາກັດ — ອະທິບາຍນະໂຍບາຍການຈໍາກັດໃນລະດັບບັນຈຸ / ຝັກໃນ ns ແລະມີຄວາມຈໍາເປັນເພື່ອອະທິບາຍຂອບເຂດຈໍາກັດໃນຕອນຕົ້ນຂອງຕູ້ຄອນເທນເນີ / ຝັກ, ເຊັ່ນດຽວກັນກັບການປ້ອງກັນການສ້າງຖັງໄຂມັນທີ່ຊັດເຈນ / ຝັກ (ຫຼືໃນທາງກັບກັນ), ຈໍາກັດຈໍານວນຂອງພວກເຂົາ. ແລະກໍານົດຄວາມແຕກຕ່າງທີ່ເປັນໄປໄດ້ໃນມູນຄ່າໃນຂອບເຂດຈໍາກັດແລະການຮ້ອງຂໍ
ໂຄຕ້າຊັບພະຍາກອນ — ອະທິບາຍນະໂຍບາຍການຈໍາກັດໂດຍທົ່ວໄປສໍາລັບການບັນຈຸທັງຫມົດໃນ ns ແລະໄດ້ຖືກນໍາໃຊ້, ເປັນລະບຽບການ, ເພື່ອຈໍາກັດຊັບພະຍາກອນໃນບັນດາສະພາບແວດລ້ອມ (ທີ່ເປັນປະໂຫຍດໃນເວລາທີ່ສະພາບແວດລ້ອມບໍ່ໄດ້ຖືກກໍານົດຢ່າງເຂັ້ມງວດໃນລະດັບ node)

ຕໍ່ໄປນີ້ແມ່ນຕົວຢ່າງຂອງ manifests ທີ່ກໍານົດຂອບເຂດຈໍາກັດຊັບພະຍາກອນ:

ໃນລະດັບບັນຈຸສະເພາະ:
```
containers:
- name: app-nginx
  image: nginx
  resources:
    requests:
      memory: 1Gi
    limits:
      cpu: 200m
```
ເຫຼົ່ານັ້ນ. ໃນກໍລະນີນີ້, ເພື່ອດໍາເນີນການ container ທີ່ມີ nginx, ທ່ານຈະຕ້ອງມີຢ່າງຫນ້ອຍ 1G ຂອງ RAM ຟຣີແລະ 0.2 CPU ໃນ node, ໃນຂະນະທີ່ຫຼາຍທີ່ສຸດ container ສາມາດບໍລິໂພກ 0.2 CPU ແລະ RAM ທັງຫມົດທີ່ມີຢູ່ໃນ node.
ໃນລະດັບຈໍານວນເຕັມ 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 ສໍາລັບ CPU ແລະ 1G ສໍາລັບ OP, ແລະຜົນລວມຂອງຂອບເຂດຈໍາກັດທັງຫມົດແມ່ນ 700m ສໍາລັບ CPU ແລະ 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
```
ເຫຼົ່ານັ້ນ. ໃນ namespace ເລີ່ມຕົ້ນສໍາລັບບັນຈຸທັງຫມົດ, ການຮ້ອງຂໍຈະຖືກກໍານົດເປັນ 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.

ຕອນນີ້ຂ້ອຍຢາກບອກເຈົ້າວ່າຂໍ້ໄດ້ປຽບທີ່ກໍານົດຂໍ້ຈໍາກັດເຫຼົ່ານີ້ສາມາດໃຫ້ພວກເຮົາ.

ກົນໄກການດຸ່ນດ່ຽງການໂຫຼດລະຫວ່າງ nodes

ຕາມທີ່ທ່ານຮູ້, ອົງປະກອບ k8s ແມ່ນຮັບຜິດຊອບສໍາລັບການແຈກຢາຍ pods ໃນບັນດາ nodes, ເຊັ່ນ: ຜູ້ ກຳ ນົດເວລາ, ເຊິ່ງເຮັດວຽກຕາມສູດການຄິດໄລ່ສະເພາະ. ສູດການຄິດໄລ່ນີ້ຜ່ານສອງຂັ້ນຕອນເມື່ອເລືອກ node ທີ່ດີທີ່ສຸດເພື່ອເປີດຕົວ:

ການກັ່ນຕອງ
ລະດັບ

ເຫຼົ່ານັ້ນ. ອີງຕາມນະໂຍບາຍທີ່ອະທິບາຍໄວ້, ໃນເບື້ອງຕົ້ນແມ່ນເລືອກ nodes ທີ່ເປັນໄປໄດ້ທີ່ຈະເປີດຕົວ pod ໂດຍອີງໃສ່ຊຸດ ຄາດ (ລວມທັງການກວດສອບວ່າ node ມີຊັບພະຍາກອນພຽງພໍເພື່ອດໍາເນີນການ pod - PodFitsResources), ແລະຫຼັງຈາກນັ້ນສໍາລັບແຕ່ລະ nodes, ອີງຕາມການ ບູລິມະສິດ ຄະແນນແມ່ນໄດ້ຮັບຮາງວັນ (ລວມທັງ, ຊັບພະຍາກອນທີ່ບໍ່ເສຍຄ່າຫຼາຍທີ່ node ມີ, ມັນໄດ້ຖືກມອບຫມາຍຫຼາຍຈຸດ - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) ແລະ pod ໄດ້ຖືກເປີດຕົວໃນ node ທີ່ມີຈຸດຫຼາຍທີ່ສຸດ (ຖ້າຫຼາຍ nodes ຕອບສະຫນອງເງື່ອນໄຂນີ້ໃນເວລາດຽວກັນ, ຫຼັງຈາກນັ້ນ. ການຄັດເລືອກແບບສຸ່ມ).

ໃນເວລາດຽວກັນ, ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈວ່າຕົວກໍານົດເວລາ, ເມື່ອປະເມີນຊັບພະຍາກອນທີ່ມີຢູ່ຂອງ node, ຖືກນໍາພາໂດຍຂໍ້ມູນທີ່ເກັບໄວ້ໃນ etcd - i.e. ສໍາລັບຈໍານວນຊັບພະຍາກອນທີ່ຮ້ອງຂໍ / ຈໍາກັດຂອງແຕ່ລະ pod ແລ່ນຢູ່ໃນ node ນີ້, ແຕ່ບໍ່ແມ່ນສໍາລັບການບໍລິໂພກຊັບພະຍາກອນຕົວຈິງ. ຂໍ້ມູນນີ້ສາມາດໄດ້ຮັບຈາກຜົນຜະລິດຄໍາສັ່ງ 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%)

ໃນທີ່ນີ້ພວກເຮົາເຫັນຝັກທັງຫມົດແລ່ນຢູ່ໃນ node ສະເພາະ, ເຊັ່ນດຽວກັນກັບຊັບພະຍາກອນທີ່ແຕ່ລະຝັກຮ້ອງຂໍ. ແລະນີ້ແມ່ນສິ່ງທີ່ບັນທຶກການກໍານົດເວລາເບິ່ງຄືເມື່ອ 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 nodes ທີ່ມັນສາມາດຖືກເປີດຕົວ (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). ຫຼັງຈາກນັ້ນ, ມັນຄິດໄລ່ຄະແນນໂດຍອີງໃສ່ຕົວກໍານົດການຈໍານວນຫນຶ່ງ (ລວມທັງ BalancedResourceAllocation, LeastResourceAllocation) ສໍາລັບແຕ່ລະ node ເຫຼົ່ານີ້ເພື່ອກໍານົດ node ທີ່ເຫມາະສົມທີ່ສຸດ. ໃນທີ່ສຸດ, ຝັກແມ່ນຖືກກໍານົດໄວ້ໃນ node ທີ່ມີຈໍານວນຈຸດສູງສຸດ (ໃນທີ່ນີ້ສອງ nodes ໃນເວລາດຽວກັນມີຈໍານວນຈຸດດຽວກັນ 100037, ດັ່ງນັ້ນຫນຶ່ງແບບສຸ່ມຖືກເລືອກ - nxs-k8s-s10).

ສະຫລຸບ: ຖ້າ node ແລ່ນ pods ທີ່ບໍ່ໄດ້ກໍານົດຂໍ້ຈໍາກັດ, ຫຼັງຈາກນັ້ນສໍາລັບ k8s (ຈາກທັດສະນະຂອງການບໍລິໂພກຊັບພະຍາກອນ) ນີ້ຈະເທົ່າກັບວ່າບໍ່ມີ pods ດັ່ງກ່າວຢູ່ໃນ node ທັງຫມົດ. ດັ່ງນັ້ນ, ຖ້າທ່ານ, ຕາມເງື່ອນໄຂ, ມີຝັກທີ່ມີຂະບວນການ gluttonous (ຕົວຢ່າງ, wowza) ແລະບໍ່ມີຂໍ້ຈໍາກັດທີ່ຖືກກໍານົດໄວ້ສໍາລັບມັນ, ຫຼັງຈາກນັ້ນສະຖານະການອາດຈະເກີດຂື້ນເມື່ອຝັກນີ້ກິນຊັບພະຍາກອນທັງຫມົດຂອງ node, ແຕ່ສໍາລັບ k8s node. ໄດ້ຖືກພິຈາລະນາ unloaded ແລະມັນຈະໄດ້ຮັບຮາງວັນຈໍານວນຈຸດດຽວກັນໃນເວລາທີ່ການຈັດອັນດັບ (ທີ່ຊັດເຈນໃນຈຸດປະເມີນຊັບພະຍາກອນທີ່ມີຢູ່) ເປັນ node ທີ່ບໍ່ມີ pods ເຮັດວຽກ, ເຊິ່ງໃນທີ່ສຸດສາມາດນໍາໄປສູ່ການແຈກຢາຍການໂຫຼດລະຫວ່າງ nodes ບໍ່ສະເຫມີກັນ.

ການຂັບໄລ່ Pod

ດັ່ງທີ່ເຈົ້າຮູ້, ແຕ່ລະຝັກແມ່ນມອບໝາຍໜຶ່ງໃນ 3 ຊັ້ນຮຽນ QoS:

ຮັບປະກັນ — ຖືກມອບໝາຍເມື່ອສຳລັບແຕ່ລະພາຊະນະໃນຝັກ ການຮ້ອງຂໍ ແລະຂໍ້ຈຳກັດຖືກລະບຸໄວ້ສຳລັບໜ່ວຍຄວາມຈຳ ແລະ CPU, ແລະ ຄ່າເຫຼົ່ານີ້ຕ້ອງກົງກັນ.
ລະເບີດໄດ້ — ຢ່າງຫນ້ອຍຫນຶ່ງຖັງໃນຝັກມີຄໍາຮ້ອງສະຫມັກແລະຈໍາກັດ, ມີຄໍາຮ້ອງສະຫມັກ < limit
ພະຍາຍາມທີ່ດີທີ່ສຸດ — ໃນເວລາທີ່ບໍ່ມີຖັງດຽວໃນຝັກແມ່ນຈໍາກັດຊັບພະຍາກອນ

ໃນເວລາດຽວກັນ, ເມື່ອ node ປະສົບກັບການຂາດແຄນຊັບພະຍາກອນ (ແຜ່ນ, ຫນ່ວຍຄວາມຈໍາ), kubelet ເລີ່ມຈັດລໍາດັບແລະຂັບໄລ່ pods ຕາມສູດການຄິດໄລ່ສະເພາະທີ່ຄໍານຶງເຖິງບູລິມະສິດຂອງ pod ແລະຊັ້ນ QoS ຂອງມັນ. ຕົວຢ່າງ, ຖ້າພວກເຮົາເວົ້າກ່ຽວກັບ RAM, ຫຼັງຈາກນັ້ນໂດຍອີງໃສ່ຊັ້ນ QoS, ຈຸດແມ່ນໄດ້ຮັບລາງວັນຕາມຫຼັກການຕໍ່ໄປນີ້:

ຮັບປະກັນ: -998
ຄວາມພະຍາຍາມທີ່ດີທີ່ສຸດ: 1000
ລະເບີດໄດ້: min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

ເຫຼົ່ານັ້ນ. ດ້ວຍບູລິມະສິດດຽວກັນ, kubelet ທໍາອິດຈະຂັບໄລ່ຝັກດ້ວຍຄວາມພະຍາຍາມທີ່ດີທີ່ສຸດ QoS class ຈາກ node.

ສະຫລຸບ: ຖ້າທ່ານຕ້ອງການຫຼຸດຜ່ອນຄວາມເປັນໄປໄດ້ຂອງຝັກທີ່ຕ້ອງການຖືກຂັບໄລ່ອອກຈາກ node ໃນກໍລະນີທີ່ຂາດຊັບພະຍາກອນໃນມັນ, ຫຼັງຈາກນັ້ນ, ພ້ອມກັບບູລິມະສິດ, ທ່ານກໍ່ຕ້ອງເບິ່ງແຍງການກໍານົດຄໍາຮ້ອງຂໍ / ຂອບເຂດຈໍາກັດສໍາລັບມັນ.

ກົນໄກສໍາລັບການປັບຕາມລວງນອນອັດຕະໂນມັດຂອງພອດຄໍາຮ້ອງສະຫມັກ (HPA)

ໃນເວລາທີ່ວຽກງານແມ່ນເພື່ອເພີ່ມທະວີການອັດຕະໂນມັດແລະຫຼຸດລົງຈໍານວນຂອງ pods ຂຶ້ນກັບການນໍາໃຊ້ຊັບພະຍາກອນ (ລະບົບ - CPU / RAM ຫຼືຜູ້ໃຊ້ - rps), ເຊັ່ນ k8s entity ເປັນ. HPA (Horizontal Pod Autoscaler). ສູດການຄິດໄລ່ຂອງມັນແມ່ນດັ່ງຕໍ່ໄປນີ້:

ການອ່ານປະຈຸບັນຂອງຊັບພະຍາກອນທີ່ສັງເກດເຫັນແມ່ນຖືກກໍານົດ (CurrentMetricValue)
ຄ່າທີ່ຕ້ອງການສໍາລັບຊັບພະຍາກອນແມ່ນຖືກກໍານົດ (desiredMetricValue), ເຊິ່ງສໍາລັບຊັບພະຍາກອນຂອງລະບົບແມ່ນຖືກກໍານົດໂດຍໃຊ້ຄໍາຮ້ອງຂໍ.
ຈໍານວນຂອງ replicas ປະຈຸບັນແມ່ນກໍານົດ (currentReplicas)
ສູດຕໍ່ໄປນີ້ຄິດໄລ່ຕົວເລກທີ່ຕ້ອງການຂອງ replicas (desiredReplicas)
desiredReplicas = [ currentReplicas * ( currentMetricValue / desiredMetricValue )]

ໃນກໍລະນີນີ້, scaling ຈະບໍ່ເກີດຂຶ້ນໃນເວລາທີ່ coefficient (currentMetricValue / desiredMetricValue) ໃກ້ກັບ 1 (ໃນກໍລະນີນີ້, ພວກເຮົາສາມາດກໍານົດຄວາມຜິດພາດທີ່ອະນຸຍາດໄດ້ຕົວເອງ; ໂດຍຄ່າເລີ່ມຕົ້ນມັນແມ່ນ 0.1).

ຂໍໃຫ້ເບິ່ງວິທີການເຮັດວຽກຂອງ hpa ໂດຍໃຊ້ຕົວຢ່າງຂອງຄໍາຮ້ອງສະຫມັກ app-test (ອະທິບາຍເປັນ Deployment), ບ່ອນທີ່ມັນຈໍາເປັນຕ້ອງມີການປ່ຽນແປງຈໍານວນຂອງ replicas ຂຶ້ນກັບການບໍລິໂພກ CPU:

ຄໍາຮ້ອງສະຫມັກ manifest

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 ທີ່ມັນຮ້ອງຂໍ), ມີຈໍານວນຂອງ replicas ໄດ້. ໃນລະຫວ່າງ 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) - ສໍາລັບການຄິດໄລ່, controller-manager ຄິດໄລ່ມູນຄ່າສະເລ່ຍຂອງການບໍລິໂພກຊັບພະຍາກອນໃນ %, i.e. ຕາມເງື່ອນໄຂເຮັດດັ່ງຕໍ່ໄປນີ້:
1. ໄດ້ຮັບຄ່າຢ່າງແທ້ຈິງຂອງ pod metrics ຈາກເຄື່ອງແມ່ຂ່າຍ metric, i.e. 101m ແລະ 4m
2. ຄິດໄລ່ຄ່າຢ່າງແທ້ຈິງສະເລ່ຍ, i.e. (101m + 4m) / 2 = 53m
3. ໄດ້ຮັບມູນຄ່າຢ່າງແທ້ຈິງສໍາລັບການບໍລິໂພກຊັບພະຍາກອນທີ່ຕ້ອງການ (ສໍາລັບການນີ້, ການຮ້ອງຂໍຂອງບັນຈຸທັງຫມົດແມ່ນສະຫຼຸບໄດ້) 60m + 30m = 90m
4. ຄິດໄລ່ອັດຕາສ່ວນສະເລ່ຍຂອງການບໍລິໂພກ CPU ທຽບກັບ pod ການຮ້ອງຂໍ, i.e. 53m / 90m * 100% = 59%

ໃນປັດຈຸບັນພວກເຮົາມີທຸກສິ່ງທຸກຢ່າງທີ່ພວກເຮົາຕ້ອງການເພື່ອກໍານົດວ່າພວກເຮົາຈໍາເປັນຕ້ອງມີການປ່ຽນແປງຈໍານວນ replicas ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຄິດໄລ່ຄ່າສໍາປະສິດ:

ratio = 59% / 30% = 1.96

ເຫຼົ່ານັ້ນ. ຈໍານວນຂອງ replicas ຄວນຈະໄດ້ຮັບການເພີ່ມຂຶ້ນໂດຍ ~2 ເທົ່າແລະຈໍານວນເປັນ [2 * 1.96] = 4.

ສະຫຼຸບ: ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ເພື່ອໃຫ້ກົນໄກນີ້ເຮັດວຽກ, ເງື່ອນໄຂທີ່ຈໍາເປັນແມ່ນການມີຄໍາຮ້ອງຂໍສໍາລັບພາຊະນະທັງຫມົດໃນຝັກທີ່ສັງເກດເຫັນ.

ກົນໄກການປັບຂະໜາດອັດຕະໂນມັດຕາມແນວນອນຂອງໂນດ (Cluster Autoscaler)

ເພື່ອເຮັດໃຫ້ຜົນກະທົບທາງລົບຕໍ່ລະບົບເປັນກາງໃນລະຫວ່າງການໂຫຼດ, ການມີ hpa ທີ່ຖືກຕັ້ງຄ່າແມ່ນບໍ່ພຽງພໍ. ຕົວຢ່າງ, ອີງຕາມການຕັ້ງຄ່າໃນຕົວຈັດການ hpa, ມັນຕັດສິນໃຈວ່າຈໍານວນ replicas ຕ້ອງໄດ້ຮັບການເພີ່ມຂຶ້ນ 2 ເທົ່າ, ແຕ່ nodes ບໍ່ມີຊັບພະຍາກອນທີ່ບໍ່ເສຍຄ່າເພື່ອດໍາເນີນການຈໍານວນຂອງ pods ດັ່ງກ່າວ (i.e. node ບໍ່ສາມາດສະຫນອງການ. ຊັບພະຍາກອນທີ່ຮ້ອງຂໍໃຫ້ກັບ pods ການຮ້ອງຂໍ) ແລະ pods ເຫຼົ່ານີ້ສະຫຼັບກັບສະຖານະທີ່ຍັງຄ້າງ.

ໃນກໍລະນີນີ້, ຖ້າຜູ້ໃຫ້ບໍລິການມີ IaaS/PaaS ທີ່ສອດຄ້ອງກັນ (ຕົວຢ່າງ, GKE/GCE, AKS, EKS, ແລະອື່ນໆ), ເຄື່ອງມືເຊັ່ນ: Node Autoscaler. ມັນຊ່ວຍໃຫ້ທ່ານສາມາດກໍານົດຈໍານວນສູງສຸດແລະຕໍາ່ສຸດຂອງ nodes ໃນ cluster ແລະປັບອັດຕະໂນມັດຈໍານວນຂອງ nodes ໃນປັດຈຸບັນ (ໂດຍການໂທຫາ API ຜູ້ໃຫ້ບໍລິການຟັງເພື່ອສັ່ງ / ຖອນ node) ເມື່ອຂາດຊັບພະຍາກອນໃນ cluster ແລະ pods. ບໍ່ສາມາດກຳນົດເວລາໄດ້ (ຢູ່ໃນສະຖານະທີ່ຍັງຄ້າງຢູ່).

ສະຫຼຸບ: ເພື່ອໃຫ້ສາມາດປັບຂະ ໜາດ ອັດຕະໂນມັດໄດ້, ມັນ ຈຳ ເປັນຕ້ອງ ກຳ ນົດ ຄຳ ຮ້ອງຂໍໃນຖັງ pods ເພື່ອໃຫ້ k8s ສາມາດປະເມີນການໂຫຼດໄດ້ຢ່າງຖືກຕ້ອງແລະລາຍງານຕາມຄວາມ ເໝາະ ສົມວ່າບໍ່ມີຊັບພະຍາກອນໃນກຸ່ມເພື່ອເປີດຕົວ pod ຕໍ່ໄປ.

ສະຫລຸບ

ມັນຄວນຈະສັງເກດວ່າການກໍານົດຂອບເຂດຈໍາກັດຊັບພະຍາກອນຂອງບັນຈຸບໍ່ແມ່ນຄວາມຕ້ອງການສໍາລັບຄໍາຮ້ອງສະຫມັກທີ່ຈະດໍາເນີນການຢ່າງສໍາເລັດຜົນ, ແຕ່ມັນຍັງດີກວ່າທີ່ຈະເຮັດແນວນັ້ນສໍາລັບເຫດຜົນດັ່ງຕໍ່ໄປນີ້:

ສໍາລັບການປະຕິບັດງານທີ່ຖືກຕ້ອງຫຼາຍຂຶ້ນຂອງຕົວກໍານົດເວລາໃນເງື່ອນໄຂຂອງການດຸ່ນດ່ຽງການໂຫຼດລະຫວ່າງ k8s nodes
ເພື່ອຫຼຸດຜ່ອນຄວາມເປັນໄປໄດ້ຂອງເຫດການ "ຂັບໄລ່ຝັກ" ທີ່ເກີດຂື້ນ
ສຳລັບການປັບຂະໜາດອັດຕະໂນມັດຕາມແນວນອນຂອງພອດແອັບພລິເຄຊັນ (HPA) ເຮັດວຽກ
ສຳລັບການປັບຂະໜາດອັດຕະໂນມັດຕາມແນວນອນຂອງໂນດ (Cluster Autoscaling) ສຳລັບຜູ້ໃຫ້ບໍລິການຄລາວ

ອ່ານບົດຄວາມອື່ນໆໃນ blog ຂອງພວກເຮົາ:

ແຫຼ່ງຂໍ້ມູນ: www.habr.com

Kubernetes: ເປັນຫຍັງມັນຈຶ່ງສຳຄັນຫຼາຍໃນການຕັ້ງຄ່າການຈັດການຊັບພະຍາກອນຂອງລະບົບ?