Istio ແລະ Kubernetes ໃນການຜະລິດ. ສ່ວນທີ 2. ການຕິດຕາມ

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

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

ຄວາມເຂົ້າໃຈຜິດອັນດັບຫນຶ່ງ: ພວກເຮົາສາມາດໄດ້ຮັບຂໍ້ມູນການຍ່າງປ່າອອນໄລນ໌ໄດ້ຟຣີ.

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

ທໍາອິດ, ໃຫ້ເບິ່ງສິ່ງທີ່ການສົ່ງ tracing spans ເບິ່ງຄືວ່າຈາກມຸມເບິ່ງສະຖາປັດຕະໃນ Istio. ດັ່ງທີ່ພວກເຮົາຈື່ຈາກພາກສ່ວນທໍາອິດ, Istio ມີອົງປະກອບແຍກຕ່າງຫາກທີ່ເອີ້ນວ່າ Mixer ສໍາລັບການເກັບກໍາ telemetry. ຢ່າງໃດກໍຕາມ, ໃນສະບັບປະຈຸບັນ 1.0.*, ການສົ່ງແມ່ນເຮັດໄດ້ໂດຍກົງຈາກເຊີບເວີພຣັອກຊີ, ຄື, ຈາກຕົວແທນຕົວແທນ. Envoy proxy ຮອງຮັບການສົ່ງ tracing spans ໂດຍໃຊ້ zipkin protocol ອອກຈາກກ່ອງ. ມັນເປັນໄປໄດ້ທີ່ຈະເຊື່ອມຕໍ່ໂປໂຕຄອນອື່ນໆ, ແຕ່ຜ່ານ plugin ເທົ່ານັ້ນ. ດ້ວຍ Istio ພວກເຮົາທັນທີໄດ້ຮັບຕົວແທນທູດທີ່ປະກອບແລະກໍາຫນົດຄ່າ, ເຊິ່ງພຽງແຕ່ສະຫນັບສະຫນູນອະນຸສັນຍາ zipkin. ຖ້າພວກເຮົາຕ້ອງການໃຊ້, ຕົວຢ່າງ, ໂປໂຕຄອນ Jaeger ແລະສົ່ງ tracing spans ຜ່ານ UDP, ຫຼັງຈາກນັ້ນພວກເຮົາຈະຕ້ອງສ້າງຮູບພາບ istio-proxy ຂອງພວກເຮົາເອງ. ມີການສະຫນັບສະຫນູນ plugins ທີ່ກໍາຫນົດເອງສໍາລັບ istio-proxy, ແຕ່ວ່າມັນຍັງຢູ່ໃນສະບັບ alpha. ດັ່ງນັ້ນ, ຖ້າພວກເຮົາຕ້ອງການເຮັດໂດຍບໍ່ມີການຕັ້ງຄ່າທີ່ກໍາຫນົດເອງຈໍານວນຫລາຍ, ຂອບເຂດຂອງເຕັກໂນໂລຢີທີ່ໃຊ້ສໍາລັບການເກັບຮັກສາແລະການຮັບ tracing spans ຫຼຸດລົງ. ຂອງລະບົບຕົ້ນຕໍ, ໃນຄວາມເປັນຈິງ, ໃນປັດຈຸບັນທ່ານສາມາດນໍາໃຊ້ Zipkin ຕົວຂອງມັນເອງ, ຫຼື Jaeger, ແຕ່ສົ່ງທຸກສິ່ງທຸກຢ່າງຢູ່ທີ່ນັ້ນໂດຍໃຊ້ zipkin compatible protocol (ເຊິ່ງມີປະສິດທິພາບຫນ້ອຍຫຼາຍ). ໂປໂຕຄອນ zipkin ຕົວຂອງມັນເອງກ່ຽວຂ້ອງກັບການສົ່ງຂໍ້ມູນການຕິດຕາມທັງຫມົດໄປຫາຜູ້ລວບລວມຂໍ້ມູນຜ່ານໂປໂຕຄອນ HTTP, ເຊິ່ງມີລາຄາແພງຫຼາຍ.

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

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

ທ່ານຍັງສາມາດໃຊ້ຊື່ປະສົມເຊັ່ນ http-magic (Istio ຈະເຫັນ http ແລະຮັບຮູ້ພອດນັ້ນເປັນ http endpoint). ຮູບແບບແມ່ນ: proto-extra.

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

