DEVOXX ອັງກິດ. Kubernetes ໃນການຜະລິດ: ການນຳໃຊ້ສີຟ້າ/ສີຂຽວ, ຂະໜາດອັດຕະໂນມັດ ແລະການນຳໃຊ້ອັດຕະໂນມັດ. ພາກທີ 2

Kubernetes ເປັນເຄື່ອງມືທີ່ດີສໍາລັບການແລ່ນ Docker containers ໃນສະພາບແວດລ້ອມການຜະລິດເປັນກຸ່ມ. ຢ່າງໃດກໍຕາມ, ມີບັນຫາທີ່ Kubernetes ບໍ່ສາມາດແກ້ໄຂໄດ້. ສໍາລັບການປະຕິບັດການຜະລິດເລື້ອຍໆ, ພວກເຮົາຕ້ອງການການຕິດຕັ້ງສີຟ້າ / ສີຂຽວແບບອັດຕະໂນມັດຢ່າງເຕັມທີ່ເພື່ອຫຼີກເວັ້ນການ downtime ໃນຂະບວນການ, ເຊິ່ງຍັງຈໍາເປັນຕ້ອງຈັດການກັບການຮ້ອງຂໍ HTTP ພາຍນອກແລະດໍາເນີນການ SSL offloads. ອັນນີ້ຮຽກຮ້ອງໃຫ້ມີການເຊື່ອມໂຍງກັບຕົວດຸ່ນດ່ຽງການໂຫຼດເຊັ່ນ ha-proxy. ສິ່ງທ້າທາຍອີກອັນໜຶ່ງແມ່ນການປັບຂະໜາດເຄິ່ງອັດຕະໂນມັດຂອງກຸ່ມ Kubernetes ຕົວມັນເອງເມື່ອແລ່ນໃນສະພາບແວດລ້ອມຄລາວ, ຕົວຢ່າງເຊັ່ນການປັບຂະໜາດກຸ່ມລົງໃນກາງຄືນບາງສ່ວນ.

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

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

DEVOXX ອັງກິດ. Kubernetes ໃນການຜະລິດ: ການນຳໃຊ້ສີຟ້າ/ສີຂຽວ, ຂະໜາດອັດຕະໂນມັດ ແລະການນຳໃຊ້ອັດຕະໂນມັດ. ພາກທີ 1

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

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

ນີ້ແມ່ນ REST, ດັ່ງນັ້ນທ່ານສາມາດນໍາໃຊ້ພາສາຫຼືເຄື່ອງມືໃດໆເພື່ອເຮັດວຽກກັບ API ນີ້, ແຕ່ຊີວິດຂອງເຈົ້າຈະຖືກເຮັດໃຫ້ງ່າຍຂຶ້ນຫຼາຍໂດຍຫ້ອງສະຫມຸດທີ່ກໍາຫນົດເອງ. ທີມງານຂອງຂ້ອຍຂຽນ 2 ຫ້ອງສະຫມຸດດັ່ງກ່າວ: ຫນຶ່ງສໍາລັບ Java / OSGi ແລະຫນຶ່ງສໍາລັບ Go. ອັນທີສອງບໍ່ໄດ້ຖືກນໍາໃຊ້ເລື້ອຍໆ, ແຕ່ໃນກໍລະນີໃດກໍ່ຕາມ, ທ່ານມີສິ່ງທີ່ເປັນປະໂຫຍດເຫຼົ່ານີ້ຢູ່ໃນການກໍາຈັດຂອງທ່ານ. ພວກເຂົາເປັນໂຄງການ open-source ທີ່ໄດ້ຮັບອະນຸຍາດບາງສ່ວນ. ມີຫຼາຍຫ້ອງສະຫມຸດດັ່ງກ່າວສໍາລັບພາສາທີ່ແຕກຕ່າງກັນ, ດັ່ງນັ້ນທ່ານສາມາດເລືອກທີ່ເຫມາະສົມສໍາລັບເຈົ້າທີ່ສຸດ.

