ຊຸດຂອງຂໍ້ຄວາມກ່ຽວກັບ Istio Service Mesh

ພວກເຮົາກໍາລັງເລີ່ມຕົ້ນຊຸດຂໍ້ຄວາມທີ່ສະແດງໃຫ້ເຫັນບາງຄວາມສາມາດຂອງ Istio Service Mesh ເມື່ອລວມກັບ Red Hat OpenShift ແລະ Kubernetes.

ສ່ວນ​ຫນຶ່ງ​, ມື້​ນີ້​:

• ໃຫ້ອະທິບາຍແນວຄວາມຄິດຂອງຖັງລົດຂ້າງ Kubernetes ແລະສ້າງຮູບແບບຂອງຫົວຂໍ້ນີ້: "ທ່ານບໍ່ຈໍາເປັນຕ້ອງປ່ຽນຫຍັງໃນລະຫັດຂອງທ່ານ".
• ໃຫ້ແນະນໍາສິ່ງພື້ນຖານຂອງ Istio - routing rules . ຄຸນສົມບັດ Istio ອື່ນໆທັງຫມົດແມ່ນສ້າງຂຶ້ນໃນພວກມັນ, ເພາະວ່າມັນເປັນກົດລະບຽບທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດສົ່ງການຈະລາຈອນໄປຫາ microservices ໂດຍກົງ, ການນໍາໃຊ້ໄຟລ໌ YAML ພາຍນອກລະຫັດການບໍລິການ. ພວກເຮົາກຳລັງພິຈາລະນາໂຄງການນຳໃຊ້ Canary Deployment. ໂບນັດປີໃໝ່ – 10 ບົດຮຽນແບບໂຕ້ຕອບໃນ Istio

ພາກ​ທີ​ສອງ​, ໃນ​ໄວໆ​ນີ້​, ຈະ​ບອກ​ທ່ານ​:

• Istio ປະຕິບັດວິທີ Pool Ejection ໃນການປະສົມປະສານກັບ Circuit Breaker ແລະຈະສະແດງໃຫ້ເຫັນວິທີການ Istio ອະນຸຍາດໃຫ້ທ່ານເອົາຝັກທີ່ຕາຍແລ້ວຫຼືປະຕິບັດບໍ່ດີອອກຈາກວົງຈອນການດຸ່ນດ່ຽງ.
• ພວກເຮົາຍັງຈະເບິ່ງຫົວຂໍ້ Circuit Breaker ຈາກຫົວຂໍ້ທໍາອິດເພື່ອເບິ່ງວ່າ Istio ສາມາດນໍາໃຊ້ໄດ້ທີ່ນີ້. ພວກເຮົາຈະສະແດງໃຫ້ທ່ານເຫັນວິທີເສັ້ນທາງການຈະລາຈອນແລະຈັດການກັບຄວາມຜິດພາດຂອງເຄືອຂ່າຍໂດຍໃຊ້ໄຟລ໌ການຕັ້ງຄ່າ YAML ແລະຄໍາສັ່ງ terminal ໂດຍບໍ່ມີການປ່ຽນແປງເລັກນ້ອຍໃນລະຫັດການບໍລິການ.

ພາກ​ທີ​ສາມ​:

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

ສຸດທ້າຍ, ໃນການຕອບສຸດທ້າຍກ່ຽວກັບ Istio Service Mesh:

• ໃຫ້ໄປຂ້າງຊ້ໍາ. ຫຼາຍທີ່ຊັດເຈນ, ພວກເຮົາຈະຮຽນຮູ້ການນໍາໃຊ້ໂຄງການ Dark Launch, ເມື່ອລະຫັດຖືກນໍາໄປໃຊ້ແລະທົດສອບຂໍ້ມູນການຜະລິດໂດຍກົງ, ແຕ່ບໍ່ມີຜົນຕໍ່ການເຮັດວຽກຂອງລະບົບໃນທາງໃດກໍ່ຕາມ. ນີ້ແມ່ນບ່ອນທີ່ຄວາມສາມາດຂອງ Istio ໃນການແບ່ງປັນການຈະລາຈອນມາສະດວກ. ແລະຄວາມສາມາດໃນການທົດສອບຂໍ້ມູນການຜະລິດສົດໂດຍບໍ່ມີຜົນກະທົບຕໍ່ການດໍາເນີນງານຂອງລະບົບການຕໍ່ສູ້ໃນທາງໃດກໍ່ຕາມແມ່ນວິທີການກວດສອບທີ່ຫນ້າເຊື່ອຖືທີ່ສຸດ.
• ການກໍ່ສ້າງໃນ Dark Launch, ພວກເຮົາຈະສະແດງໃຫ້ທ່ານເຫັນວິທີການນໍາໃຊ້ຕົວແບບ Canary Deployment ເພື່ອຫຼຸດຜ່ອນຄວາມສ່ຽງແລະເຮັດໃຫ້ມັນງ່າຍຂຶ້ນທີ່ຈະໄດ້ຮັບລະຫັດໃຫມ່ໃນການຜະລິດ. Canary Deployment ຕົວຂອງມັນເອງແມ່ນຢູ່ໄກຈາກໃຫມ່, ແຕ່ Istio ອະນຸຍາດໃຫ້ທ່ານປະຕິບັດໂຄງການນີ້ດ້ວຍໄຟລ໌ YAML ງ່າຍດາຍ.
• ສຸດທ້າຍ, ພວກເຮົາຈະສະແດງວິທີການນໍາໃຊ້ Istio Egress ເພື່ອໃຫ້ການເຂົ້າເຖິງການບໍລິການແກ່ຜູ້ທີ່ຢູ່ນອກກຸ່ມຂອງທ່ານເພື່ອນໍາໃຊ້ຄວາມສາມາດຂອງ Istio ໃນເວລາທີ່ເຮັດວຽກກັບອິນເຕີເນັດ.

ດັ່ງນັ້ນ, ພວກເຮົາໄປ ...

ເຄື່ອງມືການຕິດຕາມ ແລະການຄຸ້ມຄອງ Istio - ທຸກຢ່າງທີ່ເຈົ້າຕ້ອງການເພື່ອຈັດຕັ້ງການບໍລິການຈຸນລະພາກໃນຕາໜ່າງບໍລິການ ຕາຫນ່າງການບໍລິການ.

Istio Service Mesh ແມ່ນຫຍັງ

ຕາຫນ່າງການບໍລິການປະຕິບັດຫນ້າທີ່ເຊັ່ນ: ການຕິດຕາມການຈະລາຈອນ, ການຄວບຄຸມການເຂົ້າເຖິງ, ການຄົ້ນພົບ, ຄວາມປອດໄພ, ຄວາມທົນທານຕໍ່ຄວາມຜິດພາດແລະສິ່ງທີ່ເປັນປະໂຫຍດອື່ນໆສໍາລັບກຸ່ມບໍລິການ. Istio ອະນຸຍາດໃຫ້ທ່ານເຮັດສິ່ງທັງຫມົດນີ້ໂດຍບໍ່ມີການປ່ຽນແປງເລັກນ້ອຍຕໍ່ກັບລະຫັດຂອງການບໍລິການຂອງຕົນເອງ. ຄວາມລັບຂອງ magic ແມ່ນຫຍັງ? Istio ຄັດຕິດຕົວແທນຂອງຕົນເອງໃຫ້ກັບແຕ່ລະບໍລິການໃນຮູບແບບຂອງຕູ້ຄອນເທນເນີ sidecar (sidecar ແມ່ນ sidecar ລົດຈັກ), ຫຼັງຈາກນັ້ນການຈະລາຈອນທັງຫມົດໄປຫາບໍລິການນີ້ຜ່ານຕົວແທນ, ເຊິ່ງ, ນໍາພາໂດຍນະໂຍບາຍທີ່ກໍານົດ, ຕັດສິນໃຈແນວໃດ, ເວລາໃດແລະການຈະລາຈອນນີ້. ຄວນຈະເຂົ້າເຖິງການບໍລິການທັງຫມົດ. Istio ຍັງເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະປະຕິບັດເຕັກນິກ DevOps ຂັ້ນສູງເຊັ່ນ: ການຕິດຕັ້ງ canary, breakers circuit, fault injection ແລະອື່ນໆຈໍານວນຫຼາຍ.

