ວິທີການດໍາເນີນການ Istio ໂດຍໃຊ້ Kubernetes ໃນການຜະລິດ. ພາກທີ 1

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

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

ເຮັດແນວໃດມັນເຮັດວຽກ

Istio ປະກອບດ້ວຍສອງພື້ນທີ່ຕົ້ນຕໍ - ຍົນຄວບຄຸມແລະຍົນຂໍ້ມູນ. ຍົນຄວບຄຸມປະກອບດ້ວຍອົງປະກອບຕົ້ນຕໍທີ່ຮັບປະກັນການດໍາເນີນງານທີ່ຖືກຕ້ອງຂອງສ່ວນທີ່ເຫຼືອ. ໃນສະບັບປະຈຸບັນ (1.0) ຍົນຄວບຄຸມມີສາມອົງປະກອບຕົ້ນຕໍ: Pilot, Mixer, Citadel. ພວກເຮົາຈະບໍ່ພິຈາລະນາ Citadel, ມັນຈໍາເປັນຕ້ອງສ້າງໃບຢັ້ງຢືນເພື່ອຮັບປະກັນ TLS ເຊິ່ງກັນແລະກັນລະຫວ່າງການບໍລິການ. ລອງພິຈາລະນາເບິ່ງອຸປະກອນ ແລະຈຸດປະສົງຂອງ Pilot ແລະ Mixer ຕື່ມອີກ.

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

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

ຍົນຂໍ້ມູນຖືກປະຕິບັດໂດຍໃຊ້ຖັງບັນຈຸຕົວແທນຂອງ sidecar. ມີອໍານາດຖືກໃຊ້ໂດຍຄ່າເລີ່ມຕົ້ນ. ຕົວແທນທູດ. ມັນສາມາດຖືກແທນທີ່ດ້ວຍການປະຕິບັດອື່ນ, ເຊັ່ນ: nginx (nginmesh).

ເພື່ອໃຫ້ Istio ເຮັດວຽກຢ່າງໂປ່ງໃສຕໍ່ແອັບພລິເຄຊັນ, ມີລະບົບສີດອັດຕະໂນມັດ. ການ​ປະ​ຕິ​ບັດ​ຫລ້າ​ສຸດ​ແມ່ນ​ເຫມາະ​ສົມ​ສໍາ​ລັບ Kubernetes 1.9+ ສະ​ບັບ​ພາ​ສາ (webhook ເຂົ້າ​ຮ່ວມ mutational). ສໍາລັບ Kubernetes ເວີຊັ່ນ 1.7, 1.8 ສາມາດໃຊ້ Initializer ໄດ້.

ຕູ້ຄອນເທນເນີ Sidecar ແມ່ນເຊື່ອມຕໍ່ກັບ Pilot ໂດຍໃຊ້ GRPC protocol, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດເພີ່ມປະສິດທິພາບຮູບແບບການຊຸກຍູ້ສໍາລັບການປ່ຽນແປງທີ່ເກີດຂື້ນໃນກຸ່ມ. GRPC ໄດ້ຖືກນໍາໃຊ້ໃນ Envoy ຕັ້ງແຕ່ຮຸ່ນ 1.6, ໃນ Istio ມັນໄດ້ຖືກນໍາໃຊ້ຕັ້ງແຕ່ຮຸ່ນ 0.8 ແລະເປັນນັກບິນຕົວແທນ - golang wrapper over envoy ທີ່ກໍານົດທາງເລືອກໃນການເປີດຕົວ.

Pilot ແລະ Mixer ແມ່ນອົງປະກອບທີ່ບໍ່ມີລັດຢ່າງສົມບູນ, ລັດທັງຫມົດຈະຖືກເກັບໄວ້ໃນຫນ່ວຍຄວາມຈໍາ. ການຕັ້ງຄ່າສໍາລັບພວກມັນແມ່ນຖືກກໍານົດໃນຮູບແບບຂອງ Kubernetes Custom Resources, ເຊິ່ງຖືກເກັບໄວ້ໃນ etcd.
Istio-agent ໄດ້ຮັບທີ່ຢູ່ຂອງນັກບິນແລະເປີດ GRPC stream ກັບມັນ.

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

