ການປະເມີນປະສິດທິພາບ CNI ສໍາລັບ Kubernetes ຜ່ານເຄືອຂ່າຍ 10G (ເດືອນສິງຫາ 2020)

TL; DR: CNIs ທັງຫມົດເຮັດວຽກຕາມທີ່ຄວນ, ຍົກເວັ້ນ Kube-Router ແລະ Kube-OVN, Calico, ດ້ວຍການຍົກເວັ້ນຂອງການກວດສອບອັດຕະໂນມັດ MTU, ແມ່ນດີທີ່ສຸດ.

ການປັບປຸງບົດຄວາມຂອງການກວດສອບທີ່ຜ່ານມາຂອງຂ້ອຍ (2018 и 2019), ໃນເວລາທົດສອບຂ້ອຍກຳລັງໃຊ້ Kubernetes 1.19 ໃນ Ubuntu 18.04 ພ້ອມດ້ວຍ CNI ທີ່ອັບເດດແລ້ວສຳລັບເດືອນສິງຫາ 2020.

ກ່ອນທີ່ພວກເຮົາຈະເຂົ້າໄປໃນ metrics ...

ມີຫຍັງໃໝ່ຕັ້ງແຕ່ເດືອນເມສາ 2019?

• ສາມາດທົດສອບຢູ່ໃນກຸ່ມຂອງທ່ານເອງ: ທ່ານສາມາດດໍາເນີນການທົດສອບຢູ່ໃນກຸ່ມຂອງທ່ານເອງໂດຍໃຊ້ເຄື່ອງມືຂອງພວກເຮົາ Kubernetes Network Benchmark: knb
• ສະມາຊິກໃໝ່ໄດ້ປະກົດຕົວ
  • Antrea ຈາກ VMware Tanzu
  • Kube-OVN ຈາກ alauda.io
• ສະຖານະການໃຫມ່: ການກວດສອບປະຈຸບັນດໍາເນີນການທົດສອບປະສິດທິພາບເຄືອຂ່າຍ "Pod-to-Pod", ແລະ "Pod-to-Service" script ໃຫມ່ໄດ້ຖືກເພີ່ມທີ່ດໍາເນີນການທົດສອບໄດ້ໃກ້ຊິດກັບສະພາບຕົວຈິງ. ໃນການປະຕິບັດ, Pod ຂອງທ່ານກັບ API ເຮັດວຽກກັບພື້ນຖານເປັນການບໍລິການ, ແລະບໍ່ຜ່ານ Pod ip address (ແນ່ນອນພວກເຮົາກວດເບິ່ງທັງ TCP ແລະ UDP ສໍາລັບທັງສອງສະຖານະການ).
• ການບໍລິໂພກຊັບພະຍາກອນ: ແຕ່ລະການທົດສອບໃນປັດຈຸບັນມີການປຽບທຽບຊັບພະຍາກອນຂອງຕົນເອງ
• ການຖອນການທົດສອບຄໍາຮ້ອງສະຫມັກ: ພວກເຮົາບໍ່ໄດ້ເຮັດການທົດສອບ HTTP, FTP ແລະ SCP ອີກຕໍ່ໄປຍ້ອນວ່າການຮ່ວມມືທີ່ມີຫມາກຜົນຂອງພວກເຮົາກັບຊຸມຊົນແລະຜູ້ຮັກສາ CNI ໄດ້ຄົ້ນພົບຊ່ອງຫວ່າງລະຫວ່າງຜົນໄດ້ຮັບ iperf ຫຼາຍກວ່າ TCP ແລະຜົນ curl ເນື່ອງຈາກການຊັກຊ້າໃນການເລີ່ມຕົ້ນ CNI (ສອງສາມວິນາທີທໍາອິດຂອງ Pod ການເລີ່ມຕົ້ນ, ເຊິ່ງບໍ່ແມ່ນປົກກະຕິໃນສະພາບຕົວຈິງ).
• ແຫຼ່ງເປີດ: ແຫຼ່ງການທົດສອບທັງໝົດ (ສະຄຣິບ, ການຕັ້ງຄ່າ yml ແລະຂໍ້ມູນຕົ້ນສະບັບ “ດິບ”) ແມ່ນມີຢູ່ ທີ່ນີ້

ອະນຸສັນຍາການທົດສອບອ້າງອີງ

ພິທີການໄດ້ຖືກອະທິບາຍຢ່າງລະອຽດ ທີ່ນີ້, ກະລຸນາຮັບຊາບວ່າບົດຄວາມນີ້ແມ່ນອຸທິດໃຫ້ແກ່ Ubuntu 18.04 ດ້ວຍ kernel ເລີ່ມຕົ້ນ.