Istio ເຮັດວຽກແນວໃດກັບ containers ແລະ Kubernetes

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

ອີງຕາມຮູບແບບ sidecar, Istio ແລ່ນຢູ່ໃນຖັງ Linux, ເຊິ່ງຕັ້ງຢູ່ໃນຫນຶ່ງ Kubernetes-pod ທີ່ມີການບໍລິການຄວບຄຸມແລະ injects ແລະສະກັດການທໍາງານແລະຂໍ້ມູນຕາມການຕັ້ງຄ່າທີ່ໃຫ້. ພວກເຮົາເນັ້ນຫນັກວ່ານີ້ແມ່ນການຕັ້ງຄ່າຂອງທ່ານເອງ, ແລະມັນຢູ່ນອກລະຫັດຂອງທ່ານ. ດັ່ງນັ້ນ, ລະຫັດກາຍເປັນງ່າຍດາຍແລະສັ້ນກວ່າ.

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

ຕາໜ່າງບໍລິການ

Istio, ເຊິ່ງປະຕິບັດຫນ້າທີ່ສໍາລັບການຄຸ້ມຄອງບໍລິການຈຸລະພາກນອກລະຫັດຂອງພວກເຂົາ, ແມ່ນແນວຄວາມຄິດຂອງ Service Mesh. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ມັນເປັນກຸ່ມປະສານງານຂອງຫນຶ່ງຫຼືຫຼາຍຄູ່ທີ່ປະກອບເປັນຕາຫນ່າງຂອງຫນ້າທີ່ເຄືອຂ່າຍ.

Istio ເຮັດວຽກແນວໃດກັບບໍລິການຈຸລະພາກ

ນີ້​ແມ່ນ​ສິ່ງ​ທີ່​ການ​ເຮັດ​ວຽກ​ຂອງ​ການ​ບັນ​ຈຸ sidecar ເບິ່ງ​ຄື​ກັບ​ການ​ຮ່ວມ​ກັບ Kubernetes и ຫຼຸດໜ້ອຍລົງ bird's eye view: ເປີດຕົວຢ່າງຂອງ Minishift, ສ້າງໂຄງການສໍາລັບ Istio (ໃຫ້ເອີ້ນວ່າ "ລະບົບ istio"), ຕິດຕັ້ງແລະດໍາເນີນການອົງປະກອບທີ່ກ່ຽວຂ້ອງກັບ Istio. ຫຼັງຈາກນັ້ນ, ເມື່ອທ່ານສ້າງໂຄງການແລະ pods, ທ່ານເພີ່ມຂໍ້ມູນການຕັ້ງຄ່າໃນການນໍາໃຊ້ຂອງທ່ານ, ແລະ pods ຂອງທ່ານເລີ່ມໃຊ້ Istio. ແຜນວາດທີ່ງ່າຍດາຍເບິ່ງຄືດັ່ງນີ້:

ໃນປັດຈຸບັນທ່ານສາມາດປ່ຽນການຕັ້ງຄ່າ Istio ໃນຄໍາສັ່ງ, ສໍາລັບການຍົກຕົວຢ່າງ, ການຈັດລະບຽບການສັກຢາຄວາມຜິດ, ສະຫນັບສະຫນູນ ການນຳໃຊ້ Canary ຫຼືຄຸນສົມບັດ Istio ອື່ນໆ - ແລະທັງຫມົດນີ້ໂດຍບໍ່ມີການສໍາຜັດກັບລະຫັດຂອງຄໍາຮ້ອງສະຫມັກດ້ວຍຕົນເອງ. ໃຫ້ເວົ້າວ່າທ່ານຕ້ອງການປ່ຽນເສັ້ນທາງເວັບໄຊທ໌ທັງຫມົດຈາກຜູ້ໃຊ້ຂອງລູກຄ້າທີ່ໃຫຍ່ທີ່ສຸດຂອງທ່ານ (Foo Corporation) ໄປຫາເວັບໄຊທ໌ໃຫມ່. ເພື່ອເຮັດສິ່ງນີ້, ພຽງແຕ່ສ້າງກົດລະບຽບການກໍານົດເສັ້ນທາງ Istio ທີ່ຈະຊອກຫາ @foocorporation.com ໃນ ID ຜູ້ໃຊ້ແລະປ່ຽນເສັ້ນທາງຕາມຄວາມເຫມາະສົມ. ສໍາລັບຜູ້ໃຊ້ອື່ນໆທັງຫມົດ, ບໍ່ມີຫຍັງຈະປ່ຽນແປງ. ໃນເວລານີ້, ທ່ານຈະທົດສອບສະບັບໃຫມ່ຂອງເວັບໄຊທ໌ຢ່າງງຽບໆ. ແລະສັງເກດວ່າທ່ານບໍ່ຈໍາເປັນຕ້ອງມີສ່ວນຮ່ວມກັບນັກພັດທະນາທັງຫມົດສໍາລັບການນີ້.

ແລະເຈົ້າຈະຕ້ອງຈ່າຍເງິນຫຼາຍບໍ?

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

ອາຈານເອງ

ທີມງານປະສົບການນັກພັດທະນາ Red Hat ໄດ້ພັດທະນາແບບເຈາະເລິກ ຄູ່ມື ໂດຍ Istio (ໃນພາສາອັງກິດ). ມັນເຮັດວຽກຢູ່ໃນ Linux, MacOS ແລະ Windows, ແລະລະຫັດແມ່ນມີຢູ່ໃນ Java ແລະ Node.js.

10 ບົດຮຽນການໂຕ້ຕອບກ່ຽວກັບ Istio

ຕັນ 1 - ສໍາລັບຜູ້ເລີ່ມຕົ້ນ

ການແນະນໍາ Istio
30 ນາທີ
ມາຮູ້ຈັກກັບ Service Mesh, ຮຽນຮູ້ວິທີຕິດຕັ້ງ Istio ໃນກຸ່ມ OpenShift Kubernetes.
ເລີ່ມຕົ້ນ

ນຳໃຊ້ບໍລິການຈຸລະພາກໃນ Istio
30 ນາທີ
ພວກເຮົາໃຊ້ Istio ເພື່ອນຳໃຊ້ສາມ microservices ກັບ Spring Boot ແລະ Vert.x.
ເລີ່ມຕົ້ນ

ຕັນ 2 - ລະດັບປານກາງ

ການ​ຕິດ​ຕາມ​ແລະ​ການ​ຕິດ​ຕາມ​ໃນ Istio​
60 ນາທີ
ພວກເຮົາຈະຄົ້ນຫາເຄື່ອງມືຕິດຕາມທີ່ສ້າງຂຶ້ນໃນຕົວຂອງ Istio, ວັດແທກແບບກຳນົດເອງ ແລະ OpenTracing ຜ່ານ Prometheus ແລະ Grafana.
ເລີ່ມຕົ້ນ

ເສັ້ນທາງທີ່ງ່າຍດາຍໃນ Istio
60 ນາທີ
ຮຽນຮູ້ວິທີການຈັດການເສັ້ນທາງໃນ Istio ໂດຍໃຊ້ກົດລະບຽບງ່າຍໆ.
ເລີ່ມຕົ້ນ

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

ຕັນ 3 - ຜູ້ໃຊ້ຂັ້ນສູງ

Fault Injection ໃນ Istio
60 ນາທີ
ພວກເຮົາສຶກສາສະຖານະການການຈັດການຄວາມລົ້ມເຫລວໃນແອັບພລິເຄຊັນທີ່ແຈກຢາຍ, ການສ້າງຂໍ້ຜິດພາດ HTTP ແລະຄວາມລ່າຊ້າຂອງເຄືອຂ່າຍ, ແລະຮຽນຮູ້ທີ່ຈະໃຊ້ວິສະວະກໍາ chaos ເພື່ອຟື້ນຟູສະພາບແວດລ້ອມ.
ເລີ່ມຕົ້ນ

