🥇Ingress Controllers ສໍາລັບ Kubernetes ການທົບທວນຄືນແລະການປຽບທຽບ

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

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

ເງື່ອນໄຂ

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

ແຕ່ຂ້ອຍຈະເລີ່ມຕົ້ນດ້ວຍຄຸນລັກສະນະທີ່ຄຸ້ນເຄີຍຫຼາຍທີ່ພວກເຂົາຖືກປະຕິບັດໃນທຸກການແກ້ໄຂແລະບໍ່ໄດ້ຖືກພິຈາລະນາ:

ການຄົ້ນພົບການບໍລິການແບບເຄື່ອນໄຫວ;
ການຢຸດເຊົາ SSL;
ເຮັດວຽກກັບ websockets.

ໃນປັດຈຸບັນກ່ຽວກັບຈຸດປຽບທຽບ:

ໂປຣໂຕຄອນທີ່ຮອງຮັບ

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

ຊອບແວຢູ່ໃນຫຼັກ

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

ເສັ້ນທາງຈະລາຈອນ

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

Namespace ພາຍໃນກຸ່ມ

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

ຕົວຢ່າງສໍາລັບຕົ້ນນ້ໍາ

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

ຂັ້ນຕອນການດຸ່ນດ່ຽງ

ມີຫຼາຍທາງເລືອກ: ຈາກແບບດັ້ງເດີມ ຮອບຜູ້ ກັບຄົນ exotic rdp-cookie, ເຊັ່ນດຽວກັນກັບລັກສະນະສ່ວນບຸກຄົນເຊັ່ນ: ເຊດຊັນຫນຽວ.

ການຢືນຢັນ

ໂຄງການການອະນຸຍາດໃດທີ່ຜູ້ຄວບຄຸມສະຫນັບສະຫນູນ? ພື້ນຖານ, digest, oauth, external-auth - ຂ້າພະເຈົ້າຄິດວ່າທາງເລືອກເຫຼົ່ານີ້ຄວນຈະຄຸ້ນເຄີຍ. ນີ້ແມ່ນເງື່ອນໄຂທີ່ສໍາຄັນຖ້າຫາກວ່າມີນັກພັດທະນາຈໍານວນຫຼາຍ (ແລະ / ຫຼືເອກະຊົນ) loops ທີ່ເຂົ້າເຖິງໂດຍຜ່ານ Ingress.

ການແຜ່ກະຈາຍການຈະລາຈອນ

ຕົວຄວບຄຸມສະຫນັບສະຫນູນກົນໄກທີ່ໃຊ້ທົ່ວໄປດັ່ງກ່າວສໍາລັບການແຈກຢາຍການຈະລາຈອນເຊັ່ນ: ມ້ວນ canary, ການທົດສອບ A / B, mirroring / shadowing ບໍ? ນີ້ແມ່ນວິຊາທີ່ເຈັບປວດຢ່າງແທ້ຈິງສໍາລັບຄໍາຮ້ອງສະຫມັກທີ່ຕ້ອງການການຄຸ້ມຄອງການຈະລາຈອນທີ່ລະມັດລະວັງແລະຊັດເຈນສໍາລັບການທົດສອບການຜະລິດ, ການແກ້ໄຂຂໍ້ຜິດພາດຂອງຜະລິດຕະພັນໂດຍບໍ່ມີການຕໍ່ສູ້ (ຫຼືມີການສູນເສຍຫນ້ອຍ), ການວິເຄາະການຈະລາຈອນ, ແລະອື່ນໆ.

ການສະໝັກໃຊ້ທີ່ຈ່າຍແລ້ວ

ມີທາງເລືອກທີ່ຈ່າຍສໍາລັບຕົວຄວບຄຸມທີ່ມີຫນ້າທີ່ປັບປຸງແລະ / ຫຼືການສະຫນັບສະຫນູນດ້ານວິຊາການບໍ?

ການໂຕ້ຕອບແບບກຣາຟິກ (Web UI)

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

ການກວດສອບ JWT

