ການເປີດຕົວຊ້ໍາໃນ Istio: ບໍລິການລັບ

"ອັນຕະລາຍແມ່ນຊື່ກາງຂອງຂ້ອຍ," Austin Powers, ຜູ້ຊາຍສາກົນທີ່ມີຄວາມລຶກລັບ, ເຄີຍເວົ້າ. ແຕ່ສິ່ງທີ່ຖືຢູ່ໃນຄວາມນັບຖືສູງໂດຍຕົວແທນ super ແລະບໍລິການທາງປັນຍາແມ່ນບໍ່ເຫມາະສົມສໍາລັບການບໍລິການຄອມພິວເຕີ, ບ່ອນທີ່ຄວາມເບື່ອແມ່ນດີກ່ວາອັນຕະລາຍ.

ແລະ Istio, ຮ່ວມກັບ OpenShift ແລະ Kubernetes, ເຮັດໃຫ້ການບໍລິການຈຸລະພາກທີ່ໜ້າເບື່ອ ແລະສາມາດຄາດເດົາໄດ້ຢ່າງແທ້ຈິງ - ແລະນັ້ນກໍ່ດີຫຼາຍ. ພວກເຮົາຈະເວົ້າກ່ຽວກັບເລື່ອງນີ້ແລະຫຼາຍກວ່ານີ້ໃນບົດທີສີ່ແລະສຸດທ້າຍໃນຊຸດ Istio.

ໃນເວລາທີ່ເບື່ອແມ່ນຖືກຕ້ອງ

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

ໃນ​ເວ​ລາ​ທີ່​ການ​ນໍາ​ໃຊ້​ສະ​ບັບ​ໃຫມ່​ຂອງ​ຊອບ​ແວ​ຂອງ​ທ່ານ​, ມັນ​ເປັນ​ການ​ພິ​ຈາ​ລະ​ນາ​ທາງ​ເລືອກ​ທັງ​ຫມົດ​ສໍາ​ລັບ​ການ​ຫຼຸດ​ຜ່ອນ​ຄວາມ​ສ່ຽງ​. ແລ່ນຂະຫນານເປັນວິທີການທົດສອບທີ່ມີປະສິດທິພາບຫຼາຍແລະຖືກພິສູດແລ້ວ, ແລະ Istio ອະນຸຍາດໃຫ້ທ່ານໃຊ້ "ການບໍລິການລັບ" (ສະບັບທີ່ເຊື່ອງໄວ້ຂອງ microservice ຂອງທ່ານ) ເພື່ອເຮັດສິ່ງນີ້ໂດຍບໍ່ມີການແຊກແຊງລະບົບການຜະລິດ. ມີເຖິງແມ່ນວ່າຄໍາສັບພິເສດສໍາລັບການນີ້ - "Dark Launch", ເຊິ່ງໃນທີ່ສຸດແມ່ນ activated ໂດຍຫນ້າທີ່ທີ່ມີຊື່ spy ເທົ່າທຽມກັນ "ການສະທ້ອນການຈະລາຈອນ".

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

ການຈັດລະບຽບເບື່ອແມ່ນຫນ້າສົນໃຈ

ເບິ່ງກົດລະບຽບການກໍານົດເສັ້ນທາງ Istio ຕໍ່ໄປນີ້, ເຊິ່ງສົ່ງເສັ້ນທາງການຮ້ອງຂໍ HTTP ທັງຫມົດໄປຫາຄໍາແນະນໍາ microservice v1 (ຕົວຢ່າງທັງຫມົດທີ່ເອົາມາຈາກ Istio Tutorial GitHub repo), ໃນ​ຂະ​ນະ​ທີ່​ພ້ອມ​ກັນ​ສະ​ທ້ອນ​ໃຫ້​ເຂົາ​ເຈົ້າ​ກັບ​ການ​ແນະ​ນໍາ v2 microservice​:

ເອົາໃຈໃສ່ກັບປ້າຍຊື່ mirror: ຢູ່ລຸ່ມສຸດຂອງຫນ້າຈໍ - ມັນແມ່ນນີ້ກໍານົດການສະທ້ອນການຈະລາຈອນ. ແມ່ນແລ້ວ, ມັນງ່າຍດາຍຫຼາຍ!

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

ໃຫ້ເພີ່ມລະຄອນ

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

