ວິທີການເຂົ້າເຖິງຊັບພະຍາກອນ Kubernetes Pod

ລາງວັນໂດຍ Tohad

ເມື່ອເລີ່ມຕົ້ນດ້ວຍ Kubernetes, ມັນເປັນເລື່ອງປົກກະຕິທີ່ຈະລືມກ່ຽວກັບການຕັ້ງຄ່າຊັບພະຍາກອນບັນຈຸ. ໃນຈຸດນີ້, ມັນພຽງພໍທີ່ຈະຮັບປະກັນວ່າຮູບພາບ Docker ເຮັດວຽກແລະສາມາດຖືກນໍາໄປໃຊ້ກັບກຸ່ມ Kubernetes.

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

ທີມງານ Kubernetes aaS ຈາກ Mail.ru ແປບົດຄວາມກ່ຽວກັບຊັບພະຍາກອນບັນຈຸ (CPU & MEM), ການຮ້ອງຂໍ ແລະຂໍ້ຈໍາກັດຂອງຊັບພະຍາກອນ. ທ່ານຈະໄດ້ຮຽນຮູ້ຜົນປະໂຫຍດຂອງການຕັ້ງຄ່າເຫຼົ່ານີ້ ແລະຈະເກີດຫຍັງຂຶ້ນຫາກທ່ານບໍ່ຕັ້ງພວກມັນ.

ຊັບພະຍາກອນຄອມພິວເຕີ

ພວກເຮົາມີສອງປະເພດຂອງຊັບພະຍາກອນທີ່ມີຫນ່ວຍງານດັ່ງຕໍ່ໄປນີ້:

• ຫນ່ວຍປະມວນຜົນກາງ (CPU) - ແກນ;
• ຫນ່ວຍຄວາມຈໍາ (MEM) - bytes.

ຊັບພະຍາກອນແມ່ນລະບຸໄວ້ສໍາລັບແຕ່ລະຖັງ. ໃນໄຟລ໌ Pod YAML ຕໍ່ໄປນີ້, ທ່ານຈະເຫັນພາກສ່ວນຊັບພະຍາກອນທີ່ປະກອບດ້ວຍຊັບພະຍາກອນທີ່ຮ້ອງຂໍ ແລະຈໍາກັດ:

• Requested Pod Resources = sum of requested resources of all containers;
• Pod Resource Limit = ຜົນລວມຂອງຂອບເຂດຈໍາກັດຊັບພະຍາກອນ Pod ທັງໝົດ.

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

ຕົວຢ່າງຂອງຊັບພະຍາກອນທີ່ຮ້ອງຂໍແລະຈໍາກັດ

ພາກສະຫນາມ resources.requested ຈາກຂໍ້ກໍາຫນົດ Pod ແມ່ນຫນຶ່ງໃນອົງປະກອບທີ່ຖືກນໍາໃຊ້ເພື່ອຊອກຫາ node ທີ່ຕ້ອງການ. ເຈົ້າສາມາດວາງແຜນການນຳໃຊ້ Pod ສໍາລັບມັນໄດ້ແລ້ວ. ເຈົ້າຊອກຫາໂນດທີ່ເຫມາະສົມແນວໃດ?

Kubernetes ປະກອບດ້ວຍຫຼາຍອົງປະກອບ, ລວມທັງ node ຕົ້ນສະບັບຫຼື master node (Kubernetes Control Plane). ໂຫນດຕົ້ນສະບັບມີຫຼາຍຂະບວນການ: kube-apiserver, kube-controller-manager ແລະ kube-scheduler.

ຂະບວນການ kube-scheduler ແມ່ນຮັບຜິດຊອບສໍາລັບການທົບທວນຄືນ pods ທີ່ສ້າງຂຶ້ນໃຫມ່ແລະຊອກຫາ nodes ພະນັກງານທີ່ເປັນໄປໄດ້ທີ່ກົງກັບຄໍາຮ້ອງຂໍ pods ທັງຫມົດ, ລວມທັງຈໍານວນຂອງຊັບພະຍາກອນທີ່ຮ້ອງຂໍ. ບັນຊີລາຍຊື່ຂອງ nodes ທີ່ພົບເຫັນໂດຍ kube-scheduler ແມ່ນຈັດອັນດັບ. ຝັກແມ່ນກໍານົດຢູ່ໃນ node ທີ່ມີຄະແນນສູງສຸດ.