ການຄັດເລືອກ CNI ສໍາລັບການປະເມີນຜົນ

ການທົດສອບນີ້ແມ່ນແນໃສ່ການປຽບທຽບ CNIs ທີ່ຖືກຕັ້ງຄ່າດ້ວຍໄຟລ໌ yaml ຫນຶ່ງ (ດັ່ງນັ້ນ, ທັງຫມົດທີ່ຕິດຕັ້ງໂດຍ scripts, ເຊັ່ນ VPP ແລະອື່ນໆ, ແມ່ນຖືກຍົກເວັ້ນ).

CNIs ທີ່ເລືອກຂອງພວກເຮົາສໍາລັບການປຽບທຽບ:

• Antrea v.0.9.1
• Calico v3.16
• Canal v3.16 (ເຄືອຂ່າຍ Flannel + ນະໂຍບາຍເຄືອຂ່າຍ Calico)
• Cilium 1.8.2
• Flannel 0.12.0
• Kube-router ຫຼ້າສຸດ (2020-08-25)
• WeaveNet 2.7.0

ການຕັ້ງຄ່າ MTU ສໍາລັບ CNI

ກ່ອນອື່ນ ໝົດ, ພວກເຮົາກວດເບິ່ງຜົນກະທົບຂອງການກວດຫາ MTU ອັດຕະໂນມັດກ່ຽວກັບການປະຕິບັດ TCP:

ຜົນກະທົບຂອງ MTU ຕໍ່ການປະຕິບັດ TCP

ພົບຊ່ອງຫວ່າງທີ່ໃຫຍ່ກວ່າເມື່ອໃຊ້ UDP:

ຜົນກະທົບຂອງ MTU ຕໍ່ການປະຕິບັດ UDP

ເນື່ອງຈາກຜົນກະທົບດ້ານປະສິດທິພາບອັນໃຫຍ່ຫຼວງທີ່ເປີດເຜີຍໃນການທົດສອບ, ພວກເຮົາຕ້ອງການສົ່ງຈົດຫມາຍຄວາມຫວັງໄປຫາຜູ້ຮັກສາ CNI ທັງຫມົດ: ກະລຸນາເພີ່ມການກວດຫາ MTU ອັດຕະໂນມັດໃສ່ CNI. ທ່ານຈະຊ່ວຍປະຢັດ kittens, unicorns ແລະແມ້ກະທັ້ງຫນຶ່ງ cutest: ພຽງເລັກນ້ອຍ Devop.

ຢ່າງໃດກໍຕາມ, ຖ້າທ່ານຕ້ອງການໃຊ້ CNI ໂດຍບໍ່ມີການສະຫນັບສະຫນູນການກວດສອບ MTU ອັດຕະໂນມັດ, ທ່ານສາມາດຕັ້ງຄ່າມັນດ້ວຍຕົນເອງເພື່ອໃຫ້ໄດ້ປະສິດທິພາບ. ກະລຸນາສັງເກດວ່ານີ້ໃຊ້ກັບ Calico, Canal ແລະ WeaveNet.

ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຂະ​ຫນາດ​ນ້ອຍ​ຂອງ​ຂ້າ​ພະ​ເຈົ້າ​ກັບ CNIs ທີ່​ມາ​ພ້ອມ ...

ການທົດສອບ CNI: ຂໍ້ມູນດິບ

ໃນພາກນີ້, ພວກເຮົາຈະປຽບທຽບ CNI ກັບ MTU ທີ່ຖືກຕ້ອງ (ກໍານົດອັດຕະໂນມັດຫຼືຕັ້ງດ້ວຍຕົນເອງ). ເປົ້າຫມາຍຕົ້ນຕໍຢູ່ທີ່ນີ້ແມ່ນເພື່ອສະແດງຂໍ້ມູນດິບໃນກາຟ.

ນິທານສີ:

• ສີຂີ້ເຖົ່າ - ຕົວຢ່າງ (ເຊັ່ນ: ທາດເຫຼັກເປົ່າ)
• ສີຂຽວ - ແບນວິດສູງກວ່າ 9500 Mbps
• ສີເຫຼືອງ - ແບນວິດສູງກວ່າ 9000 Mbps
• ສີສົ້ມ - ແບນວິດສູງກວ່າ 8000 Mbps
• ສີແດງ - ແບນວິດຕ່ໍາກວ່າ 8000 Mbps
• ສີຟ້າ - ເປັນກາງ (ບໍ່ກ່ຽວຂ້ອງກັບແບນວິດ)