Circuit Breaker ໃນ Istio
30 ນາທີ
ພວກເຮົາຕິດຕັ້ງ Siege ສໍາລັບສະຖານທີ່ທົດສອບຄວາມກົດດັນແລະຮຽນຮູ້ວິທີການຮັບປະກັນຄວາມທົນທານຕໍ່ຄວາມຜິດພາດຂອງ backend ໂດຍໃຊ້ replays, circuit breaker ແລະ pool ejection.
ເລີ່ມຕົ້ນ

Egress ແລະ Istio
10 ນາທີ
ພວກເຮົາໃຊ້ເສັ້ນທາງ Egress ເພື່ອສ້າງກົດລະບຽບສໍາລັບການໂຕ້ຕອບຂອງການບໍລິການພາຍໃນກັບ APIs ແລະການບໍລິການພາຍນອກ.
ເລີ່ມຕົ້ນ

Istio ແລະ Kiali
15 ນາທີ
ຮຽນ​ຮູ້​ທີ່​ຈະ​ນໍາ​ໃຊ້ Kiali ເພື່ອ​ໄດ້​ຮັບ​ສະ​ພາບ​ລວມ​ຂອງ​ຕາ​ຫນ່າງ​ການ​ບໍ​ລິ​ການ​ແລະ​ສໍາ​ຫຼວດ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ແລະ​ການ​ໄຫຼ​ຂອງ​ຂໍ້​ມູນ​.
ເລີ່ມຕົ້ນ

TLS ເຊິ່ງກັນແລະກັນໃນ Istio
15 ນາທີ
ພວກເຮົາສ້າງ Istio Gateway ແລະ VirtualService, ຫຼັງຈາກນັ້ນພວກເຮົາສຶກສາ TLS ເຊິ່ງກັນແລະກັນ (mTLS) ແລະການຕັ້ງຄ່າຂອງມັນຢ່າງລະອຽດ.
ເລີ່ມຕົ້ນ

Block 3.1 - Deep Dive: Istio Service Mesh ສໍາລັບ Microservices

ຫນັງ​ສື​ກ່ຽວ​ກັບ​ຫຍັງ​:

• ຕາໜ່າງບໍລິການແມ່ນຫຍັງ?
• ລະບົບ Istio ແລະບົດບາດຂອງມັນໃນສະຖາປັດຕະຍະກໍາຈຸລະພາກ.
• ການນໍາໃຊ້ Istio ເພື່ອແກ້ໄຂບັນຫາຕໍ່ໄປນີ້:
  • ຄວາມທົນທານຕໍ່ຄວາມຜິດພາດ;
  • ເສັ້ນທາງ;
  • ການທົດສອບຄວາມວຸ່ນວາຍ;
  • ການຮັກສາຄວາມປອດໄພ
  • ການ​ເກັບ​ກໍາ Telemetry ການ​ນໍາ​ໃຊ້​ຕາມ​ຮອຍ​, metrics ແລະ Grafana​.

ເພື່ອດາວໂຫລດປຶ້ມ

ຊຸດຂອງບົດຄວາມກ່ຽວກັບຕາຫນ່າງການບໍລິການແລະ Istio

• ກົດລະບຽບການກໍານົດເສັ້ນທາງ Istio: ຊີ້ນໍາການຮ້ອງຂໍການບໍລິການບ່ອນທີ່ພວກເຂົາຕ້ອງການໄປ
• Circuit Breakers ໃນ Isio: ການຈັດການ Pool Ejection
• Circuit Breaker ໃນ Istio: ເມື່ອຄວາມລົ້ມເຫຼວແມ່ນທາງເລືອກ
• ການ​ຕິດ​ຕາມ​ແລະ​ຕິດ​ຕາມ​ກວດ​ກາ​ໃນ Istio​: ບ່ອນ​ທີ່​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ແມ່ນ​ການ​ເຄື່ອນ​ໄຫວ​ແລະ​ໄວ​ປານ​ໃດ​
• ວິສະວະກໍາ Chaos ໃນ Istio: ນັ້ນແມ່ນວິທີທີ່ມັນມີຈຸດປະສົງ
• ການເປີດຕົວຊ້ໍາໃນ Istio: ບໍລິການລັບ
• ການປະຕິບັດ Canary ໃນ Istio: ເຮັດໃຫ້ການມອບຫມາຍງ່າຍຂຶ້ນ
• Istio Egress: ອອກຈາກຮ້ານຂາຍເຄື່ອງທີ່ລະນຶກ