ຝັກສີມ່ວງຈະຢູ່ໃສ?

ໃນຮູບທ່ານສາມາດເຫັນໄດ້ວ່າ kube-scheduler ຄວນຈັດຕາຕະລາງ Pod ສີມ່ວງໃຫມ່. ກຸ່ມ Kubernetes ປະກອບມີສອງ nodes: A ແລະ B. ດັ່ງທີ່ເຈົ້າເຫັນ, kube-scheduler ບໍ່ສາມາດຈັດຕາຕະລາງ Pod ໃນ node A - ຊັບພະຍາກອນທີ່ມີຢູ່ (ບໍ່ໄດ້ຮ້ອງຂໍ) ບໍ່ກົງກັບຄໍາຮ້ອງຂໍຂອງ Pod ສີມ່ວງ. ດັ່ງນັ້ນ, ຫນ່ວຍຄວາມຈໍາ 1 GB ທີ່ຮ້ອງຂໍໂດຍ Pod ສີມ່ວງຈະບໍ່ເຫມາະສົມກັບ node A, ເນື່ອງຈາກວ່າຫນ່ວຍຄວາມຈໍາທີ່ມີຢູ່ແມ່ນ 0,5 GB. ແຕ່ node B ມີຊັບພະຍາກອນພຽງພໍ. ດັ່ງນັ້ນ, kube-scheduler ຕັດສິນໃຈວ່າຈຸດຫມາຍປາຍທາງຂອງ Pod ສີມ່ວງແມ່ນ node B.

ຕອນນີ້ພວກເຮົາຮູ້ວ່າຊັບພະຍາກອນທີ່ຮ້ອງຂໍມີຜົນກະທົບແນວໃດຕໍ່ທາງເລືອກຂອງ node ເພື່ອດໍາເນີນການ Pod. ແຕ່ຜົນກະທົບຂອງຊັບພະຍາກອນຂອບແມ່ນຫຍັງ?

ຂີດຈຳກັດຊັບພະຍາກອນແມ່ນຂອບເຂດທີ່ CPU/MEM ບໍ່ສາມາດຂ້າມໄດ້. ຢ່າງໃດກໍຕາມ, ຊັບພະຍາກອນ CPU ມີຄວາມຍືດຫຍຸ່ນ, ດັ່ງນັ້ນບັນຈຸທີ່ບັນລຸຂອບເຂດຈໍາກັດ CPU ຂອງເຂົາເຈົ້າຈະບໍ່ເຮັດໃຫ້ Pod ອອກໄປ. ແທນທີ່ຈະ, CPU throttling ຈະເລີ່ມຕົ້ນ. ຖ້າເຖິງຂີດຈຳກັດການນຳໃຊ້ MEM, ກ່ອງບັນຈຸຈະຖືກຢຸດເນື່ອງຈາກ OOM-Killer ແລະຣີສະຕາດຖ້າອະນຸຍາດຈາກການຕັ້ງຄ່າ RestartPolicy.

ຮ້ອງຂໍແລະຊັບພະຍາກອນສູງສຸດໃນລາຍລະອຽດ

ການສື່ສານຊັບພະຍາກອນລະຫວ່າງ Docker ແລະ Kubernetes

ວິທີທີ່ດີທີ່ສຸດທີ່ຈະອະທິບາຍວິທີການຮ້ອງຂໍຊັບພະຍາກອນແລະການຈໍາກັດຊັບພະຍາກອນເຮັດວຽກແມ່ນເພື່ອແນະນໍາຄວາມສໍາພັນລະຫວ່າງ Kubernetes ແລະ Docker. ໃນຮູບຂ້າງເທິງທ່ານສາມາດເຫັນໄດ້ວ່າຊ່ອງຂໍ້ມູນ Kubernetes ແລະທຸງເລີ່ມຕົ້ນ Docker ມີຄວາມກ່ຽວຂ້ອງກັນແນວໃດ.