ການບໍລິໂພກຊັບພະຍາກອນທີ່ບໍ່ມີການໂຫຼດ

ກ່ອນອື່ນ ໝົດ, ກວດເບິ່ງການບໍລິໂພກຊັບພະຍາກອນເມື່ອກຸ່ມ "ນອນ".

ການບໍລິໂພກຊັບພະຍາກອນທີ່ບໍ່ມີການໂຫຼດ

Pod-to-Pod

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

ສະຖານະການ Pod-to-Pod

TCP

Pod-to-Pod TCP ຜົນໄດ້ຮັບແລະການບໍລິໂພກຊັບພະຍາກອນທີ່ສອດຄ້ອງກັນ:

UDP

Pod-to-Pod ຜົນໄດ້ຮັບ UDP ແລະການບໍລິໂພກຊັບພະຍາກອນທີ່ສອດຄ້ອງກັນ:

Pod-to-Service

ພາກນີ້ແມ່ນກ່ຽວຂ້ອງສໍາລັບກໍລະນີການນໍາໃຊ້ທີ່ແທ້ຈິງ, ລູກຄ້າ Pod ເຊື່ອມຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍຂອງ Pod ຜ່ານບໍລິການ ClusterIP.

Pod-to-Service Script

TCP

Pod-to-Service TCP ຜົນໄດ້ຮັບແລະການບໍລິໂພກຊັບພະຍາກອນທີ່ສອດຄ້ອງກັນ:

UDP

Pod-to-Service UDP ຜົນໄດ້ຮັບແລະການບໍລິໂພກຊັບພະຍາກອນທີ່ສອດຄ້ອງກັນ:

ສະຫນັບສະຫນູນນະໂຍບາຍເຄືອຂ່າຍ

ໃນບັນດາສິ່ງທັງຫມົດຂ້າງເທິງ, ຄົນດຽວທີ່ບໍ່ສະຫນັບສະຫນູນທາງດ້ານການເມືອງແມ່ນ Flannel. ອື່ນໆທັງຫມົດປະຕິບັດນະໂຍບາຍເຄືອຂ່າຍຢ່າງຖືກຕ້ອງ, ລວມທັງຂາເຂົ້າແລະຂາອອກ. ດີ​ຫຼາຍ!

ການເຂົ້າລະຫັດ CNI

ໃນບັນດາ CNIs ທີ່ຖືກກວດສອບມີຜູ້ທີ່ສາມາດເຂົ້າລະຫັດການແລກປ່ຽນເຄືອຂ່າຍລະຫວ່າງ Pods:

• Antrea ໃຊ້ IPsec
• Calico ດ້ວຍການຊ່ວຍເຫຼືອ wireguard
• Cilium ໃຊ້ IPsec
• WeaveNet ໂດຍໃຊ້ IPsec

ແບນວິດ

ເນື່ອງຈາກມີ CNIs ຫນ້ອຍລົງ, ໃຫ້ພວກເຮົາເອົາສະຖານະການທັງຫມົດເຂົ້າໄປໃນຫນຶ່ງກາຟ:

ການບໍລິໂພກຊັບພະຍາກອນ

ໃນພາກນີ້, ພວກເຮົາຈະປະເມີນຊັບພະຍາກອນທີ່ໃຊ້ໃນເວລາປະມວນຜົນການສື່ສານ Pod-to-Pod ໃນ TCP ແລະ UDP. ບໍ່ມີຈຸດໃດໃນການແຕ້ມກາຟ Pod-to-Service ເນື່ອງຈາກມັນບໍ່ໄດ້ໃຫ້ຂໍ້ມູນເພີ່ມເຕີມ.

ເອົາມັນທັງຫມົດຮ່ວມກັນ

ໃຫ້ພະຍາຍາມເຮັດເລື້ມຄືນກາຟທັງຫມົດ, ພວກເຮົາໄດ້ນໍາສະເຫນີຫົວຂໍ້ເລັກນ້ອຍຢູ່ທີ່ນີ້, ແທນທີ່ຄ່າທີ່ແທ້ຈິງດ້ວຍຄໍາວ່າ "vwry ໄວ", "ຕ່ໍາ", ແລະອື່ນໆ.

ບົດສະຫຼຸບແລະບົດສະຫຼຸບຂອງຂ້ອຍ

