Kubernetes Network Plugin (CNI) Benchmark ຜົນໄດ້ຮັບຫຼາຍກວ່າ 10 Gbps ເຄືອຂ່າຍ (ອັບເດດ: ເມສາ 2019)

ນີ້ແມ່ນການປັບປຸງຂອງຂ້ອຍ ດັດຊະນີທີ່ຜ່ານມາ, ເຊິ່ງຕອນນີ້ແລ່ນໃນ Kubernetes 1.14 ພ້ອມກັບລຸ້ນ CNI ຫຼ້າສຸດຕັ້ງແຕ່ເດືອນເມສາ 2019.

ກ່ອນອື່ນ ໝົດ, ຂ້ອຍຢາກຂອບໃຈທີມງານ Cilium: ຜູ້ຊາຍໄດ້ຊ່ວຍຂ້ອຍກວດເບິ່ງແລະແກ້ໄຂ scripts ຕິດຕາມ metrics.

ສິ່ງທີ່ມີການປ່ຽນແປງນັບຕັ້ງແຕ່ເດືອນພະຈິກ 2018

ນີ້ແມ່ນສິ່ງທີ່ມີການປ່ຽນແປງຕັ້ງແຕ່ນັ້ນມາ (ຖ້າທ່ານສົນໃຈ):

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

Romana ບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນອີກຕໍ່ໄປ, ດັ່ງນັ້ນພວກເຮົາໄດ້ເອົາມັນອອກຈາກມາດຕະຖານ.

ໃນປັດຈຸບັນ WeaveNet ສະຫນັບສະຫນູນນະໂຍບາຍເຄືອຂ່າຍສໍາລັບ Ingress ແລະ Egress! ແຕ່ຜົນຜະລິດໄດ້ຫຼຸດລົງ.

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

• ການເກັບຮັກສາສະຖານະໃນ Kubernetes API ເປັນບ່ອນເກັບຂໍ້ມູນ (ຂະຫນາດຂອງກຸ່ມ < 50 nodes);
• ການເກັບຮັກສາສະຖານະໃນ Kubernetes API ເປັນບ່ອນເກັບຂໍ້ມູນດ້ວຍພຣັອກຊີ Typha ເພື່ອບັນເທົາການໂຫຼດໃນ K8S API (ຂະໜາດຂອງກຸ່ມ > 50 nodes).

Calico ປະກາດການສະຫນັບສະຫນູນ ນະໂຍບາຍລະດັບຄໍາຮ້ອງສະຫມັກ ຢູ່ເທິງສຸດຂອງ Istio ສໍາລັບຄວາມປອດໄພລະດັບແອັບພລິເຄຊັນ.

ດຽວນີ້ Cilium ຮອງຮັບການເຂົ້າລະຫັດແລ້ວ! Cilium ສະໜອງການເຂົ້າລະຫັດດ້ວຍອຸໂມງ IPSec ແລະສະເໜີທາງເລືອກໃຫ້ກັບເຄືອຂ່າຍ WeaveNet ທີ່ເຂົ້າລະຫັດໄວ້. ແຕ່ WeaveNet ແມ່ນໄວກວ່າ Cilium ດ້ວຍການເຂົ້າລະຫັດລັບ.

ດຽວນີ້ Cilium ແມ່ນງ່າຍຕໍ່ການນຳໃຊ້ຍ້ອນຕົວປະຕິບັດການ ETCD ທີ່ສ້າງມາ.

ທີມງານ Cilium ໄດ້ພະຍາຍາມຕັດນ້ໍາຫນັກບາງສ່ວນຈາກ CNI ຂອງຕົນໂດຍການຫຼຸດຜ່ອນການບໍລິໂພກຫນ່ວຍຄວາມຈໍາແລະຄ່າໃຊ້ຈ່າຍ CPU, ແຕ່ຄູ່ແຂ່ງຂອງມັນຍັງອ່ອນກວ່າ.

ບໍລິບົດມາດຕະຖານ

ມາດຕະຖານແມ່ນດໍາເນີນການຢູ່ໃນສາມເຊີບເວີ Supermicro ທີ່ບໍ່ແມ່ນ virtual ທີ່ມີສະວິດ 10 Gb Supermicro. ເຊີບເວີຖືກເຊື່ອມຕໍ່ໂດຍກົງກັບສະວິດຜ່ານສາຍ DAC SFP+ ແບບ passive ແລະຖືກຕັ້ງຄ່າຢູ່ໃນ VLAN ດຽວກັນກັບ jumbo frames (MTU 9000).

