ການ​ຂະ​ຫຍາຍ​ອັດ​ຕະ​ໂນ​ມັດ​ແລະ​ການ​ຄຸ້ມ​ຄອງ​ຊັບ​ພະ​ຍາ​ກອນ​ໃນ Kubernetes (ພາບ​ລວມ​ແລະ​ລາຍ​ງານ​ວິ​ດີ​ໂອ​)

ວັນທີ 27 ເມສາ ທີ່ກອງປະຊຸມ ການປະທ້ວງ 2019, ເປັນສ່ວນຫນຶ່ງຂອງພາກ "DevOps", ບົດລາຍງານ "ການປັບຂະຫນາດອັດຕະໂນມັດແລະການຄຸ້ມຄອງຊັບພະຍາກອນໃນ Kubernetes" ໄດ້ຖືກມອບໃຫ້. ມັນເວົ້າກ່ຽວກັບວິທີທີ່ທ່ານສາມາດນໍາໃຊ້ K8s ເພື່ອຮັບປະກັນຄວາມພ້ອມຂອງຄໍາຮ້ອງສະຫມັກຂອງທ່ານແລະຮັບປະກັນການປະຕິບັດສູງສຸດ.

ຕາມປະເພນີ, ພວກເຮົາມີຄວາມຍິນດີທີ່ຈະນໍາສະເຫນີ ວິ​ດີ​ໂອ​ຂອງ​ບົດ​ລາຍ​ງານ​ (44 ນາທີ, ມີຂໍ້ມູນຫຼາຍກວ່າບົດຄວາມ) ແລະບົດສະຫຼຸບຕົ້ນຕໍໃນຮູບແບບຂໍ້ຄວາມ. ໄປ!

ຂໍໃຫ້ວິເຄາະຫົວຂໍ້ຂອງບົດລາຍງານໂດຍຄໍາສັບແລະເລີ່ມຕົ້ນຈາກທ້າຍ.

Kubernetes

ໃຫ້ເວົ້າວ່າພວກເຮົາມີ Docker containers ຢູ່ໃນໂຮດຂອງພວກເຮົາ. ເພື່ອ​ຫຍັງ? ເພື່ອຮັບປະກັນການເຮັດຊ້ຳ ແລະໂດດດ່ຽວ, ເຊິ່ງເຮັດໃຫ້ການນຳໃຊ້ງ່າຍ ແລະ ດີ, CI/CD. ພວກ​ເຮົາ​ມີ​ພາ​ຫະ​ນະ​ດັ່ງ​ກ່າວ​ຈໍາ​ນວນ​ຫຼາຍ​ທີ່​ມີ​ພາ​ຊະນະ​.

Kubernetes ໃຫ້ຫຍັງໃນກໍລະນີນີ້?

1. ພວກເຮົາຢຸດຄິດກ່ຽວກັບເຄື່ອງຈັກເຫຼົ່ານີ້ແລະເລີ່ມເຮັດວຽກກັບ "cloud" ກຸ່ມບັນຈຸ ຫຼືຝັກ (ກຸ່ມຂອງບັນຈຸ).
2. ຍິ່ງໄປກວ່ານັ້ນ, ພວກເຮົາບໍ່ຄິດກ່ຽວກັບແຕ່ລະຝັກ, ແຕ່ຈັດການເພີ່ມເຕີມоກຸ່ມໃຫຍ່. ດັ່ງກ່າວ primitives ລະດັບສູງ ອະນຸຍາດໃຫ້ພວກເຮົາເວົ້າວ່າມີແມ່ແບບສໍາລັບການເຮັດວຽກທີ່ແນ່ນອນ, ແລະນີ້ແມ່ນຈໍານວນຕົວຢ່າງທີ່ຕ້ອງການເພື່ອດໍາເນີນການມັນ. ຖ້າພວກເຮົາປ່ຽນແມ່ແບບຕໍ່ມາ, ທຸກໆຕົວຢ່າງຈະປ່ຽນແປງ.
3. ດ້ວຍຄວາມຊ່ວຍເຫຼືອຂອງ API ປະກາດ ແທນທີ່ຈະປະຕິບັດລໍາດັບຂອງຄໍາສັ່ງສະເພາະ, ພວກເຮົາອະທິບາຍ "ໂຄງສ້າງຂອງໂລກ" (ໃນ YAML), ເຊິ່ງສ້າງໂດຍ Kubernetes. ແລະອີກເທື່ອຫນຶ່ງ: ເມື່ອຄໍາອະທິບາຍປ່ຽນແປງ, ການສະແດງຕົວຈິງຂອງມັນຈະປ່ຽນແປງເຊັ່ນກັນ.