ຄວາມພ້ອມຂອງການກວດສອບໃນຕົວຂອງ tokens ເວັບ JSON ສໍາລັບການອະນຸຍາດແລະການກວດສອບຜູ້ໃຊ້ສໍາລັບຄໍາຮ້ອງສະຫມັກສຸດທ້າຍ.

ຄວາມເປັນໄປໄດ້ສໍາລັບການປັບແຕ່ງ config

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

ກົນໄກການປ້ອງກັນ DDOS ພື້ນຖານ

ຂັ້ນຕອນການຈຳກັດອັດຕາແບບງ່າຍໆ ຫຼືທາງເລືອກທີ່ສັບສົນຫຼາຍສຳລັບການກັ່ນຕອງການສັນຈອນໂດຍອີງໃສ່ທີ່ຢູ່, ບັນຊີຂາວ, ປະເທດ, ແລະອື່ນໆ.

ຮ້ອງຂໍການຕິດຕາມ

ຄວາມສາມາດໃນການຕິດຕາມ, ຕິດຕາມແລະແກ້ໄຂຄໍາຮ້ອງສະຫມັກຈາກ Ingress ກັບການບໍລິການສະເພາະ / pods, ແລະໂດຍສະເພາະແມ່ນລະຫວ່າງການບໍລິການ / pods ເກີນໄປ.

waff

ສະຫນັບສະຫນູນ ແອັບພລິເຄຊັນໄຟວໍ.

Ingress Controllers

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

ຂາເຂົ້າຈາກ Kubernetes

ເວັບໄຊທ໌: github.com/kubernetes/ingress-nginx
ໃບອະນຸຍາດ: Apache 2.0

ນີ້ແມ່ນຕົວຄວບຄຸມຢ່າງເປັນທາງການສໍາລັບ Kubernetes ແລະຖືກພັດທະນາໂດຍຊຸມຊົນ. ແນ່ນອນຈາກຊື່, ມັນແມ່ນອີງໃສ່ nginx ແລະຖືກປະກອບໂດຍຊຸດຕ່າງໆຂອງ Lua plugins ທີ່ໃຊ້ເພື່ອປະຕິບັດຄຸນສົມບັດເພີ່ມເຕີມ. ເນື່ອງຈາກຄວາມນິຍົມຂອງ nginx ຕົວຂອງມັນເອງແລະການດັດແກ້ຫນ້ອຍທີ່ສຸດໃນເວລາທີ່ໃຊ້ເປັນຕົວຄວບຄຸມ, ທາງເລືອກນີ້ສາມາດເປັນການຕັ້ງຄ່າທີ່ງ່າຍທີ່ສຸດແລະເຂົ້າໃຈໄດ້ຫຼາຍທີ່ສຸດສໍາລັບວິສະວະກອນສະເລ່ຍ (ມີປະສົບການໃນເວັບ).

Ingress ໂດຍ NGINX Inc

ເວັບໄຊທ໌: github.com/nginxinc/kubernetes-ingress
ໃບອະນຸຍາດ: Apache 2.0

ຜະລິດຕະພັນຢ່າງເປັນທາງການຂອງນັກພັດທະນາ nginx. ມີສະບັບຈ່າຍໂດຍອີງໃສ່ NGINX Plus. ແນວຄວາມຄິດຕົ້ນຕໍແມ່ນລະດັບຄວາມຫມັ້ນຄົງສູງ, ຄວາມເຂົ້າກັນໄດ້ກັບຄືນໄປບ່ອນຄົງທີ່, ບໍ່ມີໂມດູນ extraneous ໃດແລະຄວາມໄວເພີ່ມຂຶ້ນປະກາດ (ເມື່ອປຽບທຽບກັບຕົວຄວບຄຸມຢ່າງເປັນທາງການ), ບັນລຸໄດ້ຍ້ອນການປະຖິ້ມຂອງ Lua.