ຂໍໃຫ້ເວົ້າຄືນຈຸດສໍາຄັນ

ການເປີດຕົວລັບດ້ວຍການສະທ້ອນສະພາບຈະລາຈອນ (Dark Launch/Request Mirroring) ສາມາດເຮັດໄດ້ໂດຍບໍ່ມີຜົນກະທົບຕໍ່ລະຫັດໃດໆ.

ອາຫານສໍາລັບຄວາມຄິດ

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

ການປະຕິບັດ Canary ໃນ Istio: ເຮັດໃຫ້ການມອບຫມາຍງ່າຍຂຶ້ນ

ລະມັດລະວັງແລະຄ່ອຍໆ

ໂດຍເນື້ອແທ້ແລ້ວຂອງຮູບແບບການນຳໃຊ້ Canary Deployment ແມ່ນງ່າຍດາຍທີ່ສຸດ: ເມື່ອທ່ານເປີດໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມໂປຼແກຼມလွှာอีกด้วย, ທໍາອິດທ່ານໃຫ້ການເຂົ້າເຖິງມັນກັບກຸ່ມຜູ້ໃຊ້ນ້ອຍໆ. ຖ້າທຸກສິ່ງທຸກຢ່າງດີ, ທ່ານຄ່ອຍໆເພີ່ມກຸ່ມນີ້ຈົນກ່ວາຮຸ່ນໃຫມ່ເລີ່ມປະຕິບັດ, ຫຼື - ຖ້າມັນບໍ່ - ໃນທີ່ສຸດກໍ່ຍ້າຍຜູ້ໃຊ້ທັງຫມົດໄປຫາມັນ. ໂດຍການຄິດແລະຄ່ອຍໆແນະນໍາສະບັບໃຫມ່ແລະປ່ຽນຜູ້ໃຊ້ໄປຫາມັນໃນລັກສະນະທີ່ມີການຄວບຄຸມ, ທ່ານສາມາດຫຼຸດຜ່ອນຄວາມສ່ຽງແລະເພີ່ມຄໍາຕິຊົມໄດ້.

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

ການກັ່ນຕອງຂອງຕົວທ່ອງເວັບ

ຫນຶ່ງໃນເງື່ອນໄຂການກໍານົດເສັ້ນທາງທີ່ງ່າຍດາຍທີ່ສຸດແມ່ນການປ່ຽນເສັ້ນທາງທີ່ອີງໃສ່ຕົວທ່ອງເວັບ. ໃຫ້ເວົ້າວ່າທ່ານຕ້ອງການພຽງແຕ່ການຮ້ອງຂໍຈາກຕົວທ່ອງເວັບ Safari ໄປຫາ v2. ນີ້ແມ່ນວິທີທີ່ມັນເຮັດແລ້ວ:

ໃຫ້ໃຊ້ກົດລະບຽບການກໍານົດເສັ້ນທາງນີ້ແລະຫຼັງຈາກນັ້ນນໍາໃຊ້ຄໍາສັ່ງ curl ພວກເຮົາຈະຈໍາລອງການຮ້ອງຂໍທີ່ແທ້ຈິງກັບ microservice ໃນ loop ເປັນ. ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໃນພາບໜ້າຈໍ, ພວກມັນທັງໝົດຈະໄປທີ່ v1:

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

ພະລັງງານບໍ່ຈໍາກັດ

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

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

ປະຕິບັດ Smart

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

ສົນໃຈ?

ທ່ານມີຄວາມກະຕືລືລົ້ນທີ່ຈະທົດລອງກັບ Istio, Kubernetes ແລະ OpenShift ໃນຄອມພິວເຕີຂອງທ່ານບໍ? ທີມງານ ທີມນັກພັດທະນາ Red Hat ການ​ກະ​ກຽມ​ທີ່​ດີ​ເລີດ​ ປື້ມຮຽນ ກ່ຽວກັບຫົວຂໍ້ນີ້ ແລະເຮັດໃຫ້ທຸກໄຟລ໌ທີ່ມາພ້ອມກັບສາທາລະນະ. ສະນັ້ນຈົ່ງສືບຕໍ່ເດີນຫນ້າແລະຢ່າປະຕິເສດຕົວເອງ.
 

Istio Egress: ອອກຈາກຮ້ານຂາຍເຄື່ອງທີ່ລະນຶກ