ນີ້ແມ່ນຫົວຂໍ້ເລັກນ້ອຍ, ນັບຕັ້ງແຕ່ຂ້າພະເຈົ້າຖ່າຍທອດການຕີຄວາມຫມາຍຂອງຕົນເອງກ່ຽວກັບຜົນໄດ້ຮັບ.

ຂ້າພະເຈົ້າດີໃຈທີ່ CNIs ໃຫມ່ປາກົດ, Antrea ປະຕິບັດໄດ້ດີ, ຫນ້າທີ່ຈໍານວນຫຼາຍໄດ້ຖືກປະຕິບັດເຖິງແມ່ນວ່າໃນຮຸ່ນຕົ້ນ: ການກວດສອບ MTU ອັດຕະໂນມັດ, ການເຂົ້າລະຫັດແລະການຕິດຕັ້ງງ່າຍ.

ຖ້າພວກເຮົາປຽບທຽບການປະຕິບັດ, CNI ທັງຫມົດເຮັດວຽກໄດ້ດີ, ຍົກເວັ້ນ Kube-OVN ແລະ Kube-Router. Kube-Router ຍັງບໍ່ສາມາດກວດພົບ MTU ໄດ້, ຂ້ອຍບໍ່ພົບວິທີທີ່ຈະຕັ້ງຄ່າມັນຢູ່ບ່ອນໃດກໍໄດ້ໃນເອກະສານ (ທີ່ນີ້ ການຮ້ອງຂໍກ່ຽວກັບຫົວຂໍ້ນີ້ແມ່ນເປີດ).

ໃນແງ່ຂອງການບໍລິໂພກຊັບພະຍາກອນ, Cilium ຍັງໃຊ້ RAM ຫຼາຍກ່ວາຄົນອື່ນ, ແຕ່ຜູ້ຜະລິດກໍາລັງຕັ້ງເປົ້າຫມາຍກຸ່ມຂະຫນາດໃຫຍ່ຢ່າງຊັດເຈນ, ເຊິ່ງເຫັນໄດ້ຊັດເຈນບໍ່ຄືກັບການທົດສອບໃນກຸ່ມສາມໂຫນດ. Kube-OVN ຍັງບໍລິໂພກຊັບພະຍາກອນ CPU ແລະ RAM ຫຼາຍ, ແຕ່ມັນເປັນ CNI ຫນຸ່ມໂດຍອີງໃສ່ Open vSwitch (ເຊັ່ນ Antrea, ມັນປະຕິບັດໄດ້ດີກວ່າແລະບໍລິໂພກຫນ້ອຍ).

ທຸກຄົນຍົກເວັ້ນ Flannel ມີນະໂຍບາຍເຄືອຂ່າຍ. ມັນເປັນໄປໄດ້ຫຼາຍທີ່ລາວຈະບໍ່ສະຫນັບສະຫນູນພວກເຂົາ, ເພາະວ່າເປົ້າຫມາຍແມ່ນງ່າຍດາຍກວ່າ turnip ຫນື້ງ: ສີມ້ານ, ດີກວ່າ.

ນອກຈາກນັ້ນ, ປະສິດທິພາບການເຂົ້າລະຫັດແມ່ນໜ້າອັດສະຈັນ. Calico ແມ່ນໜຶ່ງໃນ CNI ທີ່ເກົ່າແກ່ທີ່ສຸດ, ແຕ່ການເຂົ້າລະຫັດໄດ້ຖືກເພີ່ມເຂົ້າມາພຽງແຕ່ສອງສາມອາທິດກ່ອນ. ພວກເຂົາເລືອກ wireguard ແທນທີ່ຈະເປັນ IPsec, ແລະເວົ້າງ່າຍໆ, ທຸກຢ່າງເຮັດວຽກໄດ້ຢ່າງສະຫຼາດ ແລະ ໜ້າອັດສະຈັນ, ໂດຍການທົດແທນ CNI ອື່ນໆຢ່າງສິ້ນເຊີງໃນສ່ວນນີ້ຂອງການທົດສອບ. ແນ່ນອນ, ການໃຊ້ຊັບພະຍາກອນເພີ່ມຂຶ້ນຍ້ອນການເຂົ້າລະຫັດ, ແຕ່ປະລິມານວຽກທີ່ບັນລຸໄດ້ແມ່ນຄຸ້ມຄ່າ (Calico ສະແດງໃຫ້ເຫັນເຖິງຄວາມໄດ້ປຽບຫົກເທົ່າຂອງ Cilium, ເຊິ່ງຢູ່ໃນອັນດັບທີສອງ, ໃນການທົດສອບການເຂົ້າລະຫັດ). ຍິ່ງໄປກວ່ານັ້ນ, ທ່ານສາມາດເປີດໃຊ້ງານ wireguard ຫຼັງຈາກການນຳໃຊ້ Calico ເຂົ້າໃນ cluster ໄດ້ທຸກເວລາ, ທ່ານຍັງສາມາດປິດການໃຊ້ງານມັນໄດ້ຊົ່ວຄາວ ຫຼື ຖາວອນ ຖ້າທ່ານຕ້ອງການ. ນີ້ແມ່ນສະດວກຫຼາຍ, ແຕ່! ພວກເຮົາຂໍເຕືອນທ່ານວ່າ Calico ໃນປະຈຸບັນບໍ່ໄດ້ກວດພົບ MTU ໂດຍອັດຕະໂນມັດ (ຄຸນສົມບັດນີ້ໄດ້ຖືກວາງແຜນໄວ້ສຳລັບລຸ້ນຕໍ່ໄປ), ສະນັ້ນໃຫ້ແນ່ໃຈວ່າໄດ້ຕັ້ງຄ່າ MTU ຖ້າເຄືອຂ່າຍຂອງທ່ານຮອງຮັບ Jumbo Frames (MTU 9000).