1. ກຳລັງນຳໃຊ້ບໍລິການເວີຊັນໃໝ່.
2. ອີງຕາມວິທີການສີດພາຊະນະ sidecar, ຖັງບັນຈຸ istio-init ແລະບັນຈຸ istio-ຕົວແທນ (ທູດ) ຈະຖືກເພີ່ມໃສ່ໃນຂັ້ນຕອນຂອງການນໍາໃຊ້ການຕັ້ງຄ່າ, ຫຼືເຂົາເຈົ້າສາມາດຖືກໃສ່ເຂົ້າໄປໃນລາຍລະອຽດຂອງຫນ່ວຍງານ Kubernetes Pod ໄດ້ແລ້ວ.
3. ກ່ອງບັນຈຸ istio-init ແມ່ນສະຄຣິບທີ່ໃຊ້ກົດລະບຽບ iptables ກັບຝັກ. ມີສອງທາງເລືອກໃນການຕັ້ງຄ່າການຈະລາຈອນທີ່ຈະຫໍ່ຢູ່ໃນຖັງ istio-agent: ໃຊ້ກົດລະບຽບການປ່ຽນເສັ້ນທາງ iptables, ຫຼື TPROXY. ໃນເວລາຂຽນ, ວິທີການເລີ່ມຕົ້ນແມ່ນກັບກົດລະບຽບການປ່ຽນເສັ້ນທາງ. ໃນ istio-init, ມັນເປັນໄປໄດ້ທີ່ຈະກໍານົດວ່າການຈະລາຈອນໃດຄວນຖືກຂັດຂວາງແລະສົ່ງໄປຫາ istio-agent. ຕົວຢ່າງ, ເພື່ອຂັດຂວາງການຈະລາຈອນຂາເຂົ້າແລະຂາອອກທັງຫມົດ, ທ່ານຈໍາເປັນຕ້ອງກໍານົດພາລາມິເຕີ -i и -b ເຂົ້າໄປໃນຄວາມຫມາຍ *. ທ່ານສາມາດກໍານົດພອດສະເພາະເພື່ອສະກັດ. ເພື່ອບໍ່ຂັດຂວາງເຄືອຂ່າຍຍ່ອຍສະເພາະ, ທ່ານສາມາດກໍານົດມັນໂດຍໃຊ້ທຸງ -x.
4. ຫຼັງຈາກບັນຈຸ init ໄດ້ຖືກປະຕິບັດ, ຕົ້ນຕໍໄດ້ຖືກເປີດຕົວ, ລວມທັງນັກບິນ - ຕົວແທນ (ທູດ). ມັນເຊື່ອມຕໍ່ກັບ Pilot ທີ່ນຳໃຊ້ແລ້ວຜ່ານ GRPC ແລະໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບການບໍລິການທີ່ມີຢູ່ທັງໝົດ ແລະນະໂຍບາຍການກຳນົດເສັ້ນທາງໃນກຸ່ມ. ອີງຕາມຂໍ້ມູນທີ່ໄດ້ຮັບ, ລາວ configure ກຸ່ມແລະມອບໃຫ້ເຂົາເຈົ້າໂດຍກົງກັບຈຸດສິ້ນສຸດຂອງຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາໃນກຸ່ມ Kubernetes. ມັນຍັງມີຄວາມຈໍາເປັນທີ່ຈະສັງເກດຈຸດສໍາຄັນ: ທູດກໍານົດການຟັງແບບໄດນາມິກ (IP, ຄູ່ພອດ) ​​ທີ່ມັນເລີ່ມຟັງ. ດັ່ງນັ້ນ, ເມື່ອຄໍາຮ້ອງຂໍເຂົ້າໄປໃນຝັກ, ຖືກໂອນໂດຍໃຊ້ກົດລະບຽບ redirect iptables ໃນ sidecar, ທູດສາມາດດໍາເນີນການເຊື່ອມຕໍ່ເຫຼົ່ານີ້ສົບຜົນສໍາເລັດແລະເຂົ້າໃຈບ່ອນທີ່ຈະສົ່ງຕໍ່ການຈະລາຈອນເພີ່ມເຕີມ. ນອກຈາກນີ້ໃນຂັ້ນຕອນນີ້, ຂໍ້ມູນຖືກສົ່ງໄປຫາ Mixer, ເຊິ່ງພວກເຮົາຈະເບິ່ງໃນພາຍຫລັງ, ແລະ tracing spans ຖືກສົ່ງ.

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບເຄືອຂ່າຍຕົວແທນຕົວແທນທັງໝົດທີ່ພວກເຮົາສາມາດຕັ້ງຄ່າໄດ້ຈາກຈຸດດຽວ (Pilot). ການຮ້ອງຂໍຂາເຂົ້າແລະຂາອອກທັງຫມົດແມ່ນຜ່ານທູດ. ຍິ່ງໄປກວ່ານັ້ນ, ພຽງແຕ່ການຈະລາຈອນ TCP ຖືກຂັດຂວາງ. ນີ້ຫມາຍຄວາມວ່າ IP ການບໍລິການ Kubernetes ຖືກແກ້ໄຂໂດຍໃຊ້ kube-dns ຜ່ານ UDP ໂດຍບໍ່ມີການປ່ຽນແປງ. ຫຼັງຈາກນັ້ນ, ຫຼັງຈາກການແກ້ໄຂ, ການຮ້ອງຂໍອອກຈະຖືກຂັດຂວາງແລະດໍາເນີນການໂດຍທູດ, ເຊິ່ງໄດ້ຕັດສິນໃຈແລ້ວວ່າຈຸດສິ້ນສຸດຄໍາຮ້ອງຂໍຄວນຖືກສົ່ງໄປຫາ (ຫຼືບໍ່ໄດ້ສົ່ງ, ໃນກໍລະນີຂອງນະໂຍບາຍການເຂົ້າເຖິງຫຼືຕົວຕັດວົງຈອນຂອງ algorithm).

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