ສະບັບຟຣີໄດ້ຖືກຕັດລົງຢ່າງຫຼວງຫຼາຍ, ລວມທັງເຖິງແມ່ນວ່າເມື່ອປຽບທຽບກັບຕົວຄວບຄຸມຢ່າງເປັນທາງການ (ເນື່ອງຈາກການຂາດໂມດູນ Lua ດຽວກັນ). ສະບັບທີ່ຈ່າຍມີລະດັບຄວາມກ້ວາງຂອງການເຮັດວຽກເພີ່ມເຕີມ: metrics ໃນເວລາທີ່ແທ້ຈິງ, ການກວດສອບ JWT, ການກວດສອບສຸຂະພາບແລະອື່ນໆອີກ. ປະໂຫຍດທີ່ສໍາຄັນຕໍ່ NGINX Ingress ແມ່ນການສະຫນັບສະຫນູນຢ່າງເຕັມທີ່ສໍາລັບການຈະລາຈອນ TCP / UDP (ແລະໃນສະບັບຊຸມຊົນເຊັ່ນກັນ!). ລົບ - ການຂາດ ຄຸນນະສົມບັດສໍາລັບການແຈກຢາຍການຈະລາຈອນ, ເຊິ່ງ, ຢ່າງໃດກໍຕາມ, "ມີບູລິມະສິດສູງສຸດສໍາລັບນັກພັດທະນາ," ແຕ່ໃຊ້ເວລາໃນການປະຕິບັດ.

ກົງ Ingress

ເວັບໄຊທ໌: github.com/Kong/kubernetes-ingress-controller
ໃບອະນຸຍາດ: Apache 2.0

ຜະລິດຕະພັນພັດທະນາໂດຍ Kong Inc. ໃນສອງສະບັບ: ການຄ້າແລະການຟຣີ. ອີງໃສ່ nginx, ຄວາມສາມາດທີ່ຂະຫຍາຍອອກໂດຍໂມດູນ Lua ຈໍານວນຫລາຍ.

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

ລັກສະນະທີ່ສໍາຄັນຂອງຜະລິດຕະພັນ - ການເຮັດວຽກພາຍໃນວົງຈອນຫນຶ່ງ (ແທນທີ່ຈະ cross-namespaced) ເປັນຫົວຂໍ້ທີ່ມີການໂຕ້ຖຽງກັນ: ສໍາລັບບາງຄົນມັນຈະເບິ່ງຄືວ່າເປັນຂໍ້ເສຍ (ທ່ານຕ້ອງສ້າງຫນ່ວຍງານສໍາລັບແຕ່ລະວົງຈອນ), ແຕ່ສໍາລັບຄົນອື່ນມັນຈະເປັນລັກສະນະ. (ຂоລະດັບສູງຂອງ insulation, ເນື່ອງຈາກວ່າ ຖ້າຕົວຄວບຄຸມຫນຶ່ງແຕກ, ບັນຫາແມ່ນຈໍາກັດພຽງແຕ່ຫນຶ່ງວົງຈອນ).

Traefik

ເວັບໄຊທ໌: github.com/containous/traefik
ໃບອະນຸຍາດ: MIT

ພຣັອກຊີທີ່ສ້າງຂຶ້ນໃນເບື້ອງຕົ້ນເພື່ອເຮັດວຽກກັບເສັ້ນທາງການຮ້ອງຂໍສໍາລັບການບໍລິການຈຸລະພາກ ແລະສະພາບແວດລ້ອມແບບເຄື່ອນໄຫວຂອງພວກມັນ. ດັ່ງນັ້ນ, ຄຸນນະສົມບັດທີ່ເປັນປະໂຫຍດຫຼາຍ: ການປັບປຸງການຕັ້ງຄ່າໂດຍບໍ່ມີການ reboots ທັງຫມົດ, ສະຫນັບສະຫນູນສໍາລັບການຈໍານວນຂະຫນາດໃຫຍ່ຂອງວິທີການດຸ່ນດ່ຽງ, ການໂຕ້ຕອບເວັບໄຊຕ໌, metrics ການສົ່ງຕໍ່, ສະຫນັບສະຫນູນສໍາລັບໂປໂຕຄອນຕ່າງໆ, REST API, ການປ່ອຍ canary ແລະອື່ນໆອີກ. ຄຸນນະສົມບັດທີ່ດີແມ່ນຍັງສະຫນັບສະຫນູນສໍາລັບ Let's Encrypt ໃບຢັ້ງຢືນອອກຈາກກ່ອງ. ຂໍ້ເສຍ - ເພື່ອຈັດຕັ້ງການມີຢູ່ສູງ (HA), ຜູ້ຄວບຄຸມຈະຕ້ອງຕິດຕັ້ງແລະເຊື່ອມຕໍ່ການເກັບຮັກສາ KV ຂອງຕົນເອງ.