ດັ່ງນັ້ນ, ກ່ອນທີ່ທ່ານຈະເລີ່ມຕົ້ນອັດຕະໂນມັດການນໍາໃຊ້ຂອງທ່ານ, ທ່ານຈໍາເປັນຕ້ອງໃຫ້ແນ່ໃຈວ່າຂະບວນການດັ່ງກ່າວຈະບໍ່ຂຶ້ນກັບເວລາຢຸດໃດໆ. ຕົວຢ່າງ, ທີມງານຂອງພວກເຮົາດໍາເນີນການປະຕິບັດການຜະລິດໃນລະຫວ່າງກາງຂອງມື້ໃນເວລາທີ່ປະຊາຊົນກໍາລັງໃຊ້ຄໍາຮ້ອງສະຫມັກທີ່ສຸດຂອງເຂົາເຈົ້າ, ສະນັ້ນມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຫຼີກເວັ້ນການຊັກຊ້າໃນຂະບວນການນີ້. ເພື່ອຫຼີກເວັ້ນການ downtime, 2 ວິທີການຖືກນໍາໃຊ້: ສີຟ້າ / ສີຂຽວ deployment ຫຼື rolling update. ໃນກໍລະນີສຸດທ້າຍ, ຖ້າທ່ານມີ 5 replicas ຂອງຄໍາຮ້ອງສະຫມັກທີ່ເຮັດວຽກ, ເຂົາເຈົ້າໄດ້ຖືກປັບປຸງຕາມລໍາດັບຫນຶ່ງຫຼັງຈາກທີ່ອື່ນ. ວິທີການນີ້ເຮັດວຽກໄດ້ດີ, ແຕ່ມັນບໍ່ເຫມາະສົມຖ້າຫາກວ່າທ່ານມີສະບັບທີ່ແຕກຕ່າງກັນຂອງຄໍາຮ້ອງສະຫມັກທີ່ເຮັດວຽກພ້ອມໆກັນໃນລະຫວ່າງການຂະບວນການຕິດຕັ້ງ. ໃນກໍລະນີນີ້, ທ່ານສາມາດປັບປຸງສ່ວນຕິດຕໍ່ຜູ້ໃຊ້ໃນຂະນະທີ່ backend ກໍາລັງແລ່ນເວີຊັນເກົ່າ, ແລະແອັບພລິເຄຊັນຈະຢຸດເຮັດວຽກ. ດັ່ງນັ້ນ, ຈາກທັດສະນະຂອງການຂຽນໂປລແກລມ, ການເຮັດວຽກໃນເງື່ອນໄຂດັ່ງກ່າວແມ່ນຂ້ອນຂ້າງຍາກ.

ນີ້ແມ່ນເຫດຜົນອັນໜຶ່ງທີ່ພວກເຮົາມັກນຳໃຊ້ການນຳໃຊ້ສີຟ້າ/ສີຂຽວເພື່ອເຮັດໃຫ້ການນຳໃຊ້ແອັບພລິເຄຊັນຂອງພວກເຮົາເຮັດວຽກໂດຍອັດຕະໂນມັດ. ດ້ວຍວິທີການນີ້, ທ່ານຕ້ອງຮັບປະກັນວ່າພຽງແຕ່ຫນຶ່ງສະບັບຂອງຄໍາຮ້ອງສະຫມັກແມ່ນການເຄື່ອນໄຫວໃນເວລາ.

ກົນໄກການນຳໃຊ້ສີຟ້າ/ສີຂຽວມີລັກສະນະເປັນແບບນີ້. ພວກເຮົາໄດ້ຮັບການຈະລາຈອນສໍາລັບຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາໂດຍຜ່ານ ha-proxy, ເຊິ່ງສົ່ງຕໍ່ມັນໄປສູ່ການດໍາເນີນການ replicas ຂອງຄໍາຮ້ອງສະຫມັກຂອງສະບັບດຽວກັນ.

