🥇ໂຫຼດການດຸ່ນດ່ຽງ ແລະປັບຂະໜາດການເຊື່ອມຕໍ່ທີ່ມີອາຍຸຍາວນານໃນ Kubernetes

ບົດຄວາມນີ້ຈະຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈວ່າການດຸ່ນດ່ຽງການໂຫຼດເຮັດວຽກຢູ່ໃນ Kubernetes, ຈະເກີດຫຍັງຂຶ້ນໃນເວລາທີ່ການຂະຫຍາຍການເຊື່ອມຕໍ່ທີ່ມີຊີວິດຍາວ, ແລະເປັນຫຍັງທ່ານຄວນພິຈາລະນາການດຸ່ນດ່ຽງດ້ານລູກຄ້າຖ້າທ່ານໃຊ້ HTTP / 2, gRPC, RSockets, AMQP, ຫຼືໂປໂຕຄອນທີ່ມີອາຍຸຍືນອື່ນໆ. .

ເລັກນ້ອຍກ່ຽວກັບວິທີການຈາລະຈອນຖືກແຈກຢາຍຄືນໃຫມ່ໃນ Kubernetes

Kubernetes ສະໜອງສິ່ງຫຍໍ້ທໍ້ທີ່ສະດວກສອງຢ່າງສຳລັບການນຳໃຊ້ແອັບພລິເຄຊັນ: ບໍລິການ ແລະການນຳໃຊ້.

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

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

ຂໍໃຫ້ເບິ່ງວ່າມັນມີລັກສະນະແນວໃດ.

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

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

ມັນເບິ່ງຄືວ່ານີ້.

ໄດ້ຮັບການຮ້ອງຂໍ curl 10.96.45.152 ກັບການບໍລິການ:
ການບໍລິການເລືອກຫນຶ່ງໃນສາມທີ່ຢູ່ pod ເປັນຈຸດຫມາຍປາຍທາງຂອງມັນ:
ການຈະລາຈອນຖືກປ່ຽນເສັ້ນທາງໄປຫາພື້ນທີ່ສະເພາະ:

ຖ້າຄໍາຮ້ອງສະຫມັກຂອງທ່ານປະກອບດ້ວຍ frontend ແລະ backend, ຫຼັງຈາກນັ້ນທ່ານຈະມີທັງການບໍລິການແລະການນໍາໃຊ້ສໍາລັບແຕ່ລະຄົນ.

ເມື່ອ frontend ເຮັດການຮ້ອງຂໍກັບ backend, ມັນບໍ່ຈໍາເປັນຕ້ອງຮູ້ວ່າມີຈໍານວນ pods ທີ່ backend ໃຫ້ບໍລິການ: ອາດຈະມີຫນຶ່ງ, ສິບ, ຫຼືຮ້ອຍ.

ນອກຈາກນີ້, ດ້ານຫນ້າບໍ່ຮູ້ຫຍັງກ່ຽວກັບທີ່ຢູ່ຂອງຝັກທີ່ໃຫ້ບໍລິການດ້ານຫຼັງ.

ເມື່ອ frontend ເຮັດການຮ້ອງຂໍກັບ backend, ມັນໃຊ້ທີ່ຢູ່ IP ຂອງບໍລິການ backend, ເຊິ່ງບໍ່ປ່ຽນແປງ.

ນີ້ແມ່ນສິ່ງທີ່ມັນຄ້າຍຄື.

ພາຍໃຕ້ 1 ຮ້ອງຂໍອົງປະກອບ backend ພາຍໃນ. ແທນທີ່ຈະເລືອກເອົາສະເພາະໃດຫນຶ່ງສໍາລັບ backend ໄດ້, ມັນເຮັດໃຫ້ຄໍາຮ້ອງສະຫມັກການບໍລິການ:
ບໍລິການເລືອກໜຶ່ງໃນ backend pods ເປັນທີ່ຢູ່ປາຍທາງ:
ການຈະລາຈອນໄປຈາກ Pod 1 ຫາ Pod 5, ເລືອກໂດຍການບໍລິການ:
ພາຍໃຕ້ 1 ບໍ່ຮູ້ວ່າມີຈໍານວນຝັກທີ່ຄ້າຍຄືຕ່ໍາກວ່າ 5 ໄດ້ຖືກເຊື່ອງໄວ້ຢູ່ຫລັງການບໍລິການ:

ແຕ່ວ່າການບໍລິການແຈກຢາຍການຮ້ອງຂໍແນວໃດ? ມັນເບິ່ງຄືວ່າການດຸ່ນດ່ຽງຮອບ-robin ຖືກໃຊ້ບໍ? ໃຫ້ຄິດອອກ.

ການດຸ່ນດ່ຽງໃນການບໍລິການ Kubernetes

ບໍລິການ Kubernetes ບໍ່ມີຢູ່. ບໍ່ມີຂະບວນການສໍາລັບການບໍລິການທີ່ຖືກມອບຫມາຍທີ່ຢູ່ IP ແລະພອດ.

ທ່ານສາມາດກວດສອບນີ້ໂດຍການເຂົ້າສູ່ລະບົບ node ໃດໃນ cluster ແລະແລ່ນຄໍາສັ່ງ netstat -ntlp.

ທ່ານຈະບໍ່ສາມາດຊອກຫາທີ່ຢູ່ IP ທີ່ຈັດສັນໃຫ້ກັບບໍລິການໄດ້.

ທີ່ຢູ່ IP ຂອງການບໍລິການແມ່ນຢູ່ໃນຊັ້ນຄວບຄຸມ, ໃນຕົວຄວບຄຸມ, ແລະຖືກບັນທຶກໄວ້ໃນຖານຂໍ້ມູນ - etcd. ທີ່ຢູ່ດຽວກັນຖືກນໍາໃຊ້ໂດຍອົງປະກອບອື່ນ - kube-proxy .
Kube-proxy ໄດ້ຮັບບັນຊີລາຍຊື່ຂອງທີ່ຢູ່ IP ສໍາລັບການບໍລິການທັງຫມົດແລະສ້າງຊຸດຂອງກົດລະບຽບ iptables ໃນແຕ່ລະ node ໃນ cluster.

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

ທີ່ຢູ່ IP ການບໍລິການແມ່ນໃຊ້ພຽງແຕ່ເປັນຈຸດເຂົ້າແລະບໍ່ໄດ້ໃຫ້ບໍລິການໂດຍຂະບວນການໃດໆທີ່ຟັງທີ່ຢູ່ IP ແລະພອດນັ້ນ.

ໃຫ້ເບິ່ງຢູ່ໃນນີ້.

ພິຈາລະນາກຸ່ມຂອງສາມຂໍ້. ແຕ່ລະ node ມີ pods:
Tied pods painted beige ເປັນສ່ວນຫນຶ່ງຂອງການບໍລິການ. ເນື່ອງຈາກວ່າການບໍລິການບໍ່ມີເປັນຂະບວນການ, ມັນສະແດງເປັນສີຂີ້ເຖົ່າ:
ຝັກທໍາອິດຮ້ອງຂໍການບໍລິການແລະຕ້ອງໄປຫາຫນຶ່ງໃນຝັກທີ່ກ່ຽວຂ້ອງ:
ແຕ່ການບໍລິການບໍ່ມີ, ຂະບວນການບໍ່ມີຢູ່. ມັນເຮັດວຽກແນວໃດ?
ກ່ອນທີ່ຄໍາຮ້ອງຂໍອອກຈາກ node, ມັນຜ່ານກົດລະບຽບ iptables:
ກົດລະບຽບ iptables ຮູ້ວ່າການບໍລິການບໍ່ມີຢູ່ແລະປ່ຽນແທນທີ່ຢູ່ IP ຂອງມັນດ້ວຍທີ່ຢູ່ IP ຫນຶ່ງຂອງ pods ທີ່ກ່ຽວຂ້ອງກັບການບໍລິການນັ້ນ:
ການຮ້ອງຂໍໄດ້ຮັບທີ່ຢູ່ IP ທີ່ຖືກຕ້ອງເປັນທີ່ຢູ່ປາຍທາງ ແລະຖືກປະມວນຜົນຕາມປົກກະຕິ:
ອີງຕາມ topology ເຄືອຂ່າຍ, ໃນທີ່ສຸດການຮ້ອງຂໍໄປເຖິງ pod:

iptables ສາມາດໂຫຼດຍອດເງິນໄດ້ບໍ?

ບໍ່, iptables ຖືກນໍາໃຊ້ສໍາລັບການກັ່ນຕອງແລະບໍ່ໄດ້ຖືກອອກແບບມາສໍາລັບການດຸ່ນດ່ຽງ.

ຢ່າງໃດກໍ່ຕາມ, ມັນເປັນໄປໄດ້ທີ່ຈະຂຽນຊຸດຂອງກົດລະບຽບທີ່ເຮັດວຽກຄືກັບ pseudo-balancer.

ແລະນີ້ແມ່ນສິ່ງທີ່ຖືກປະຕິບັດຢູ່ໃນ Kubernetes.

ຖ້າທ່ານມີສາມຝັກ, kube-proxy ຈະຂຽນກົດລະບຽບຕໍ່ໄປນີ້:

ເລືອກຍ່ອຍທໍາອິດທີ່ມີຄວາມເປັນໄປໄດ້ 33%, ຖ້າບໍ່ດັ່ງນັ້ນໄປຫາກົດລະບຽບຕໍ່ໄປ.
ເລືອກອັນທີສອງທີ່ມີຄວາມເປັນໄປໄດ້ 50%, ຖ້າບໍ່ດັ່ງນັ້ນໄປກັບກົດລະບຽບຕໍ່ໄປ.
ເລືອກທີສາມພາຍໃຕ້.

ລະບົບນີ້ສົ່ງຜົນໃຫ້ແຕ່ລະຝັກຖືກເລືອກດ້ວຍຄວາມເປັນໄປໄດ້ 33%.

ແລະບໍ່ມີການຮັບປະກັນວ່າ Pod 2 ຈະຖືກເລືອກຕໍ່ໄປຫຼັງຈາກ Pod 1.

Примечание: iptables ໃຊ້ໂມດູນສະຖິຕິທີ່ມີການແຈກຢາຍແບບສຸ່ມ. ດັ່ງນັ້ນ, ສູດການດຸ່ນດ່ຽງແມ່ນອີງໃສ່ການເລືອກແບບສຸ່ມ.

ໃນປັດຈຸບັນທີ່ທ່ານເຂົ້າໃຈວິທີການເຮັດວຽກຂອງການບໍລິການ, ໃຫ້ພວກເຮົາເບິ່ງສະຖານະການການບໍລິການທີ່ຫນ້າສົນໃຈຫຼາຍ.

ການເຊື່ອມຕໍ່ທີ່ມີອາຍຸຍາວນານໃນ Kubernetes ບໍ່ໄດ້ປັບຂະຫນາດຕາມຄ່າເລີ່ມຕົ້ນ

ແຕ່ລະຄໍາຮ້ອງຂໍ HTTP ຈາກ frontend ກັບ backend ແມ່ນໃຫ້ບໍລິການໂດຍການເຊື່ອມຕໍ່ TCP ແຍກຕ່າງຫາກ, ເຊິ່ງເປີດແລະປິດ.

ຖ້າ frontend ສົ່ງ 100 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີໄປຫາ backend, ຫຼັງຈາກນັ້ນ 100 ການເຊື່ອມຕໍ່ TCP ທີ່ແຕກຕ່າງກັນແມ່ນເປີດແລະປິດ.