HAProxy

ເວັບໄຊທ໌: github.com/jcmoraisjr/haproxy-ingress
ໃບອະນຸຍາດ: Apache 2.0

HAProxy ເປັນທີ່ຮູ້ກັນມາດົນນານວ່າເປັນຕົວດຸ່ນດ່ຽງຕົວແທນ ແລະການຈະລາຈອນ. ພາຍໃນກຸ່ມ Kubernetes, ມັນສະຫນອງການປັບປຸງການຕັ້ງຄ່າ "ອ່ອນ" (ໂດຍບໍ່ມີການສູນເສຍການຈະລາຈອນ), ການຄົ້ນພົບການບໍລິການທີ່ອີງໃສ່ DNS, ແລະການຕັ້ງຄ່າແບບເຄື່ອນໄຫວໂດຍໃຊ້ API. ມັນອາດຈະເປັນສິ່ງທີ່ຫນ້າສົນໃຈທີ່ຈະປັບແຕ່ງແບບ config ຢ່າງສົມບູນໂດຍການປ່ຽນແທນ CM, ເຊັ່ນດຽວກັນກັບຄວາມເປັນໄປໄດ້ຂອງການນໍາໃຊ້ຫນ້າທີ່ຂອງຫ້ອງສະຫມຸດ Sprig ໃນມັນ. ໂດຍທົ່ວໄປ, ຄວາມສໍາຄັນຕົ້ນຕໍຂອງການແກ້ໄຂແມ່ນກ່ຽວກັບຄວາມໄວສູງ, ການເພີ່ມປະສິດທິພາບແລະປະສິດທິພາບຂອງມັນໃນຊັບພະຍາກອນທີ່ບໍລິໂພກ. ປະໂຫຍດຂອງຕົວຄວບຄຸມແມ່ນວ່າມັນສະຫນັບສະຫນູນຈໍານວນບັນທຶກຂອງວິທີການດຸ່ນດ່ຽງທີ່ແຕກຕ່າງກັນ.

Voyager

ເວັບໄຊທ໌: github.com/appscode/voyager
ໃບອະນຸຍາດ: Apache 2.0

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

ວົງຈອນ

ເວັບໄຊທ໌: github.com/heptio/contour
ໃບອະນຸຍາດ: Apache 2.0

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

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

Istio Ingress

ເວັບໄຊທ໌: istio.io/docs/tasks/traffic-management/ingress
ໃບອະນຸຍາດ: Apache 2.0

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

Ambassador

ເວັບໄຊທ໌: github.com/datawire/ambassador
ໃບອະນຸຍາດ: Apache 2.0

ການແກ້ໄຂອື່ນໂດຍອີງໃສ່ Envoy. ມັນມີສະບັບຟຣີແລະການຄ້າ. ຖືກຕັ້ງເປັນ "ບ້ານເດີມຂອງ Kubernetes", ເຊິ່ງນໍາເອົາຜົນປະໂຫຍດທີ່ສອດຄ້ອງກັນ (ການເຊື່ອມໂຍງຢ່າງແຫນ້ນຫນາກັບວິທີການແລະຫນ່ວຍງານຂອງກຸ່ມ K8s).

ຕາຕະລາງການປຽບທຽບ

ດັ່ງນັ້ນ, ຈຸດສູງສຸດຂອງບົດຄວາມແມ່ນຕາຕະລາງຂະຫນາດໃຫຍ່ນີ້:

ມັນສາມາດຄລິກໄດ້ສໍາລັບການເບິ່ງລາຍລະອຽດເພີ່ມເຕີມ, ແລະຍັງມີຢູ່ໃນຮູບແບບ Google Sheets.