ໂດຍການນໍາໃຊ້ Istio ຮ່ວມກັບ Red Hat OpenShift ແລະ Kubernetes, ທ່ານສາມາດເຮັດໃຫ້ຊີວິດຂອງທ່ານກັບ microservices ງ່າຍຂຶ້ນຫຼາຍ. ຕາໜ່າງບໍລິການຂອງ Istio ຖືກເຊື່ອງໄວ້ພາຍໃນຝັກ Kubernetes, ແລະລະຫັດຂອງທ່ານເຮັດວຽກ (ສ່ວນຫຼາຍແມ່ນ) ຢູ່ໃນການໂດດດ່ຽວ. ປະສິດທິພາບ, ຄວາມງ່າຍຂອງການປ່ຽນແປງ, ການຕິດຕາມ, ແລະອື່ນໆ – ທັງຫມົດນີ້ແມ່ນງ່າຍທີ່ຈະນໍາໃຊ້ຂໍຂອບໃຈກັບການນໍາໃຊ້ຂອງບັນຈຸ sidecar. ແຕ່ຈະເຮັດແນວໃດຖ້າບໍລິການຈຸລະພາກຂອງທ່ານຕ້ອງການຕິດຕໍ່ສື່ສານກັບບໍລິການອື່ນໆທີ່ຢູ່ນອກລະບົບ OpenShift-Kubernetes ຂອງທ່ານ?

ນີ້ແມ່ນບ່ອນທີ່ Istio Egress ເຂົ້າມາຊ່ວຍ. ໂດຍຫຍໍ້, ມັນພຽງແຕ່ອະນຸຍາດໃຫ້ທ່ານເຂົ້າເຖິງຊັບພະຍາກອນ (ອ່ານ: "ການບໍລິການ") ທີ່ບໍ່ແມ່ນສ່ວນຫນຶ່ງຂອງລະບົບ pods Kubernetes ຂອງທ່ານ. ຖ້າທ່ານບໍ່ປະຕິບັດການຕັ້ງຄ່າເພີ່ມເຕີມ, ການຈະລາຈອນໃນສະພາບແວດລ້ອມ Istio Egress ແມ່ນສົ່ງຜ່ານພຽງແຕ່ພາຍໃນກຸ່ມຂອງຝັກແລະລະຫວ່າງກຸ່ມດັ່ງກ່າວໂດຍອີງໃສ່ຕາຕະລາງ IP ພາຍໃນ. ແລະ pupation ດັ່ງກ່າວເຮັດວຽກໄດ້ດີຕາບໃດທີ່ທ່ານບໍ່ຈໍາເປັນຕ້ອງເຂົ້າເຖິງການບໍລິການຈາກພາຍນອກ.

Egress ອະນຸຍາດໃຫ້ທ່ານຂ້າມຕາຕະລາງ IP ຂ້າງເທິງ, ໂດຍອີງໃສ່ກົດລະບຽບ Egress ຫຼືຢູ່ໃນຂອບເຂດຂອງທີ່ຢູ່ IP.

ໃຫ້ເວົ້າວ່າພວກເຮົາມີໂຄງການ Java ທີ່ເຮັດໃຫ້ຄໍາຮ້ອງຂໍ GET ກັບ httpbin.org/headers.

(httpbin.org ແມ່ນພຽງແຕ່ເປັນຊັບພະຍາກອນທີ່ສະດວກສໍາລັບການທົດສອບການຮ້ອງຂໍການບໍລິການຂາອອກ.)

ຖ້າທ່ານເຂົ້າໄປໃນເສັ້ນຄໍາສັ່ງ curl http://httpbin.org/headers, ພວກເຮົາຈະເຫັນດັ່ງຕໍ່ໄປນີ້:

ຫຼືທ່ານສາມາດເປີດທີ່ຢູ່ດຽວກັນຢູ່ໃນຕົວທ່ອງເວັບ:

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ການບໍລິການທີ່ຕັ້ງຢູ່ທີ່ນັ້ນພຽງແຕ່ສົ່ງຄືນ headers ທີ່ຜ່ານໄປຫາມັນ.

ພວກເຮົາປ່ຽນແທນການນໍາເຂົ້າ