ທ່ານສາມາດຫຼຸດຜ່ອນເວລາການຮ້ອງຂໍແລະການໂຫຼດໄດ້ໂດຍການເປີດການເຊື່ອມຕໍ່ TCP ຫນຶ່ງແລະນໍາໃຊ້ມັນສໍາລັບການຮ້ອງຂໍ HTTP ຕໍ່ໄປທັງຫມົດ.

ໂປຣໂຕຄໍ HTTP ມີຄຸນສົມບັດທີ່ເອີ້ນວ່າ HTTP Keep-alive, ຫຼືການເຊື່ອມຕໍ່ໃຊ້ຄືນ. ໃນກໍລະນີນີ້, ການເຊື່ອມຕໍ່ TCP ດຽວຖືກນໍາໃຊ້ເພື່ອສົ່ງແລະຮັບຄໍາຮ້ອງຂໍ HTTP ຫຼາຍແລະຄໍາຕອບ:

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

ການຕິດຕັ້ງຕົວມັນເອງແມ່ນງ່າຍດາຍແລະສາມາດເຂົ້າເຖິງໄດ້ສໍາລັບພາສາການຂຽນໂປລແກລມແລະສະພາບແວດລ້ອມສ່ວນໃຫຍ່.

ນີ້ແມ່ນບາງລິ້ງໄປຫາຕົວຢ່າງໃນພາສາຕ່າງໆ:

ຈະເກີດຫຍັງຂຶ້ນຖ້າພວກເຮົາໃຊ້ Keep-alive ໃນການບໍລິການ Kubernetes?
ໃຫ້ສົມມຸດວ່າທັງ frontend ແລະ backend ສະຫນັບສະຫນູນຮັກສາຊີວິດ.

ພວກເຮົາມີສະບັບຫນຶ່ງຂອງ frontend ແລະສາມສໍາເນົາຂອງ backend. Frontend ເຮັດການຮ້ອງຂໍທໍາອິດແລະເປີດການເຊື່ອມຕໍ່ TCP ກັບ backend ໄດ້. ການຮ້ອງຂໍໄປຮອດການບໍລິການ, ຫນຶ່ງໃນ backend pods ຖືກເລືອກເປັນທີ່ຢູ່ປາຍທາງ. backend ສົ່ງຄໍາຕອບ, ແລະ frontend ໄດ້ຮັບມັນ.

ບໍ່ເຫມືອນກັບສະຖານະການປົກກະຕິທີ່ການເຊື່ອມຕໍ່ TCP ປິດຫຼັງຈາກໄດ້ຮັບການຕອບສະຫນອງ, ມັນໄດ້ຖືກເກັບຮັກສາໄວ້ສໍາລັບການຮ້ອງຂໍ HTTP ເພີ່ມເຕີມ.

ຈະເກີດຫຍັງຂຶ້ນຖ້າ frontend ສົ່ງຄໍາຮ້ອງຂໍເພີ່ມເຕີມໄປຫາ backend?

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

iptables ບໍ່ຄວນແຈກຢາຍການຈະລາຈອນຄືນໃຫມ່ບໍ?

ບໍ່ແມ່ນໃນກໍລະນີນີ້.

ເມື່ອການເຊື່ອມຕໍ່ TCP ຖືກສ້າງຂື້ນ, ມັນຈະຜ່ານກົດລະບຽບ iptables, ເຊິ່ງເລືອກ backend ສະເພາະບ່ອນທີ່ການຈະລາຈອນຈະໄປ.

ເນື່ອງຈາກການຮ້ອງຂໍຕໍ່ໄປທັງຫມົດແມ່ນຢູ່ໃນການເຊື່ອມຕໍ່ TCP ທີ່ເປີດຢູ່ແລ້ວ, ກົດລະບຽບ iptables ບໍ່ໄດ້ຖືກເອີ້ນອີກຕໍ່ໄປ.

ຂໍໃຫ້ເບິ່ງວ່າມັນມີລັກສະນະແນວໃດ.

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