ຫນ່ວຍຄວາມຈໍາ: ຄໍາຮ້ອງຂໍແລະຂໍ້ຈໍາກັດ

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

ດັ່ງທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, ຫນ່ວຍຄວາມຈໍາຖືກວັດແທກເປັນ bytes. ອີງໃສ່ ເອກະສານ Kubernetes, ພວກເຮົາສາມາດລະບຸຄວາມຊົງຈໍາເປັນຕົວເລກ. ປົກກະຕິແລ້ວມັນເປັນຈໍານວນເຕັມ, ຕົວຢ່າງ 2678 - ນັ້ນແມ່ນ, 2678 bytes. ທ່ານຍັງສາມາດໃຊ້ຄໍາຕໍ່ທ້າຍໄດ້ G и Gi, ສິ່ງທີ່ສໍາຄັນແມ່ນເພື່ອຈື່ຈໍາວ່າພວກເຂົາບໍ່ທຽບເທົ່າ. ອັນທໍາອິດແມ່ນທົດສະນິຍົມ ແລະອັນທີສອງແມ່ນເລກຖານສອງ. ເຊັ່ນດຽວກັນກັບຕົວຢ່າງທີ່ໄດ້ກ່າວມາໃນເອກະສານ k8s: 128974848, 129e6, 129M, 123Mi - ພວກເຂົາເຈົ້າແມ່ນປະຕິບັດທຽບເທົ່າ.

ທາງເລືອກ Kubernetes limits.memory ກົງກັບທຸງຊາດ --memory ຈາກ Docker. ໃນ​ກໍ​ລະ​ນີ​ຂອງ request.memory ບໍ່ມີລູກສອນສໍາລັບ Docker ເພາະວ່າ Docker ບໍ່ໄດ້ໃຊ້ຊ່ອງຂໍ້ມູນນີ້. ເຈົ້າ​ອາດ​ຈະ​ຖາມ​ວ່າ, ນີ້​ແມ່ນ​ເຖິງ​ແມ່ນ​ວ່າ​ຈໍາ​ເປັນ? ແມ່ນແລ້ວຕ້ອງການ. ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ກ່າວມາກ່ອນ, ພາກສະຫນາມແມ່ນສໍາຄັນສໍາລັບ Kubernetes. ອີງຕາມຂໍ້ມູນຈາກມັນ, kube-scheduler ຕັດສິນໃຈວ່າ node ໃດທີ່ຈະຈັດຕາຕະລາງ Pod.

ຈະເກີດຫຍັງຂຶ້ນຖ້າທ່ານຕັ້ງຫນ່ວຍຄວາມຈໍາບໍ່ພຽງພໍສໍາລັບການຮ້ອງຂໍ?

ຖ້າບັນຈຸໄດ້ເຖິງຂອບເຂດຈໍາກັດຂອງຫນ່ວຍຄວາມຈໍາທີ່ຮ້ອງຂໍ, ຫຼັງຈາກນັ້ນ Pod ຈະຖືກຈັດໃສ່ໃນກຸ່ມຂອງ Pods ທີ່ຢຸດເຊົາໃນເວລາທີ່ບໍ່ມີຫນ່ວຍຄວາມຈໍາພຽງພໍໃນ node.

ຈະເກີດຫຍັງຂຶ້ນຫາກເຈົ້າຕັ້ງຂີດຈຳກັດຄວາມຈຳຕໍ່າເກີນໄປ?

ຖ້າບັນຈຸເກີນຂີດຈຳກັດຄວາມຈຳ, ມັນຈະຖືກປິດເນື່ອງຈາກ OOM-Killed. ແລະຈະ restart ຖ້າເປັນໄປໄດ້ໂດຍອີງໃສ່ RestartPolicy ທີ່ຄ່າເລີ່ມຕົ້ນແມ່ນ Always.

ຈະເກີດຫຍັງຂຶ້ນຖ້າທ່ານບໍ່ລະບຸຄວາມຊົງຈໍາທີ່ຮ້ອງຂໍ?

Kubernetes ຈະເອົາຄ່າຈຳກັດ ແລະຕັ້ງມັນເປັນຄ່າເລີ່ມຕົ້ນ.