Kubernetes 1.14.0 ຕິດຕັ້ງຢູ່ໃນ Ubuntu 18.04 LTS ກັບ Docker 18.09.2 (ສະບັບ Docker ເລີ່ມຕົ້ນໃນລຸ້ນນີ້).

ເພື່ອປັບປຸງການແຜ່ພັນ, ພວກເຮົາຕັດສິນໃຈສະເຫມີ configure ແມ່ບົດໃນ node ທໍາອິດ, ວາງພາກສ່ວນຂອງເຄື່ອງແມ່ຂ່າຍຂອງ benchmark ໃນເຄື່ອງແມ່ຂ່າຍທີສອງ, ແລະພາກສ່ວນລູກຄ້າຢູ່ໃນທີສາມ. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາໃຊ້ NodeSelector ໃນການຕິດຕັ້ງ Kubernetes.

ພວກເຮົາຈະອະທິບາຍຜົນໄດ້ຮັບ benchmark ໃນລະດັບດັ່ງຕໍ່ໄປນີ້:

ການເລືອກ CNI ສໍາລັບມາດຕະຖານ

ນີ້ແມ່ນມາດຕະຖານພຽງແຕ່ສໍາລັບ CNI ຈາກບັນຊີລາຍຊື່ໃນພາກ ກ່ຽວກັບການສ້າງກຸ່ມແມ່ບົດດຽວກັບ kubeadm ເບິ່ງເອກະສານ Kubernetes ຢ່າງເປັນທາງການ. ໃນຈໍານວນ 9 CNIs, ພວກເຮົາຈະເອົາພຽງແຕ່ 6: ພວກເຮົາຈະຍົກເວັ້ນສິ່ງທີ່ມີຄວາມຫຍຸ້ງຍາກໃນການຕິດຕັ້ງແລະ / ຫຼືບໍ່ເຮັດວຽກໂດຍບໍ່ມີການກໍານົດຕາມເອກະສານ (Romana, Contiv-VPP ແລະ JuniperContrail / TungstenFabric).

ພວກເຮົາຈະປຽບທຽບ CNIs ຕໍ່ໄປນີ້:

• Calico v3.6
• Canal v3.6 (ໂດຍສະເພາະ Flannel ສໍາລັບເຄືອຂ່າຍ + Calico ເປັນ firewall)
• Cilium 1.4.2
• Flannel 0.11.0
• Kube-router 0.2.5
• WeaveNet 2.5.1

ການຕັ້ງຄ່າ

ການຕິດຕັ້ງ CNI ງ່າຍຂຶ້ນ, ຄວາມປະທັບໃຈຄັ້ງທໍາອິດຂອງພວກເຮົາຈະດີຂຶ້ນ. CNIs ທັງຫມົດຈາກ benchmark ແມ່ນງ່າຍທີ່ຈະຕິດຕັ້ງ (ມີຫນຶ່ງຫຼືສອງຄໍາສັ່ງ).

ດັ່ງທີ່ພວກເຮົາເວົ້າ, ເຊີບເວີແລະສະຫຼັບໄດ້ຖືກຕັ້ງຄ່າດ້ວຍກອບ jumbo ທີ່ເປີດໃຊ້ງານ (ພວກເຮົາຕັ້ງ MTU ເປັນ 9000). ພວກເຮົາຈະດີໃຈຖ້າ CNI ກໍານົດ MTU ໂດຍອັດຕະໂນມັດໂດຍອີງໃສ່ການຕັ້ງຄ່າຂອງຜູ້ດັດແປງ. ຢ່າງໃດກໍຕາມ, ພຽງແຕ່ Cilium ແລະ Flannel ຈັດການນີ້. ສ່ວນທີ່ເຫຼືອຂອງ CNIs ມີຄໍາຮ້ອງຂໍກ່ຽວກັບ GitHub ເພື່ອເພີ່ມການຄົ້ນພົບ MTU ອັດຕະໂນມັດ, ແຕ່ພວກເຮົາຈະຕັ້ງຄ່າມັນດ້ວຍຕົນເອງໂດຍການປ່ຽນ ConfigMap ສໍາລັບ Calico, Canal ແລະ Kube-router, ຫຼືຜ່ານຕົວແປສະພາບແວດລ້ອມສໍາລັບ WeaveNet.