Mixer ໃນຮູບແບບປະຈຸບັນຂອງມັນປະກອບດ້ວຍສອງອົງປະກອບ: istio-telemetry, istio-policy (ກ່ອນຮຸ່ນ 0.8 ມັນແມ່ນອົງປະກອບຫນຶ່ງຂອງ istio-mixer). ທັງສອງຂອງພວກເຂົາແມ່ນຜູ້ປະສົມ, ແຕ່ລະຄົນຮັບຜິດຊອບສໍາລັບວຽກງານຂອງຕົນເອງ. Istio telemetry ໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບຜູ້ທີ່ໄປບ່ອນໃດແລະມີພາລາມິເຕີຈາກ sidecar Report containers ຜ່ານ GRPC. Istio-policy ຍອມຮັບການຮ້ອງຂໍການກວດສອບເພື່ອກວດສອບວ່າກົດລະບຽບນະໂຍບາຍແມ່ນພໍໃຈ. ແນ່ນອນວ່າ, ການກວດສອບ poilicy ບໍ່ໄດ້ດໍາເນີນການສໍາລັບທຸກຄໍາຮ້ອງຂໍ, ແຕ່ຖືກເກັບໄວ້ໃນລູກຄ້າ (ໃນ sidecar) ສໍາລັບເວລາທີ່ແນ່ນອນ. ລາຍງານການກວດສອບຖືກສົ່ງເປັນຄໍາຮ້ອງຂໍ batch. ໃຫ້ພວກເຮົາເບິ່ງວິທີການກໍາຫນົດຄ່າແລະສິ່ງທີ່ພາລາມິເຕີຄວນຈະຖືກສົ່ງຕໍ່ມາເລັກນ້ອຍ.

Mixer ແມ່ນ supposed ຈະ ເປັນ ອົງ ປະ ກອບ ທີ່ ມີ ຢ່າງ ສູງ ທີ່ ຮັບ ປະ ກັນ ການ ເຮັດ ວຽກ ທີ່ ບໍ່ ມີ ການ ຂັດ ຂວາງ ກ່ຽວ ກັບ ການ ປະ ກອບ ແລະ ການ ປຸງ ແຕ່ງ ຂອງ ຂໍ້ ມູນ telemetry. ລະບົບໄດ້ຮັບຜົນເປັນ buffer ຫຼາຍລະດັບ. ໃນເບື້ອງຕົ້ນ, ຂໍ້ມູນແມ່ນ buffered ຢູ່ຂ້າງ sidecar ຂອງບັນຈຸ, ຫຼັງຈາກນັ້ນຢູ່ຂ້າງ mixer, ແລະຫຼັງຈາກນັ້ນຖືກສົ່ງໄປຫາອັນທີ່ເອີ້ນວ່າ mixer backends. ດັ່ງນັ້ນ, ຖ້າອົງປະກອບໃດໆຂອງລະບົບລົ້ມເຫລວ, buffer ຈະເລີນເຕີບໂຕແລະຖືກ flushed ຫຼັງຈາກລະບົບຖືກຟື້ນຟູ. Mixer backends ແມ່ນຈຸດສິ້ນສຸດສໍາລັບການສົ່ງຂໍ້ມູນ telemetry: statsd, newrelic, ແລະອື່ນໆ. ທ່ານສາມາດຂຽນ backend ຂອງທ່ານເອງ, ມັນຂ້ອນຂ້າງງ່າຍດາຍ, ແລະພວກເຮົາຈະເບິ່ງວິທີການເຮັດມັນ.

ເພື່ອສະຫຼຸບ, ໂຄງການສໍາລັບການເຮັດວຽກກັບ istio-telemetry ແມ່ນດັ່ງຕໍ່ໄປນີ້.