ເມື່ອມີການຕິດຕັ້ງໃຫມ່, ພວກເຮົາໃຊ້ Deployer, ເຊິ່ງໃຫ້ອົງປະກອບໃຫມ່ແລະນໍາໃຊ້ສະບັບໃຫມ່. ການນຳໃຊ້ແອັບພລິເຄຊັ່ນ ເວີຊັ່ນໃໝ່ ໝາຍຄວາມວ່າຊຸດຂອງແບບຈຳລອງໃໝ່ຖືກ “ຍົກຂຶ້ນມາ”, ຫລັງຈາກນັ້ນ ການຈຳລອງລຸ້ນໃໝ່ເຫຼົ່ານີ້ກໍຖືກເປີດຕົວໃນຝັກໃໝ່. ຢ່າງໃດກໍຕາມ, ha-proxy ບໍ່ຮູ້ຫຍັງກ່ຽວກັບພວກເຂົາແລະບໍ່ໄດ້ສົ່ງວຽກໃດໆໃຫ້ກັບພວກເຂົາເທື່ອ.

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

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

ຫຼັງຈາກລະບົບກວດສອບວ່າການຈໍາລອງທີ່ຖືກປັບປຸງທັງຫມົດເຮັດວຽກ, Deployer ຈະປັບປຸງການຕັ້ງຄ່າແລະຜ່ານ confd ທີ່ຖືກຕ້ອງ, ເຊິ່ງຈະ configure ha-proxy.

ພຽງແຕ່ຫຼັງຈາກນັ້ນການຈະລາຈອນຈະຖືກສົ່ງໄປຫາຝັກທີ່ມີ replicas ຂອງຮຸ່ນໃຫມ່, ແລະຝັກເກົ່າຈະຫາຍໄປ.

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

ຕອນນີ້ຂ້ອຍຈະແນະນໍາທ່ານກ່ຽວກັບອົງປະກອບຂອງການຕິດຕັ້ງໃຫມ່ - Deployer, ເຊິ່ງປະຕິບັດການກວດສອບສຸຂະພາບ, reconfigures proxies, ແລະອື່ນໆ. ນີ້ແມ່ນແນວຄວາມຄິດທີ່ບໍ່ໄດ້ໃຊ້ກັບໂລກພາຍນອກແລະມີຢູ່ໃນ Kubernetes. ຂ້ອຍຈະສະແດງວິທີທີ່ເຈົ້າສາມາດສ້າງແນວຄວາມຄິດ Deployer ຂອງເຈົ້າເອງໂດຍໃຊ້ເຄື່ອງມື open-source.

ດັ່ງນັ້ນ, ສິ່ງທໍາອິດທີ່ Deployer ເຮັດແມ່ນສ້າງຕົວຄວບຄຸມການຈໍາລອງ RC ໂດຍໃຊ້ Kubernetes API. API ນີ້ສ້າງຝັກ ແລະບໍລິການເພື່ອນຳໃຊ້ຕໍ່ໄປ, ນັ້ນແມ່ນ, ມັນສ້າງກຸ່ມໃໝ່ທັງໝົດສຳລັບແອັບພລິເຄຊັນຂອງພວກເຮົາ. ທັນທີທີ່ RC ໝັ້ນໃຈວ່າເຄື່ອງຈຳລອງໄດ້ເລີ່ມຕົ້ນແລ້ວ, ມັນຈະເຮັດການກວດສຸຂະພາບກ່ຽວກັບການເຮັດວຽກຂອງມັນ. ເພື່ອເຮັດສິ່ງນີ້, Deployer ໃຊ້ຄໍາສັ່ງ GET /health. ມັນດໍາເນີນການອົງປະກອບສະແກນທີ່ເຫມາະສົມແລະກວດສອບອົງປະກອບທັງຫມົດທີ່ສະຫນັບສະຫນູນການເຮັດວຽກຂອງກຸ່ມ.