ບັນຫາກັບ MTU ທີ່ບໍ່ຖືກຕ້ອງແມ່ນຫຍັງ? ແຜນວາດນີ້ສະແດງໃຫ້ເຫັນຄວາມແຕກຕ່າງລະຫວ່າງ WeaveNet ກັບ MTU ເລີ່ມຕົ້ນແລະກອບ jumbo ທີ່ເປີດໃຊ້:

MTU ມີຜົນກະທົບຕໍ່ການສົ່ງຕໍ່ແນວໃດ?

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

CNI ກວດພົບ MTU ໂດຍອັດຕະໂນມັດ

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

ຄວາມປອດໄພ

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

ພຽງແຕ່ສອງ CNIs ເຂົ້າລະຫັດຂໍ້ມູນ: Cilium ແລະ WeaveNet. ການເຂົ້າລະຫັດ WeaveNet ເປີດໃຊ້ໂດຍການຕັ້ງລະຫັດຜ່ານການເຂົ້າລະຫັດເປັນຕົວແປສະພາບແວດລ້ອມ CNI. IN ເອກະສານ WeaveNet ອະທິບາຍມັນໃນທາງທີ່ສັບສົນ, ແຕ່ທຸກຢ່າງແມ່ນເຮັດໄດ້ງ່າຍໆ. ການເຂົ້າລະຫັດ ຄຣີມ ຕັ້ງຄ່າໂດຍຄໍາສັ່ງ, ໂດຍການສ້າງຄວາມລັບ Kubernetes, ແລະໂດຍຜ່ານການດັດແປງ daemonSet (ສັບສົນຫຼາຍກ່ວາໃນ WeaveNet, ແຕ່ Cilium ມີຂັ້ນຕອນໂດຍຂັ້ນຕອນ. ຄໍາແນະນໍາ).

ສໍາລັບການປະຕິບັດນະໂຍບາຍເຄືອຂ່າຍ, ພວກເຂົາເຈົ້າໄດ້ປະສົບຜົນສໍາເລັດ Calico, Canal, Cilium ແລະ WeaveNet, ທີ່ທ່ານສາມາດ configure Ingress ແລະ Egress ກົດລະບຽບ. ສໍາລັບ Kube-router ມີກົດລະບຽບພຽງແຕ່ສໍາລັບ Ingress, ແລະ Flannel ບໍ່ມີນະໂຍບາຍເຄືອຂ່າຍໃດໆ.

ນີ້ແມ່ນຜົນໄດ້ຮັບໂດຍລວມ:

ຜົນ​ການ​ຄາດ​ຄະ​ເນ​ການ​ປະ​ຕິ​ບັດ​ດ້ານ​ຄວາມ​ປອດ​ໄພ​

ຜະລິດຕະພັນ

ດັດຊະນີນີ້ສະແດງໃຫ້ເຫັນເຖິງການຜ່ານສະເລ່ຍໃນໄລຍະຢ່າງຫນ້ອຍສາມໄລຍະຂອງແຕ່ລະການທົດສອບ. ພວກເຮົາທົດສອບການປະຕິບັດຂອງ TCP ແລະ UDP (ໂດຍໃຊ້ iperf3), ຄໍາຮ້ອງສະຫມັກທີ່ແທ້ຈິງເຊັ່ນ HTTP (ກັບ Nginx ແລະ curl) ຫຼື FTP (ກັບ vsftpd ແລະ curl) ແລະສຸດທ້າຍການປະຕິບັດການນໍາໃຊ້ການເຂົ້າລະຫັດ SCP (ໃຊ້ລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍ OpenSSH).

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

• ສີເຫຼືອງ = ດີຫຼາຍ
• ສີສົ້ມ = ດີ
• ສີຟ້າ = ຄືກັນ
• ສີແດງ = ບໍ່ດີ