ໃນບັນດາສິ່ງອື່ນໆ, ຈົ່ງສັງເກດວ່າ Cilium ສາມາດເຂົ້າລະຫັດການຈະລາຈອນລະຫວ່າງ nodes ກຸ່ມ (ແລະບໍ່ພຽງແຕ່ລະຫວ່າງ Pods), ເຊິ່ງສາມາດມີຄວາມສໍາຄັນຫຼາຍສໍາລັບ nodes ກຸ່ມສາທາລະນະ.

ໃນການສະຫຼຸບ, ຂ້າພະເຈົ້າຂໍແນະນໍາກໍລະນີການນໍາໃຊ້ດັ່ງຕໍ່ໄປນີ້:

• ຕ້ອງການ CNI ສໍາລັບກຸ່ມຂະຫນາດນ້ອຍຫຼາຍ OR ຂ້ອຍບໍ່ຕ້ອງການຄວາມປອດໄພ: ເຮັດ​ວຽກ​ຮ່ວມ​ກັບ Flannel, CNI ທີ່ເບົາທີ່ສຸດແລະຫມັ້ນຄົງທີ່ສຸດ (ລາວຍັງເປັນຄົນເກົ່າແກ່ທີ່ສຸດ, ອີງຕາມນິທານທີ່ລາວຖືກປະດິດໂດຍ Homo Kubernautus ຫຼື Homo Contaitorus.). ທ່ານອາດຈະສົນໃຈໂຄງການ ingenious ທີ່ສຸດ k3s, ກວດ!
• ຕ້ອງການ CNI ສໍາລັບກຸ່ມປົກກະຕິ: Calico - ທາງ​ເລືອກ​ຂອງ​ທ່ານ​, ແຕ່​ບໍ່​ລືມ​ທີ່​ຈະ​ຕັ້ງ​ຄ່າ MTU ຖ້າ​ຫາກ​ວ່າ​ຈໍາ​ເປັນ​. ທ່ານສາມາດຫຼິ້ນໄດ້ງ່າຍ ແລະເປັນທໍາມະຊາດກັບນະໂຍບາຍເຄືອຂ່າຍ, ເປີດ ແລະປິດການເຂົ້າລະຫັດ, ແລະອື່ນໆ.
• ຕ້ອງການ CNI ສໍາລັບ (ຫຼາຍ) ກຸ່ມຂະຫນາດໃຫຍ່: ດີ, ການທົດສອບບໍ່ໄດ້ສະແດງໃຫ້ເຫັນເຖິງພຶດຕິກໍາຂອງກຸ່ມຂະຫນາດໃຫຍ່, ຂ້ອຍຈະດີໃຈທີ່ຈະເຮັດການທົດສອບ, ແຕ່ພວກເຮົາບໍ່ມີເຄື່ອງແມ່ຂ່າຍຫຼາຍຮ້ອຍຄົນທີ່ມີການເຊື່ອມຕໍ່ 10Gbps. ດັ່ງນັ້ນທາງເລືອກທີ່ດີທີ່ສຸດແມ່ນເພື່ອດໍາເນີນການທົດສອບດັດແກ້ກ່ຽວກັບຂໍ້ຂອງທ່ານ, ຢ່າງຫນ້ອຍກັບ Calico ແລະ Cilium.

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