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

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

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

ກໍລະນີທີ 1: ເມື່ອບໍ່ມີການກຳນົດຄ່າທີ່ຕ້ອງການ

ໃຫ້ເບິ່ງກໍລະນີທີ່ງ່າຍດາຍ.

ການຕັ້ງຄ່າເສັ້ນທາງເພີ່ມເຕີມແມ່ນບໍ່ຈໍາເປັນເມື່ອທີ່ຢູ່ທີ່ອອກໂດຍ MetalLB ຢູ່ໃນເຄືອຂ່າຍຍ່ອຍດຽວກັນກັບທີ່ຢູ່ຂອງ nodes ຂອງທ່ານ.

ຕົວຢ່າງ, ທ່ານມີເຄືອຂ່າຍຍ່ອຍ 192.168.1.0/24, ມັນມີ router 192.168.1.1, ແລະ nodes ຂອງ​ທ່ານ​ໄດ້​ຮັບ​ທີ່​ຢູ່​: 192.168.1.10-30, ຫຼັງຈາກນັ້ນສໍາລັບ MetalLB ທ່ານສາມາດປັບລະດັບ 192.168.1.100-120 ແລະໃຫ້ແນ່ໃຈວ່າພວກເຂົາຈະເຮັດວຽກໂດຍບໍ່ມີການຕັ້ງຄ່າເພີ່ມເຕີມ.

ເປັນຫຍັງຄື? ເນື່ອງຈາກວ່າ nodes ຂອງທ່ານມີເສັ້ນທາງທີ່ກໍາຫນົດຄ່າແລ້ວ:

# ip route
default via 192.168.1.1 dev eth0 onlink 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

ແລະທີ່ຢູ່ຈາກໄລຍະດຽວກັນຈະໃຊ້ພວກມັນຄືນໃໝ່ໂດຍບໍ່ມີການດໍາເນີນການເພີ່ມເຕີມໃດໆ.

ກໍລະນີ 2: ເມື່ອຕ້ອງການການປັບແຕ່ງເພີ່ມເຕີມ

ທ່ານຄວນກໍາຫນົດຄ່າເສັ້ນທາງເພີ່ມເຕີມທຸກຄັ້ງທີ່ nodes ຂອງທ່ານບໍ່ມີທີ່ຢູ່ IP ທີ່ກໍານົດໄວ້ຫຼືເສັ້ນທາງໄປຫາເຄືອຂ່າຍຍ່ອຍທີ່ MetalLB ແກ້ໄຂບັນຫາ.

ຂ້ອຍຈະອະທິບາຍລາຍລະອຽດເພີ່ມເຕີມເລັກນ້ອຍ. ເມື່ອໃດກໍ່ຕາມທີ່ MetalLB ສົ່ງອອກທີ່ຢູ່, ມັນສາມາດຖືກປຽບທຽບກັບການມອບຫມາຍງ່າຍໆເຊັ່ນ:

ip addr add 10.9.8.7/32 dev lo

ຕັ້ງ​ໃຈ:

• a) ທີ່ຢູ່ໄດ້ຖືກມອບຫມາຍດ້ວຍຄໍານໍາຫນ້າ /32 ນັ້ນແມ່ນ, ເສັ້ນທາງຈະບໍ່ຖືກເພີ່ມໃສ່ເຄືອຂ່າຍຍ່ອຍໂດຍອັດຕະໂນມັດ (ມັນເປັນພຽງແຕ່ທີ່ຢູ່)
• b) ທີ່ຢູ່ແມ່ນຕິດກັບສ່ວນຕິດຕໍ່ຂອງ node ໃດ (ຕົວຢ່າງ: loopback). ມັນເປັນມູນຄ່າທີ່ໄດ້ກ່າວມາໃນທີ່ນີ້ຄຸນນະສົມບັດຂອງ stack ເຄືອຂ່າຍ Linux. ບໍ່ວ່າອິນເຕີເຟດໃດທີ່ທ່ານເພີ່ມທີ່ຢູ່, kernel ຈະປະມວນຜົນຄໍາຮ້ອງຂໍ arp ແລະສົ່ງຄໍາຕອບ arp ໄປຫາໃດໆຂອງພວກເຂົາ, ພຶດຕິກໍານີ້ຖືວ່າຖືກຕ້ອງແລະນອກຈາກນັ້ນ, ຖືກນໍາໃຊ້ຢ່າງກວ້າງຂວາງໃນສະພາບແວດລ້ອມແບບເຄື່ອນໄຫວເຊັ່ນ Kubernetes.