ພວກເຮົາຈະບໍ່ເອົາ CNIs ທີ່ຖືກຕັ້ງຄ່າບໍ່ຖືກຕ້ອງແລະພຽງແຕ່ຈະສະແດງຜົນໄດ້ຮັບສໍາລັບ CNIs ກັບ MTU ທີ່ຖືກຕ້ອງ. (ຫມາຍເຫດ: Cilium ບໍ່ໄດ້ຄິດໄລ່ MTU ຢ່າງຖືກຕ້ອງຖ້າທ່ານເປີດໃຊ້ການເຂົ້າລະຫັດ, ດັ່ງນັ້ນທ່ານຈະຕ້ອງຫຼຸດລົງ MTU ດ້ວຍຕົນເອງເປັນ 8900 ໃນຮຸ່ນ 1.4. ຮຸ່ນຕໍ່ໄປ, 1.5, ເຮັດແບບນີ້ໂດຍອັດຕະໂນມັດ.)

ນີ້ແມ່ນຜົນໄດ້ຮັບ:

ປະສິດທິພາບ TCP

CNI ທັງຫມົດປະຕິບັດໄດ້ດີໃນມາດຕະຖານ TCP. CNI ທີ່ມີການເຂົ້າລະຫັດຍັງລ້າຊ້າຍ້ອນວ່າການເຂົ້າລະຫັດມີລາຄາແພງ.

ປະສິດທິພາບ UDP

ນີ້, ເຊັ່ນດຽວກັນ, CNI ທັງຫມົດແມ່ນເຮັດໄດ້ດີ. CNI ທີ່ມີການເຂົ້າລະຫັດສະແດງໃຫ້ເຫັນເກືອບຜົນໄດ້ຮັບດຽວກັນ. Cilium ແມ່ນເລັກນ້ອຍຢູ່ຫລັງການແຂ່ງຂັນ, ແຕ່ມັນເປັນພຽງແຕ່ 2,3% ຂອງໂລຫະເປົ່າ, ດັ່ງນັ້ນມັນບໍ່ແມ່ນຜົນທີ່ບໍ່ດີ. ຢ່າລືມວ່າພຽງແຕ່ Cilium ແລະ Flannel ກໍານົດ MTU ຢ່າງຖືກຕ້ອງດ້ວຍຕົນເອງ, ແລະເຫຼົ່ານີ້ແມ່ນຜົນໄດ້ຮັບຂອງເຂົາເຈົ້າໂດຍບໍ່ມີການກໍາຫນົດຄ່າເພີ່ມເຕີມ.

ຈະເປັນແນວໃດກ່ຽວກັບຄໍາຮ້ອງສະຫມັກທີ່ແທ້ຈິງ? ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ການປະຕິບັດໂດຍລວມສໍາລັບ HTTP ແມ່ນຕ່ໍາກວ່າສໍາລັບ TCP ເລັກນ້ອຍ. ເຖິງແມ່ນວ່າທ່ານໃຊ້ HTTP ກັບ TCP, ພວກເຮົາໄດ້ຕັ້ງຄ່າ iperf3 ໃນດັດຊະນີ TCP ເພື່ອຫຼີກເວັ້ນການເລີ່ມຕົ້ນຊ້າທີ່ຈະສົ່ງຜົນກະທົບຕໍ່ມາດຕະຖານ HTTP. ທຸກຄົນເຮັດວຽກໄດ້ດີຢູ່ທີ່ນີ້. Kube-router ມີປະໂຫຍດທີ່ຊັດເຈນ, ແຕ່ WeaveNet ບໍ່ໄດ້ປະຕິບັດໄດ້ດີ: ປະມານ 20% ຮ້າຍແຮງກວ່າໂລຫະເປົ່າ. Cilium ແລະ WeaveNet ທີ່ມີການເຂົ້າລະຫັດເບິ່ງຫນ້າເສົ້າໃຈແທ້ໆ.

ດ້ວຍ FTP, ໂປຣໂຕຄໍທີ່ອີງໃສ່ TCP ອື່ນ, ຜົນໄດ້ຮັບແຕກຕ່າງກັນ. Flannel ແລະ Kube-router ເຮັດວຽກ, ແຕ່ Calico, Canal ແລະ Cilium ແມ່ນຢູ່ຫລັງເລັກນ້ອຍແລະຊ້າກວ່າໂລຫະເປົ່າປະມານ 10%. WeaveNet ແມ່ນຢູ່ເບື້ອງຫຼັງຫຼາຍເຖິງ 17%, ແຕ່ WeaveNet ທີ່ຖືກເຂົ້າລະຫັດແມ່ນ 40% ກ່ອນການເຂົ້າລະຫັດ Cilium.

