ການຕິດຕາມຊັບພະຍາກອນຂອງກຸ່ມ Kubernetes

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

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

ຂ້ອຍຈັດການຫຼາຍກຸ່ມຂອງ 4-50 nodes. ແຕ່ລະກຸ່ມມີເຖິງ 200 microservices ແລະແອັບພລິເຄຊັນ. ເພື່ອເຮັດໃຫ້ການນໍາໃຊ້ທີ່ດີກວ່າຂອງຮາດແວທີ່ມີຢູ່ແລ້ວ, ການຕິດຕັ້ງສ່ວນໃຫຍ່ໄດ້ຖືກຕັ້ງຄ່າດ້ວຍຊັບພະຍາກອນ RAM ແລະ CPU ລະເບີດ. ວິທີນີ້, ຝັກສາມາດເອົາຊັບພະຍາກອນທີ່ມີຢູ່ຖ້າຈໍາເປັນ, ແລະໃນເວລາດຽວກັນບໍ່ແຊກແຊງຄໍາຮ້ອງສະຫມັກອື່ນໆໃນ node ນີ້. ແລ້ວ, ມັນດີບໍ?

ແລະເຖິງແມ່ນວ່າ cluster ບໍລິໂພກ CPU ຂ້ອນຂ້າງຫນ້ອຍ (8%) ແລະ RAM (40%), ພວກເຮົາສະເຫມີມີບັນຫາກັບ pods ໄດ້ຖືກ preempted ເມື່ອພວກເຂົາພະຍາຍາມຈັດສັນຫນ່ວຍຄວາມຈໍາຫຼາຍກ່ວາທີ່ມີຢູ່ໃນ node. ໃນຄາວນັ້ນ, ພວກເຮົາມີພຽງ dashboard ດຽວສໍາລັບການຕິດຕາມຊັບພະຍາກອນ Kubernetes. ແບບນີ້:

Grafana dashboard ທີ່ມີ cAdvisor metrics ເທົ່ານັ້ນ

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

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

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

ຂ້ອຍມີກຸ່ມ Kubernetes ເກືອບທັງໝົດທີ່ຕິດຕາມດ້ວຍ ຜູ້ສົ່ງອອກ Node и ເມຕຣິກລັດ Kube. Node Exporter ສະໜອງສະຖິຕິກ່ຽວກັບການນຳໃຊ້ I/O ແລະ disk, CPU, ແລະ RAM, ໃນຂະນະທີ່ລັດ Kube State Metrics ສະແດງຕົວຊີ້ວັດວັດຖຸ Kubernetes ເຊັ່ນຄຳຮ້ອງຂໍ ແລະ CPU ແລະຄວາມຈຳຈຳກັດຊັບພະຍາກອນ.

ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ສົມທົບການວັດແທກການນໍາໃຊ້ກັບຄໍາຮ້ອງຂໍແລະການຈໍາກັດ metrics ໃນ Grafana, ແລະຫຼັງຈາກນັ້ນພວກເຮົາຈະໄດ້ຮັບຂໍ້ມູນທັງຫມົດກ່ຽວກັບບັນຫາ. ນີ້ຟັງຄືງ່າຍດາຍ, ແຕ່ສອງເຄື່ອງມືຕົວຈິງແລ້ວຊື່ປ້າຍຊື່ແຕກຕ່າງກັນ, ແລະບາງ metrics ບໍ່ມີປ້າຍຊື່ metadata ທັງຫມົດ. Kube Eagle ເຮັດທຸກຢ່າງດ້ວຍຕົວມັນເອງແລະກະດານເບິ່ງຄືວ່າ:

ແຜງໜ້າປັດ Kube Eagle

ພວກ​ເຮົາ​ໄດ້​ຈັດ​ການ​ແກ້​ໄຂ​ບັນ​ຫາ​ຈໍາ​ນວນ​ຫຼາຍ​ກັບ​ຊັບ​ພະ​ຍາ​ກອນ​ແລະ​ການ​ປະ​ຢັດ​ອຸ​ປະ​ກອນ​:

1. ນັກພັດທະນາບາງຄົນບໍ່ຮູ້ວ່າຈໍານວນ microservices ຕ້ອງການ (ຫຼືພຽງແຕ່ບໍ່ໄດ້ລົບກວນ). ບໍ່ມີທາງສໍາລັບພວກເຮົາທີ່ຈະຊອກຫາຄໍາຮ້ອງຂໍທີ່ບໍ່ຖືກຕ້ອງສໍາລັບຊັບພະຍາກອນ - ສໍາລັບນີ້ພວກເຮົາຈໍາເປັນຕ້ອງຮູ້ວ່າການບໍລິໂພກບວກກັບຄໍາຮ້ອງຂໍແລະຂໍ້ຈໍາກັດ. ໃນປັດຈຸບັນພວກເຂົາເບິ່ງ Prometheus metrics, ຕິດຕາມການນໍາໃຊ້ຕົວຈິງແລະປັບການຮ້ອງຂໍແລະຂໍ້ຈໍາກັດ.
2. ແອັບພລິເຄຊັນ JVM ໃຊ້ RAM ຫຼາຍເທົ່າທີ່ພວກເຂົາສາມາດຈັດການໄດ້. ເຄື່ອງເກັບຂີ້ເຫຍື້ອພຽງແຕ່ປ່ອຍຄວາມຊົງຈໍາເມື່ອໃຊ້ຫຼາຍກ່ວາ 75%. ແລະນັບຕັ້ງແຕ່ການບໍລິການສ່ວນໃຫຍ່ມີຄວາມຊົງຈໍາທີ່ແຕກຫັກ, ມັນໄດ້ຖືກຄອບຄອງໂດຍ JVM ສະເຫມີ. ດັ່ງນັ້ນ, ການບໍລິການ Java ທັງຫມົດເຫຼົ່ານີ້ໄດ້ກິນ RAM ຫຼາຍກ່ວາທີ່ຄາດໄວ້.
3. ບາງແອັບພລິເຄຊັນໄດ້ຮ້ອງຂໍຄວາມຈໍາຫຼາຍເກີນໄປ, ແລະຕົວກໍານົດເວລາ Kubernetes ບໍ່ໄດ້ໃຫ້ໂຫນດເຫຼົ່ານີ້ໃຫ້ກັບແອັບພລິເຄຊັນອື່ນ, ເຖິງແມ່ນວ່າໃນຄວາມເປັນຈິງແລ້ວພວກມັນຈະບໍ່ເສຍຄ່າກວ່າໂຫນດອື່ນໆ. ນັກພັດທະນາຄົນຫນຶ່ງໄດ້ເພີ່ມຕົວເລກພິເສດໃນຄໍາຮ້ອງຂໍໂດຍບັງເອີນແລະຈັບເອົາຊິ້ນສ່ວນຂະຫນາດໃຫຍ່ຂອງ RAM: 20 GB ແທນ 2. ບໍ່ມີໃຜສັງເກດເຫັນ. ແອັບພລິເຄຊັນມີ 3 replicas, ດັ່ງນັ້ນຫຼາຍເຖິງ 3 nodes ໄດ້ຮັບຜົນກະທົບ.
4. ພວກ​ເຮົາ​ໄດ້​ນໍາ​ສະ​ເຫນີ​ຂໍ້​ຈໍາ​ກັດ​ຂອງ​ຊັບ​ພະ​ຍາ​ກອນ​, ການ​ຈັດ​ຕາ​ຕະ​ລາງ​ການ pods ກັບ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ທີ່​ຖືກ​ຕ້ອງ​, ແລະ​ໄດ້​ຮັບ​ຄວາມ​ສົມ​ດູນ​ທີ່​ເຫມາະ​ສົມ​ຂອງ​ການ​ນໍາ​ໃຊ້​ຮາດ​ແວ​ໃນ​ທົ່ວ​ທຸກ nodes​. ສອງສາມໂຫນດສາມາດຖືກປິດທັງຫມົດ. ແລະຫຼັງຈາກນັ້ນພວກເຮົາໄດ້ເຫັນວ່າພວກເຮົາມີເຄື່ອງຈັກທີ່ບໍ່ຖືກຕ້ອງ (CPU ຮັດກຸມ, ບໍ່ແມ່ນການຮັດກຸມຫນ່ວຍຄວາມຈໍາ). ພວກເຮົາໄດ້ປ່ຽນປະເພດ ແລະລຶບຫຼາຍໂຫນດເພີ່ມເຕີມ.

ຜົນໄດ້ຮັບ

ດ້ວຍຊັບພະຍາກອນທີ່ສາມາດລະເບີດໄດ້ໃນກຸ່ມ, ທ່ານໃຊ້ຮາດແວທີ່ມີຢູ່ຢ່າງມີປະສິດທິພາບຫຼາຍຂຶ້ນ, ແຕ່ຕົວກໍານົດເວລາ Kubernetes ກໍານົດເວລາ pods ໂດຍອີງໃສ່ການຮ້ອງຂໍສໍາລັບຊັບພະຍາກອນ, ແລະນີ້ແມ່ນ fraught. ເພື່ອຂ້ານົກສອງໂຕດ້ວຍຫີນກ້ອນດຽວ: ເພື່ອຫຼີກເວັ້ນບັນຫາແລະການນໍາໃຊ້ຊັບພະຍາກອນຢ່າງເຕັມທີ່, ທ່ານຈໍາເປັນຕ້ອງມີການຕິດຕາມທີ່ດີ. ນີ້ແມ່ນເຫດຜົນທີ່ມັນຈະເປັນປະໂຫຍດ Kube Eagle (ຜູ້ສົ່ງອອກ Prometheus ແລະ dashboard Grafana).

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