ຫຼັງຈາກ pods ທັງຫມົດໄດ້ລາຍງານສຸຂະພາບຂອງເຂົາເຈົ້າ, Deployer ສ້າງອົງປະກອບການຕັ້ງຄ່າໃຫມ່ - etcd distribution storage, ເຊິ່ງຖືກນໍາໃຊ້ພາຍໃນໂດຍ Kubernetes, ລວມທັງການເກັບຮັກສາ configuration Load balancer. ພວກເຮົາຂຽນຂໍ້ມູນໃສ່ etcd, ແລະເຄື່ອງມືຂະຫນາດນ້ອຍທີ່ເອີ້ນວ່າ confd monitors etcd ສໍາລັບຂໍ້ມູນໃຫມ່.

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

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ເຖິງວ່າຈະມີສ່ວນປະກອບທີ່ອຸດົມສົມບູນ, ບໍ່ມີຫຍັງສັບສົນຢູ່ທີ່ນີ້. ທ່ານພຽງແຕ່ຕ້ອງການເອົາໃຈໃສ່ເພີ່ມເຕີມຕໍ່ກັບ API ແລະ etcd. ຂ້ອຍຢາກບອກເຈົ້າກ່ຽວກັບຕົວຈັດວາງແບບເປີດທີ່ຕົວເຮົາເອງໃຊ້ - Amdatu Kubernetes Deployer .

ມັນ​ເປັນ​ເຄື່ອງ​ມື​ສໍາ​ລັບ​ການ orchestrating ການ​ນໍາ​ໃຊ້ Kubernetes ແລະ​ມີ​ລັກ​ສະ​ນະ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

• ນຳໃຊ້ສີຟ້າ/ສີຂຽວ;
• ການຕັ້ງຄ່າຕົວດຸ່ນດ່ຽງການໂຫຼດພາຍນອກ;
• ການຈັດການ deployment descriptor;
• ການ​ຄຸ້ມ​ຄອງ​ການ​ນໍາ​ໃຊ້​ຕົວ​ຈິງ​;
• ການກວດສອບການເຮັດວຽກຂອງການກວດສຸຂະພາບໃນລະຫວ່າງການປະຕິບັດ;
• ການປະຕິບັດຕົວແປສະພາບແວດລ້ອມເຂົ້າໄປໃນຝັກ.

Deployer ນີ້ຖືກສ້າງຂຶ້ນເທິງ Kubernetes API ແລະສະຫນອງ REST API ສໍາລັບການຈັດການ handles ແລະ deployments, ເຊັ່ນດຽວກັນກັບ Websocket API ສໍາລັບການຖ່າຍທອດບັນທຶກໃນລະຫວ່າງການປະຕິບັດການ.

ມັນເຮັດໃຫ້ຂໍ້ມູນການຕັ້ງຄ່າ load balancer ເຂົ້າໄປໃນ etcd, ດັ່ງນັ້ນທ່ານບໍ່ຈໍາເປັນຕ້ອງໃຊ້ ha-proxy ທີ່ມີການສະຫນັບສະຫນູນນອກກ່ອງ, ແຕ່ໃຊ້ໄຟລ໌ການຕັ້ງຄ່າຕົວດຸ່ນດ່ຽງການໂຫຼດຂອງທ່ານເອງໄດ້ຢ່າງງ່າຍດາຍ. Amdatu Deployer ຖືກຂຽນໄວ້ໃນ Go, ເຊັ່ນ Kubernetes ເອງ, ແລະໄດ້ຮັບອະນຸຍາດຈາກ Apache.