1. ການບໍລິການ 1 ສົ່ງຄໍາຮ້ອງຂໍການບໍລິການ 2.
2. ໃນເວລາທີ່ອອກຈາກການບໍລິການ 1, ການຮ້ອງຂໍແມ່ນຫໍ່ຢູ່ໃນ sidecar ຂອງຕົນເອງ.
3. ທູດ Sidecar ຕິດຕາມກວດກາວິທີການຮ້ອງຂໍໄປຫາການບໍລິການ 2 ແລະກະກຽມຂໍ້ມູນທີ່ຈໍາເປັນ.
4. ຫຼັງຈາກນັ້ນ, ສົ່ງໄປທີ່ istio-telemetry ໂດຍໃຊ້ການຮ້ອງຂໍລາຍງານ.
5. Istio-telemetry ກໍານົດວ່າບົດລາຍງານນີ້ຄວນຈະຖືກສົ່ງໄປຫາ backends, ຂໍ້ມູນໃດແລະຄວນຖືກສົ່ງ.
6. Istio-telemetry ສົ່ງຂໍ້ມູນລາຍງານໄປຫາ backend ຖ້າຈໍາເປັນ.

ຕອນນີ້ໃຫ້ເຮົາມາເບິ່ງວິທີການນຳໃຊ້ Istio ໃນລະບົບ, ເຊິ່ງປະກອບດ້ວຍອົງປະກອບຫຼັກໆເທົ່ານັ້ນ (ນັກບິນ ແລະ ທູດຂ້າງຄຽງ).

ທໍາອິດ, ໃຫ້ເບິ່ງການຕັ້ງຄ່າຕົ້ນຕໍ (ຕາຫນ່າງ) ທີ່ Pilot ອ່ານ:

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio
  namespace: istio-system
  labels:
    app: istio
    service: istio
data:
  mesh: |-

    # пока что не включаем отправку tracing информации (pilot настроит envoy’и таким образом, что отправка не будет происходить)
    enableTracing: false

    # пока что не указываем mixer endpoint’ы, чтобы sidecar контейнеры не отправляли информацию туда
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # ставим временной промежуток, с которым будет envoy переспрашивать Pilot (это для старой версии envoy proxy)
    rdsRefreshDelay: 5s

    # default конфигурация для envoy sidecar
    defaultConfig:
      # аналогично как rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # оставляем по умолчанию (путь к конфигурации и бинарю envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # дефолтное имя запущенного sidecar контейнера (используется, например, в именах сервиса при отправке tracing span’ов)
      serviceCluster: istio-proxy

      # время, которое будет ждать envoy до того, как он принудительно завершит все установленные соединения
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # по умолчанию используются REDIRECT правила iptables. Можно изменить на TPROXY.
      #interceptionMode: REDIRECT

      # Порт, на котором будет запущена admin панель каждого sidecar контейнера (envoy)
      proxyAdminPort: 15000

      # адрес, по которому будут отправляться trace’ы по zipkin протоколу (в начале мы отключили саму отправку, поэтому это поле сейчас не будет использоваться)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd адрес для отправки метрик envoy контейнеров (отключаем)
      # statsdUdpAddress: aggregator:8126

      # выключаем поддержку опции Mutual TLS
      controlPlaneAuthPolicy: NONE

      # адрес, на котором будет слушать istio-pilot для того, чтобы сообщать информацию о service discovery всем sidecar контейнерам
      discoveryAddress: istio-pilot.istio-system:15007

ອົງປະກອບຄວບຄຸມຕົ້ນຕໍທັງຫມົດ (ຍົນຄວບຄຸມ) ຈະຕັ້ງຢູ່ໃນລະບົບ namespace istio ໃນ Kubernetes.

ຢ່າງໜ້ອຍ, ພວກເຮົາພຽງແຕ່ຕ້ອງນຳໃຊ້ Pilot ເທົ່ານັ້ນ. ສໍາລັບນີ້ພວກເຮົາໃຊ້ ການຕັ້ງຄ່າດັ່ງກ່າວ.

ແລະພວກເຮົາຈະ configure sidecar ສັກຢາຂອງບັນຈຸໄດ້ດ້ວຍຕົນເອງ.

ກ່ອງບັນຈຸ:

initContainers:
 - name: istio-init
   args:
   - -p
   - "15001"
   - -u
   - "1337"
   - -m
   - REDIRECT
   - -i
   - '*'
   - -b
   - '*'
   - -d
   - ""
   image: istio/proxy_init:1.0.0
   imagePullPolicy: IfNotPresent
   resources:
     limits:
       memory: 128Mi
   securityContext:
     capabilities:
       add:
       - NET_ADMIN