ດ້ວຍ SCP ພວກເຮົາສາມາດເຫັນໄດ້ທັນທີວ່າການເຂົ້າລະຫັດ SSH ມີຄ່າໃຊ້ຈ່າຍຫຼາຍປານໃດ. ເກືອບ CNIs ທັງຫມົດແມ່ນເຮັດໄດ້ດີ, ແຕ່ WeaveNet ຍັງລ້າຫລັງອີກເທື່ອຫນຶ່ງ. Cilium ແລະ WeaveNet ທີ່ມີການເຂົ້າລະຫັດຄາດວ່າຈະຮ້າຍແຮງທີ່ສຸດເນື່ອງຈາກການເຂົ້າລະຫັດສອງເທົ່າ (SSH + CNI).

ນີ້ແມ່ນຕາຕະລາງສະຫຼຸບທີ່ມີຜົນໄດ້ຮັບ:

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

ຕອນນີ້ໃຫ້ປຽບທຽບວິທີການ CNI ບໍລິໂພກຊັບພະຍາກອນພາຍໃຕ້ການໂຫຼດຫນັກ (ໃນລະຫວ່າງການໂອນ TCP, 10 Gbps). ໃນການທົດສອບການປະຕິບັດພວກເຮົາປຽບທຽບ CNI ກັບໂລຫະເປົ່າ (ເສັ້ນສີຂຽວ). ສໍາລັບການບໍລິໂພກຊັບພະຍາກອນ, ໃຫ້ສະແດງ Kubernetes ບໍລິສຸດ (ເສັ້ນສີມ່ວງ) ໂດຍບໍ່ມີ CNI ແລະເບິ່ງວ່າ CNI ບໍລິໂພກຊັບພະຍາກອນພິເສດຫຼາຍປານໃດ.

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍຄວາມຊົງຈໍາ. ນີ້ແມ່ນຄ່າສະເລ່ຍຂອງ RAM ຂອງ nodes (ບໍ່ລວມ buffers ແລະ cache) ໃນ MB ໃນລະຫວ່າງການໂອນ.

ການບໍລິໂພກຄວາມຊົງຈໍາ

Flannel ແລະ Kube-router ສະແດງໃຫ້ເຫັນຜົນໄດ້ຮັບທີ່ດີເລີດ - ພຽງແຕ່ 50 MB. Calico ແລະ Canal ແຕ່ລະຄົນມີ 70. WeaveNet ຢ່າງຊັດເຈນບໍລິໂພກຫຼາຍກ່ວາຄົນອື່ນ - 130 MB, ແລະ Cilium ໃຊ້ຫຼາຍເຖິງ 400.
ຕອນນີ້ໃຫ້ກວດເບິ່ງການບໍລິໂພກເວລາ CPU. ເປັນທີ່ສັງເກດ: ແຜນວາດສະແດງໃຫ້ເຫັນບໍ່ອັດຕາສ່ວນ, ແຕ່ ppm, ນັ້ນແມ່ນ, 38 ppm ສໍາລັບ "ທາດເຫຼັກເປົ່າ" ແມ່ນ 3,8%. ນີ້ແມ່ນຜົນໄດ້ຮັບ:

ການບໍລິໂພກ CPU

Calico, Canal, Flannel ແລະ Kube-router ແມ່ນ CPU ທີ່ມີປະສິດທິພາບຫຼາຍ - ພຽງແຕ່ 2% ຫຼາຍກ່ວາ Kubernetes ທີ່ບໍ່ມີ CNI. WeaveNet ຍັງລ້າຊ້າກວ່າດ້ວຍການເພີ່ມ 5%, ຕິດຕາມດ້ວຍ Cilium ຢູ່ 7%.

ນີ້ແມ່ນສະຫຼຸບການບໍລິໂພກຊັບພະຍາກອນ:

ຜົນໄດ້ຮັບ

ຕາຕະລາງທີ່ມີຜົນໄດ້ຮັບທັງຫມົດ:

ຜົນໄດ້ຮັບມາດຕະຖານທົ່ວໄປ

ສະຫລຸບ

