ການສ້າງເວທີ kubernetes ໃນ Pinterest

ໃນໄລຍະປີທີ່ຜ່ານມາ, ຜູ້ໃຊ້ 300 ລ້ານຄົນຂອງ Pinterest ໄດ້ສ້າງຫຼາຍກວ່າ 200 ຕື້ pins ໃນຫຼາຍກວ່າ 4 ຕື້ກະດານ. ເພື່ອຮັບໃຊ້ກອງທັບຂອງຜູ້ຊົມໃຊ້ນີ້ແລະພື້ນຖານເນື້ອໃນທີ່ກວ້າງຂວາງ, ປະຕູໄດ້ພັດທະນາຫລາຍພັນການບໍລິການ, ຕັ້ງແຕ່ microservices ທີ່ສາມາດຈັດການໄດ້ໂດຍ CPUs ຈໍານວນຫນ້ອຍ, ຈົນເຖິງ monoliths ຍັກໃຫຍ່ທີ່ແລ່ນຢູ່ໃນເຄື່ອງຈັກ virtual. ແລະຫຼັງຈາກນັ້ນປັດຈຸບັນໄດ້ມາເມື່ອຕາຂອງບໍລິສັດຕົກຢູ່ໃນ k8s. ເປັນຫຍັງ "cube" ຈຶ່ງເບິ່ງດີໃນ Pinterest? ທ່ານຈະຮຽນຮູ້ກ່ຽວກັບເລື່ອງນີ້ຈາກການແປພາສາຂອງພວກເຮົາຂອງບົດຄວາມທີ່ຜ່ານມາຈາກ blog Pinterest ການປັບປຸງ.

ດັ່ງນັ້ນ, ຫຼາຍຮ້ອຍລ້ານຜູ້ໃຊ້ແລະຫຼາຍຮ້ອຍລ້ານ pins. ເພື່ອຮັບໃຊ້ກອງທັບຂອງຜູ້ຊົມໃຊ້ນີ້ແລະພື້ນຖານເນື້ອໃນທີ່ກວ້າງຂວາງ, ພວກເຮົາໄດ້ພັດທະນາການບໍລິການຫລາຍພັນຄົນ, ຕັ້ງແຕ່ microservices ທີ່ສາມາດຈັດການກັບ CPUs ຈໍານວນຫນ້ອຍ, ຈົນເຖິງ monoliths ຍັກໃຫຍ່ທີ່ແລ່ນຢູ່ໃນເຄື່ອງຈັກ virtual. ນອກຈາກນັ້ນ, ພວກເຮົາມີຫຼາຍໆກອບທີ່ອາດຈະຕ້ອງການ CPU, ຫນ່ວຍຄວາມຈໍາ, ຫຼືການເຂົ້າເຖິງ I/O.

ໃນການຮັກສາສວນສັດຂອງເຄື່ອງມືນີ້, ທີມງານພັດທະນາປະເຊີນກັບສິ່ງທ້າທາຍຈໍານວນຫນຶ່ງ:

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

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

ຮູບທີ 1: ບູລິມະສິດພື້ນຖານໂຄງລ່າງ (ຄວາມໜ້າເຊື່ອຖື, ຜົນຜະລິດຂອງຜູ້ພັດທະນາ ແລະ ປະສິດທິພາບ).

ທີມງານຂອງເວທີການຄຸ້ມຄອງ Cloud ຢູ່ Pinterest ຄົ້ນພົບ K8s ໃນປີ 2017. ໃນເຄິ່ງທໍາອິດຂອງປີ 2017, ພວກເຮົາໄດ້ບັນທຶກຄວາມສາມາດໃນການຜະລິດສ່ວນໃຫຍ່ຂອງພວກເຮົາ, ລວມທັງ API ແລະເຄື່ອງແມ່ຂ່າຍເວັບທັງຫມົດຂອງພວກເຮົາ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາໄດ້ດໍາເນີນການປະເມີນຜົນຢ່າງລະອຽດຂອງລະບົບຕ່າງໆສໍາລັບ orchestrating ການແກ້ໄຂຕູ້ຄອນເທນເນີ, ການສ້າງກຸ່ມແລະເຮັດວຽກກັບພວກມັນ. ໃນທ້າຍປີ 2017, ພວກເຮົາໄດ້ຕັດສິນໃຈໃຊ້ Kubernetes. ມັນຂ້ອນຂ້າງຍືດຫຍຸ່ນແລະໄດ້ຮັບການສະຫນັບສະຫນູນຢ່າງກວ້າງຂວາງໃນຊຸມຊົນນັກພັດທະນາ.

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

