ຂີດຈຳກັດ CPU ແລະການຂັດຂວາງທີ່ຮຸກຮານໃນ Kubernetes

ຫມາຍ​ເຫດ​. ແປ.: ປະຫວັດການເປີດຕາອັນນີ້ຂອງ Omio—ຜູ້ລວມການເດີນທາງຂອງເອີຣົບ—ເອົາຜູ້ອ່ານຈາກທິດສະດີພື້ນຖານໄປສູ່ຄວາມຊັບຊ້ອນພາກປະຕິບັດທີ່ໜ້າສົນໃຈຂອງການຕັ້ງຄ່າ Kubernetes. ຄວາມຄຸ້ນເຄີຍກັບກໍລະນີດັ່ງກ່າວຊ່ວຍບໍ່ພຽງແຕ່ຂະຫຍາຍຂອບເຂດຂອງທ່ານ, ແຕ່ຍັງປ້ອງກັນບັນຫາທີ່ບໍ່ແມ່ນເລື່ອງເລັກນ້ອຍ.

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

TL; DR:
ພວກເຮົາຂໍແນະນໍາໃຫ້ປິດການຈໍາກັດ CPU ໃນ Kubernetes (ຫຼືປິດໂຄຕ້າ CFS ໃນ Kubelet) ຖ້າທ່ານກໍາລັງໃຊ້ Linux kernel ທີ່ມີໂຄຕ້າ CFS. ໃນຫຼັກ ແມ່ນມີຢູ່ ຮ້າຍແຮງ ແລະ ເປັນທີ່ຮູ້ຈັກດີ bug ທີ່ນໍາໄປສູ່ການ throttling ຫຼາຍເກີນໄປແລະການຊັກຊ້າ.

ໃນ Omio ໂຄງສ້າງພື້ນຖານທັງໝົດຖືກຄຸ້ມຄອງໂດຍ Kubernetes. ທັງໝົດຂອງວຽກທີ່ບໍ່ມີລັດ ແລະບໍ່ມີລັດຂອງພວກເຮົາແມ່ນເຮັດວຽກຢູ່ໃນ Kubernetes ສະເພາະ (ພວກເຮົາໃຊ້ Google Kubernetes Engine). ໃນຫົກເດືອນທີ່ຜ່ານມາ, ພວກເຮົາເລີ່ມສັງເກດເຫັນການຊ້າລົງແບບສຸ່ມ. ແອັບພລິເຄຊັ່ນຄ້າງ ຫຼືຢຸດການຕອບສະໜອງຕໍ່ການກວດສຸຂະພາບ, ສູນເສຍການເຊື່ອມຕໍ່ກັບເຄືອຂ່າຍ, ແລະອື່ນໆ. ພຶດຕິກໍານີ້ເຮັດໃຫ້ພວກເຮົາສັບສົນເປັນເວລາດົນນານ, ແລະສຸດທ້າຍພວກເຮົາໄດ້ຕັດສິນໃຈເອົາບັນຫາຢ່າງຈິງຈັງ.

ບົດສະຫຼຸບຂອງບົດຂຽນ:

• ສອງສາມຄໍາກ່ຽວກັບຕູ້ຄອນເທນເນີແລະ Kubernetes;
• ວິທີການຮ້ອງຂໍ CPU ແລະຂໍ້ຈໍາກັດຖືກປະຕິບັດ;
• ວິທີການຈໍາກັດ CPU ເຮັດວຽກຢູ່ໃນສະພາບແວດລ້ອມຫຼາຍແກນ;
• ວິທີການຕິດຕາມ throttling CPU;
• ການ​ແກ້​ໄຂ​ບັນ​ຫາ​ແລະ nuances​.

ສອງສາມຄໍາກ່ຽວກັບຕູ້ຄອນເທນເນີແລະ Kubernetes

Kubernetes ເປັນສິ່ງຈໍາເປັນມາດຕະຖານທີ່ທັນສະໄຫມໃນໂລກໂຄງສ້າງພື້ນຖານ. ຫນ້າທີ່ຕົ້ນຕໍຂອງຕົນແມ່ນ orchestration ຕູ້ຄອນເທນເນີ.