ຜົນໄດ້ຮັບແມ່ນເວລາຕອບໂຕ້ໄວຂຶ້ນ ແລະສົ່ງສັນຍານທີ່ສູງຂຶ້ນ, ແຕ່ທ່ານສູນເສຍຄວາມສາມາດໃນການປັບຂະຫນາດຂອງ backend.

ເຖິງແມ່ນວ່າທ່ານມີສອງຝັກໃນ backend, ດ້ວຍການເຊື່ອມຕໍ່ຄົງທີ່, ການຈະລາຈອນຈະໄປຫາຫນຶ່ງໃນນັ້ນສະເຫມີ.

ນີ້ສາມາດແກ້ໄຂໄດ້ບໍ?

ເນື່ອງຈາກ Kubernetes ບໍ່ຮູ້ວິທີດຸ່ນດ່ຽງການເຊື່ອມຕໍ່ທີ່ຄົງຄ້າງ, ວຽກງານນີ້ຈະຕົກຢູ່ກັບເຈົ້າ.

ການບໍລິການແມ່ນການເກັບກໍາທີ່ຢູ່ IP ແລະພອດທີ່ເອີ້ນວ່າ endpoints.

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

ຫຼືສະໝັກເພີ່ມເຕີມ ຂັ້ນຕອນການດຸ່ນດ່ຽງທີ່ຊັບຊ້ອນ.

ລະຫັດຝ່າຍລູກຄ້າທີ່ຮັບຜິດຊອບໃນການດຸ່ນດ່ຽງຄວນປະຕິບັດຕາມເຫດຜົນນີ້:

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

ນີ້ແມ່ນສິ່ງທີ່ມັນຈະມີລັກສະນະ.

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

ໃນປັດຈຸບັນຄໍາຖາມທີ່ເກີດຂື້ນ: ບັນຫານີ້ໃຊ້ກັບ HTTP Keep-alive ເທົ່ານັ້ນບໍ?

ການດຸ່ນດ່ຽງການໂຫຼດຂ້າງລູກຄ້າ

HTTP ບໍ່ແມ່ນໂປໂຕຄອນດຽວທີ່ສາມາດໃຊ້ການເຊື່ອມຕໍ່ TCP ຢ່າງຕໍ່ເນື່ອງ.

ຖ້າຄໍາຮ້ອງສະຫມັກຂອງທ່ານໃຊ້ຖານຂໍ້ມູນ, ຫຼັງຈາກນັ້ນການເຊື່ອມຕໍ່ TCP ບໍ່ໄດ້ເປີດທຸກຄັ້ງທີ່ທ່ານຕ້ອງການເຮັດການຮ້ອງຂໍຫຼືເອົາເອກະສານຈາກຖານຂໍ້ມູນ.

ແທນທີ່ຈະ, ການເຊື່ອມຕໍ່ TCP ຢ່າງຕໍ່ເນື່ອງກັບຖານຂໍ້ມູນແມ່ນເປີດແລະຖືກນໍາໃຊ້.

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

ການຈໍາລອງຖານຂໍ້ມູນອັນໜຶ່ງຈະຖືກໂຫຼດຫຼາຍກວ່າອັນອື່ນ. Kube-proxy ແລະ Kubernetes ຈະບໍ່ຊ່ວຍດຸ່ນດ່ຽງການເຊື່ອມຕໍ່. ທ່ານຕ້ອງເອົາໃຈໃສ່ໃນການດຸ່ນດ່ຽງການສອບຖາມກັບຖານຂໍ້ມູນຂອງທ່ານ.

ອີງຕາມຫ້ອງສະຫມຸດທີ່ທ່ານໃຊ້ເພື່ອເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນ, ທ່ານອາດຈະມີທາງເລືອກທີ່ແຕກຕ່າງກັນສໍາລັບການແກ້ໄຂບັນຫານີ້.

ຂ້າງລຸ່ມນີ້ແມ່ນຕົວຢ່າງຂອງການເຂົ້າເຖິງກຸ່ມຖານຂໍ້ມູນ MySQL ຈາກ Node.js:

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