ການຄຸ້ມຄອງຊັບພະຍາກອນ

CPU

ໃຫ້ພວກເຮົາດໍາເນີນການ nginx, php-fpm ແລະ mysql ໃນເຄື່ອງແມ່ຂ່າຍ. ການບໍລິການເຫຼົ່ານີ້ຕົວຈິງແລ້ວຈະມີຂະບວນການເຮັດວຽກຫຼາຍຂຶ້ນ, ແຕ່ລະອັນຕ້ອງການຊັບພະຍາກອນຄອມພິວເຕີ:

(ຕົວເລກຢູ່ໃນສະໄລ້ແມ່ນ "ນົກແກ້ວ", ຄວາມຕ້ອງການທີ່ບໍ່ມີຕົວຕົນຂອງແຕ່ລະຂະບວນການສໍາລັບພະລັງງານຄອມພິວເຕີ້)

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

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

ໃນສະພາບການຂອງບົດລາຍງານ, ພວກເຮົາພຽງແຕ່ມີຄວາມສົນໃຈໃນ ກຸ່ມ, ເນື່ອງຈາກວ່າກຸ່ມຄວບຄຸມແມ່ນສ່ວນຫນຶ່ງຂອງການເຮັດວຽກຂອງບັນຈຸ (Docker, ແລະອື່ນໆ) ທີ່ປະຕິບັດການຄຸ້ມຄອງຊັບພະຍາກອນ. ຂະບວນການລວມເຂົ້າກັນເປັນກຸ່ມ, ຕາມທີ່ພວກເຮົາຕ້ອງການ, ແມ່ນກຸ່ມຄວບຄຸມ.

ໃຫ້ກັບຄືນໄປຫາຄວາມຕ້ອງການ CPU ສໍາລັບຂະບວນການເຫຼົ່ານີ້, ແລະໃນປັດຈຸບັນສໍາລັບກຸ່ມຂອງຂະບວນການ:

(ຂ້າພະເຈົ້າເວົ້າຄືນວ່າຕົວເລກທັງຫມົດເປັນການສະແດງອອກທີ່ບໍ່ມີຕົວຕົນຂອງຄວາມຕ້ອງການຊັບພະຍາກອນ)

ໃນເວລາດຽວກັນ, CPU ຕົວຂອງມັນເອງມີຊັບພະຍາກອນທີ່ແນ່ນອນ (ໃນຕົວຢ່າງນີ້ແມ່ນ 1000), ເຊິ່ງທຸກຄົນອາດຈະຂາດ (ຜົນລວມຂອງຄວາມຕ້ອງການຂອງກຸ່ມທັງຫມົດແມ່ນ 150+850+460=1460). ຈະເກີດຫຍັງຂຶ້ນໃນກໍລະນີນີ້?

kernel ເລີ່ມແຈກຢາຍຊັບພະຍາກອນແລະເຮັດມັນ "ຍຸດຕິທໍາ", ໃຫ້ຈໍານວນຊັບພະຍາກອນດຽວກັນກັບແຕ່ລະກຸ່ມ. ແຕ່ໃນກໍລະນີທໍາອິດ, ມັນມີຫຼາຍກວ່າທີ່ຕ້ອງການ (333> 150), ດັ່ງນັ້ນສ່ວນເກີນ (333-150 = 183) ຍັງຄົງຢູ່ໃນສະຫງວນ, ເຊິ່ງຍັງຖືກແຈກຢາຍເທົ່າທຽມກັນລະຫວ່າງສອງຖັງອື່ນໆ:

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

ໃຫ້ເບິ່ງກໍລະນີຂອງການຂາດຊັບພະຍາກອນໃນຖັງທີສອງ (php-fpm). ຊັບພະຍາກອນບັນຈຸທັງຫມົດແມ່ນແຈກຢາຍເທົ່າທຽມກັນລະຫວ່າງຂະບວນການ. ດັ່ງນັ້ນ, ຂະບວນການແມ່ບົດເຮັດວຽກໄດ້ດີ, ແຕ່ແຮງງານທັງຫມົດຊ້າລົງ, ໄດ້ຮັບຫນ້ອຍກວ່າເຄິ່ງຫນຶ່ງຂອງສິ່ງທີ່ເຂົາເຈົ້າຕ້ອງການ:

ນີ້ແມ່ນວິທີການກໍານົດເວລາ CFS ເຮັດວຽກ. ພວກ​ເຮົາ​ຈະ​ເອີ້ນ​ຕື່ມ​ວ່າ​ນ​້​ໍາ​ຫນັກ​ທີ່​ພວກ​ເຮົາ​ກໍາ​ນົດ​ໃຫ້​ບັນ​ຈຸ​ ການຮ້ອງຂໍ. ເປັນຫຍັງຄືແນວນີ້ - ເບິ່ງຕື່ມອີກ.

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

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

ໃຫ້ກັບຄືນໄປຫາ Linux kernel ແລະປະຕິສໍາພັນຂອງມັນກັບ CPU - ພາບລວມແມ່ນດັ່ງຕໍ່ໄປນີ້:

cgroup ມີສອງການຕັ້ງຄ່າ - ທີ່ສໍາຄັນເຫຼົ່ານີ້ແມ່ນສອງ "ບິດ" ງ່າຍດາຍທີ່ອະນຸຍາດໃຫ້ທ່ານສາມາດກໍານົດ:

1. ນ້ໍາຫນັກສໍາລັບບັນຈຸ (ຄໍາຮ້ອງຂໍ) ແມ່ນ ຮຸ້ນ;
2. ເປີເຊັນຂອງເວລາ CPU ທັງຫມົດສໍາລັບການເຮັດວຽກໃນວຽກງານບັນຈຸ (ຈໍາກັດ) ແມ່ນ quota.

ວິທີການວັດແທກ CPU?

ມີວິທີທີ່ແຕກຕ່າງກັນ:

1. ຈະເປັນແນວໃດ parrots, ບໍ່ມີໃຜຮູ້ - ທ່ານຈໍາເປັນຕ້ອງເຈລະຈາທຸກໆຄັ້ງ.
2. ຄວາມສົນໃຈ clearer, ແຕ່ພີ່ນ້ອງ: 50% ຂອງເຄື່ອງແມ່ຂ່າຍທີ່ມີ 4 cores ແລະມີ 20 cores ແມ່ນສິ່ງທີ່ແຕກຕ່າງກັນຫມົດ.
3. ທ່ານສາມາດນໍາໃຊ້ສິ່ງທີ່ໄດ້ກ່າວມາແລ້ວ ນ້ໍາຫນັກ, ທີ່ Linux ຮູ້, ແຕ່ພວກເຂົາຍັງເປັນພີ່ນ້ອງ.
4. ທາງເລືອກທີ່ພຽງພໍທີ່ສຸດແມ່ນການວັດແທກຊັບພະຍາກອນຄອມພິວເຕີໃນ ວິນາທີ. ເຫຼົ່ານັ້ນ. ໃນວິນາທີຂອງເວລາຂອງໂປເຊດເຊີທຽບກັບວິນາທີຂອງເວລາທີ່ແທ້ຈິງ: 1 ວິນາທີຂອງເວລາຂອງໂປເຊດເຊີຖືກໃຫ້ຕໍ່ 1 ວິນາທີທີ່ແທ້ຈິງ - ນີ້ແມ່ນຫນຶ່ງຫຼັກຂອງ CPU.

ເພື່ອເຮັດໃຫ້ມັນງ່າຍຂຶ້ນໃນການເວົ້າ, ພວກເຂົາເລີ່ມວັດແທກໂດຍກົງ ແກ່ນ, ຊຶ່ງຫມາຍຄວາມວ່າພວກເຂົາໃຊ້ເວລາ CPU ດຽວກັນກັບຕົວຈິງ. ເນື່ອງຈາກ Linux ເຂົ້າໃຈນ້ໍາຫນັກ, ແຕ່ບໍ່ມີເວລາ CPU / cores ຫຼາຍ, ກົນໄກແມ່ນຈໍາເປັນເພື່ອແປຈາກຫນຶ່ງໄປຫາອີກ.