.онтейнеры

ໃນອະດີດ, ພວກເຮົາຕ້ອງສ້າງສິ່ງປະດິດເຊັ່ນ Java JARs/WARs, Python Eggs, ຫຼື executables ເພື່ອແລ່ນໃນເຊີບເວີ. ຢ່າງໃດກໍ່ຕາມ, ເພື່ອເຮັດໃຫ້ພວກມັນເຮັດວຽກ, ວຽກງານເພີ່ມເຕີມຕ້ອງເຮັດ: ການຕິດຕັ້ງສະພາບແວດລ້ອມ runtime (Java / Python), ການວາງໄຟລ໌ທີ່ຈໍາເປັນໃນສະຖານທີ່ທີ່ເຫມາະສົມ, ຮັບປະກັນຄວາມເຂົ້າກັນໄດ້ກັບລະບົບປະຕິບັດການສະເພາະ, ແລະອື່ນໆ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ຕ້ອງໄດ້ເອົາໃຈໃສ່ຢ່າງລະມັດລະວັງຕໍ່ການຈັດການການຕັ້ງຄ່າ (ເຊິ່ງມັກຈະເປັນແຫຼ່ງຂອງການຂັດແຍ້ງລະຫວ່າງຜູ້ພັດທະນາແລະຜູ້ເບິ່ງແຍງລະບົບ).

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

ນອກຈາກນັ້ນ, ຕູ້ຄອນເທນເນີເຮັດວຽກຢູ່ໃນສະພາບແວດລ້ອມ sandbox ຂອງຕົນເອງ. ພວກເຂົາເຈົ້າມີອະແດບເຕີເຄືອຂ່າຍ virtual ຂອງຕົນເອງ, ລະບົບໄຟລ໌ຂອງຕົນເອງທີ່ມີການເຂົ້າເຖິງຈໍາກັດ, ລໍາດັບຊັ້ນຂອງຂະບວນການຂອງຕົນເອງ, ຂໍ້ຈໍາກັດຂອງຕົນເອງກ່ຽວກັບ CPU ແລະຫນ່ວຍຄວາມຈໍາ, ແລະອື່ນໆ. ທັງຫມົດນີ້ຖືກປະຕິບັດຍ້ອນລະບົບຍ່ອຍພິເສດຂອງ Linux kernel - namespaces .

Kubernetes

ດັ່ງທີ່ໄດ້ກ່າວໄວ້ກ່ອນຫນ້ານີ້, Kubernetes ແມ່ນນັກດົນຕີບັນຈຸ. ມັນເຮັດວຽກແບບນີ້: ເຈົ້າໃຫ້ມັນກັບເຄື່ອງຈັກ, ແລະຫຼັງຈາກນັ້ນເວົ້າວ່າ: "Hey, Kubernetes, ໃຫ້ເປີດສິບຕົວຢ່າງຂອງຖັງຂອງຂ້ອຍດ້ວຍໂປເຊດເຊີ 2 ຫນ່ວຍແລະຫນ່ວຍຄວາມຈໍາ 3 GB ຂອງແຕ່ລະອັນ, ແລະເຮັດໃຫ້ພວກມັນເຮັດວຽກ!" Kubernetes ຈະດູແລສ່ວນທີ່ເຫຼືອ. ມັນ​ຈະ​ຊອກ​ຫາ​ຄວາມ​ອາດ​ສາ​ມາດ​ຟຣີ​, ເປີດ​ບັນ​ຈຸ​ແລະ restart ພວກ​ເຂົາ​ຖ້າ​ຫາກ​ວ່າ​ຈໍາ​ເປັນ​, ມ້ວນ​ອອກ​ການ​ປັບ​ປຸງ​ໃນ​ເວ​ລາ​ທີ່​ການ​ປ່ຽນ​ແປງ​ສະ​ບັບ​, ແລະ​ອື່ນໆ​. ໂດຍພື້ນຖານແລ້ວ, Kubernetes ຊ່ວຍໃຫ້ທ່ານສາມາດຖອດຖອນສ່ວນປະກອບຂອງຮາດແວອອກໄປໄດ້ ແລະ ເຮັດໃຫ້ລະບົບຫຼາກຫຼາຍຊະນິດທີ່ເໝາະສົມກັບການນຳໃຊ້ ແລະ ແລ່ນແອັບພລິເຄຊັນ.