ກ່ອນທີ່ຂ້ອຍຈະເລີ່ມໃຊ້ຕົວ deployer ລຸ້ນນີ້, ຂ້ອຍໃຊ້ຕົວອະທິບາຍການໃຊ້ງານຕໍ່ໄປນີ້, ເຊິ່ງລະບຸຕົວກໍານົດການທີ່ຕ້ອງການ.

ຫນຶ່ງໃນຕົວກໍານົດທີ່ສໍາຄັນຂອງລະຫັດນີ້ແມ່ນເພື່ອເປີດໃຊ້ທຸງ "useHealthCheck". ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ລະບຸວ່າການກວດສອບສຸຂາພິບານຕ້ອງໄດ້ຮັບການປະຕິບັດໃນລະຫວ່າງການຂະບວນການຕິດຕັ້ງ. ການຕັ້ງຄ່ານີ້ສາມາດຖືກປິດໃຊ້ງານໄດ້ເມື່ອການຕິດຕັ້ງໃຊ້ບັນຈຸຂອງພາກສ່ວນທີສາມທີ່ບໍ່ຈໍາເປັນຕ້ອງໄດ້ຮັບການຢັ້ງຢືນ. ຕົວອະທິບາຍນີ້ຍັງຊີ້ບອກຈໍານວນຂອງ replicas ແລະ URL frontend ທີ່ ha-proxy ຕ້ອງການ. ໃນຕອນທ້າຍແມ່ນທຸງສະເພາະຂອງຝັກ "podspec", ເຊິ່ງເອີ້ນ Kubernetes ສໍາລັບຂໍ້ມູນກ່ຽວກັບການຕັ້ງຄ່າພອດ, ຮູບພາບ, ແລະອື່ນໆ. ນີ້ແມ່ນຕົວອະທິບາຍ JSON ທີ່ງ່າຍດາຍພໍສົມຄວນ.

ເຄື່ອງມືອື່ນທີ່ເປັນສ່ວນຫນຶ່ງຂອງໂຄງການ Amdatu open-source ແມ່ນ Deploymentctl. ມັນມີ UI ສໍາລັບການຕັ້ງຄ່າການໃຊ້ງານ, ເກັບຮັກສາປະຫວັດການໃຊ້ງານ, ແລະມີ webhooks ສໍາລັບການ callback ຈາກຜູ້ໃຊ້ພາກສ່ວນທີສາມແລະນັກພັດທະນາ. ທ່ານອາດຈະບໍ່ໃຊ້ UI ນັບຕັ້ງແຕ່ Amdatu Deployer ຕົວຂອງມັນເອງເປັນ REST API, ແຕ່ການໂຕ້ຕອບນີ້ສາມາດເຮັດໃຫ້ການນໍາໃຊ້ງ່າຍຂຶ້ນຫຼາຍສໍາລັບທ່ານໂດຍບໍ່ມີການກ່ຽວຂ້ອງກັບ API ໃດ. Deploymentctl ຖືກຂຽນໄວ້ໃນ OSGi/Vertx ໂດຍໃຊ້ Angular 2.

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

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

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

ສະນັ້ນໃຫ້ເລີ່ມຕົ້ນ. ທໍາອິດ, ພວກເຮົາກວດເບິ່ງການປະກົດຕົວຂອງ pods ໃດໆທີ່ແລ່ນໂດຍໃຊ້ຄໍາສັ່ງ ~ kubectl get pods ແລະ, ໂດຍອີງໃສ່ການບໍ່ມີຄໍາຕອບຈາກ URL ທີ່ຢູ່ດ້ານຫນ້າ, ພວກເຮົາໃຫ້ແນ່ໃຈວ່າບໍ່ມີການນໍາມາໃຊ້ໃນປັດຈຸບັນ.

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

ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ໃນ​ປັດ​ຈຸ​ບັນ​ເຮັດ​ເລ​ື້ມ​ຄືນ​ຄໍາ​ສັ່ງ ~ kubectl ໄດ້​ຮັບ pods​, ທ່ານ​ສາ​ມາດ​ເບິ່ງ​ວ່າ​ລະ​ບົບ "freezes​" ສໍາ​ລັບ 20 ວິ​ນາ​ທີ​, ໃນ​ໄລ​ຍະ​ທີ່ ha-proxy ແມ່ນ reconfigured​. ຫຼັງຈາກນີ້, ຝັກເລີ່ມຕົ້ນ, ແລະການຈໍາລອງຂອງພວກເຮົາສາມາດເຫັນໄດ້ໃນບັນທຶກການນໍາໃຊ້.

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