ຂໍໃຫ້ພິຈາລະນາຕົວຢ່າງງ່າຍໆກັບເຄື່ອງແມ່ຂ່າຍທີ່ມີ 3 ແກນ CPU, ບ່ອນທີ່ສາມຝັກຈະໄດ້ຮັບນ້ໍາຫນັກ (500, 1000 ແລະ 1500) ທີ່ສາມາດປ່ຽນໄດ້ຢ່າງງ່າຍດາຍກັບສ່ວນທີ່ສອດຄ້ອງກັນຂອງແກນທີ່ຈັດສັນໃຫ້ພວກເຂົາ (0,5, 1 ແລະ 1,5).

ຖ້າທ່ານເອົາເຄື່ອງແມ່ຂ່າຍທີສອງ, ບ່ອນທີ່ຈະມີແກນຫຼາຍເທົ່າ (6), ແລະວາງ pods ດຽວກັນຢູ່ທີ່ນັ້ນ, ການແຜ່ກະຈາຍຂອງແກນສາມາດຖືກຄິດໄລ່ໄດ້ງ່າຍໂດຍການຄູນດ້ວຍ 2 (1, 2 ແລະ 3, ຕາມລໍາດັບ). ແຕ່ຊ່ວງເວລາທີ່ສໍາຄັນແມ່ນເກີດຂື້ນເມື່ອຝັກທີສີ່ປາກົດຢູ່ໃນເຄື່ອງແມ່ຂ່າຍນີ້, ນ້ໍາຫນັກ, ເພື່ອຄວາມສະດວກ, ຈະເປັນ 3000. ມັນໃຊ້ເວລາສ່ວນຫນຶ່ງຂອງຊັບພະຍາກອນ CPU (ເຄິ່ງຫນຶ່ງຂອງແກນ), ແລະສໍາລັບຝັກທີ່ຍັງເຫຼືອແມ່ນພວກເຂົາຖືກຄິດໄລ່ຄືນໃຫມ່ (ເຄິ່ງຫນຶ່ງ):

Kubernetes ແລະຊັບພະຍາກອນ CPU

ໃນ Kubernetes, ຊັບພະຍາກອນ CPU ມັກຈະຖືກວັດແທກໃນ milliadrax, i.e. 0,001 cores ຖືກປະຕິບັດເປັນນ້ໍາຫນັກພື້ນຖານ. (ສິ່ງດຽວກັນໃນ Linux/cgroups terminology ເອີ້ນວ່າການແບ່ງປັນ CPU, ເຖິງແມ່ນວ່າ, ຊັດເຈນກວ່າ, 1000 millicores = 1024 CPU shares.) K8s ຮັບປະກັນວ່າມັນບໍ່ໄດ້ວາງ pods ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຫຼາຍກ່ວາມີຊັບພະຍາກອນ CPU ສໍາລັບຜົນລວມຂອງນ້ໍາຫນັກຂອງ pods ທັງຫມົດ.

ນີ້ເກີດຂຶ້ນແນວໃດ? ເມື່ອທ່ານເພີ່ມເຊີບເວີໃສ່ກຸ່ມ Kubernetes, ມັນໄດ້ຖືກລາຍງານວ່າມີ CPU cores ເທົ່າໃດ. ແລະເມື່ອສ້າງຝັກໃໝ່, ຕົວກຳນົດເວລາ Kubernetes ຮູ້ວ່າພອດນີ້ຈະຕ້ອງການຈັກແກນ. ດັ່ງນັ້ນ, ຝັກຈະຖືກມອບໃຫ້ເຄື່ອງແມ່ຂ່າຍທີ່ມີແກນພຽງພໍ.

ຈະເກີດຫຍັງຂຶ້ນຖ້າ ບໍ່ ການຮ້ອງຂໍຖືກລະບຸ (i. e. ຝັກບໍ່ມີຈໍານວນຫຼັກທີ່ມັນຕ້ອງການ)? ລອງຄິດເບິ່ງວ່າ ໂດຍທົ່ວໄປແລ້ວ Kubernetes ນັບຊັບພະຍາກອນແນວໃດ.

ສໍາ​ລັບ​ຝັກ​ທີ່​ທ່ານ​ສາ​ມາດ​ລະ​ບຸ​ທັງ​ສອງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ (CFS ກໍາ​ນົດ​ເວ​ລາ​) ແລະ​ຈໍາ​ກັດ (ຈື່​ຈໍາ​ໄຟ​ຈະ​ລາ​ຈອນ​?):