ມີຫຼາຍໂປໂຕຄອນອື່ນໆທີ່ໃຊ້ການເຊື່ອມຕໍ່ TCP ຢ່າງຕໍ່ເນື່ອງ:

WebSockets ແລະ WebSockets ທີ່ປອດໄພ
HTTP / 2
ກ. ພ. ພ
RSockets
AMQP

ທ່ານຄວນຄຸ້ນເຄີຍກັບໂປໂຕຄອນສ່ວນໃຫຍ່ເຫຼົ່ານີ້ແລ້ວ.

ແຕ່ຖ້າໂປໂຕຄອນເຫຼົ່ານີ້ເປັນທີ່ນິຍົມຫຼາຍ, ເປັນຫຍັງບໍ່ມີການແກ້ໄຂການດຸ່ນດ່ຽງມາດຕະຖານ? ເປັນຫຍັງເຫດຜົນຂອງລູກຄ້າຈໍາເປັນຕ້ອງມີການປ່ຽນແປງ? ມີການແກ້ໄຂ Kubernetes ພື້ນເມືອງບໍ?

Kube-proxy ແລະ iptables ຖືກອອກແບບມາເພື່ອໃຫ້ກວມເອົາກໍລະນີທີ່ໃຊ້ທົ່ວໄປສ່ວນໃຫຍ່ເມື່ອນຳໃຊ້ກັບ Kubernetes. ນີ້ແມ່ນເພື່ອຄວາມສະດວກ.

ຖ້າທ່ານກໍາລັງໃຊ້ການບໍລິການເວັບທີ່ເປີດເຜີຍ REST API, ທ່ານກໍາລັງໂຊກດີ - ໃນກໍລະນີນີ້, ການເຊື່ອມຕໍ່ TCP ຄົງທີ່ບໍ່ໄດ້ຖືກນໍາໃຊ້, ທ່ານສາມາດໃຊ້ບໍລິການ Kubernetes ໃດໆ.

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

ຢ່າງໃດກໍຕາມ, ແນ່ນອນວ່າມີທາງເລືອກທີ່ສາມາດຊ່ວຍໄດ້.

ການດຸ່ນດ່ຽງການເຊື່ອມຕໍ່ທີ່ມີອາຍຸຍາວນານໃນ Kubernetes

ມີສີ່ປະເພດຂອງການບໍລິການໃນ Kubernetes:

ClusterIP
NodePort
LoadBalancer
ບໍ່ມີຫົວ

ສາມບໍລິການທໍາອິດດໍາເນີນການໂດຍອີງໃສ່ທີ່ຢູ່ IP virtual, ເຊິ່ງຖືກນໍາໃຊ້ໂດຍ kube-proxy ເພື່ອສ້າງກົດລະບຽບ iptables. ແຕ່ພື້ນຖານພື້ນຖານຂອງການບໍລິການທັງຫມົດແມ່ນການບໍລິການທີ່ບໍ່ມີຫົວ.

ການບໍລິການ headless ບໍ່ມີທີ່ຢູ່ IP ທີ່ກ່ຽວຂ້ອງກັບມັນແລະພຽງແຕ່ສະຫນອງກົນໄກສໍາລັບການດຶງບັນຊີລາຍຊື່ຂອງທີ່ຢູ່ IP ແລະພອດຂອງຝັກ (ຈຸດສິ້ນສຸດ) ທີ່ກ່ຽວຂ້ອງກັບມັນ.

ການບໍລິການທັງຫມົດແມ່ນອີງໃສ່ການບໍລິການ headless.

ການບໍລິການ ClusterIP ແມ່ນການບໍລິການທີ່ບໍ່ມີຫົວດ້ວຍການເພີ່ມເຕີມບາງຢ່າງ:

ຊັ້ນການຈັດການມອບໝາຍໃຫ້ມັນເປັນທີ່ຢູ່ IP.
Kube-proxy ສ້າງກົດລະບຽບ iptables ທີ່ຈໍາເປັນ.