Kubernetes: ວິທີ Pinterest

ການເລີ່ມຕົ້ນກັບ Kubernetes ໃນຂະຫນາດຂອງ Pinterest ເປັນເວທີທີ່ວິສະວະກອນຂອງພວກເຮົາມັກແມ່ນມາພ້ອມກັບສິ່ງທ້າທາຍຫຼາຍ.

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

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

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

ຄຸນສົມບັດຜູ້ໃຊ້ Pinterest ແລະຕົວຄວບຄຸມ

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

CRDs ສະຫນອງການທໍາງານດັ່ງຕໍ່ໄປນີ້:

1. ສົມທົບຊັບພະຍາກອນ Kubernetes ພື້ນເມືອງທີ່ແຕກຕ່າງກັນເພື່ອໃຫ້ພວກມັນເຮັດວຽກເປັນວຽກດຽວ. ຕົວຢ່າງເຊັ່ນ, ຊັບພະຍາກອນ PinterestService ປະກອບມີການນໍາໃຊ້, ບໍລິການເຂົ້າສູ່ລະບົບ, ແລະແຜນທີ່ການຕັ້ງຄ່າ. ນີ້ອະນຸຍາດໃຫ້ນັກພັດທະນາບໍ່ຕ້ອງກັງວົນກ່ຽວກັບການຕັ້ງຄ່າ DNS.
2. ປະຕິບັດການສະຫນັບສະຫນູນຄໍາຮ້ອງສະຫມັກທີ່ຈໍາເປັນ. ຜູ້ໃຊ້ຕ້ອງການເນັ້ນໃສ່ສະເພາະຕູ້ຄອນເທນເນີຕາມເຫດຜົນທາງທຸລະກິດຂອງເຂົາເຈົ້າ, ໃນຂະນະທີ່ຕົວຄວບຄຸມ CRD ປະຕິບັດການບັນຈຸ init ທີ່ຈໍາເປັນທັງຫມົດ, ຕົວແປສະພາບແວດລ້ອມແລະຂໍ້ມູນສະເພາະຂອງຝັກ. ນີ້ສະຫນອງລະດັບຄວາມສະດວກສະບາຍທີ່ແຕກຕ່າງກັນໂດຍພື້ນຖານສໍາລັບນັກພັດທະນາ.
3. ຕົວຄວບຄຸມ CRD ຍັງຈັດການວົງຈອນຊີວິດຂອງຊັບພະຍາກອນພື້ນເມືອງ ແລະປັບປຸງການມີໃຫ້ດີບັກ. ນີ້ລວມມີການຄືນດີກັບຂໍ້ມູນສະເພາະທີ່ຕ້ອງການ ແລະຕົວຈິງ, ການປັບປຸງສະຖານະ CRD ແລະການຮັກສາບັນທຶກເຫດການ, ແລະອື່ນໆອີກ. ຖ້າບໍ່ມີ CRD, ນັກພັດທະນາຈະຖືກບັງຄັບໃຫ້ຈັດການຊັບພະຍາກອນຫຼາຍ, ເຊິ່ງພຽງແຕ່ຈະເພີ່ມຄວາມເປັນໄປໄດ້ຂອງຄວາມຜິດພາດ.

ນີ້ແມ່ນຕົວຢ່າງຂອງ PinterestService ແລະຊັບພະຍາກອນພາຍໃນທີ່ຖືກຄຸ້ມຄອງໂດຍຜູ້ຄວບຄຸມຂອງພວກເຮົາ:

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

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