ລອງໃຊ້ເອງ

ຊຸດຂອງຂໍ້ຄວາມນີ້ບໍ່ໄດ້ມີຈຸດປະສົງເພື່ອສະຫນອງການດໍານ້ໍາເລິກເຂົ້າໄປໃນໂລກຂອງ Istio. ພວກເຮົາພຽງແຕ່ຕ້ອງການແນະນໍາທ່ານກ່ຽວກັບແນວຄວາມຄິດແລະອາດຈະດົນໃຈໃຫ້ທ່ານລອງ Istio ສໍາລັບຕົວທ່ານເອງ. ມັນເຮັດໄດ້ຟຣີໝົດ, ແລະ Red Hat ໃຫ້ເຄື່ອງມືທັງໝົດທີ່ເຈົ້າຕ້ອງການເພື່ອເລີ່ມຕົ້ນດ້ວຍ OpenShift, Kubernetes, Linux containers, ແລະ Istio, ລວມທັງ: Red Hat Developer OpenShift Container Platform, ຄູ່ມືຂອງພວກເຮົາກັບ Istio ແລະຊັບພະຍາກອນອື່ນໆຂອງພວກເຮົາ microsite ໃນ Service Mesh. ຢ່າຊ້າ, ເລີ່ມມື້ນີ້!

ກົດລະບຽບການກໍານົດເສັ້ນທາງ Istio: ຊີ້ນໍາການຮ້ອງຂໍການບໍລິການບ່ອນທີ່ພວກເຂົາຕ້ອງການໄປ

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

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

ຄ່າເລີ່ມຕົ້ນ Kubernetes: ເລັກນ້ອຍ "50/50"

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

ໃຫ້ເວົ້າວ່າພວກເຮົາໄດ້ນໍາໃຊ້ສອງສະບັບຂອງການບໍລິການແນະນໍາຂອງພວກເຮົາໃນ OpenShift, recommendation-v1 ແລະ recommendation-v2.
ໃນຮູບ. ຮູບທີ 1 ສະແດງໃຫ້ເຫັນວ່າເມື່ອແຕ່ລະບໍລິການຖືກສະແດງຢູ່ໃນຕົວຢ່າງດຽວ, ການຮ້ອງຂໍສະລັບກັນລະຫວ່າງພວກມັນ: 1-2-1-2-... ນີ້ແມ່ນວິທີເສັ້ນທາງ Kubernetes ເຮັດວຽກຕາມຄ່າເລີ່ມຕົ້ນ:

ການແຈກຢາຍນ້ໍາຫນັກລະຫວ່າງຮຸ່ນ

ໃນຮູບ. ຮູບທີ 2 ສະແດງໃຫ້ເຫັນສິ່ງທີ່ເກີດຂື້ນຖ້າທ່ານເພີ່ມຈໍານວນ replicas ການບໍລິການ v2 ຈາກຫນຶ່ງຫາສອງ (ອັນນີ້ແມ່ນເຮັດດ້ວຍຄໍາສັ່ງ oc scale —replicas=2 deployment/recommendation-v2). ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ການຮ້ອງຂໍລະຫວ່າງ v1 ແລະ v2 ໄດ້ຖືກແບ່ງອອກໃນອັດຕາສ່ວນຫນຶ່ງຫາສາມ: 1-2-2-1-2-2-…:

ບໍ່ສົນໃຈສະບັບໂດຍໃຊ້ Istio