ວິທີນີ້ທ່ານສາມາດລະເລີຍ kube-proxy ແລະນໍາໃຊ້ໂດຍກົງບັນຊີລາຍຊື່ຂອງຈຸດສິ້ນສຸດທີ່ໄດ້ຮັບຈາກການບໍລິການ headless ເພື່ອໂຫຼດຍອດເງິນຄໍາຮ້ອງສະຫມັກຂອງທ່ານ.

ແຕ່ພວກເຮົາສາມາດເພີ່ມເຫດຜົນທີ່ຄ້າຍຄືກັນກັບທຸກແອັບພລິເຄຊັນທີ່ຖືກນໍາໃຊ້ໃນກຸ່ມໄດ້ແນວໃດ?

ຖ້າແອັບພລິເຄຊັນຂອງທ່ານຖືກນຳໃຊ້ແລ້ວ, ວຽກງານນີ້ອາດເບິ່ງຄືວ່າເປັນໄປບໍ່ໄດ້. ຢ່າງໃດກໍຕາມ, ມີທາງເລືອກອື່ນ.

Service Mesh ຈະຊ່ວຍທ່ານໄດ້

ທ່ານອາດຈະສັງເກດເຫັນແລ້ວວ່າຍຸດທະສາດການດຸ່ນດ່ຽງການໂຫຼດດ້ານລູກຄ້າແມ່ນຂ້ອນຂ້າງມາດຕະຖານ.

ເມື່ອແອັບພລິເຄຊັນເລີ່ມຕົ້ນ, ມັນ:

ໄດ້ຮັບບັນຊີລາຍຊື່ຂອງທີ່ຢູ່ IP ຈາກການບໍລິການ.
ເປີດແລະຮັກສາສະນຸກເກີການເຊື່ອມຕໍ່.
ອັບເດດສະລອຍນ້ຳເປັນໄລຍະໂດຍການເພີ່ມ ຫຼືລຶບຈຸດສິ້ນສຸດອອກ.

ເມື່ອແອັບພລິເຄຊັນຕ້ອງການເຮັດການຮ້ອງຂໍ, ມັນ:

ເລືອກການເຊື່ອມຕໍ່ທີ່ມີຢູ່ໂດຍໃຊ້ເຫດຜົນບາງຢ່າງ (ເຊັ່ນ: round-robin).
ປະຕິບັດການຮ້ອງຂໍ.

ຂັ້ນຕອນເຫຼົ່ານີ້ເຮັດວຽກສໍາລັບທັງສອງ WebSockets, gRPC, ແລະການເຊື່ອມຕໍ່ AMQP.

ທ່ານສາມາດແຍກເຫດຜົນນີ້ເຂົ້າໄປໃນຫ້ອງສະຫມຸດແຍກຕ່າງຫາກແລະນໍາໃຊ້ມັນໃນຄໍາຮ້ອງສະຫມັກຂອງທ່ານ.

ຢ່າງໃດກໍຕາມ, ທ່ານສາມາດນໍາໃຊ້ຕາຫນ່າງການບໍລິການເຊັ່ນ Istio ຫຼື Linkerd ແທນ.

Service Mesh ຂະຫຍາຍແອັບພລິເຄຊັນຂອງທ່ານດ້ວຍຂະບວນການທີ່:

ຄົ້ນຫາທີ່ຢູ່ IP ການບໍລິການໂດຍອັດຕະໂນມັດ.
ທົດສອບການເຊື່ອມຕໍ່ເຊັ່ນ WebSockets ແລະ gRPC.
ການດຸ່ນດ່ຽງການຮ້ອງຂໍໂດຍໃຊ້ໂປໂຕຄອນທີ່ຖືກຕ້ອງ.