ຂັ້ນຕອນການເຮັດວຽກຂອງແອັບພລິເຄຊັນ

ຮູບພາບຂ້າງເທິງນີ້ສະແດງໃຫ້ເຫັນວິທີການນໍາໃຊ້ຊັບພະຍາກອນ Pinterest ແບບກໍານົດເອງໃຫ້ກັບກຸ່ມ Kubernetes:

1. ນັກພັດທະນາພົວພັນກັບກຸ່ມ Kubernetes ຂອງພວກເຮົາຜ່ານ CLI ແລະສ່ວນຕິດຕໍ່ຜູ້ໃຊ້.
2. ເຄື່ອງມື CLI/UI ດຶງເອົາໄຟລ໌ YAML ການຕັ້ງຄ່າ workflow ແລະຄຸນສົມບັດການກໍ່ສ້າງອື່ນໆ (ID ຮຸ່ນດຽວກັນ) ຈາກ Artifactory ແລະຫຼັງຈາກນັ້ນສົ່ງໃຫ້ເຂົາເຈົ້າກັບການບໍລິການສົ່ງວຽກ. ຂັ້ນຕອນນີ້ຮັບປະກັນວ່າມີພຽງແຕ່ລຸ້ນການຜະລິດເທົ່ານັ້ນທີ່ຖືກສົ່ງໄປຫາກຸ່ມ.
3. JSS ເປັນປະຕູສໍາລັບເວທີຕ່າງໆ, ລວມທັງ Kubernetes. ທີ່ນີ້ຜູ້ໃຊ້ໄດ້ຮັບການພິສູດຢືນຢັນ, ໂຄຕ້າອອກແລະການຕັ້ງຄ່າ CRD ຂອງພວກເຮົາຖືກກວດສອບບາງສ່ວນ.
4. ຫຼັງຈາກການກວດສອບ CRD ໃນດ້ານ JSS, ຂໍ້ມູນຖືກສົ່ງໄປຫາ API ແພລະຕະຟອມ k8s.
5. ຕົວຄວບຄຸມ CRD ຂອງພວກເຮົາຕິດຕາມເຫດການໃນຊັບພະຍາກອນຜູ້ໃຊ້ທັງຫມົດ. ມັນປ່ຽນ CRs ເຂົ້າໄປໃນຊັບພະຍາກອນ k8s ພື້ນເມືອງ, ເພີ່ມໂມດູນທີ່ຈໍາເປັນ, ກໍານົດຕົວແປສະພາບແວດລ້ອມທີ່ເຫມາະສົມ, ແລະປະຕິບັດວຽກງານສະຫນັບສະຫນູນອື່ນໆເພື່ອຮັບປະກັນຄໍາຮ້ອງສະຫມັກຂອງຜູ້ໃຊ້ທີ່ບັນຈຸມີໂຄງສ້າງພື້ນຖານພຽງພໍ.
6. ຫຼັງຈາກນັ້ນ, ຕົວຄວບຄຸມ CRD ຈະສົ່ງຂໍ້ມູນທີ່ໄດ້ຮັບໄປຫາ Kubernetes API ເພື່ອໃຫ້ມັນສາມາດຖືກປຸງແຕ່ງໂດຍຜູ້ກໍານົດເວລາແລະໃສ່ໃນການຜະລິດ.