ຈະເກີດຫຍັງຂຶ້ນຫາກເຈົ້າບໍ່ລະບຸຂີດຈຳກັດຄວາມຈຳ?

ກ່ອງບັນຈຸບໍ່ມີຂໍ້ຈໍາກັດ; ມັນສາມາດນໍາໃຊ້ຫນ່ວຍຄວາມຈໍາໄດ້ຫຼາຍເທົ່າທີ່ມັນຕ້ອງການ. ຖ້າລາວເລີ່ມໃຊ້ຄວາມຊົງຈໍາທີ່ມີຢູ່ທັງຫມົດຂອງ node, ຫຼັງຈາກນັ້ນ OOM ຈະຂ້າລາວ. ຫຼັງຈາກນັ້ນ, ກ່ອງບັນຈຸຈະຖືກເປີດໃຫມ່ຖ້າເປັນໄປໄດ້ໂດຍອີງໃສ່ RestartPolicy.

ຈະເກີດຫຍັງຂຶ້ນຫາກທ່ານບໍ່ລະບຸຂີດຈຳກັດຄວາມຈຳ?

ນີ້ແມ່ນສະຖານະການກໍລະນີທີ່ຮ້າຍແຮງທີ່ສຸດ: ຜູ້ຈັດຕາຕະລາງບໍ່ຮູ້ວ່າມີຊັບພະຍາກອນຈໍານວນເທົ່າໃດທີ່ບັນຈຸຕ້ອງການ, ແລະນີ້ສາມາດເຮັດໃຫ້ເກີດບັນຫາຮ້າຍແຮງໃນ node. ໃນກໍລະນີນີ້, ມັນຈະດີທີ່ຈະມີຂອບເຂດຈໍາກັດໃນຕອນຕົ້ນຂອງ namespace (ກໍານົດໂດຍ LimitRange). ບໍ່ມີຂໍ້ຈໍາກັດໃນຕອນຕົ້ນ - Pod ບໍ່ມີຂອບເຂດຈໍາກັດ, ມັນສາມາດນໍາໃຊ້ຫນ່ວຍຄວາມຈໍາໄດ້ຫຼາຍເທົ່າທີ່ມັນຕ້ອງການ.

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

ມັນປົກກະຕິແລ້ວແນະນໍາໃຫ້ກໍານົດຄ່າດຽວກັນສໍາລັບ request.memory и limit.memory. ນີ້ຮັບປະກັນວ່າ Kubernetes ຈະບໍ່ຈັດຕາຕະລາງ Pod ໃນ node ທີ່ມີຫນ່ວຍຄວາມຈໍາພຽງພໍເພື່ອແລ່ນ Pod ແຕ່ບໍ່ພຽງພໍທີ່ຈະດໍາເນີນການໄດ້. ຈົ່ງຈື່ໄວ້ວ່າ: ການວາງແຜນ Kubernetes Pod ພຽງແຕ່ຄໍານຶງເຖິງ requests.memoryແລະ limits.memory ບໍ່ໄດ້ຄໍານຶງເຖິງ.

CPU: ຮ້ອງຂໍແລະຈໍາກັດ

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

ດ້ວຍ CPU ທຸກຢ່າງແມ່ນສັບສົນຫຼາຍ. ກັບຄືນໄປຫາຮູບພາບຂອງຄວາມສໍາພັນລະຫວ່າງ Kubernetes ແລະ Docker, ທ່ານສາມາດເບິ່ງວ່າ request.cpu ກົງກັບ --cpu-shares, ໃນຂະນະທີ່ limit.cpu ກົງກັບທຸງຊາດ cpus ໃນ Docker.

CPU ທີ່ Kubernetes ຮ້ອງຂໍແມ່ນຄູນດ້ວຍ 1024, ອັດຕາສ່ວນຂອງຮອບວຽນ CPU. ຖ້າທ່ານຕ້ອງການຮ້ອງຂໍ 1 ຫຼັກເຕັມ, ທ່ານຕ້ອງເພີ່ມ cpu: 1ດັ່ງທີ່ສະແດງຂ້າງເທິງ.

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

ການຮ້ອງຂໍ CPU - ລະບົບຫຼັກດຽວ