Service Mesh ຊ່ວຍຈັດການການຈະລາຈອນພາຍໃນກຸ່ມ, ແຕ່ມັນຂ້ອນຂ້າງໃຊ້ຊັບພະຍາກອນຫຼາຍ. ທາງເລືອກອື່ນແມ່ນໃຊ້ຫ້ອງສະໝຸດພາກສ່ວນທີສາມເຊັ່ນ: Netflix Ribbon ຫຼືຕົວແທນທີ່ສາມາດຂຽນໂປຣແກຣມໄດ້ເຊັ່ນ: Envoy.

ຈະເກີດຫຍັງຂຶ້ນຖ້າທ່ານບໍ່ສົນໃຈບັນຫາການດຸ່ນດ່ຽງ?

ທ່ານສາມາດເລືອກທີ່ຈະບໍ່ໃຊ້ການດຸ່ນດ່ຽງການໂຫຼດແລະຍັງບໍ່ສັງເກດເຫັນການປ່ຽນແປງໃດໆ. ຂໍໃຫ້ເບິ່ງສະຖານະການເຮັດວຽກຈໍານວນຫນ້ອຍຫນຶ່ງ.

ຖ້າທ່ານມີລູກຄ້າຫຼາຍກວ່າເຄື່ອງແມ່ຂ່າຍ, ນີ້ບໍ່ແມ່ນບັນຫາໃຫຍ່.

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

ການເຊື່ອມຕໍ່ອາດຈະບໍ່ຖືກແຈກຢາຍເທົ່າທຽມກັນ: ບາງທີລູກຄ້າສີ່ຄົນເຊື່ອມຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍດຽວກັນ, ແຕ່ມີໂອກາດດີທີ່ເຄື່ອງແມ່ຂ່າຍທັງສອງຈະຖືກນໍາໃຊ້.

ສິ່ງທີ່ເປັນບັນຫາຫຼາຍແມ່ນສະຖານະການກົງກັນຂ້າມ.

ຖ້າທ່ານມີລູກຄ້າຫນ້ອຍລົງແລະເຄື່ອງແມ່ຂ່າຍຫຼາຍ, ຊັບພະຍາກອນຂອງທ່ານອາດຈະຖືກໃຊ້ຫນ້ອຍລົງແລະຂໍ້ບົກຜ່ອງທີ່ອາດຈະເກີດຂື້ນ.

ໃຫ້ເວົ້າວ່າມີສອງລູກຄ້າແລະຫ້າເຄື່ອງແມ່ຂ່າຍ. ໃນກໍລະນີທີ່ດີທີ່ສຸດ, ຈະມີສອງການເຊື່ອມຕໍ່ຖາວອນກັບສອງເຄື່ອງແມ່ຂ່າຍອອກຈາກຫ້າ.

ເຊີບເວີທີ່ຍັງເຫຼືອຈະບໍ່ເຮັດວຽກ:

ຖ້າສອງເຊີບເວີເຫຼົ່ານີ້ບໍ່ສາມາດຈັດການຄໍາຮ້ອງຂໍຂອງລູກຄ້າໄດ້, ການປັບຂະຫນາດຕາມລວງນອນຈະບໍ່ຊ່ວຍໄດ້.

ສະຫລຸບ

ບໍລິການ Kubernetes ຖືກອອກແບບມາເພື່ອເຮັດວຽກໃນສະຖານະການແອັບພລິເຄຊັນເວັບມາດຕະຖານສ່ວນໃຫຍ່.

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

ນີ້ຫມາຍຄວາມວ່າທ່ານຕ້ອງຂຽນຄໍາຮ້ອງສະຫມັກທີ່ມີການດຸ່ນດ່ຽງດ້ານລູກຄ້າຢູ່ໃນໃຈ.

ການແປທີ່ກະກຽມໂດຍທີມງານ Kubernetes aaS ຈາກ Mail.ru.

ມີຫຍັງອີກແດ່ທີ່ຈະອ່ານກ່ຽວກັບຫົວຂໍ້:

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

ໂຫຼດການດຸ່ນດ່ຽງ ແລະຂະຫຍາຍການເຊື່ອມຕໍ່ທີ່ມີອາຍຸຍາວນານໃນ Kubernetes