ພຶດຕິກໍານີ້ສາມາດຖືກປັບແຕ່ງໄດ້, ຕົວຢ່າງໂດຍການເປີດໃຊ້ arp ທີ່ເຄັ່ງຄັດ:

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

ໃນກໍລະນີນີ້, ການຕອບໂຕ້ arp ຈະຖືກສົ່ງພຽງແຕ່ຖ້າການໂຕ້ຕອບມີທີ່ຢູ່ IP ສະເພາະຢ່າງຊັດເຈນ. ການຕັ້ງຄ່ານີ້ແມ່ນຈໍາເປັນຖ້າທ່ານວາງແຜນທີ່ຈະໃຊ້ MetalLB ແລະ kube-proxy ຂອງເຈົ້າກໍາລັງເຮັດວຽກຢູ່ໃນໂຫມດ IPVS.

ຢ່າງໃດກໍຕາມ, MetalLB ບໍ່ໄດ້ໃຊ້ kernel ເພື່ອປະມວນຜົນຄໍາຮ້ອງຂໍ arp, ແຕ່ມັນຢູ່ໃນພື້ນທີ່ຜູ້ໃຊ້, ດັ່ງນັ້ນທາງເລືອກນີ້ຈະບໍ່ມີຜົນກະທົບຕໍ່ການດໍາເນີນງານຂອງ MetalLB.

ໃຫ້ກັບຄືນໄປຫາວຽກງານຂອງພວກເຮົາ. ຖ້າເສັ້ນທາງສໍາລັບທີ່ຢູ່ທີ່ອອກບໍ່ມີຢູ່ໃນ nodes ຂອງທ່ານ, ເພີ່ມມັນລ່ວງຫນ້າໃສ່ທຸກ nodes:

ip route add 10.9.8.0/24 dev eth1

ກໍລະນີທີ 3: ເມື່ອທ່ານຕ້ອງການເສັ້ນທາງທີ່ອີງໃສ່ແຫຼ່ງ

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

ຕົວຢ່າງ, ທ່ານມີ subnet ດຽວກັນ 192.168.1.0/24 ອຸທິດຕົນໃຫ້ກັບ nodes ຂອງທ່ານ, ແຕ່ທ່ານຕ້ອງການອອກທີ່ຢູ່ພາຍນອກໂດຍໃຊ້ MetalLB. ໃຫ້ສົມມຸດວ່າທ່ານມີຫຼາຍທີ່ຢູ່ຈາກເຄືອຂ່າຍຍ່ອຍ 1.2.3.0/24 ຕັ້ງຢູ່ໃນ VLAN 100 ແລະທ່ານຕ້ອງການໃຊ້ພວກມັນເພື່ອເຂົ້າເຖິງການບໍລິການ Kubernetes ພາຍນອກ.

ເມື່ອຕິດຕໍ່ 1.2.3.4 ທ່ານຈະໄດ້ຮັບການຮ້ອງຂໍຈາກ subnet ທີ່ແຕກຕ່າງກັນກ່ວາ 1.2.3.0/24 ແລະລໍຖ້າຄໍາຕອບ. node ທີ່ປະຈຸບັນເປັນແມ່ບົດສໍາລັບທີ່ຢູ່ MetalLB ອອກໃຫ້ 1.2.3.4, ຈະໄດ້ຮັບແພັກເກັດຈາກ router 1.2.3.1, ແຕ່ຄໍາຕອບສໍາລັບເຂົາຈໍາເປັນຕ້ອງໄປເສັ້ນທາງດຽວກັນ, ຜ່ານ 1.2.3.1.