ໃຫ້ສົມກຽດ

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

Classic Ingress ຈາກ Kubernetes ແມ່ນດີສໍາລັບການເຂົ້າເຖິງແລະຄວາມຫນ້າເຊື່ອຖື, ຄວາມສາມາດທີ່ອຸດົມສົມບູນພໍສົມຄວນ - ໃນກໍລະນີທົ່ວໄປ, ມັນຄວນຈະ "ພຽງພໍສໍາລັບຕາ". ຢ່າງໃດກໍຕາມ, ຖ້າທ່ານມີຄວາມຕ້ອງການເພີ່ມຂຶ້ນສໍາລັບຄວາມຫມັ້ນຄົງ, ລະດັບຂອງລັກສະນະແລະການພັດທະນາ, ທ່ານຄວນເອົາໃຈໃສ່ກັບ Ingress ກັບ NGINX Plus ແລະການສະຫມັກທີ່ຈ່າຍ. Kong ມີຊຸດ plugins ທີ່ອຸດົມສົມບູນ (ແລະ, ຕາມຄວາມເຫມາະສົມ, ຄວາມສາມາດທີ່ເຂົາເຈົ້າສະຫນອງ), ແລະມີຫຼາຍກວ່ານັ້ນໃນສະບັບຈ່າຍ. ມັນມີຄວາມສາມາດພຽງພໍໃນການເຮັດວຽກເປັນ API Gateway, ການຕັ້ງຄ່າແບບເຄື່ອນໄຫວໂດຍອີງໃສ່ຊັບພະຍາກອນ CRD, ເຊັ່ນດຽວກັນກັບການບໍລິການ Kubernetes ພື້ນຖານ.

ຖ້າທ່ານມີຄວາມຕ້ອງການເພີ່ມເຕີມສໍາລັບການດຸ່ນດ່ຽງແລະວິທີການອະນຸຍາດ, ໃຫ້ເບິ່ງທີ່ໃກ້ຊິດກັບ Traefik ແລະ HAProxy. ເຫຼົ່ານີ້ແມ່ນໂຄງການ Open Source, ພິສູດໃນປີທີ່ຜ່ານມາ, ມີຄວາມຫມັ້ນຄົງຫຼາຍແລະພັດທະນາຢ່າງຫ້າວຫັນ. Contour ໄດ້ປະມານສອງສາມປີແລ້ວ, ແຕ່ມັນຍັງເບິ່ງອ່ອນເກີນໄປແລະມີພຽງແຕ່ລັກສະນະພື້ນຖານທີ່ເພີ່ມໃສ່ເທິງຂອງ Envoy. ຖ້າມີຄວາມຕ້ອງການສໍາລັບການມີ / ການຝັງ WAF ຢູ່ທາງຫນ້າຂອງແອັບພລິເຄຊັນ, ທ່ານຄວນເອົາໃຈໃສ່ກັບ Ingress ດຽວກັນຈາກ Kubernetes ຫຼື HAProxy.

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

ພວກເຮົາເລືອກແລະຍັງໃຊ້ Ingress ຈາກ Kubernetes ເປັນຕົວຄວບຄຸມມາດຕະຖານ, ເຊິ່ງກວມເອົາ 80-90% ຂອງຄວາມຕ້ອງການຂອງພວກເຮົາ. ມັນເປັນທີ່ຂ້ອນຂ້າງຫນ້າເຊື່ອຖື, ງ່າຍທີ່ຈະຕັ້ງຄ່າ, ແລະຂະຫຍາຍ. ໂດຍທົ່ວໄປ, ເວັ້ນເສຍແຕ່ວ່າມີຄວາມຕ້ອງການສະເພາະ, ມັນຄວນຈະເຫມາະສົມກັບກຸ່ມ / ຄໍາຮ້ອງສະຫມັກສ່ວນໃຫຍ່. ຂອງຜະລິດຕະພັນດຽວກັນທົ່ວໄປແລະຂ້ອນຂ້າງງ່າຍດາຍ, ພວກເຮົາສາມາດແນະນໍາ Traefik ແລະ HAProxy.