Примечание: ຂັ້ນຕອນການເຮັດວຽກກ່ອນການປ່ອຍຕົວນີ້ຂອງການຕິດຕັ້ງໄດ້ຖືກສ້າງຂື້ນສໍາລັບຜູ້ໃຊ້ທໍາອິດຂອງແພລະຕະຟອມ k8s ໃຫມ່. ໃນປັດຈຸບັນພວກເຮົາຢູ່ໃນຂະບວນການປັບປຸງຂະບວນການນີ້ເພື່ອປະສົມປະສານຢ່າງເຕັມສ່ວນກັບ CI / CD ໃຫມ່ຂອງພວກເຮົາ. ນີ້ຫມາຍຄວາມວ່າພວກເຮົາບໍ່ສາມາດບອກທ່ານທຸກຢ່າງທີ່ກ່ຽວຂ້ອງກັບ Kubernetes. ພວກເຮົາຫວັງວ່າຈະແບ່ງປັນປະສົບການຂອງພວກເຮົາແລະຄວາມກ້າວຫນ້າຂອງທີມງານໃນທິດທາງນີ້ໃນການຕອບ blog ຂອງພວກເຮົາຕໍ່ໄປ, "ການສ້າງເວທີ CI / CD ສໍາລັບ Pinterest."

ປະເພດຂອງຊັບພະຍາກອນພິເສດ

ອີງຕາມຄວາມຕ້ອງການສະເພາະຂອງ Pinterest, ພວກເຮົາໄດ້ພັດທະນາ CRDs ຕໍ່ໄປນີ້ເພື່ອໃຫ້ເຫມາະສົມກັບຂະບວນການເຮັດວຽກທີ່ແຕກຕ່າງກັນ:

• PinterestService ແມ່ນການບໍລິການທີ່ບໍ່ມີລັດທີ່ເຮັດວຽກເປັນເວລາດົນນານ. ຫຼາຍລະບົບຫຼັກຂອງພວກເຮົາແມ່ນອີງໃສ່ຊຸດຂອງການບໍລິການດັ່ງກ່າວ.
• PinterestJobSet ແບບຈໍາລອງວຽກ batch ວົງຈອນເຕັມ. ສະຖານະການທົ່ວໄປໃນ Pinterest ແມ່ນວ່າຫຼາຍວຽກດໍາເນີນການບັນຈຸດຽວກັນໃນຂະຫນານ, ບໍ່ວ່າຈະເປັນຂະບວນການທີ່ຄ້າຍຄືກັນອື່ນໆ.
• PinterestCronJob ຖືກນໍາໃຊ້ຢ່າງກວ້າງຂວາງໂດຍສົມທົບກັບການໂຫຼດແຕ່ລະໄລຍະຂະຫນາດນ້ອຍ. ນີ້ແມ່ນ wrapper ສໍາລັບການເຮັດວຽກ cron native ກັບກົນໄກສະຫນັບສະຫນູນ Pinterest ທີ່ຮັບຜິດຊອບຄວາມປອດໄພ, ການຈະລາຈອນ, ບັນທຶກແລະ metrics.
• PinterestDaemon ປະກອບມີ Daemon ໂຄງສ້າງພື້ນຖານ. ຄອບຄົວນີ້ຍັງສືບຕໍ່ຂະຫຍາຍຕົວຍ້ອນວ່າພວກເຮົາເພີ່ມການສະຫນັບສະຫນູນເພີ່ມເຕີມຕໍ່ກັບກຸ່ມຂອງພວກເຮົາ.
• PinterestTrainingJob ຂະຫຍາຍໄປສູ່ຂະບວນການ Tensorflow ແລະ Pytorg, ສະຫນອງການສະຫນັບສະຫນູນລະດັບດຽວກັນກັບ runtime ທັງຫມົດ CRDs ອື່ນໆ. ນັບຕັ້ງແຕ່ Pinterest ໃຊ້ Tensorflow ແລະລະບົບການຮຽນຮູ້ເຄື່ອງຈັກອື່ນໆຢ່າງຈິງຈັງ, ພວກເຮົາມີເຫດຜົນທີ່ຈະສ້າງ CRD ແຍກຕ່າງຫາກປະມານພວກມັນ.

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

ຮອງຮັບເວລາແລ່ນ

