ໂນດພະນັກງານ Kubernetes: ໜ່ວຍນ້ອຍຫຼາຍອັນ ຫຼືອັນໃຫຍ່ຫຼາຍອັນ?

ເມື່ອສ້າງກຸ່ມ Kubernetes, ຄຳຖາມອາດເກີດຂຶ້ນ: ມີຈັກຄົນທີ່ຈະກຳນົດຄ່າ ແລະປະເພດໃດ? ສິ່ງທີ່ດີກວ່າສໍາລັບກຸ່ມຢູ່ໃນສະຖານທີ່: ຊື້ເຄື່ອງແມ່ຂ່າຍທີ່ມີປະສິດທິພາບຫຼາຍຫຼືໃຊ້ເຄື່ອງຈັກເກົ່າຫຼາຍສິບເຄື່ອງຢູ່ໃນສູນຂໍ້ມູນຂອງທ່ານ? ມັນດີກວ່າທີ່ຈະເອົາແປດ quad-core instances ດຽວຫຼືສອງ quad-core ໃນຄລາວບໍ?

ຄໍາຕອບຂອງຄໍາຖາມເຫຼົ່ານີ້ແມ່ນຢູ່ໃນບົດຄວາມ. Daniel Weibel, ວິສະວະກອນຊອບແວ ແລະຄູສອນຂອງໂຄງການການສຶກສາ Learnk8s ໃນການແປຄໍາສັ່ງ Kubernetes aaS ຈາກ Mail.ru.

ຄວາມອາດສາມາດຂອງກຸ່ມ

ໂດຍທົ່ວໄປ, ກຸ່ມ Kubernetes ສາມາດຖືກຄິດວ່າເປັນ "supernode". ພະລັງງານຄອມພິວເຕີທັງໝົດຂອງມັນແມ່ນຜົນລວມຂອງອຳນາດຂອງຂໍ້ປະກອບທັງໝົດຂອງມັນ.

ມີຫຼາຍວິທີເພື່ອບັນລຸເປົ້າໝາຍຄວາມອາດສາມາດຂອງກຸ່ມທີ່ຕ້ອງການ. ຕົວຢ່າງ, ພວກເຮົາຕ້ອງການກຸ່ມທີ່ມີຄວາມສາມາດທັງຫມົດຂອງ 8 ແກນໂປເຊດເຊີແລະ 32 GB ຂອງ RAM ເພາະວ່າຊຸດຂອງແອັບພລິເຄຊັນຕ້ອງການຊັບພະຍາກອນຫຼາຍ. ຫຼັງຈາກນັ້ນ, ທ່ານສາມາດຕິດຕັ້ງສອງໂຫນດທີ່ມີຫນ່ວຍຄວາມຈໍາ 16 GB ຫຼືສີ່ໂຫນດທີ່ມີຫນ່ວຍຄວາມຈໍາ 8 GB, ສອງໂປເຊດເຊີ quad-core ຫຼືສີ່ dual-core.

ນີ້ແມ່ນພຽງແຕ່ສອງວິທີທີ່ເປັນໄປໄດ້ໃນການສ້າງກຸ່ມ:

ທັງສອງທາງເລືອກຜະລິດກຸ່ມທີ່ມີຄວາມສາມາດດຽວກັນ, ແຕ່ການຕັ້ງຄ່າດ້ານລຸ່ມມີສີ່ໂຫນດນ້ອຍກວ່າແລະການຕັ້ງຄ່າເທິງມີສອງໂຫນດໃຫຍ່ກວ່າ.

ທາງເລືອກໃດດີກວ່າ?

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

ຂໍ້ໃຫຍ່ຫຼາຍອັນ

ຂໍ້ນ້ອຍຫຼາຍ

ການຈັດການກຸ່ມທີ່ງ່າຍຂຶ້ນ (ຖ້າມັນຢູ່ໃນສະຖານທີ່)

Smooth autoscaling

ລາຄາຖືກກວ່າ (ຖ້າຢູ່ໃນສະຖານທີ່)

ລາຄາແຕກຕ່າງກັນເລັກນ້ອຍ (ຢູ່ໃນເມຄ)

ສາມາດແລ່ນແອັບພລິເຄຊັນທີ່ໃຊ້ຊັບພະຍາກອນຫຼາຍ

ການຈໍາລອງແບບເຕັມ