Istio ເຮັດໃຫ້ມັນງ່າຍຕໍ່ການປ່ຽນແປງການແຈກຢາຍການຮ້ອງຂໍໃນທາງທີ່ພວກເຮົາຕ້ອງການ. ຕົວຢ່າງ, ສົ່ງທຣາບຟິກທັງໝົດໄປຫາ recommendation-v1 ໂດຍໃຊ້ໄຟລ໌ Istio yaml ຕໍ່ໄປນີ້:

ທີ່ນີ້ທ່ານຈໍາເປັນຕ້ອງເອົາໃຈໃສ່ກັບເລື່ອງນີ້: ຝັກຖືກເລືອກຕາມປ້າຍຊື່. ຕົວຢ່າງຂອງພວກເຮົາໃຊ້ປ້າຍ v1. ພາລາມິເຕີ "ນ້ໍາຫນັກ: 100" ຫມາຍຄວາມວ່າ 100% ຂອງການຈະລາຈອນຈະຖືກສົ່ງໄປຫາ pods ບໍລິການທັງຫມົດທີ່ມີປ້າຍ v1.

ການແຈກຢາຍຕາມຄຳສັ່ງລະຫວ່າງລຸ້ນຕ່າງໆ (ການນຳໃຊ້ Canary)

ຕໍ່ໄປ, ການນໍາໃຊ້ຕົວກໍານົດການນ້ໍາຫນັກ, ທ່ານສາມາດນໍາການຈະລາຈອນໄປຫາທັງສອງຝັກ, ບໍ່ສົນໃຈຈໍານວນຂອງ microservice instances ແລ່ນໃນແຕ່ລະຂອງພວກເຂົາ. ຕົວຢ່າງ, ໃນທີ່ນີ້ພວກເຮົາຊີ້ນໍາ 90% ຂອງການຈະລາຈອນໄປຫາ v1 ແລະ 10% ໄປ v2:

ແຍກເສັ້ນທາງສໍາລັບຜູ້ໃຊ້ມືຖື

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

ດຽວນີ້ມັນຮອດຜຽນຂອງເຈົ້າແລ້ວ

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

ແລະຈື່ໄວ້ວ່າ Ops, ບໍ່ແມ່ນ Dev

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

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

ໃຊ້ຈິນຕະນາການຂອງເຈົ້າ

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

ລອງໃຊ້ເອງ

ການອ່ານກ່ຽວກັບ Istio, Kubernetes ແລະ OpenShift ແມ່ນສິ່ງຫນຶ່ງ, ແຕ່ເປັນຫຍັງບໍ່ແຕະທຸກຢ່າງດ້ວຍຕົວເອງ? ທີມງານ ໂຄງການນັກພັດທະນາ Red Hat ໄດ້​ກະ​ກຽມ​ຄູ່​ມື​ລະ​ອຽດ (ໃນ​ພາ​ສາ​ອັງ​ກິດ​) ທີ່​ຈະ​ຊ່ວຍ​ໃຫ້​ທ່ານ​ສາ​ມາດ​ນໍາ​ໃຊ້​ເຕັກ​ໂນ​ໂລ​ຊີ​ເຫຼົ່າ​ນີ້​ໄວ​ເທົ່າ​ທີ່​ເປັນ​ໄປ​ໄດ້​. ຄູ່ມືຍັງເປັນແຫຼ່ງເປີດ 100%, ສະນັ້ນມັນຖືກປະກາດຢູ່ໃນສາທາລະນະ. ໄຟລ໌ດັ່ງກ່າວເຮັດວຽກຢູ່ໃນ macOS, Linux ແລະ Windows, ແລະລະຫັດແຫຼ່ງແມ່ນມີຢູ່ໃນສະບັບພາສາ Java ແລະ node.js (ສະບັບພາສາອື່ນໆໃນໄວໆນີ້). ພຽງແຕ່ເປີດ git repository ທີ່ສອດຄ້ອງກັນໃນຕົວທ່ອງເວັບຂອງທ່ານ ການສາທິດນັກພັດທະນາ Red Hat.

ໃນບົດຂຽນຕໍ່ໄປ: ພວກເຮົາແກ້ໄຂບັນຫາທີ່ສວຍງາມ

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

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