ແລະ sidecar:

       name: istio-proxy
       args:
         - "bash"
         - "-c"
         - |
           exec /usr/local/bin/pilot-agent proxy sidecar 
           --configPath 
           /etc/istio/proxy 
           --binaryPath 
           /usr/local/bin/envoy 
           --serviceCluster 
           service-name 
           --drainDuration 
           45s 
           --parentShutdownDuration 
           1m0s 
           --discoveryAddress 
           istio-pilot.istio-system:15007 
           --discoveryRefreshDelay 
           1s 
           --connectTimeout 
           10s 
           --proxyAdminPort 
           "15000" 
           --controlPlaneAuthPolicy 
           NONE
         env:
         - name: POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: POD_NAMESPACE
           valueFrom:
             fieldRef:
               fieldPath: metadata.namespace
         - name: INSTANCE_IP
           valueFrom:
             fieldRef:
               fieldPath: status.podIP
         - name: ISTIO_META_POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: ISTIO_META_INTERCEPTION_MODE
           value: REDIRECT
         image: istio/proxyv2:1.0.0
         imagePullPolicy: IfNotPresent
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             memory: 2048Mi
         securityContext:
           privileged: false
           readOnlyRootFilesystem: true
           runAsUser: 1337
         volumeMounts:
         - mountPath: /etc/istio/proxy
           name: istio-envoy

ເພື່ອໃຫ້ທຸກສິ່ງທຸກຢ່າງເລີ່ມຕົ້ນຢ່າງສໍາເລັດຜົນ, ທ່ານຈໍາເປັນຕ້ອງສ້າງ ServiceAccount, ClusterRole, ClusterRoleBinding, CRD ສໍາລັບນັກບິນ, ເຊິ່ງສາມາດພົບໄດ້. ທີ່ນີ້.

ດັ່ງນັ້ນ, ການບໍລິການທີ່ພວກເຮົາສັກຢາ sidecar ກັບທູດຄວນເລີ່ມຕົ້ນຢ່າງສໍາເລັດຜົນ, ໄດ້ຮັບການຄົ້ນພົບທັງຫມົດຈາກການທົດລອງແລະການຮ້ອງຂໍຂະບວນການ.

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

ນອກຈາກນີ້, Istio (ຍັງທົດລອງ) ມີຄວາມສາມາດທີ່ຈະດໍາເນີນການຢູ່ນອກກຸ່ມແລະຄວາມສາມາດໃນການເບິ່ງແລະການຄົ້ນພົບການບໍລິການ fumble ລະຫວ່າງຫລາຍກຸ່ມ Kubernetes. ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ ທີ່ນີ້.

ສໍາລັບການຕິດຕັ້ງຫຼາຍກຸ່ມ, ຈົ່ງລະວັງຂໍ້ຈໍາກັດຕໍ່ໄປນີ້:

1. Pod CIDR ແລະ Service CIDR ຈະຕ້ອງບໍ່ຊໍ້າກັນທົ່ວທຸກກຸ່ມ ແລະບໍ່ຄວນທັບຊ້ອນກັນ.
2. ທຸກ CIDR Pods ຕ້ອງສາມາດເຂົ້າເຖິງໄດ້ຈາກ CIDR Pods ໃດໆລະຫວ່າງກຸ່ມ.
3. ເຊີບເວີ Kubernetes API ທັງໝົດຈະຕ້ອງເຂົ້າເຖິງເຊິ່ງກັນແລະກັນ.

ນີ້ແມ່ນຂໍ້ມູນເບື້ອງຕົ້ນເພື່ອຊ່ວຍໃຫ້ທ່ານເລີ່ມຕົ້ນກັບ Istio. ຢ່າງໃດກໍຕາມ, ຍັງມີຫຼາຍ pitfalls. ສໍາລັບຕົວຢ່າງ, ລັກສະນະຂອງການກໍານົດເສັ້ນທາງການຈະລາຈອນພາຍນອກ (ນອກກຸ່ມ), ວິທີການເພື່ອ debugging sidecars, profiling, ການຕັ້ງຄ່າ mixer ແລະການຂຽນ backend mixer ກໍານົດເອງ, ສ້າງຕັ້ງກົນໄກການຕິດຕາມແລະການດໍາເນີນງານຂອງຕົນໂດຍ envoy.
ທັງຫມົດນີ້ພວກເຮົາຈະພິຈາລະນາໃນສິ່ງພິມຕໍ່ໄປນີ້. ຖາມຄໍາຖາມຂອງເຈົ້າ, ຂ້ອຍຈະພະຍາຍາມປົກປິດພວກມັນ.

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