ຕອນນີ້ໃຫ້ເອົາລະຫັດ Java ຂອງການບໍລິການນີ້, ພາຍນອກກັບລະບົບຂອງພວກເຮົາ, ແລະດໍາເນີນການມັນດ້ວຍຕົວເຮົາເອງ, ບ່ອນທີ່, ຈື່, Istio ຖືກຕິດຕັ້ງ. (ທ່ານສາມາດເຮັດສິ່ງນີ້ດ້ວຍຕົນເອງໂດຍການຕິດຕໍ່ ການສອນ Istio ຂອງພວກເຮົາ.) ໄດ້ສ້າງຮູບພາບທີ່ເຫມາະສົມແລະເປີດຕົວໃນເວທີ OpenShift, ພວກເຮົາຈະໂທຫາບໍລິການນີ້ດ້ວຍຄໍາສັ່ງ curl egresshttpbin-istioegress.$(minishift ip).nip.io, ຫຼັງຈາກນັ້ນພວກເຮົາຈະເຫັນມັນຢູ່ໃນຫນ້າຈໍ:

ອຸຍ, ເກີດຫຍັງຂຶ້ນ? ທຸກສິ່ງທຸກຢ່າງພຽງແຕ່ເຮັດວຽກ. ບໍ່ພົບ ໝາຍ ຄວາມວ່າແນວໃດ? ພວກເຮົາພຽງແຕ່ເຮັດມັນສໍາລັບລາວ curl.

ຂະຫຍາຍຕາຕະລາງ IP ໄປສູ່ອິນເຕີເນັດທັງຫມົດ

Istio ຄວນຖືກຕໍາຫນິ (ຫຼືຂອບໃຈ) ສໍາລັບເລື່ອງນີ້. ຫຼັງຈາກທີ່ທັງຫມົດ, Istio ແມ່ນພຽງແຕ່ຕູ້ຄອນເທນເນີ sidecar ທີ່ຮັບຜິດຊອບສໍາລັບການຊອກຄົ້ນຫາແລະເສັ້ນທາງ (ແລະຫຼາຍສິ່ງອື່ນໆທີ່ພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບກ່ອນຫນ້ານີ້). ສໍາລັບເຫດຜົນນີ້, ຕາຕະລາງ IP ພຽງແຕ່ຮູ້ວ່າສິ່ງທີ່ຢູ່ໃນລະບົບ cluster ຂອງທ່ານ. ແລະ httpbin.org ແມ່ນຕັ້ງຢູ່ພາຍນອກແລະດັ່ງນັ້ນຈຶ່ງບໍ່ສາມາດເຂົ້າໄດ້. ແລະນີ້ແມ່ນບ່ອນທີ່ Istio Egress ເຂົ້າມາຊ່ວຍຊີວິດ - ໂດຍບໍ່ມີການປ່ຽນແປງເລັກນ້ອຍຕໍ່ກັບລະຫັດແຫຼ່ງຂອງທ່ານ.

ກົດລະບຽບ Egress ຂ້າງລຸ່ມນີ້ບັງຄັບໃຫ້ Istio ຄົ້ນຫາ (ຖ້າຈໍາເປັນ, ຫຼັງຈາກນັ້ນໃນທົ່ວອິນເຕີເນັດທັງຫມົດ) ສໍາລັບການບໍລິການທີ່ຕ້ອງການ, ໃນກໍລະນີນີ້, httpbin.org. ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້ຈາກໄຟລ໌ນີ້ (egress_httpbin.yml), ການເຮັດວຽກຢູ່ທີ່ນີ້ແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ:

ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນການນໍາໃຊ້ກົດລະບຽບນີ້:

istioctl create -f egress_httpbin.yml -n istioegress

ທ່ານສາມາດເບິ່ງກົດລະບຽບ Egress ດ້ວຍຄໍາສັ່ງ istioctl get egressrules:

ແລະສຸດທ້າຍ, ພວກເຮົາດໍາເນີນການຄໍາສັ່ງອີກເທື່ອຫນຶ່ງ curl - ແລະພວກເຮົາເຫັນວ່າທຸກສິ່ງທຸກຢ່າງເຮັດວຽກ:

ພວກເຮົາຄິດຢ່າງເປີດເຜີຍ

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

ນີ້ແມ່ນການຕອບຫຼ້າສຸດໃນຊຸດໃນ Istio. ຢູ່ tuned - ມີຫຼາຍສິ່ງທີ່ຫນ້າສົນໃຈຢູ່ຂ້າງຫນ້າ!

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