ຊັບພະຍາກອນຖືກນຳໃຊ້ຢ່າງມີປະສິດທິພາບ (ໜ້ອຍລົງໃນລະບົບ daemon
ຄວາມທົນທານຄວາມຜິດຂອງກຸ່ມທີ່ສູງຂຶ້ນ

ກະລຸນາຮັບຊາບວ່າພວກເຮົາພຽງແຕ່ເວົ້າກ່ຽວກັບຂໍ້ຂອງພະນັກງານ. ການເລືອກຈໍານວນແລະຂະຫນາດຂອງຂໍ້ຕົ້ນຕໍແມ່ນເປັນຫົວຂໍ້ທີ່ແຕກຕ່າງກັນຫມົດ.

ດັ່ງນັ້ນ, ໃຫ້ພິຈາລະນາແຕ່ລະຈຸດຈາກຕາຕະລາງໃນລາຍລະອຽດເພີ່ມເຕີມ.

ທາງເລືອກທໍາອິດ: ຫຼາຍຂໍ້ຂະຫນາດໃຫຍ່

ທາງ​ເລືອກ​ທີ່​ຮ້າຍ​ແຮງ​ທີ່​ສຸດ​ແມ່ນ​ຫນຶ່ງ​ຂໍ້​ພະ​ນັກ​ງານ​ສໍາ​ລັບ​ຄວາມ​ສາ​ມາດ​ຂອງ​ກຸ່ມ​ທັງ​ຫມົດ​. ໃນຕົວຢ່າງຂ້າງເທິງ, ນີ້ຈະເປັນ node ພະນັກງານດຽວທີ່ມີ 16 CPU cores ແລະ 16 GB ຂອງ RAM.

ຄວາມຄິດເຫັນ

ບວກເລກ 1. ການຈັດການງ່າຍກວ່າ
ມັນງ່າຍກວ່າທີ່ຈະຈັດການເຄື່ອງຈັກໜ້ອຍໜຶ່ງກວ່າເຮືອທັງໝົດ. ມັນໄວກວ່າທີ່ຈະເປີດຕົວການອັບເດດ ແລະການແກ້ໄຂ, ແລະມັນງ່າຍຂຶ້ນໃນການ synchronize. ຈໍານວນຂອງຄວາມລົ້ມເຫລວໃນຈໍານວນຢ່າງແທ້ຈິງແມ່ນຍັງຫນ້ອຍ.

ກະ​ລຸ​ນາ​ສັງ​ເກດ​ວ່າ​ທັງ​ຫມົດ​ຂ້າງ​ເທິງ​ນີ້​ໃຊ້​ໄດ້​ກັບ​ຮາດ​ແວ​ຂອງ​ທ່ານ​, ເຄື່ອງ​ແມ່​ຂ່າຍ​ຂອງ​ທ່ານ​, ແລະ​ບໍ່​ແມ່ນ​ກັບ​ການ​ຟັງ​.

ສະຖານະການແມ່ນແຕກຕ່າງກັນໃນເມຄ. ຢູ່ທີ່ນັ້ນ, ການຈັດການແມ່ນຈັດການໂດຍຜູ້ໃຫ້ບໍລິການຟັງ. ດັ່ງນັ້ນ, ການຈັດການສິບໂຫນດໃນຄລາວແມ່ນບໍ່ແຕກຕ່າງຈາກການຈັດການຫນຶ່ງ node.

ເສັ້ນທາງການຈະລາຈອນແລະການແຈກຢາຍການໂຫຼດລະຫວ່າງ pods ໃນຄລາວ ປະຕິບັດອັດຕະໂນມັດ: ການຈະລາຈອນທີ່ມາຈາກອິນເຕີເນັດແມ່ນຖືກສົ່ງໄປຫາຕົວດຸ່ນດ່ຽງການໂຫຼດຕົ້ນຕໍ, ເຊິ່ງສົ່ງການຈະລາຈອນໄປຫາພອດຂອງຫນຶ່ງຂອງ nodes (ບໍລິການ NodePort ກໍານົດພອດຢູ່ໃນລະດັບ 30000-32767 ໃນແຕ່ລະ node cluster). ກົດລະບຽບທີ່ກໍານົດໄວ້ໂດຍ kube-proxy ປ່ຽນເສັ້ນທາງການຈະລາຈອນຈາກ node ໄປຫາ pod. ນີ້ແມ່ນສິ່ງທີ່ເບິ່ງຄືວ່າສໍາລັບສິບ pods ໃນສອງ nodes:

Pro #2: ຄ່າໃຊ້ຈ່າຍຫນ້ອຍລົງຕໍ່ node
ລົດທີ່ມີອໍານາດມີລາຄາແພງກວ່າ, ແຕ່ການເພີ່ມຂຶ້ນຂອງລາຄາແມ່ນບໍ່ຈໍາເປັນ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ເຄື່ອງແມ່ຂ່າຍຫນຶ່ງສິບຫຼັກທີ່ມີຫນ່ວຍຄວາມຈໍາ 10 GB ມັກຈະມີລາຄາຖືກກວ່າສິບເຄື່ອງແມ່ຂ່າຍດຽວທີ່ມີຈໍານວນຫນ່ວຍຄວາມຈໍາດຽວກັນ.

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

ດັ່ງນັ້ນ, ຢູ່ໃນຄລາວມັກຈະບໍ່ສາມາດປະຫຍັດໃນເຄື່ອງແມ່ຂ່າຍທີ່ມີປະສິດທິພາບຫຼາຍ.

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

Минусы

ຂໍ້ເສຍ 1. ຝັກຫຼາຍຕໍ່ node
ຖ້າວຽກງານດຽວກັນຖືກປະຕິບັດຢູ່ໃນໂຫມດຫນ້ອຍ, ຫຼັງຈາກນັ້ນແຕ່ລະພວກມັນຈະມີຝັກຫຼາຍຕາມທໍາມະຊາດ.

ນີ້ອາດຈະເປັນບັນຫາ.

ເຫດຜົນແມ່ນວ່າແຕ່ລະໂມດູນແນະນໍາການ overhead ບາງກັບ container runtime (ເຊັ່ນ: Docker), ເຊັ່ນດຽວກັນກັບ kubelet ແລະ cAdvisor.

ຕົວຢ່າງ, kubelet ກວດຫາພາຊະນະທັງໝົດຢູ່ໃນໂຫນດເພື່ອຄວາມຢູ່ລອດເປັນປະຈຳ - ຍິ່ງບັນຈຸຫຼາຍ, kubelet ຕ້ອງເຮັດຫຼາຍເທົ່າໃດ.

CAdvisor ເກັບກໍາສະຖິຕິການນໍາໃຊ້ຊັບພະຍາກອນສໍາລັບທຸກ containers ໃນ node, ແລະ kubelet ສອບຖາມຂໍ້ມູນນີ້ເປັນປົກກະຕິແລະສະຫນອງມັນຜ່ານ API. ອີກເທື່ອ ໜຶ່ງ, ຖັງບັນຈຸຫຼາຍ ໝາຍ ເຖິງການເຮັດວຽກຫຼາຍ ສຳ ລັບທັງ cAdvisor ແລະ kubelet.

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

ຢູ່ໃນບ່ອນເກັບມ້ຽນ Kubernetes ບາງ ຈົ່ມnodes ເຕັ້ນໄປຫາລະຫວ່າງສະຖານະ Ready/NotReady ເພາະວ່າການກວດສອບ kubelet ປົກກະຕິຂອງທຸກ container ໃນ node ໃຊ້ເວລາດົນເກີນໄປ.
ສໍາລັບເຫດຜົນນີ້ Kubernetes ແນະນໍາໃຫ້ວາງບໍ່ເກີນ 110 pods ຕໍ່ node. ອີງຕາມການປະຕິບັດຂອງ node, ທ່ານສາມາດດໍາເນີນການ pods ຫຼາຍຕໍ່ node, ແຕ່ມັນຍາກທີ່ຈະຄາດຄະເນວ່າຈະມີບັນຫາຫຼືທຸກສິ່ງທຸກຢ່າງຈະເຮັດວຽກດີ. ມັນເປັນມູນຄ່າການທົດສອບການເຮັດວຽກລ່ວງຫນ້າ.

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

ຫ້າ replicas ສາມາດຖືກແຈກຢາຍໃນທົ່ວສອງ nodes, ແລະຖ້າຫາກວ່າຫນຶ່ງໃນພວກມັນລົ້ມເຫລວ, ມັນຈະເອົາການ replicas ຫຼາຍລົງໃນຄັ້ງດຽວ.

ຖ້າທ່ານມີ XNUMX nodes ຫຼືຫຼາຍກວ່ານັ້ນ, ແຕ່ລະ replica ຈະດໍາເນີນການຢູ່ໃນ node ແຍກຕ່າງຫາກ, ແລະຄວາມລົ້ມເຫຼວຂອງ node ຈະເອົາອອກຫຼາຍທີ່ສຸດຫນຶ່ງ replica.

ດັ່ງນັ້ນ, ຄວາມຕ້ອງການຄວາມພ້ອມສູງອາດຈະຮຽກຮ້ອງໃຫ້ມີຈໍານວນຕໍາ່ສຸດທີ່ສະເພາະໃດຫນຶ່ງຂອງ nodes ໃນ cluster.

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

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

ດັ່ງນັ້ນ, ຫຼາຍ nodes, ຜົນກະທົບຂອງຄວາມລົ້ມເຫຼວຂອງຮາດແວຫນ້ອຍ.

ຂໍ້ເສຍ #4: ຂັ້ນຕອນການປັບຂະໜາດອັດຕະໂນມັດເພີ່ມເຕີມ
Kubernetes ມີລະບົບການຂະຫຍາຍກຸ່ມອັດຕະໂນມັດສໍາລັບໂຄງສ້າງພື້ນຖານຂອງຄລາວ, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານເພີ່ມ ຫຼືລຶບ nodes ໂດຍອັດຕະໂນມັດຂຶ້ນກັບຄວາມຕ້ອງການປັດຈຸບັນຂອງທ່ານ. ດ້ວຍໂນດທີ່ໃຫຍ່ຂຶ້ນ, ການປັບຂະໜາດອັດຕະໂນມັດຈະກາຍເປັນເລື່ອງທີ່ກະທັນຫັນ ແລະ ສັບສົນຫຼາຍ. ຕົວຢ່າງ, ໃນສອງ node, ການເພີ່ມ node ເພີ່ມເຕີມຈະເພີ່ມຄວາມສາມາດຂອງ cluster ທັນທີ 50%. ແລະທ່ານຈະຕ້ອງຈ່າຍຄ່າຊັບພະຍາກອນເຫຼົ່ານັ້ນ, ເຖິງແມ່ນວ່າທ່ານບໍ່ຕ້ອງການມັນ.

ດັ່ງນັ້ນ, ຖ້າທ່ານວາງແຜນທີ່ຈະໃຊ້ການຂະຫຍາຍກຸ່ມອັດຕະໂນມັດ, ເສັ້ນຂະ ໜາດ ນ້ອຍກວ່າ, ການປັບຂະ ໜາດ ທີ່ຍືດຫຍຸ່ນແລະປະຫຍັດຄ່າໃຊ້ຈ່າຍຫຼາຍທ່ານຈະໄດ້ຮັບ.

ໃນປັດຈຸບັນໃຫ້ພວກເຮົາເບິ່ງຂໍ້ດີແລະຂໍ້ເສຍຂອງຈໍານວນຂະຫນາດໃຫຍ່ຂອງຂໍ້ຂະຫນາດນ້ອຍ.

ທາງເລືອກທີສອງ: ຫຼາຍຂໍ້ຂະຫນາດນ້ອຍ

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

ຄວາມຄິດເຫັນ

Pro #1: ຜົນກະທົບຫນ້ອຍຂອງຄວາມລົ້ມເຫຼວ
ຫຼາຍ nodes, pods ຫນ້ອຍໃນແຕ່ລະ node. ຕົວຢ່າງ, ຖ້າທ່ານມີຫນຶ່ງຮ້ອຍໂມດູນຕໍ່ສິບ, ຫຼັງຈາກນັ້ນແຕ່ລະ node ຈະມີສິບໂມດູນໂດຍສະເລ່ຍ.

ວິທີນີ້, ຖ້າຫນຶ່ງຂອງ nodes ລົ້ມເຫລວ, ທ່ານພຽງແຕ່ສູນເສຍ 10% ຂອງວຽກງານ. ໂອກາດແມ່ນມີພຽງແຕ່ຈໍານວນຫນ້ອຍຂອງ replicas ທີ່ຈະໄດ້ຮັບຜົນກະທົບແລະຄໍາຮ້ອງສະຫມັກໂດຍລວມຈະຍັງຄົງດໍາເນີນການ.

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

Pro #2: ການຈໍາລອງທີ່ດີ
ຖ້າມີ nodes ພຽງພໍ, ຕົວກໍານົດເວລາ Kubernetes ສາມາດກໍານົດ nodes ທີ່ແຕກຕ່າງກັນໃຫ້ກັບ replicas ທັງຫມົດ. ວິທີນີ້, ຖ້າ node ລົ້ມເຫລວ, ມີພຽງແຕ່ຫນຶ່ງ replica ຈະໄດ້ຮັບຜົນກະທົບແລະຄໍາຮ້ອງສະຫມັກຈະຍັງຄົງມີຢູ່.

Минусы

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

ຕົວຄວບຄຸມ node ໃນ Kubernetes Controller Manager ປົກກະຕິຍ່າງທຸກ nodes ໃນ cluster ເພື່ອກວດເບິ່ງສຸຂະພາບ - ຫຼາຍ nodes, ການໂຫຼດຫຼາຍໃນຕົວຄວບຄຸມ.

ການໂຫຼດຢູ່ໃນຖານຂໍ້ມູນ etcd ຍັງເຕີບໃຫຍ່ - ແຕ່ລະ kubelet ແລະ kube-proxy calls watcher ສໍາລັບ etcd (ຜ່ານ API), ທີ່ etcd ຄວນອອກອາກາດການປັບປຸງວັດຖຸ.

ໂດຍທົ່ວໄປ, ແຕ່ລະ node ພະນັກງານ imposes ການໂຫຼດເພີ່ມເຕີມໃນອົງປະກອບຂອງລະບົບຂອງແມ່ບົດ nodes.

Kubernetes ຢ່າງເປັນທາງການສະຫນັບສະຫນູນກຸ່ມທີ່ມີ ຈໍາ​ນວນ​ຂອງ​ຂໍ້​ສູງ​ເຖິງ 5000​. ຢ່າງໃດກໍຕາມ, ໃນທາງປະຕິບັດມີແລ້ວ 500 nodes ສາມາດເຮັດໃຫ້ເກີດບັນຫາທີ່ບໍ່ແມ່ນເລື່ອງເລັກນ້ອຍ.

ເພື່ອຈັດການຈຳນວນຫຼາຍຂອງ worker nodes, ທ່ານຄວນເລືອກ master nodes ທີ່ມີອໍານາດຫຼາຍກວ່າ. ສໍາລັບຕົວຢ່າງ, kube-up ຕິດຕັ້ງອັດຕະໂນມັດ ຂະໜາດ VM ທີ່ຖືກຕ້ອງສຳລັບແມ່ບົດ ຂຶ້ນກັບຈຳນວນຂອງ worker node. ນັ້ນແມ່ນ, ໂຫມດຜູ້ອອກແຮງງານຫຼາຍ, ຜະລິດຕະພັນແມ່ບົດຄວນຈະເປັນ.

ເພື່ອແກ້ໄຂບັນຫາສະເພາະເຫຼົ່ານີ້ມີການພັດທະນາພິເສດ, ເຊັ່ນ: Kubelet Virtual. ລະບົບນີ້ອະນຸຍາດໃຫ້ທ່ານຂ້າມຂໍ້ຈໍາກັດແລະສ້າງກຸ່ມທີ່ມີຈໍານວນຈໍານວນຫລາຍຂອງໂຫນດພະນັກງານ.

ຂໍ້ເສຍ #2: ຄ່າໃຊ້ຈ່າຍເກີນຄ່າໃຊ້ຈ່າຍ.
ໃນແຕ່ລະ node ຂອງພະນັກງານ, Kubernetes ແລ່ນຊຸດ daemons ຂອງລະບົບ - ເຫຼົ່ານີ້ລວມມີ container runtime (ເຊັ່ນ Docker), kube-proxy ແລະ kubelet, ລວມທັງ cAdvisor. ຮ່ວມກັນເຂົາເຈົ້າບໍລິໂພກຈໍານວນຄົງທີ່ຂອງຊັບພະຍາກອນ.

ຖ້າທ່ານມີຂໍ້ນ້ອຍຫຼາຍ, ອັດຕາສ່ວນຂອງສ່ວນເກີນຂອງແຕ່ລະ node ຈະໃຫຍ່ກວ່າ. ຕົວຢ່າງ, ຈິນຕະນາການວ່າ daemons ລະບົບທັງຫມົດໃນ node ດຽວຮ່ວມກັນໃຊ້ 0,1 CPU cores ແລະ 0,1 GB ຂອງຫນ່ວຍຄວາມຈໍາ. ຖ້າທ່ານມີຫນຶ່ງສິບແກນທີ່ມີຫນ່ວຍຄວາມຈໍາ 10 GB, ຫຼັງຈາກນັ້ນ daemons ໃຊ້ 1% ຂອງຄວາມອາດສາມາດຂອງກຸ່ມ. ໃນທາງກົງກັນຂ້າມ, ໃນສິບໂຫນດດຽວທີ່ມີຫນ່ວຍຄວາມຈໍາ 1 GB, daemon ຈະໃຊ້ເວລາ 10% ຂອງຄວາມອາດສາມາດຂອງກຸ່ມ.

ດັ່ງນັ້ນ, ຂໍ້ຫນ້ອຍ, ໂຄງສ້າງພື້ນຖານຖືກນໍາໃຊ້ຢ່າງມີປະສິດທິພາບ.

ຂໍ້ເສຍທີ 3. ການນຳໃຊ້ຊັບພະຍາກອນບໍ່ມີປະສິດທິພາບ
ໃນໂຫນດຂະຫນາດນ້ອຍ, ມັນອາດຈະວ່າຊິ້ນຊັບພະຍາກອນທີ່ຍັງເຫຼືອແມ່ນນ້ອຍເກີນໄປທີ່ຈະມອບຫມາຍວຽກໃດໆ, ດັ່ງນັ້ນພວກມັນຍັງຄົງບໍ່ໄດ້ໃຊ້.

ຕົວຢ່າງ, ແຕ່ລະຝັກຕ້ອງການຫນ່ວຍຄວາມຈໍາ 0,75 GB. ຖ້າທ່ານມີສິບໂຫມດ, ແຕ່ລະຫນ່ວຍຄວາມຈໍາ 1GB, ທ່ານສາມາດດໍາເນີນການສິບ pods, ເຊິ່ງເຮັດໃຫ້ແຕ່ລະ node ມີຫນ່ວຍຄວາມຈໍາທີ່ບໍ່ໄດ້ໃຊ້ 0,25GB.

ນີ້ຫມາຍຄວາມວ່າ 25% ຂອງຄວາມຊົງຈໍາຂອງກຸ່ມທັງຫມົດແມ່ນເສຍໄປ.

ໃນ node ຂະຫນາດໃຫຍ່ທີ່ມີ 10 GB ຂອງຫນ່ວຍຄວາມຈໍາ, ທ່ານສາມາດດໍາເນີນການ 13 ຂອງໂມດູນເຫຼົ່ານີ້ - ແລະຈະມີພຽງແຕ່ຫນຶ່ງຊິ້ນສ່ວນທີ່ບໍ່ໄດ້ໃຊ້ຂອງ 0,25 GB.

ໃນກໍລະນີນີ້, ພຽງແຕ່ 2,5% ຂອງຫນ່ວຍຄວາມຈໍາໄດ້ຖືກສູນເສຍໄປ.

ດັ່ງນັ້ນ, ຊັບພະຍາກອນແມ່ນໃຊ້ໄດ້ດີທີ່ສຸດໃນໂຫນດໃຫຍ່ກວ່າ.

ຫຼາຍຂໍ້ໃຫຍ່ ຫຼືຫຼາຍອັນນ້ອຍໆ?

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

ຕົວຢ່າງ, ຖ້າແອັບພລິເຄຊັນຕ້ອງການຫນ່ວຍຄວາມຈໍາ 10 GB, nodes ຂະຫນາດໃຫຍ່ແມ່ນທາງເລືອກທີ່ຊັດເຈນ. ແລະຖ້າຫາກວ່າຄໍາຮ້ອງສະຫມັກຮຽກຮ້ອງໃຫ້ມີການຈໍາລອງສິບເທົ່າສໍາລັບຄວາມພ້ອມສູງ, ມັນບໍ່ຄຸ້ມຄ່າທີ່ຈະວາງ replicas ຢູ່ໃນພຽງແຕ່ສອງ nodes - ຕ້ອງມີຢ່າງຫນ້ອຍສິບ nodes ໃນ cluster.

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

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

ບໍ່ມີສູດດຽວ, ແລະແຕ່ລະສະຖານະການມີ nuances ຂອງຕົນເອງ, ແລະການຜະລິດພຽງແຕ່ຈະສະແດງໃຫ້ເຫັນຄວາມຈິງ.

ການແປທີ່ກະກຽມໂດຍທີມງານເວທີຄລາວ Mail.ru Cloud Solutions.

ເພີ່ມເຕີມກ່ຽວກັບ Kubernetes: 25 ເຄື່ອງມືທີ່ເປັນປະໂຫຍດສໍາລັບການຄຸ້ມຄອງແລະການນໍາໃຊ້ກຸ່ມ.

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