• ຖ້າພວກເຂົາຖືກລະບຸເທົ່າທຽມກັນ, ຫຼັງຈາກນັ້ນຝັກຈະຖືກມອບຫມາຍເປັນຊັ້ນ QoS ຮັບປະກັນ. ຈໍາ​ນວນ​ຂອງ​ຫຼັກ​ການ​ນີ້​ສະ​ເຫມີ​ໄປ​ທີ່​ມັນ​ແມ່ນ​ການ​ຮັບ​ປະ​ກັນ​.
• ຖ້າຄໍາຮ້ອງຂໍແມ່ນຫນ້ອຍກວ່າຂອບເຂດຈໍາກັດ - QoS class ລະເບີດໄດ້. ເຫຼົ່ານັ້ນ. ຕົວຢ່າງ, ພວກເຮົາຄາດຫວັງວ່າຝັກຈະໃຊ້ 1 ຫຼັກສະເໝີ, ແຕ່ຄ່ານີ້ບໍ່ແມ່ນຂໍ້ຈຳກັດສຳລັບມັນ: ບາງຄັ້ງ pod ສາມາດນໍາໃຊ້ໄດ້ຫຼາຍ (ເມື່ອເຄື່ອງແມ່ຂ່າຍມີຊັບພະຍາກອນຟຣີສໍາລັບການນີ້).
• ນອກນັ້ນຍັງມີຫ້ອງຮຽນ QoS ພະຍາຍາມທີ່ດີທີ່ສຸດ — ມັນ​ລວມ​ເອົາ​ຝັກ​ທີ່​ຮ້ອງ​ຂໍ​ບໍ່​ໄດ້​ລະ​ບຸ​ໄວ້​. ຊັບພະຍາກອນໄດ້ຖືກມອບໃຫ້ພວກເຂົາສຸດທ້າຍ.

ຫນ່ວຍຄວາມຈໍາ

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

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

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

ໃຫ້ກັບຄືນໄປຫາຫ້ອງຮຽນ QoS ຂອງ CPU ແລະແຕ້ມການປຽບທຽບກັບຄ່າ oom_score_adj ທີ່ກໍານົດບູລິມະສິດການບໍລິໂພກຫນ່ວຍຄວາມຈໍາສໍາລັບ pods:

• ຄ່າ oom_score_adj ຕໍ່າສຸດສໍາລັບຝັກ - -998 - ຫມາຍຄວາມວ່າຝັກດັ່ງກ່າວຄວນຈະຖືກຂ້າສຸດທ້າຍ, ນີ້ ຮັບປະກັນ.
• ສູງສຸດ - 1000 - ແມ່ນ ພະຍາຍາມທີ່ດີທີ່ສຸດ, ຝັກດັ່ງກ່າວຖືກຂ້າຕາຍກ່ອນ.
• ເພື່ອຄິດໄລ່ຄ່າທີ່ຍັງເຫຼືອ (ລະເບີດໄດ້) ມີສູດຫນຶ່ງ, ໂດຍເນື້ອແທ້ແລ້ວຂອງທີ່ຕົ້ມລົງກັບຄວາມຈິງທີ່ວ່າຊັບພະຍາກອນຫຼາຍຝັກໄດ້ຮ້ອງຂໍ, ຄວາມເປັນໄປໄດ້ຫນ້ອຍທີ່ຈະຂ້າ.

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

ລວມ

ແຕ່ລະຝັກໃນ Kubernetes ແມ່ນໃຫ້ requests и limits - ຕົວກໍານົດການທັງສອງສໍາລັບ CPU ແລະຫນ່ວຍຄວາມຈໍາ:

1. ອີງຕາມການຮ້ອງຂໍ, ຕົວກໍານົດເວລາ Kubernetes ເຮັດວຽກ, ເຊິ່ງແຈກຢາຍ pods ລະຫວ່າງເຄື່ອງແມ່ຂ່າຍ;
2. ອີງຕາມຕົວກໍານົດການທັງຫມົດ, ຫ້ອງຮຽນ QoS ຂອງຝັກແມ່ນຖືກກໍານົດ;
3. ນ້ຳໜັກສົມທຽບແມ່ນຄຳນວນຕາມຄຳຮ້ອງຂໍ CPU;
4. ຕົວກໍານົດເວລາ CFS ຖືກຕັ້ງຄ່າໂດຍອີງໃສ່ການຮ້ອງຂໍ CPU;
5. killer OOM ຖືກຕັ້ງຄ່າໂດຍອີງໃສ່ການຮ້ອງຂໍຄວາມຈໍາ;
6. "ໄຟຈະລາຈອນ" ຖືກຕັ້ງຄ່າໂດຍອີງໃສ່ການຈໍາກັດ CPU;
7. ອີງຕາມການຈໍາກັດຫນ່ວຍຄວາມຈໍາ, ກໍານົດຂອບເຂດຈໍາກັດສໍາລັບ cgroup.

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