ເນື່ອງຈາກ node ຂອງພວກເຮົາມີ gateway ເລີ່ມຕົ້ນທີ່ຕັ້ງຄ່າໄວ້ແລ້ວ 192.168.1.1, ຫຼັງຈາກນັ້ນໂດຍຄ່າເລີ່ມຕົ້ນການຕອບສະຫນອງຈະໄປຫາລາວ, ແລະບໍ່ແມ່ນ 1.2.3.1, ໂດຍຜ່ານທີ່ພວກເຮົາໄດ້ຮັບຊຸດ.

ວິທີການຮັບມືກັບສະຖານະການນີ້?

ໃນກໍລະນີນີ້, ທ່ານຈໍາເປັນຕ້ອງໄດ້ກະກຽມ nodes ທັງຫມົດຂອງທ່ານໃນລັກສະນະທີ່ເຂົາເຈົ້າພ້ອມທີ່ຈະໃຫ້ບໍລິການທີ່ຢູ່ພາຍນອກໂດຍບໍ່ມີການກໍາຫນົດຄ່າເພີ່ມເຕີມ. ນັ້ນແມ່ນ, ສໍາລັບຕົວຢ່າງຂ້າງເທິງ, ທ່ານຈໍາເປັນຕ້ອງສ້າງການໂຕ້ຕອບ VLAN ໃນ node ລ່ວງຫນ້າ:

ip link add link eth0 name eth0.100 type vlan id 100
ip link set eth0.100 up

ແລະຫຼັງຈາກນັ້ນເພີ່ມເສັ້ນທາງ:

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

ກະລຸນາຮັບຊາບວ່າພວກເຮົາເພີ່ມເສັ້ນທາງໄປຫາຕາຕະລາງເສັ້ນທາງແຍກຕ່າງຫາກ 100 ມັນຈະປະກອບມີພຽງແຕ່ສອງເສັ້ນທາງທີ່ຈໍາເປັນເພື່ອສົ່ງຊອງຕອບສະຫນອງຜ່ານປະຕູ 1.2.3.1, ຕັ້ງຢູ່ທາງຫລັງຂອງການໂຕ້ຕອບ eth0.100.

ໃນປັດຈຸບັນພວກເຮົາຈໍາເປັນຕ້ອງເພີ່ມກົດລະບຽບງ່າຍໆ:

ip rule add from 1.2.3.0/24 lookup 100

ເຊິ່ງເວົ້າຢ່າງຈະແຈ້ງວ່າ: ຖ້າທີ່ຢູ່ຂອງແພັກເກັດຢູ່ໃນ 1.2.3.0/24, ຫຼັງຈາກນັ້ນທ່ານຈໍາເປັນຕ້ອງໃຊ້ຕາຕະລາງການກໍານົດເສັ້ນທາງ 100. ໃນມັນພວກເຮົາໄດ້ອະທິບາຍແລ້ວເສັ້ນທາງທີ່ຈະສົ່ງລາວຜ່ານ 1.2.3.1

ກໍລະນີທີ 4: ເມື່ອທ່ານຕ້ອງການເສັ້ນທາງທີ່ອີງໃສ່ນະໂຍບາຍ

topology ເຄືອຂ່າຍແມ່ນຄືກັນກັບໃນຕົວຢ່າງທີ່ຜ່ານມາ, ແຕ່ໃຫ້ເວົ້າວ່າທ່ານຕ້ອງການສາມາດເຂົ້າເຖິງທີ່ຢູ່ສະນຸກເກີພາຍນອກ. 1.2.3.0/24 ຈາກ​ຝັກ​ຂອງ​ທ່ານ​:

peculiarity ແມ່ນ​ວ່າ​ໃນ​ເວ​ລາ​ທີ່​ການ​ເຂົ້າ​ເຖິງ​ທີ່​ຢູ່​ໃດ​ຫນຶ່ງ​ໃນ 1.2.3.0/24, packet ຕອບສະຫນອງ hits node ແລະມີທີ່ຢູ່ແຫຼ່ງໃນຂອບເຂດ 1.2.3.0/24 ຈະ​ຖືກ​ສົ່ງ​ໄປ​ຢ່າງ​ເຊື່ອ​ຟັງ eth0.100, ແຕ່ພວກເຮົາຕ້ອງການ Kubernetes ປ່ຽນເສັ້ນທາງໄປຫາຝອດທໍາອິດຂອງພວກເຮົາ, ເຊິ່ງສ້າງຄໍາຮ້ອງຂໍຕົ້ນສະບັບ.