ເພື່ອເຂົ້າໃຈວ່າໂປໂຕຄອນຖືກ ກຳ ນົດຢ່າງຖືກຕ້ອງຫຼືບໍ່, ທ່ານ ຈຳ ເປັນຕ້ອງເຂົ້າໄປໃນຕູ້ຄອນເທນເນີຂອງລົດຂ້າງໃດ ໜຶ່ງ ທີ່ມີຕົວແທນຕົວແທນແລະສົ່ງ ຄຳ ຮ້ອງຂໍໄປຍັງຜອດ admin ຂອງການໂຕ້ຕອບ envoy ກັບສະຖານທີ່ / config_dump. ໃນການຕັ້ງຄ່າຜົນໄດ້ຮັບ, ທ່ານຈໍາເປັນຕ້ອງເບິ່ງພາກສະຫນາມການດໍາເນີນງານຂອງການບໍລິການທີ່ຕ້ອງການ. ມັນຖືກນໍາໃຊ້ໃນ Istio ເປັນຕົວລະບຸບ່ອນທີ່ການຮ້ອງຂໍຖືກເຮັດ. ເພື່ອປັບແຕ່ງຄ່າຂອງພາລາມິເຕີນີ້ໃນ Istio (ຫຼັງຈາກນັ້ນພວກເຮົາຈະເຫັນມັນຢູ່ໃນລະບົບການຕິດຕາມຂອງພວກເຮົາ), ມັນຈໍາເປັນຕ້ອງລະບຸທຸງ serviceCluster ໃນຂັ້ນຕອນຂອງການເປີດຕົວຖັງ sidecar. ຕົວຢ່າງ, ມັນສາມາດຖືກຄິດໄລ່ແບບນີ້ຈາກຕົວແປທີ່ໄດ້ຮັບຈາກ kubernetes API ລົງລຸ່ມ:

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

ຕົວຢ່າງທີ່ດີທີ່ຈະເຂົ້າໃຈວິທີການຕິດຕາມເຮັດວຽກໃນທູດ ທີ່ນີ້.

ຈຸດສິ້ນສຸດຕົວມັນເອງສໍາລັບການສົ່ງ tracing spans ຕ້ອງຖືກລະບຸໄວ້ໃນທຸງເປີດຕົວຕົວແທນຕົວແທນ, ຕົວຢ່າງ: --zipkinAddress tracing-collector.tracing:9411

ຄວາມ​ຄິດ​ຜິດ​ທີ່​ສອງ​: ພວກ​ເຮົາ​ມີ​ລາ​ຄາ​ຖືກ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ຕິດ​ຕາມ​ທີ່​ສົມ​ບູນ​ຂອງ​ການ​ຮ້ອງ​ຂໍ​ໂດຍ​ຜ່ານ​ລະ​ບົບ​ອອກ​ຈາກ​ປ່ອງ

ແຕ່ຫນ້າເສຍດາຍ, ມັນບໍ່ແມ່ນ. ຄວາມສັບສົນຂອງການປະຕິບັດແມ່ນຂຶ້ນກັບວິທີທີ່ທ່ານໄດ້ປະຕິບັດປະຕິສໍາພັນຂອງການບໍລິການແລ້ວ. ເປັນຫຍັງຄື?

ຄວາມຈິງແມ່ນວ່າເພື່ອໃຫ້ istio-proxy ສາມາດເຂົ້າໃຈການຕອບໂຕ້ຂອງຄໍາຮ້ອງຂໍທີ່ເຂົ້າມາໃນການບໍລິການກັບຜູ້ທີ່ອອກຈາກການບໍລິການດຽວກັນ, ມັນບໍ່ພຽງພໍທີ່ຈະພຽງແຕ່ຂັດຂວາງການຈະລາຈອນທັງຫມົດ. ທ່ານຕ້ອງມີຕົວລະບຸການສື່ສານບາງປະເພດ. HTTP envoy proxy ໃຊ້ headers ພິເສດ, ໂດຍ envoy ເຂົ້າໃຈວ່າການຮ້ອງຂໍສະເພາະກັບການບໍລິການສ້າງການຮ້ອງຂໍສະເພາະກັບການບໍລິການອື່ນໆ. ບັນຊີລາຍຊື່ຂອງຫົວຂໍ້ດັ່ງກ່າວ:

• x-request-id,
• x-b3-traceid,
• x-b3-ສະເປນ,
• x-b3-parentspanid,
• x-b3-ຕົວຢ່າງ,
• x-b3-ທຸງ,
• x-ot-span-context.

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

ສະຫລຸບ

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

ໃນບົດຄວາມຕໍ່ໄປກ່ຽວກັບ Service Mesh, ພວກເຮົາຈະເບິ່ງຫນຶ່ງໃນບັນຫາທີ່ໃຫຍ່ທີ່ສຸດກັບ Istio - ການບໍລິໂພກຂະຫນາດໃຫຍ່ຂອງ RAM ໂດຍແຕ່ລະຖັງຕົວແທນ sidecar ແລະປຶກສາຫາລືກ່ຽວກັບວິທີທີ່ທ່ານສາມາດຈັດການກັບມັນ.

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