ປັບຂະໜາດອັດຕະໂນມັດ

K8s cluster-autoscaler

ລອງນຶກພາບເບິ່ງວ່າກຸ່ມທັງໝົດຖືກຄອບຄອງແລ້ວ ແລະຈະຕ້ອງສ້າງຝັກໃໝ່. ໃນຂະນະທີ່ຝັກບໍ່ສາມາດປາກົດ, ມັນຢູ່ໃນສະຖານະ ທີ່ຍັງຄ້າງ. ເພື່ອໃຫ້ມັນປາກົດ, ພວກເຮົາສາມາດເຊື່ອມຕໍ່ເຄື່ອງແມ່ຂ່າຍໃຫມ່ກັບ cluster ຫຼື ... ຕິດຕັ້ງ cluster-autoscaler, ເຊິ່ງຈະເຮັດມັນສໍາລັບພວກເຮົາ: ສັ່ງເຄື່ອງ virtual ຈາກຜູ້ໃຫ້ບໍລິການຟັງ (ໃຊ້ຄໍາຮ້ອງຂໍ API) ແລະເຊື່ອມຕໍ່ມັນກັບ cluster. , ຫຼັງຈາກນັ້ນຝັກຈະຖືກເພີ່ມ.

ນີ້ແມ່ນການປັບຂະໜາດອັດຕະໂນມັດຂອງກຸ່ມ Kubernetes, ເຊິ່ງເຮັດວຽກໄດ້ດີ (ໃນປະສົບການຂອງພວກເຮົາ). ຢ່າງໃດກໍຕາມ, ເປັນບ່ອນອື່ນ, ມີບາງ nuances ຢູ່ທີ່ນີ້ ...

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

ພິຈາລະນາກຸ່ມຂອງ 3 ເຊີບເວີທີ່ມີ Deployment. ມັນມີ 6 ຝັກ: ໃນປັດຈຸບັນມີ 2 ສໍາລັບແຕ່ລະເຄື່ອງແມ່ຂ່າຍ. ສໍາລັບເຫດຜົນບາງຢ່າງທີ່ພວກເຮົາຕ້ອງການປິດຫນຶ່ງໃນເຄື່ອງແມ່ຂ່າຍ. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຈະນໍາໃຊ້ຄໍາສັ່ງ kubectl drain, ເຊິ່ງ:

• ຈະຫ້າມການສົ່ງ pods ໃຫມ່ໄປຫາເຄື່ອງແມ່ຂ່າຍນີ້;
• ຈະລຶບພອດທີ່ມີຢູ່ໃນເຊີບເວີ.

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

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

MongoDB ສາມາດ ຕາຍເພາະວ່າມັນຕ້ອງການກຸ່ມ: ສໍາລັບກຸ່ມຂອງສາມການຕິດຕັ້ງ, ຢ່າງຫນ້ອຍສອງຕ້ອງໄດ້ເຮັດວຽກ. ຢ່າງໃດກໍຕາມ, ນີ້ ບໍ່ເກີດຂຶ້ນ - ຂອບໃຈ PodDisruptionBudget. ພາລາມິເຕີນີ້ກໍານົດຈໍານວນຕໍາ່ສຸດທີ່ຕ້ອງການຂອງຝັກເຮັດວຽກ. ຮູ້ວ່າຫນຶ່ງໃນຝັກ MongoDB ບໍ່ໄດ້ເຮັດວຽກອີກຕໍ່ໄປ, ແລະເຫັນວ່າ PodDisruptionBudget ຖືກຕັ້ງໄວ້ສໍາລັບ MongoDB. minAvailable: 2, Kubernetes ຈະບໍ່ອະນຸຍາດໃຫ້ທ່ານລຶບຝັກ.