ຕອນນີ້ໃຫ້ລອງລຸ້ນທີສອງ. ເພື່ອເຮັດສິ່ງນີ້, ຂ້ອຍປ່ຽນຂໍ້ຄວາມຂອງແອັບພລິເຄຊັນຈາກ "ສະບາຍດີ, Kubernetes!" ໃນ "ສະບາຍດີ, Deployer!", ລະບົບຈະສ້າງຮູບພາບນີ້ແລະວາງໄວ້ໃນ Docker registry, ຫຼັງຈາກນັ້ນພວກເຮົາພຽງແຕ່ຄລິກໃສ່ປຸ່ມ "Deploy" ອີກເທື່ອຫນຶ່ງໃນປ່ອງຢ້ຽມ Deploymentctl. ໃນ​ກໍ​ລະ​ນີ​ນີ້​, ບັນ​ທຶກ​ການ​ນໍາ​ໃຊ້​ແມ່ນ​ເປີດ​ອັດ​ຕະ​ໂນ​ມັດ​ໃນ​ວິ​ທີ​ການ​ດຽວ​ກັນ​ທີ່​ມັນ​ເກີດ​ຂຶ້ນ​ໃນ​ເວ​ລາ​ທີ່​ການ​ນໍາ​ໃຊ້​ສະ​ບັບ​ທໍາ​ອິດ​ຂອງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​.

ຄໍາສັ່ງ ~ kubectl get pods ສະແດງໃຫ້ເຫັນວ່າປະຈຸບັນມີ 2 ເວີຊັ່ນຂອງແອັບພລິເຄຊັນທີ່ເຮັດວຽກຢູ່, ແຕ່ frontend ສະແດງໃຫ້ເຫັນວ່າພວກເຮົາຍັງແລ່ນເວີຊັນ 1.

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

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

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ການນຳໃຊ້ໄດ້ຜ່ານຂັ້ນຕອນທັງໝົດຂ້າງເທິງ ແລະ ~kubectl get pods ສະແດງໃຫ້ເຫັນວ່າຝັກທັງສອງກຳລັງແລ່ນຢູ່. ແຕ່ບໍ່ເຫມືອນກັບການນໍາໃຊ້ທີ່ຜ່ານມາ, ບັນທຶກສະແດງໃຫ້ເຫັນສະຖານະການຫມົດເວລາ. ນັ້ນແມ່ນ, ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າການກວດສອບສຸຂະພາບລົ້ມເຫລວ, ຄໍາຮ້ອງສະຫມັກຮຸ່ນໃຫມ່ບໍ່ສາມາດຖືກນໍາໄປໃຊ້. ດັ່ງນັ້ນ, ທ່ານເຫັນວ່າລະບົບໄດ້ກັບຄືນໄປໃຊ້ຄໍາຮ້ອງສະຫມັກສະບັບເກົ່າ, ແລະສະບັບໃຫມ່ພຽງແຕ່ໄດ້ຖືກຖອນການຕິດຕັ້ງ.

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

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