ໃຫ້ຈິນຕະນາການວ່າທ່ານມີລະບົບໂຮດຫຼັກດຽວທີ່ແລ່ນບັນຈຸບັນຈຸ. ແມ່ (Kubernetes) baked pie (CPU) ແລະຕ້ອງການແບ່ງມັນລະຫວ່າງເດັກນ້ອຍ (ບັນຈຸ). ເດັກນ້ອຍສາມຄົນຕ້ອງການ pie ທັງຫມົດ (ອັດຕາສ່ວນ = 1024), ເດັກນ້ອຍຄົນອື່ນຕ້ອງການ pie ເຄິ່ງຫນຶ່ງ (512). ບ້ານມອມຕ້ອງການຄວາມຍຸຕິທໍາແລະເຮັດໃຫ້ການຄິດໄລ່ງ່າຍດາຍ.

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

ອີງຕາມການຄິດໄລ່, ສາມເດັກຈະໄດ້ຮັບ 28% ຂອງຫຼັກ, ແລະບໍ່ແມ່ນຫຼັກທັງຫມົດ. ເດັກທີ່ສີ່ຈະໄດ້ຮັບ 14% ຂອງແກ່ນເຕັມ, ບໍ່ແມ່ນເຄິ່ງຫນຶ່ງ. ແຕ່ສິ່ງຕ່າງໆຈະແຕກຕ່າງກັນຖ້າທ່ານມີລະບົບຫຼາຍຫຼັກ.

CPU Request - Multi-Core (4) System

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

ການຄິດໄລ່ຂ້າງເທິງນີ້ແມ່ນງ່າຍດາຍເພື່ອເຂົ້າໃຈວິທີການກະຈາຍ CPU ໃນບັນດາບັນຈຸ. ແນ່ນອນ, ນອກຈາກຕົວບັນຈຸເອງ, ຍັງມີຂະບວນການອື່ນໆທີ່ຍັງໃຊ້ຊັບພະຍາກອນ CPU. ເມື່ອຂະບວນການຕ່າງໆຢູ່ໃນກ່ອງບັນຈຸໜຶ່ງບໍ່ເຮັດວຽກ, ຄົນອື່ນສາມາດໃຊ້ຊັບພະຍາກອນຂອງມັນໄດ້. CPU: "200m" ກົງກັບ CPU: 0,2, ຊຶ່ງຫມາຍຄວາມວ່າປະມານ 20% ຂອງຫນຶ່ງຫຼັກ.

ຕອນນີ້ໃຫ້ເວົ້າກ່ຽວກັບ limit.cpu. CPU ທີ່ Kubernetes ຈຳກັດແມ່ນຄູນດ້ວຍ 100. ຜົນໄດ້ຮັບແມ່ນຈຳນວນເວລາທີ່ບັນຈຸສາມາດນຳໃຊ້ທຸກໆ 100 µs (cpu-period).

limit.cpu ກົງກັບທຸງ Docker --cpus. ນີ້ແມ່ນການປະສົມປະສານໃຫມ່ຂອງເກົ່າ --cpu-period и --cpu-quota. ໂດຍການຕັ້ງຄ່າມັນ, ພວກເຮົາຊີ້ບອກຈໍານວນຊັບພະຍາກອນ CPU ທີ່ມີຢູ່ທີ່ບັນຈຸສາມາດນໍາໃຊ້ໄດ້ສູງສຸດກ່ອນທີ່ຈະເລີ່ມຕົ້ນການປິດກັ້ນ:

• CPU - ປະສົມປະສານ cpu-period и cpu-quota. cpus = 1.5 ທຽບ​ເທົ່າ​ກັບ​ການ​ຕັ້ງ​ຄ່າ​ cpu-period = 100000 и cpu-quota = 150000;
• CPU-ໄລຍະເວລາ - ໄລຍະເວລາ CPU CFS ກໍານົດເວລາ, ຄ່າເລີ່ມຕົ້ນ 100 microseconds;
• cpu-ໂຄຕ້າ - ຈໍາ​ນວນ microseconds ພາຍ​ໃນ​ cpu-period, ເຊິ່ງຖືກຜູກມັດໂດຍຕູ້ຄອນເທນເນີ.