ເສັ້ນທາງລຸ່ມ: ເພື່ອໃຫ້ການເຄື່ອນໄຫວ (ແລະໃນຄວາມເປັນຈິງ, ການສ້າງໃຫມ່) ຂອງຝັກເພື່ອເຮັດວຽກຢ່າງຖືກຕ້ອງເມື່ອກຸ່ມຖືກປ່ອຍອອກມາ, ມັນຈໍາເປັນຕ້ອງຕັ້ງຄ່າ PodDisruptionBudget.

ການ​ຂະ​ຫຍາຍ​ອອກ​ຕາມ​ລວງ​ນອນ​

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

ມື້ນີ້ໃນ Kubernetes ມັນບໍ່ຈໍາເປັນຕ້ອງເຮັດດ້ວຍຕົນເອງ: ການເພີ່ມ / ຫຼຸດລົງຂອງຈໍານວນຝັກອັດຕະໂນມັດແມ່ນຖືກກໍານົດໂດຍຂຶ້ນກັບຄ່າຂອງຕົວຊີ້ວັດການໂຫຼດທີ່ວັດແທກ.

ຄໍາຖາມຕົ້ນຕໍຢູ່ທີ່ນີ້ແມ່ນ: ສິ່ງທີ່ແນ່ນອນທີ່ຈະວັດແທກ и ວິ​ທີ​ການ​ຕີ​ຄວາມ​ຫມາຍ​ ໄດ້ຮັບຄ່າ (ສໍາລັບການຕັດສິນໃຈກ່ຽວກັບການປ່ຽນແປງຈໍານວນຂອງຝັກ). ທ່ານສາມາດວັດແທກໄດ້ຫຼາຍ:

ວິທີການເຮັດແນວນີ້ທາງດ້ານວິຊາການ - ເກັບກໍາ metrics, ແລະອື່ນໆ. — ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ເວົ້າ​ໃນ​ລາຍ​ລະ​ອຽດ​ໃນ​ລາຍ​ງານ​ກ່ຽວ​ກັບ​ການ​ ການຕິດຕາມແລະ Kubernetes. ແລະຄໍາແນະນໍາຕົ້ນຕໍສໍາລັບການເລືອກຕົວກໍານົດການທີ່ດີທີ່ສຸດແມ່ນ ການທົດລອງ!

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

ແທນທີ່ຈະເປັນການສະຫລຸບໄດ້

ບົດລາຍງານມີການສືບຕໍ່: ກ່ຽວກັບການປັບຂະຫນາດຕາມແນວຕັ້ງແລະວິທີການເລືອກຊັບພະຍາກອນທີ່ຖືກຕ້ອງ. ຂ້ອຍຈະເວົ້າກ່ຽວກັບເລື່ອງນີ້ໃນວິດີໂອໃນອະນາຄົດ YouTube ຂອງພວກເຮົາ - ຈອງ​ເພື່ອ​ບໍ່​ໃຫ້​ພາດ​!

ວິດີໂອ ແລະສະໄລ້

ວິດີໂອຈາກການສະແດງ (44 ນາທີ):

ການ​ນໍາ​ສະ​ເຫນີ​ບົດ​ລາຍ​ງານ​:

PS

ບົດລາຍງານອື່ນໆກ່ຽວກັບ Kubernetes ໃນ blog ຂອງພວກເຮົາ:

• «ຂະຫຍາຍ ແລະເສີມສ້າງ Kubernetes» (Andrey Polovov; ວັນທີ 8 ເມສາ 2019 ໃນ Saint HighLoad++);
• «ຖານຂໍ້ມູນ ແລະ Kubernetes» (Dmitry Stolyarov; ເດືອນພະຈິກ 8, 2018 on HighLoad++);
• «ການຕິດຕາມແລະ Kubernetes» (Dmitry Stolyarov; 28 ພຶດສະພາ 2018 ຢູ່ RootConf);
• «CI/CD ການປະຕິບັດທີ່ດີທີ່ສຸດກັບ Kubernetes ແລະ GitLab» (Dmitry Stolyarov; ເດືອນພະຈິກ 7, 2017 on HighLoad++);
• «ປະສົບການຂອງພວກເຮົາກັບ Kubernetes ໃນໂຄງການຂະຫນາດນ້ອຍ» (Dmitry Stolyarov; 6 ເດືອນມິຖຸນາ 2017 ຢູ່ RootConf).

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