Build Server ຂອງພວກເຮົາຈະສ້າງຮູບພາບ Docker, ຍູ້ມັນເຂົ້າໄປໃນ Docker Hub ຫຼືໃດກໍ່ຕາມທີ່ທ່ານໃຊ້. Docker Hub ຮອງຮັບ webhook, ດັ່ງນັ້ນພວກເຮົາສາມາດເປີດໃຊ້ງານຫ່າງໄກສອກຫຼີກຜ່ານ Deployer ໃນວິທີທີ່ສະແດງຂ້າງເທິງ. ດ້ວຍວິທີນີ້, ທ່ານສາມາດເຮັດໃຫ້ການ ນຳ ໃຊ້ແອັບພລິເຄຊັນຂອງທ່ານໄປສູ່ການຜະລິດທີ່ເປັນໄປໄດ້ໂດຍອັດຕະໂນມັດ.

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

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

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

ດັ່ງນັ້ນພວກເຮົາຈະຕ້ອງໄດ້ດູແລທັງສອງ nodes ແລະ pods. ພວກ​ເຮົາ​ສາ​ມາດ​ປັບ​ຂະ​ຫນາດ​ການ​ເປີດ​ຕົວ​ຂອງ nodes ໃຫມ່​ໄດ້​ຢ່າງ​ງ່າຍ​ດາຍ​ໂດຍ​ການ​ນໍາ​ໃຊ້ AWS API ແລະ​ເຄື່ອງ​ຈັກ​ກຸ່ມ Scaling ເພື່ອ​ກໍາ​ນົດ​ຈໍາ​ນວນ​ຂອງ Kubernetes worker nodes. ທ່ານຍັງສາມາດໃຊ້ cloud-init ຫຼືສະຄິບທີ່ຄ້າຍຄືກັນເພື່ອລົງທະບຽນ nodes ໃນກຸ່ມ Kubernetes.

ເຄື່ອງຈັກໃຫມ່ເລີ່ມຕົ້ນຢູ່ໃນກຸ່ມ Scaling, ເລີ່ມຕົ້ນຕົວຂອງມັນເອງເປັນ node, ລົງທະບຽນຢູ່ໃນທະບຽນຂອງແມ່ບົດແລະເລີ່ມເຮັດວຽກ. ຫຼັງຈາກນີ້, ທ່ານສາມາດເພີ່ມຈໍານວນຂອງ replicas ສໍາລັບການນໍາໃຊ້ໃນ nodes ຜົນໄດ້ຮັບ. ການຂະຫຍາຍຂະຫນາດຕ້ອງໃຊ້ຄວາມພະຍາຍາມຫຼາຍຂຶ້ນ, ເພາະວ່າທ່ານຕ້ອງການໃຫ້ແນ່ໃຈວ່າຂັ້ນຕອນດັ່ງກ່າວບໍ່ໄດ້ນໍາໄປສູ່ການທໍາລາຍຄໍາຮ້ອງສະຫມັກທີ່ເຮັດວຽກຢູ່ແລ້ວຫຼັງຈາກປິດເຄື່ອງທີ່ບໍ່ຈໍາເປັນ. ເພື່ອປ້ອງກັນສະຖານະການດັ່ງກ່າວ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ກໍານົດ nodes ເປັນສະຖານະ "ບໍ່ສາມາດກໍານົດເວລາໄດ້". ນີ້ຫມາຍຄວາມວ່າຕົວກໍານົດເວລາເລີ່ມຕົ້ນຈະບໍ່ສົນໃຈ nodes ເຫຼົ່ານີ້ໃນເວລາທີ່ກໍານົດເວລາ DaemonSet pods. ຕົວກຳນົດເວລາຈະບໍ່ລຶບອັນໃດອອກຈາກເຊີບເວີເຫຼົ່ານີ້, ແຕ່ຍັງຈະບໍ່ເປີດກ່ອງບັນຈຸໃໝ່ຢູ່ທີ່ນັ້ນ. ຂັ້ນ​ຕອນ​ຕໍ່​ໄປ​ແມ່ນ​ການ​ຂັບ​ໄລ່ node ໄດ້​, ນັ້ນ​ແມ່ນ​ການ​ໂອນ pods ແລ່ນ​ຈາກ​ມັນ​ກັບ​ເຄື່ອງ​ອື່ນ​, ຫຼື​ຂໍ້​ອື່ນໆ​ທີ່​ມີ​ຄວາມ​ສາ​ມາດ​ພຽງ​ພໍ​ສໍາ​ລັບ​ການ​ນີ້​. ເມື່ອທ່ານຮັບປະກັນວ່າບໍ່ມີກ່ອງບັນຈຸໃດໆຢູ່ໃນໂນດເຫຼົ່ານີ້, ທ່ານສາມາດເອົາພວກມັນອອກຈາກ Kubernetes ໄດ້. ຫຼັງຈາກນີ້, ພວກມັນພຽງແຕ່ຢຸດຢູ່ສໍາລັບ Kubernetes. ຕໍ່ໄປ, ທ່ານຈໍາເປັນຕ້ອງໃຊ້ AWS API ເພື່ອປິດການໃຊ້ງານ nodes ຫຼືເຄື່ອງຈັກທີ່ບໍ່ຈໍາເປັນ.
ທ່ານສາມາດນໍາໃຊ້ Amdatu Scalerd, ເຄື່ອງມືການຂະຫຍາຍແຫຼ່ງເປີດອື່ນທີ່ຄ້າຍຄືກັນກັບ AWS API. ມັນສະຫນອງ CLI ເພື່ອເພີ່ມຫຼືລຶບ nodes ໃນກຸ່ມ. ຄຸນນະສົມບັດທີ່ຫນ້າສົນໃຈຂອງມັນແມ່ນຄວາມສາມາດໃນການກໍາຫນົດຄ່າຕົວກໍານົດເວລາໂດຍໃຊ້ໄຟລ໌ json ຕໍ່ໄປນີ້.

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

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

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

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

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

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