Kubernetes ຈາກທັດສະນະຂອງ layman ໄດ້

ການຮ້ອງຂໍແລະຂໍ້ຈໍາກັດໃນ Kubernetes ແມ່ນຫຍັງ

ຕົກລົງ, ພວກເຮົາໄດ້ກວມເອົາຕູ້ຄອນເທນເນີ ແລະ Kubernetes ແລ້ວ. ພວກເຮົາຍັງຮູ້ວ່າຕູ້ຄອນເທນເນີຫຼາຍອັນສາມາດຢູ່ໃນເຄື່ອງດຽວກັນ.

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

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

ການຮ້ອງຂໍ ແລະຂໍ້ຈໍາກັດຖືກປະຕິບັດແນວໃດໃນ Kubernetes

Kubernetes ໃຊ້ກົນໄກການປິດບັງ (ຂ້າມຮອບວຽນໂມງ) ທີ່ສ້າງຂຶ້ນໃນ kernel ເພື່ອປະຕິບັດການຈໍາກັດ CPU. ຖ້າແອັບພລິເຄຊັນເກີນຂອບເຂດຈໍາກັດ, throttling ຖືກເປີດໃຊ້ (ເຊັ່ນ: ມັນໄດ້ຮັບຮອບ CPU ຫນ້ອຍລົງ). ການຮ້ອງຂໍແລະຂໍ້ຈໍາກັດສໍາລັບຫນ່ວຍຄວາມຈໍາໄດ້ຖືກຈັດລຽງແຕກຕ່າງກັນ, ດັ່ງນັ້ນພວກມັນງ່າຍຕໍ່ການກວດພົບ. ເພື່ອເຮັດສິ່ງນີ້, ພຽງແຕ່ກວດເບິ່ງສະຖານະ restart ສຸດທ້າຍຂອງຝັກ: ບໍ່ວ່າຈະເປັນ "OOMKilled". ການຂັດຂວາງ CPU ແມ່ນບໍ່ງ່າຍດາຍ, ເພາະວ່າ K8s ພຽງແຕ່ເຮັດໃຫ້ metrics ສາມາດໃຊ້ໄດ້ໂດຍການນໍາໃຊ້, ບໍ່ແມ່ນໂດຍ cgroups.

ການຮ້ອງຂໍ CPU

ວິທີການຮ້ອງຂໍ CPU ຖືກປະຕິບັດ

ເພື່ອຄວາມງ່າຍດາຍ, ໃຫ້ເບິ່ງຂະບວນການທີ່ໃຊ້ເຄື່ອງຈັກທີ່ມີ CPU 4-core ເປັນຕົວຢ່າງ.