ຈະເກີດຫຍັງຂຶ້ນຖ້າທ່ານຕິດຕັ້ງ CPU ທີ່ຮ້ອງຂໍບໍ່ພຽງພໍ?

ຖ້າບັນຈຸຕ້ອງການຫຼາຍກ່ວາທີ່ມັນໄດ້ຕິດຕັ້ງ, ມັນຈະລັກ CPU ຈາກຂະບວນການອື່ນໆ.

ຈະເກີດຫຍັງຂຶ້ນຖ້າທ່ານຕັ້ງຂີດຈໍາກັດ CPU ຕໍ່າເກີນໄປ?

ເນື່ອງຈາກຊັບພະຍາກອນ CPU ສາມາດປັບໄດ້, ການປິດກັ້ນຈະເປີດຂຶ້ນ.

ຈະເກີດຫຍັງຂຶ້ນຖ້າທ່ານບໍ່ລະບຸຄໍາຮ້ອງຂໍ CPU?

ເຊັ່ນດຽວກັນກັບຫນ່ວຍຄວາມຈໍາ, ມູນຄ່າການຮ້ອງຂໍແມ່ນເທົ່າກັບຂອບເຂດຈໍາກັດ.

ຈະເກີດຫຍັງຂຶ້ນຫາກທ່ານບໍ່ລະບຸຂີດຈຳກັດ CPU?

ຕູ້ຄອນເທນເນີຈະໃຊ້ CPU ຫຼາຍເທົ່າທີ່ມັນຕ້ອງການ. ຖ້ານະໂຍບາຍ CPU ເລີ່ມຕົ້ນ (LimitRange) ຖືກກໍານົດໄວ້ໃນ namespace, ຫຼັງຈາກນັ້ນ, ຂອບເຂດຈໍາກັດນີ້ຍັງຖືກນໍາໃຊ້ສໍາລັບ container ໄດ້.

ຈະເກີດຫຍັງຂຶ້ນຖ້າທ່ານບໍ່ລະບຸການຮ້ອງຂໍຫຼືຂອບເຂດຈໍາກັດ CPU?

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

ຈືຂໍ້ມູນການ: ຖ້າທ່ານຮ້ອງຂໍ CPU ຫຼາຍກວ່າທີ່ nodes ສາມາດສະຫນອງໄດ້, Pod ຈະບໍ່ຖືກກໍານົດ. Requests.cpu - ບໍ່​ແມ່ນ​ຄ່າ​ຕໍາ​່​ສຸດ​ທີ່​, ແຕ່​ເປັນ​ມູນ​ຄ່າ​ພຽງ​ພໍ​ທີ່​ຈະ​ເລີ່ມ​ຕົ້ນ Pod ແລະ​ເຮັດ​ວຽກ​ໂດຍ​ບໍ່​ມີ​ການ​ລົ້ມ​ເຫຼວ​. ຖ້າແອັບພລິເຄຊັນບໍ່ປະຕິບັດການຄິດໄລ່ທີ່ສັບສົນ, ທາງເລືອກທີ່ດີທີ່ສຸດແມ່ນການຕິດຕັ້ງ request.cpu <= 1 ແລະເປີດຕົວແບບຈໍາລອງຫຼາຍເທົ່າທີ່ຕ້ອງການ.

ຈໍານວນທີ່ເຫມາະສົມຂອງຊັບພະຍາກອນທີ່ຮ້ອງຂໍຫຼືຈໍາກັດຊັບພະຍາກອນ

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

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

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

ເປັນຕົວຢ່າງເບິ່ງນີ້ ແຜງໜ້າປັດ Grafana. ມັນສະແດງຄວາມແຕກຕ່າງລະຫວ່າງຊັບພະຍາກອນທີ່ຮ້ອງຂໍຫຼືຂອບເຂດຈໍາກັດຂອງຊັບພະຍາກອນແລະການນໍາໃຊ້ຊັບພະຍາກອນໃນປະຈຸບັນ.

ສະຫລຸບ