ບາງໂຄສະນາ🙂

ຂອບໃຈສໍາລັບການຢູ່ກັບພວກເຮົາ. ເຈົ້າມັກບົດຄວາມຂອງພວກເຮົາບໍ? ຕ້ອງການເບິ່ງເນື້ອຫາທີ່ຫນ້າສົນໃຈຫຼາຍບໍ? ສະຫນັບສະຫນູນພວກເຮົາໂດຍການວາງຄໍາສັ່ງຫຼືແນະນໍາໃຫ້ຫມູ່ເພື່ອນ, cloud VPS ສໍາລັບນັກພັດທະນາຈາກ $4.99, ການປຽບທຽບທີ່ເປັນເອກະລັກຂອງເຊີບເວີລະດັບເຂົ້າ, ເຊິ່ງຖືກປະດິດໂດຍພວກເຮົາສໍາລັບທ່ານ: ຄວາມຈິງທັງໝົດກ່ຽວກັບ VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ຈາກ $19 ຫຼືວິທີການແບ່ງປັນເຄື່ອງແມ່ຂ່າຍ? (ສາມາດໃຊ້ໄດ້ກັບ RAID1 ແລະ RAID10, ສູງສຸດ 24 cores ແລະສູງສຸດ 40GB DDR4).

Dell R730xd 2x ລາຄາຖືກກວ່າຢູ່ໃນສູນຂໍ້ມູນ Equinix Tier IV ໃນ Amsterdam? ທີ່ນີ້ເທົ່ານັ້ນ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ຈາກ $199 ໃນປະເທດເນເທີແລນ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ຈາກ $99! ອ່ານກ່ຽວກັບ ວິທີການສ້າງໂຄງສ້າງພື້ນຖານຂອງບໍລິສັດ. ຫ້ອງຮຽນທີ່ມີການນໍາໃຊ້ເຄື່ອງແມ່ຂ່າຍຂອງ Dell R730xd E5-2650 v4 ມູນຄ່າ 9000 ເອີໂຣສໍາລັບເງິນບໍ?

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