ໃນພາກສຸດທ້າຍ, ຂ້າພະເຈົ້າຈະສະແດງຄວາມຄິດເຫັນຂອງຂ້າພະເຈົ້າກ່ຽວກັບຜົນໄດ້ຮັບ. ຈົ່ງຈື່ໄວ້ວ່າດັດຊະນີນີ້ພຽງແຕ່ທົດສອບການສົ່ງຜ່ານຂອງການເຊື່ອມຕໍ່ດຽວຢູ່ໃນກຸ່ມຂະຫນາດນ້ອຍຫຼາຍ (3 nodes). ມັນບໍ່ໃຊ້ກັບກຸ່ມຂະຫນາດໃຫຍ່ (<50 nodes) ຫຼືການເຊື່ອມຕໍ່ຂະຫນານ.

ຂ້ອຍຂໍແນະນໍາໃຫ້ໃຊ້ CNIs ຕໍ່ໄປນີ້ຂຶ້ນຢູ່ກັບສະຖານະການ:

• ທ່ານມີຢູ່ໃນກຸ່ມຂອງທ່ານ nodes ທີ່ມີຊັບພະຍາກອນຈໍານວນຫນ້ອຍ (ຫຼາຍ GB ຂອງ RAM, ຫຼາຍແກນ) ແລະທ່ານບໍ່ຕ້ອງການຄຸນນະສົມບັດຄວາມປອດໄພ - ເລືອກ Flannel. ນີ້ແມ່ນຫນຶ່ງໃນ CNIs ທີ່ມີປະສິດທິພາບທີ່ສຸດ. ແລະມັນເຫມາະສົມກັບສະຖາປັດຕະຍະກໍາທີ່ຫລາກຫລາຍ (amd64, arm, arm64, ແລະອື່ນໆ). ນອກຈາກນັ້ນ, ນີ້ແມ່ນຫນຶ່ງໃນສອງ (ອີກອັນຫນຶ່ງແມ່ນ Cilium) CNI ທີ່ສາມາດກໍານົດ MTU ໂດຍອັດຕະໂນມັດ, ດັ່ງນັ້ນທ່ານບໍ່ຈໍາເປັນຕ້ອງຕັ້ງຄ່າຫຍັງ. Kube-router ຍັງເຫມາະສົມ, ແຕ່ວ່າມັນບໍ່ແມ່ນມາດຕະຖານແລະທ່ານຈະຕ້ອງຕັ້ງຄ່າ MTU ດ້ວຍຕົນເອງ.
• ຖ້າຕ້ອງການ ເຂົ້າລະຫັດເຄືອຂ່າຍ ເພື່ອຄວາມປອດໄພ, ເອົາ WeaveNet. ຢ່າລືມລະບຸຂະຫນາດ MTU ຖ້າທ່ານກໍາລັງໃຊ້ jumbo frames, ແລະເປີດໃຊ້ການເຂົ້າລະຫັດໂດຍການລະບຸລະຫັດຜ່ານຜ່ານຕົວແປສະພາບແວດລ້ອມ. ແຕ່ມັນກໍ່ດີກວ່າທີ່ຈະລືມກ່ຽວກັບການປະຕິບັດ - ນັ້ນແມ່ນຄ່າໃຊ້ຈ່າຍຂອງການເຂົ້າລະຫັດ.
• ໄປ ການ​ນໍາ​ໃຊ້​ປົກ​ກະ​ຕິ​ советую Calico. CNI ນີ້ຖືກນໍາໃຊ້ຢ່າງກວ້າງຂວາງໃນເຄື່ອງມືການນໍາໃຊ້ Kubernetes ຕ່າງໆ (Kops, Kubespray, Rancher, ແລະອື່ນໆ). ເຊັ່ນດຽວກັນກັບ WeaveNet, ໃຫ້ແນ່ໃຈວ່າຈະຕັ້ງຄ່າ MTU ໃນ ConfigMap ຖ້າໃຊ້ jumbo frames. ມັນເປັນເຄື່ອງມືທີ່ມີປະໂຫຍດຫຼາຍດ້ານທີ່ມີປະສິດທິພາບໃນການບໍລິໂພກຊັບພະຍາກອນ, ການປະຕິບັດແລະຄວາມປອດໄພ.

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

ແຜນວາດພາບສໍາລັບການເລືອກ CNI

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