K8s ໃຊ້ກົນໄກກຸ່ມຄວບຄຸມ (cgroups) ເພື່ອຄວບຄຸມການຈັດສັນຊັບພະຍາກອນ (ຫນ່ວຍຄວາມຈໍາແລະໂປເຊດເຊີ). ຮູບແບບລໍາດັບຊັ້ນແມ່ນມີໃຫ້ສໍາລັບມັນ: ເດັກນ້ອຍສືບທອດຂອບເຂດຈໍາກັດຂອງກຸ່ມພໍ່ແມ່. ລາຍ​ລະ​ອຽດ​ການ​ແຜ່​ກະ​ຈາຍ​ໄດ້​ຖືກ​ເກັບ​ຮັກ​ສາ​ໄວ້​ໃນ​ລະ​ບົບ​ໄຟລ​໌ virtual (/sys/fs/cgroup). ໃນກໍລະນີຂອງໂປເຊດເຊີ, ນີ້ແມ່ນ /sys/fs/cgroup/cpu,cpuacct/*.

K8s ໃຊ້ໄຟລ໌ cpu.share ເພື່ອຈັດສັນຊັບພະຍາກອນຂອງໂປເຊດເຊີ. ໃນກໍລະນີຂອງພວກເຮົາ, cgroup ຮາກໄດ້ຮັບ 4096 ຮຸ້ນຂອງຊັບພະຍາກອນ CPU - 100% ຂອງພະລັງງານຂອງໂປເຊດເຊີທີ່ມີຢູ່ (1 core = 1024; ນີ້ແມ່ນມູນຄ່າຄົງທີ່). ກຸ່ມຮາກແຈກຢາຍຊັບພະຍາກອນຕາມອັດຕາສ່ວນຂຶ້ນກັບຮຸ້ນຂອງລູກຫລານທີ່ລົງທະບຽນໃນ cpu.share, ແລະພວກເຂົາ, ໃນທາງກັບກັນ, ເຮັດເຊັ່ນດຽວກັນກັບລູກຫລານຂອງພວກເຂົາ, ແລະອື່ນໆ. ໃນ node Kubernetes ປົກກະຕິ, cgroup ຮາກມີສາມລູກ: system.slice, user.slice и kubepods. ສອງກຸ່ມຍ່ອຍທໍາອິດຖືກນໍາໃຊ້ເພື່ອແຈກຢາຍຊັບພະຍາກອນລະຫວ່າງການໂຫຼດຂອງລະບົບທີ່ສໍາຄັນແລະໂຄງການຜູ້ໃຊ້ຢູ່ນອກ K8s. ອັນ​ສຸດ​ທ້າຍ - kubepods — ສ້າງໂດຍ Kubernetes ເພື່ອແຈກຢາຍຊັບພະຍາກອນລະຫວ່າງຝັກ.

ແຜນວາດຂ້າງເທິງສະແດງໃຫ້ເຫັນວ່າກຸ່ມຍ່ອຍທໍາອິດແລະທີສອງໄດ້ຮັບແຕ່ລະຄົນ 1024 ຮຸ້ນ, ກັບກຸ່ມຍ່ອຍ kuberpod ຈັດສັນ 4096 ຮຸ້ນ ມັນເປັນໄປໄດ້ແນວໃດ: ຫຼັງຈາກທີ່ທັງຫມົດ, ກຸ່ມຮາກມີການເຂົ້າເຖິງພຽງແຕ່ 4096 ຮຸ້ນ, ແລະຜົນລວມຂອງຮຸ້ນຂອງລູກຫລານຂອງນາງເກີນຈໍານວນນີ້ຢ່າງຫຼວງຫຼາຍ (6144)? ຈຸດແມ່ນວ່າມູນຄ່າເຮັດໃຫ້ຄວາມຮູ້ສຶກຢ່າງມີເຫດຜົນ, ດັ່ງນັ້ນ Linux scheduler (CFS) ໃຊ້ມັນເພື່ອຈັດສັນຊັບພະຍາກອນ CPU ເປັນສັດສ່ວນ. ໃນກໍລະນີຂອງພວກເຮົາ, ສອງກຸ່ມທໍາອິດໄດ້ຮັບ 680 ຮຸ້ນທີ່ແທ້ຈິງ (16,6% ຂອງ 4096), ແລະ kubepod ໄດ້ຮັບສ່ວນທີ່ເຫຼືອ 2736 ຮຸ້ນ ໃນກໍລະນີຂອງການຢຸດເຊົາ, ສອງກຸ່ມທໍາອິດຈະບໍ່ນໍາໃຊ້ຊັບພະຍາກອນທີ່ຈັດສັນ.

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

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

ຈຳກັດ CPU

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

K8s ມີສ່ວນຮ່ວມ ກົນໄກໂຄຕ້າ CFS ເພື່ອປະຕິບັດຂອບເຂດຈໍາກັດ. ການຕັ້ງຄ່າຂອງພວກເຂົາຖືກລະບຸໄວ້ໃນໄຟລ໌ cfs_period_us и cfs_quota_us ໃນໄດເລກະທໍລີ cgroup (ໄຟລ໌ກໍ່ຕັ້ງຢູ່ທີ່ນັ້ນ cpu.share).

ຊຶ່ງ​ແຕກ​ຕ່າງ​ຈາກ cpu.share, ໂຄຕ້າແມ່ນອີງໃສ່ ໄລ​ຍະ​ເວ​ລາ, ແລະບໍ່ແມ່ນຢູ່ໃນພະລັງງານຂອງໂປເຊດເຊີທີ່ມີຢູ່. cfs_period_us ກໍານົດໄລຍະເວລາຂອງໄລຍະເວລາ (epoch) - ມັນແມ່ນສະເຫມີ 100000 μs (100 ms). ມີທາງເລືອກທີ່ຈະປ່ຽນຄ່ານີ້ຢູ່ໃນ K8s, ແຕ່ມັນມີພຽງແຕ່ຢູ່ໃນອັນຟາເທົ່ານັ້ນ. ຜູ້ກຳນົດເວລາໃຊ້ຊ່ວງເວລາເພື່ອເລີ່ມໂຄຕ້າທີ່ໃຊ້ແລ້ວຄືນໃໝ່. ໄຟລ໌ທີສອງ cfs_quota_us, ລະບຸເວລາທີ່ມີຢູ່ (ໂຄຕ້າ) ໃນແຕ່ລະຍຸກ. ໃຫ້ສັງເກດວ່າມັນຍັງຖືກລະບຸໄວ້ໃນ microseconds. ໂຄຕ້າອາດຈະເກີນໄລຍະເວລາ; ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ມັນອາດຈະໃຫຍ່ກວ່າ 100 ms.

ຂໍໃຫ້ເບິ່ງສອງສະຖານະການກ່ຽວກັບເຄື່ອງຈັກ 16-core (ປະເພດຄອມພິວເຕີທົ່ວໄປທີ່ສຸດທີ່ພວກເຮົາມີຢູ່ Omio):

ສະຖານະການ 1: 2 threads ແລະຂອບເຂດຈໍາກັດ 200 ms. ບໍ່ມີການຄວບຄຸມ

ສະຖານະການ 2: 10 threads ແລະຈໍາກັດ 200 ms. Throttling ເລີ່ມຕົ້ນຫຼັງຈາກ 20 ms, ການເຂົ້າເຖິງຊັບພະຍາກອນຂອງໂປເຊດເຊີແມ່ນສືບຕໍ່ຫຼັງຈາກອີກ 80 ms.

ໃຫ້ເວົ້າວ່າທ່ານກໍານົດຂອບເຂດຈໍາກັດ CPU ເປັນ 2 ແກ່ນ; Kubernetes ຈະແປຄ່ານີ້ເປັນ 200 ms. ນີ້ຫມາຍຄວາມວ່າຕູ້ຄອນເທນເນີສາມາດນໍາໃຊ້ໄດ້ສູງສຸດຂອງ 200ms ຂອງເວລາ CPU ໂດຍບໍ່ມີການ throttling.

ແລະນີ້ແມ່ນບ່ອນທີ່ຄວາມມ່ວນເລີ່ມຕົ້ນ. ດັ່ງທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, ໂຄຕ້າທີ່ມີຢູ່ແມ່ນ 200 ms. ຖ້າທ່ານກໍາລັງເຮັດວຽກຂະຫນານ ສິບ ກະທູ້ຢູ່ໃນເຄື່ອງ 12-core (ເບິ່ງຮູບປະກອບສໍາລັບສະຖານະການ 2), ໃນຂະນະທີ່ຝັກອື່ນໆທັງຫມົດແມ່ນບໍ່ເຮັດວຽກ, ໂຄຕ້າຈະຫມົດໃນພຽງແຕ່ 20 ms (ນັບຕັ້ງແຕ່ 10 * 20 ms = 200 ms), ແລະກະທູ້ທັງຫມົດຂອງຝັກນີ້ຈະຫ້ອຍ. » (ປິດ) ສໍາລັບ 80 ms ຕໍ່ໄປ. ທີ່ໄດ້ກ່າວມາແລ້ວ bug ຕາຕະລາງ, ເນື່ອງຈາກການປິດກັ້ນຫຼາຍເກີນໄປເກີດຂຶ້ນແລະບັນຈຸບໍ່ສາມາດປະຕິບັດໄດ້ເຖິງແມ່ນວ່າໂຄຕ້າທີ່ມີຢູ່ແລ້ວ.

ວິ​ທີ​ການ​ປະ​ເມີນ​ການ throttling ໃນ​ຝັກ​?

ພຽງແຕ່ເຂົ້າສູ່ລະບົບ pod ແລະປະຕິບັດ cat /sys/fs/cgroup/cpu/cpu.stat.

• nr_periods — ຈໍາ​ນວນ​ທັງ​ຫມົດ​ຂອງ​ໄລ​ຍະ​ເວ​ລາ​ກໍາ​ນົດ​ເວ​ລາ​;
• nr_throttled — ຈໍາ​ນວນ​ຂອງ​ໄລ​ຍະ throttled ໃນ​ອົງ​ປະ​ກອບ​ nr_periods;
• throttled_time — ໄລຍະເວລາການບີບອັດສະສົມເປັນ nanoseconds.

ມີຫຍັງເກີດຂຶ້ນແທ້?

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບການ throttling ສູງໃນທຸກຄໍາຮ້ອງສະຫມັກ. ບາງຄັ້ງລາວຢູ່ໃນ ເວລາຫນຶ່ງແລະເຄິ່ງຫນຶ່ງ ແຂງ​ແຮງ​ກວ່າ​ການ​ຄິດ​ໄລ່​!

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

ການຕັດສິນໃຈແລະຜົນສະທ້ອນ

ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍຢູ່ທີ່ນີ້. ພວກ​ເຮົາ​ປະ​ຖິ້ມ​ຂໍ້​ຈໍາ​ກັດ CPU ແລະ​ໄດ້​ເລີ່ມ​ຕົ້ນ​ການ​ປັບ​ປຸງ OS kernel ໃນ​ກຸ່ມ​ກັບ​ສະ​ບັບ​ຫລ້າ​ສຸດ​, ໃນ​ການ​ແກ້​ໄຂ bug ໄດ້​. ຈໍານວນຂໍ້ຜິດພາດ (HTTP 5xx) ໃນການບໍລິການຂອງພວກເຮົາຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ:

HTTP 5xx ຜິດພາດ

HTTP 5xx ຜິດພາດສໍາລັບການບໍລິການທີ່ສໍາຄັນຫນຶ່ງ

ເວລາຕອບສະຫນອງ p95

ການຕອບສະໜອງການຮ້ອງຂໍການບໍລິການທີ່ສໍາຄັນ, ເປີເຊັນທີ 95

ຄ່າໃຊ້ຈ່າຍໃນການດໍາເນີນງານ

ຈຳນວນຊົ່ວໂມງຕົວຢ່າງທີ່ໃຊ້

ການຈັບແມ່ນຫຍັງ?

ດັ່ງທີ່ໄດ້ກ່າວໃນຕອນຕົ້ນຂອງບົດຄວາມ:

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

ນີ້ແມ່ນການຈັບ. ຖັງທີ່ບໍ່ມີການດູແລອັນໜຶ່ງສາມາດກິນຊັບພະຍາກອນ CPU ທັງໝົດທີ່ມີຢູ່ໃນເຄື່ອງໄດ້. ຖ້າທ່ານມີ stack ຄໍາຮ້ອງສະຫມັກທີ່ສະຫຼາດ (ຕົວຢ່າງ, JVM, Go, Node VM ຖືກຕັ້ງຄ່າຢ່າງຖືກຕ້ອງ), ນີ້ບໍ່ແມ່ນບັນຫາ: ທ່ານສາມາດເຮັດວຽກໃນເງື່ອນໄຂດັ່ງກ່າວເປັນເວລາດົນນານ. ແຕ່​ຖ້າ​ຫາກ​ວ່າ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ບໍ່​ດີ​ທີ່​ສຸດ​ຫຼື​ບໍ່​ໄດ້​ຖືກ​ປັບ​ໃຫ້​ເຫມາະ​ທັງ​ຫມົດ (FROM java:latest), ສະຖານະການອາດຈະອອກຈາກການຄວບຄຸມ. ທີ່ Omio ພວກເຮົາມີ Dockerfiles ພື້ນຖານອັດຕະໂນມັດທີ່ມີການຕັ້ງຄ່າເລີ່ມຕົ້ນທີ່ພຽງພໍສໍາລັບ stack ພາສາທີ່ສໍາຄັນ, ດັ່ງນັ້ນບັນຫານີ້ບໍ່ມີ.

ພວກເຮົາແນະນໍາໃຫ້ຕິດຕາມ metrics ໃຊ້ (ການນໍາໃຊ້, ການອີ່ມຕົວແລະຄວາມຜິດພາດ), ຄວາມລ່າຊ້າ API ແລະອັດຕາຄວາມຜິດພາດ. ໃຫ້ແນ່ໃຈວ່າຜົນໄດ້ຮັບຕອບສະຫນອງຄວາມຄາດຫວັງ.

ເອກະສານ

ນີ້ແມ່ນເລື່ອງຂອງພວກເຮົາ. ເອກະສານຕໍ່ໄປນີ້ຊ່ວຍເຂົ້າໃຈສິ່ງທີ່ເກີດຂຶ້ນໄດ້ຫຼາຍ:

• kernel.org → CFS Scheduler;
• kernel.org → CFS Bandwidth Control;
• ເຂົ້າໃຈການຈັດຕາຕະລາງ Linux Container;
• ທຸກຢ່າງທີ່ເຈົ້າຕ້ອງຮູ້ກ່ຽວກັບ Linux Containers, ສ່ວນ I: Linux Control Groups ແລະ Process Isolation;
• Kubernetes ເລື່ອງຄວາມລົ້ມເຫລວ - ຊອກຫາ "cpu throttling".

ລາຍງານຂໍ້ຜິດພາດ Kubernetes:

• #51135: ຫຼີກເວັ້ນການກໍານົດຂອບເຂດຈໍາກັດ CPU ສໍາລັບ pods ຮັບປະກັນ;
• #67577: ໂຄຕ້າ CFS ສາມາດນໍາໄປສູ່ການປິດກັ້ນທີ່ບໍ່ຈໍາເປັນ;
• CFS ຮຸກຮານເກີນໄປ.

ທ່ານພົບບັນຫາທີ່ຄ້າຍຄືກັນໃນການປະຕິບັດຂອງທ່ານຫຼືມີປະສົບການທີ່ກ່ຽວຂ້ອງກັບການຂັດຂວາງໃນສະພາບແວດລ້ອມການຜະລິດບັນຈຸ? ແບ່ງປັນເລື່ອງຂອງທ່ານໃນຄໍາເຫັນ!

PS ຈາກນັກແປ

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ການ​ຂະ​ຫຍາຍ​ອັດ​ຕະ​ໂນ​ມັດ​ແລະ​ການ​ຄຸ້ມ​ຄອງ​ຊັບ​ພະ​ຍາ​ກອນ​ໃນ Kubernetes (ພາບ​ລວມ​ແລະ​ລາຍ​ງານ​ວິ​ດີ​ໂອ​)"
• «CPU Manager ເຮັດວຽກແນວໃດໃນ Kubernetes"
• «ຈະເກີດຫຍັງຂຶ້ນໃນ Kubernetes ເມື່ອທ່ານແລ່ນ kubectl run? ພາກທີ 2".

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