ການ​ແກ້​ໄຂ​ບັນ​ຫາ​ນີ້​ໄດ້​ກາຍ​ເປັນ​ຄວາມ​ຫຍຸ້ງ​ຍາກ, ແຕ່​ມັນ​ເປັນ​ໄປ​ໄດ້​ຍ້ອນ​ການ​ວາງ​ເສັ້ນ​ທາງ​ທີ່​ອີງ​ໃສ່​ນະ​ໂຍ​ບາຍ:

ສໍາລັບຄວາມເຂົ້າໃຈດີຂຶ້ນກ່ຽວກັບຂະບວນການ, ນີ້ແມ່ນແຜນວາດ netfilter block:

ທໍາອິດ, ເຊັ່ນດຽວກັບຕົວຢ່າງທີ່ຜ່ານມາ, ໃຫ້ສ້າງຕາຕະລາງການກໍານົດເສັ້ນທາງເພີ່ມເຕີມ:

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

ຕອນນີ້ໃຫ້ພວກເຮົາເພີ່ມກົດລະບຽບບາງຢ່າງໃຫ້ກັບ iptables:

iptables -t mangle -A PREROUTING -i eth0.100 -j CONNMARK --set-mark 0x100
iptables -t mangle -A PREROUTING  -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j RETURN
iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark

ກົດລະບຽບເຫຼົ່ານີ້ຈະຫມາຍການເຊື່ອມຕໍ່ຂາເຂົ້າກັບການໂຕ້ຕອບ eth0.100, ຫມາຍແພັກເກັດທັງຫມົດດ້ວຍແທັກ 0x100, ຄໍາຕອບພາຍໃນການເຊື່ອມຕໍ່ດຽວກັນຈະຖືກຫມາຍດ້ວຍແທັກດຽວກັນ.

ໃນປັດຈຸບັນພວກເຮົາສາມາດເພີ່ມກົດລະບຽບການກໍານົດເສັ້ນທາງ:

ip rule add from 1.2.3.0/24 fwmark 0x100 lookup 100

ນັ້ນແມ່ນ, ທຸກແພັກເກັດທີ່ມີທີ່ຢູ່ແຫຼ່ງ 1.2.3.0/24 ແລະແທັກ 0x100 ຕ້ອງ​ໄດ້​ຮັບ​ການ​ນໍາ​ໃຊ້​ຕາ​ຕະ​ລາງ​ 100.

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

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

ບັນຫາແມ່ນວ່າໃນກໍລະນີຂອງພວກເຮົາມັນຈະບໍ່ເຮັດວຽກຢ່າງຖືກຕ້ອງ, ແຕ່ພວກເຮົາສາມາດປິດການໃຊ້ງານໄດ້:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0.100/rp_filter

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

ເພື່ອບໍ່ຈໍາກັດການເຮັດວຽກຂອງການກັ່ນຕອງຢ່າງສົມບູນ, ພວກເຮົາສາມາດນໍາໃຊ້ການປະຕິບັດ rp_filter ສໍາລັບ netfilter. ການນໍາໃຊ້ rpfilter ເປັນໂມດູນ iptables, ທ່ານສາມາດກໍານົດກົດລະບຽບທີ່ຂ້ອນຂ້າງປ່ຽນແປງໄດ້, ສໍາລັບການຍົກຕົວຢ່າງ:

iptables -t raw -A PREROUTING -i eth0.100 -d 1.2.3.0/24 -j RETURN
iptables -t raw -A PREROUTING -i eth0.100 -m rpfilter --invert -j DROP

ເປີດໃຊ້ rp_filter ໃນການໂຕ້ຕອບ eth0.100 ສໍາລັບທີ່ຢູ່ທັງຫມົດຍົກເວັ້ນ 1.2.3.0/24.

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