ການຮ້ອງຂໍແລະການຈໍາກັດຊັບພະຍາກອນຊ່ວຍໃຫ້ກຸ່ມ Kubernetes ຂອງທ່ານມີສຸຂະພາບດີ. ການກໍານົດຂອບເຂດຈໍາກັດທີ່ເຫມາະສົມເຮັດໃຫ້ຄ່າໃຊ້ຈ່າຍຫນ້ອຍລົງແລະເຮັດໃຫ້ແອັບພລິເຄຊັນເຮັດວຽກຢູ່ຕະຫຼອດເວລາ.

ໃນສັ້ນ, ມີບາງສິ່ງທີ່ຄວນຈື່:

1. ຊັບພະຍາກອນທີ່ຮ້ອງຂໍແມ່ນການຕັ້ງຄ່າທີ່ຖືກພິຈາລະນາໃນເວລາເລີ່ມຕົ້ນ (ເມື່ອ Kubernetes ວາງແຜນທີ່ຈະເປັນເຈົ້າພາບແອັບພລິເຄຊັນ). ໃນທາງກົງກັນຂ້າມ, ການຈໍາກັດຊັບພະຍາກອນແມ່ນມີຄວາມສໍາຄັນໃນເວລາແລ່ນ - ເມື່ອແອັບພລິເຄຊັນກໍາລັງແລ່ນຢູ່ໃນ node.
2. ເມື່ອປຽບທຽບກັບຫນ່ວຍຄວາມຈໍາ, CPU ເປັນຊັບພະຍາກອນທີ່ມີການຄວບຄຸມ. ຖ້າມີ CPU ບໍ່ພຽງພໍ, Pod ຂອງເຈົ້າຈະບໍ່ປິດແລະກົນໄກການປິດບັງຈະເປີດ.
3. ຊັບພະຍາກອນທີ່ຮ້ອງຂໍແລະຂອບເຂດຈໍາກັດຂອງຊັບພະຍາກອນບໍ່ແມ່ນຄ່າຕໍ່າສຸດແລະສູງສຸດ! ໂດຍການກໍານົດຊັບພະຍາກອນທີ່ຮ້ອງຂໍ, ທ່ານຮັບປະກັນວ່າແອັບພລິເຄຊັນຈະເຮັດວຽກໂດຍບໍ່ມີບັນຫາ.
4. ການປະຕິບັດທີ່ດີແມ່ນກໍານົດການຮ້ອງຂໍຫນ່ວຍຄວາມຈໍາເທົ່າກັບຈໍາກັດຄວາມຈໍາ.
5. Ok ຂໍຕິດຕັ້ງແລ້ວ CPU <=1, ຖ້າແອັບພລິເຄຊັນບໍ່ປະຕິບັດການຄິດໄລ່ທີ່ສັບສົນ.
6. ຖ້າທ່ານຮ້ອງຂໍຊັບພະຍາກອນຫຼາຍກວ່າທີ່ມີຢູ່ໃນ node, Pod ຈະບໍ່ຖືກກໍານົດໃຫ້ node.
7. ເພື່ອກໍານົດຈໍານວນທີ່ຖືກຕ້ອງຂອງຊັບພະຍາກອນທີ່ຮ້ອງຂໍ / ຂອບເຂດຈໍາກັດ, ໃຊ້ການທົດສອບການໂຫຼດແລະການຕິດຕາມ.

ຂ້າພະເຈົ້າຫວັງວ່າບົດຄວາມນີ້ຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈແນວຄວາມຄິດພື້ນຖານຂອງການຈໍາກັດຊັບພະຍາກອນ. ແລະເຈົ້າຈະສາມາດໃຊ້ຄວາມຮູ້ນີ້ເຂົ້າໃນວຽກງານຂອງເຈົ້າ.

ໂຊກດີ!

ມີຫຍັງອີກແດ່ທີ່ຈະອ່ານ:

1. SRE Observability: Namespaces ແລະໂຄງສ້າງ Metric.
2. 90+ ເຄື່ອງມືທີ່ເປັນປະໂຫຍດສໍາລັບ Kubernetes: ການນຳໃຊ້, ການຈັດການ, ການຕິດຕາມ, ຄວາມປອດໄພ ແລະອື່ນໆອີກ.
3. ຊ່ອງຂອງພວກເຮົາປະມານ Kubernetes ໃນ Telegram.

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