ເມື່ອພອດແອັບພລິເຄຊັນເຮັດວຽກຢູ່ໃນ Kubernetes, ມັນຈະໄດ້ຮັບໃບຢັ້ງຢືນອັດຕະໂນມັດເພື່ອລະບຸຕົວຕົນ. ໃບຮັບຮອງນີ້ແມ່ນໃຊ້ເພື່ອເຂົ້າເຖິງບ່ອນເກັບຂໍ້ມູນລັບ ຫຼືເພື່ອຕິດຕໍ່ສື່ສານກັບການບໍລິການອື່ນຜ່ານ mTLS. ໃນຂະນະດຽວກັນ, Container Init Configurator ແລະ Daemon ຈະດາວໂຫລດທຸກ dependencies ທີ່ຈໍາເປັນກ່ອນທີ່ຈະດໍາເນີນການຄໍາຮ້ອງສະຫມັກ containerized. ເມື່ອທຸກຢ່າງພ້ອມແລ້ວ, ລົດດ້ານການຈະລາຈອນ ແລະ Daemon ຈະລົງທະບຽນທີ່ຢູ່ IP ຂອງໂມດູນກັບ Zookeeper ຂອງພວກເຮົາເພື່ອໃຫ້ລູກຄ້າສາມາດຄົ້ນພົບມັນໄດ້. ທັງໝົດນີ້ຈະເຮັດວຽກໄດ້ເພາະວ່າໂມດູນເຄືອຂ່າຍຖືກຕັ້ງຄ່າກ່ອນທີ່ແອັບພລິເຄຊັນຈະເປີດຕົວ.

ຂ້າງເທິງນີ້ແມ່ນຕົວຢ່າງປົກກະຕິຂອງການສະຫນັບສະຫນູນ runtime ສໍາລັບ workloads. ປະເພດອື່ນໆຂອງວຽກອາດຈະຕ້ອງການການສະຫນັບສະຫນູນທີ່ແຕກຕ່າງກັນເລັກນ້ອຍ, ແຕ່ພວກມັນທັງຫມົດມາໃນຮູບແບບຂອງ pod-level sidecars, node-level ຫຼື virtual machine-level Daemons. ພວກເຮົາຮັບປະກັນວ່າສິ່ງທັງ ໝົດ ນີ້ຖືກ ນຳ ໃຊ້ພາຍໃນໂຄງສ້າງພື້ນຖານການຄຸ້ມຄອງແລະມີຄວາມສອດຄ່ອງໃນທົ່ວແອັບພລິເຄຊັນ, ເຊິ່ງໃນທີ່ສຸດຈະຊ່ວຍຫຼຸດຜ່ອນພາລະໃນດ້ານເຕັກນິກແລະການສະ ໜັບ ສະ ໜູນ ລູກຄ້າ.

ການທົດສອບແລະ QA

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

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

ທາງເລືອກ

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

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

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

ວຽກທີ່ຈະມາເຖິງ

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

• ຄໍເລັກຊັນຂອງກຸ່ມແຈກຢາຍຄໍາຮ້ອງສະຫມັກຂະຫນາດໃຫຍ່ໃນທົ່ວກຸ່ມທີ່ແຕກຕ່າງກັນເພື່ອການຂະຫຍາຍແລະຄວາມຫມັ້ນຄົງ.
• ຮັບປະກັນຄວາມໝັ້ນຄົງຂອງກຸ່ມ, ການຂະຫຍາຍ ແລະ ການເບິ່ງເຫັນເພື່ອສ້າງການເຊື່ອມຕໍ່ແອັບພລິເຄຊັນ ແລະ SLAs.
• ການຄຸ້ມຄອງຊັບພະຍາກອນແລະໂຄຕ້າເພື່ອໃຫ້ຄໍາຮ້ອງສະຫມັກບໍ່ຂັດແຍ້ງກັບກັນແລະກັນ, ແລະຂະຫນາດຂອງກຸ່ມຖືກຄວບຄຸມຢູ່ໃນສ່ວນຂອງພວກເຮົາ.
• ແພລດຟອມ CI/CD ໃໝ່ສຳລັບການຮອງຮັບ ແລະນຳໃຊ້ແອັບພລິເຄຊັນເທິງ Kubernetes.

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