ເຂົ້າໃຈຕົວເລືອກນະໂຍບາຍເຄືອຂ່າຍກັບ Calico

ປັ໊ກອິນເຄືອຂ່າຍ Calico ສະໜອງນະໂຍບາຍເຄືອຂ່າຍທີ່ຫຼາກຫຼາຍດ້ວຍ syntax ຮວມກັນເພື່ອປົກປ້ອງຮາດແວໂຮສ, ເຄື່ອງສະເໝືອນ ແລະພອດ. ນະໂຍບາຍເຫຼົ່ານີ້ສາມາດຖືກນຳໃຊ້ພາຍໃນ namespace ຫຼືເປັນນະໂຍບາຍເຄືອຂ່າຍທົ່ວໂລກທີ່ນຳໃຊ້ກັບ ຈຸດສິ້ນສຸດຂອງເຈົ້າພາບ (ເພື່ອປົກປ້ອງແອັບພລິເຄຊັນທີ່ເຮັດວຽກໂດຍກົງໃນໂຮດ - ເຈົ້າພາບສາມາດເປັນເຄື່ອງແມ່ຂ່າຍຫຼືເຄື່ອງ virtual) ຫຼື ຈຸດສິ້ນສຸດວຽກ (ເພື່ອປົກປ້ອງແອັບພລິເຄຊັນທີ່ແລ່ນຢູ່ໃນຕູ້ຄອນເທນເນີ ຫຼືເຄື່ອງ virtual ທີ່ເປັນເຈົ້າພາບ). ນະໂຍບາຍ calico ອະນຸຍາດໃຫ້ທ່ານນໍາໃຊ້ມາດຕະການຄວາມປອດໄພໃນຈຸດຕ່າງໆໃນເສັ້ນທາງຂອງແພັກເກັດໂດຍໃຊ້ທາງເລືອກເຊັ່ນ: preDNAT, unracked, ແລະ applyOnForward. ຄວາມເຂົ້າໃຈວິທີການເຮັດວຽກຂອງທາງເລືອກເຫຼົ່ານີ້ສາມາດຊ່ວຍປັບປຸງຄວາມປອດໄພແລະປະສິດທິພາບຂອງລະບົບໂດຍລວມຂອງທ່ານ. ບົດຄວາມນີ້ອະທິບາຍຄວາມສໍາຄັນຂອງທາງເລືອກນະໂຍບາຍ Calico ເຫຼົ່ານີ້ (preDNAT, unraracked ແລະ applyOnForward) ນໍາໃຊ້ກັບ endpoints ເຈົ້າພາບ, ໂດຍເນັ້ນໃສ່ສິ່ງທີ່ເກີດຂຶ້ນໃນເສັ້ນທາງການປະມວນຜົນ packet (ຕ່ອງໂສ້ iptabels).

ບົດ​ຄວາມ​ນີ້​ສົມ​ມຸດ​ວ່າ​ທ່ານ​ມີ​ຄວາມ​ເຂົ້າ​ໃຈ​ພື້ນ​ຖານ​ກ່ຽວ​ກັບ​ວິ​ທີ​ການ​ນະ​ໂຍ​ບາຍ​ເຄືອ​ຂ່າຍ Kubernetes ແລະ Calico ເຮັດ​ວຽກ​. ຖ້າບໍ່, ພວກເຮົາແນະນໍາໃຫ້ລອງມັນ ການສອນການນຳໃຊ້ນະໂຍບາຍເຄືອຂ່າຍພື້ນຖານ и ການສອນການປ້ອງກັນເຈົ້າພາບ ໃຊ້ Calico ກ່ອນທີ່ຈະອ່ານບົດຄວາມນີ້. ພວກເຮົາຍັງຄາດຫວັງໃຫ້ທ່ານມີຄວາມເຂົ້າໃຈພື້ນຖານກ່ຽວກັບວຽກງານ iptables ໃນ Linux.

Calico ນະໂຍບາຍເຄືອຂ່າຍທົ່ວໂລກ ອະນຸຍາດໃຫ້ທ່ານນໍາໃຊ້ຊຸດຂອງກົດລະບຽບການເຂົ້າເຖິງໂດຍປ້າຍຊື່ (ກັບກຸ່ມຂອງ hosts ແລະ workloads / pods). ນີ້ແມ່ນເປັນປະໂຫຍດຫຼາຍຖ້າທ່ານໃຊ້ລະບົບ heterogeneous ຮ່ວມກັນ - ເຄື່ອງຈັກ virtual, ລະບົບໂດຍກົງກ່ຽວກັບຮາດແວ, ຫຼືໂຄງສ້າງພື້ນຖານ kubernetes. ນອກຈາກນັ້ນ, ທ່ານສາມາດປົກປ້ອງກຸ່ມຂອງທ່ານ (nodes) ໂດຍໃຊ້ຊຸດຂອງນະໂຍບາຍການປະກາດແລະນໍາໃຊ້ນະໂຍບາຍເຄືອຂ່າຍກັບການຈະລາຈອນຂາເຂົ້າ (ຕົວຢ່າງ, ຜ່ານບໍລິການ NodePorts ຫຼື IPs ພາຍນອກ).

ໃນລະດັບພື້ນຖານ, ເມື່ອ Calico ເຊື່ອມຕໍ່ຝັກກັບເຄືອຂ່າຍ (ເບິ່ງແຜນວາດຂ້າງລຸ່ມນີ້), ມັນຈະເຊື່ອມຕໍ່ມັນກັບເຈົ້າພາບໂດຍໃຊ້ການໂຕ້ຕອບ Ethernet virtual (veth). ການຈະລາຈອນທີ່ສົ່ງໂດຍຝັກມາຫາເຈົ້າພາບຈາກການໂຕ້ຕອບ virtual ນີ້ແລະຖືກປຸງແຕ່ງໃນລັກສະນະດຽວກັນກັບວ່າມັນມາຈາກການໂຕ້ຕອບເຄືອຂ່າຍທາງດ້ານຮ່າງກາຍ. ໂດຍຄ່າເລີ່ມຕົ້ນ, Calico ຕັ້ງຊື່ສ່ວນຕິດຕໍ່ເຫຼົ່ານີ້ caliXXX. ນັບຕັ້ງແຕ່ການຈະລາຈອນມາໂດຍຜ່ານການໂຕ້ຕອບ virtual, ມັນຜ່ານ iptables ຄືກັບວ່າຝັກແມ່ນຫນຶ່ງ hop ໄປ. ດັ່ງນັ້ນ, ເມື່ອການຈະລາຈອນມາຫາ / ຈາກຝັກ, ມັນຖືກສົ່ງຕໍ່ຈາກທັດສະນະຂອງເຈົ້າພາບ.

ໃນ node Kubernetes ແລ່ນ Calico, ທ່ານສາມາດສ້າງແຜນທີ່ virtual interface (veth) ກັບ workload ດັ່ງຕໍ່ໄປນີ້. ໃນຕົວຢ່າງຂ້າງລຸ່ມນີ້, ທ່ານສາມາດເຫັນໄດ້ວ່າ veth #10 (calic1cbf1ca0f8) ແມ່ນເຊື່ອມຕໍ່ກັບ cnx-manager-* ໃນ namespace calico-monitoring.

[centos@ip-172-31-31-46 K8S]$ sudo ip a
...
10: calic1cbf1ca0f8@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 5
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link
       valid_lft forever preferred_lft forever
...

[centos@ip-172-31-31-46 K8S]$ calicoctl get wep --all-namespaces
...
calico-monitoring cnx-manager-8f778bd66-lz45m                            ip-172-31-31-46.ec2.internal 192.168.103.134/32
calic1cbf1ca0f8
...

ເນື່ອງຈາກ Calico ສ້າງການໂຕ້ຕອບ veth ສໍາລັບແຕ່ລະວຽກ, ມັນບັງຄັບໃຊ້ນະໂຍບາຍແນວໃດ? ເພື່ອເຮັດສິ່ງນີ້, Calico ສ້າງ hooks ໃນຕ່ອງໂສ້ຕ່າງໆຂອງເສັ້ນທາງການປຸງແຕ່ງແພັກເກັດໂດຍໃຊ້ iptables.

ແຜນວາດຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນລະບົບຕ່ອງໂສ້ທີ່ກ່ຽວຂ້ອງກັບການປຸງແຕ່ງແພັກເກັດໃນ iptables (ຫຼືລະບົບຍ່ອຍ netfilter). ເມື່ອແພັກເກັດມາຮອດຜ່ານອິນເຕີເຟດເຄືອຂ່າຍ, ທຳອິດມັນຈະຜ່ານລະບົບຕ່ອງໂສ້ PREROUTING. ການຕັດສິນໃຈເສັ້ນທາງແມ່ນເຮັດ, ແລະອີງໃສ່ນີ້, packet ຜ່ານທັງ INPUT (ມຸ້ງໄປຫາຂະບວນການໂຮດ) ຫຼື FORWARD (ມຸ້ງໄປຫາ pod ຫຼື node ອື່ນໃນເຄືອຂ່າຍ). ຈາກຂະບວນການທ້ອງຖິ່ນ, ແພັກເກັດຈະຜ່ານ OUTPUT ແລະຫຼັງຈາກນັ້ນລະບົບຕ່ອງໂສ້ POSTROUTING ກ່ອນທີ່ຈະຖືກສົ່ງລົງສາຍ.

ໃຫ້ສັງເກດວ່າຝັກແມ່ນຍັງເປັນຫນ່ວຍງານພາຍນອກ (ເຊື່ອມຕໍ່ກັບ veth) ໃນການປຸງແຕ່ງ iptables. ຂໍສະຫຼຸບ:

• ການຈະລາຈອນທີ່ສົ່ງຕໍ່ (nat, routed ຫຼື to/ from a pod) ຈະຜ່ານຕ່ອງໂສ້ການສົ່ງຕໍ່ - ຕໍ່ໄປ - POSTROUTING.
• ການຈະລາຈອນໄປຫາຂະບວນການໂຮດທ້ອງຖິ່ນຜ່ານລະບົບຕ່ອງໂສ້ PREROUTING - INPUT.
• ການຈະລາຈອນຈາກຂະບວນການໂຮດທ້ອງຖິ່ນຜ່ານລະບົບຕ່ອງໂສ້ OUTPUT - POSTROUTING.

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

1. ນະໂຍບາຍຈຸດສິ້ນສຸດວຽກ (pod).
2. ນະໂຍບາຍຈຸດສິ້ນສຸດຂອງເຈົ້າພາບ
3. ທາງເລືອກ ApplyOnForward
4. ນະໂຍບາຍ PreDNAT
5. ນະໂຍບາຍທີ່ບໍ່ມີການຕິດຕາມ

ໃຫ້ເລີ່ມຕົ້ນໂດຍການເບິ່ງວິທີການນໍາໃຊ້ນະໂຍບາຍກັບຈຸດສິ້ນສຸດຂອງວຽກ (Kubernetes pods ຫຼື OpenStack VMs), ແລະຫຼັງຈາກນັ້ນເບິ່ງຕົວເລືອກນະໂຍບາຍສໍາລັບຈຸດສິ້ນສຸດຂອງເຈົ້າພາບ.

ຈຸດສິ້ນສຸດວຽກ

ນະໂຍບາຍຈຸດສິ້ນສຸດຂອງວຽກ (1)

ນີ້ແມ່ນທາງເລືອກທີ່ຈະປົກປ້ອງຝັກ kubernetes ຂອງທ່ານ. Calico ສະຫນັບສະຫນູນການເຮັດວຽກກັບ Kubernetes NetworkPolicy, ແຕ່ມັນຍັງສະຫນອງນະໂຍບາຍເພີ່ມເຕີມ - Calico NetworkPolicy ແລະ GlobalNetworkPolicy. Calico ສ້າງຕ່ອງໂສ້ສໍາລັບແຕ່ລະຝັກ (workload) ແລະ hooks ໃນຕ່ອງໂສ້ INPUT ແລະ OUTPUT ສໍາລັບ workload ກັບຕາຕະລາງການກັ່ນຕອງຂອງຕ່ອງໂສ້ FORWARD.

ໂຮສຈຸດສິ້ນສຸດ

ນະໂຍບາຍຈຸດສິ້ນສຸດຂອງເຈົ້າພາບ (2)

ນອກເຫນືອຈາກ CNI (ການໂຕ້ຕອບເຄືອຂ່າຍຕູ້ຄອນເທນເນີ), ນະໂຍບາຍ Calico ໃຫ້ຄວາມສາມາດໃນການປົກປ້ອງເຈົ້າພາບຕົວເອງ. ໃນ Calico, ທ່ານສາມາດສ້າງຈຸດສິ້ນສຸດຂອງເຈົ້າພາບໂດຍການລະບຸການປະສົມປະສານຂອງອິນເຕີເຟດໂຮດແລະ, ຖ້າຈໍາເປັນ, ຕົວເລກພອດ. ການບັງຄັບໃຊ້ນະໂຍບາຍສໍາລັບນິຕິບຸກຄົນນີ້ແມ່ນບັນລຸໄດ້ໂດຍໃຊ້ຕາຕະລາງການກັ່ນຕອງໃນລະບົບຕ່ອງໂສ້ INPUT ແລະ OUTPUT. ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້ຈາກແຜນວາດ, (2) ພວກມັນໃຊ້ກັບຂະບວນການທ້ອງຖິ່ນໃນ node / host. ນັ້ນແມ່ນ, ຖ້າທ່ານສ້າງນະໂຍບາຍທີ່ນໍາໃຊ້ກັບຈຸດສິ້ນສຸດຂອງເຈົ້າພາບ, ມັນຈະບໍ່ມີຜົນກະທົບຕໍ່ການຈະລາຈອນໄປ / ຈາກ pods ຂອງທ່ານ. ແຕ່ມັນສະຫນອງການໂຕ້ຕອບ / syntax ດຽວສໍາລັບການສະກັດການຈະລາຈອນສໍາລັບເຈົ້າພາບແລະ pods ຂອງທ່ານໂດຍໃຊ້ນະໂຍບາຍ Calico. ອັນນີ້ເຮັດໃຫ້ຂະບວນການຄຸ້ມຄອງນະໂຍບາຍງ່າຍຂຶ້ນຫຼາຍສຳລັບເຄືອຂ່າຍທີ່ຫຼາກຫຼາຍ. ການຕັ້ງຄ່ານະໂຍບາຍຈຸດສິ້ນສຸດຂອງແມ່ຂ່າຍເພື່ອເພີ່ມຄວາມປອດໄພຂອງກຸ່ມເປັນກໍລະນີການນໍາໃຊ້ທີ່ສໍາຄັນອີກອັນຫນຶ່ງ.

ນຳໃຊ້ນະໂຍບາຍ OnForward (3)

ທາງເລືອກ ApplyOnForward ແມ່ນມີຢູ່ໃນນະໂຍບາຍເຄືອຂ່າຍທົ່ວໂລກ Calico ເພື່ອອະນຸຍາດໃຫ້ນະໂຍບາຍຖືກນໍາໃຊ້ກັບການຈະລາຈອນທັງຫມົດທີ່ຜ່ານຈຸດສຸດທ້າຍຂອງເຈົ້າພາບ, ລວມທັງການຈະລາຈອນທີ່ຈະຖືກສົ່ງຕໍ່ໂດຍເຈົ້າພາບ. ນີ້ລວມມີການສົ່ງຕໍ່ໄປຫາ pod ທ້ອງຖິ່ນຫຼືບ່ອນອື່ນໃນເຄືອຂ່າຍ. Calico ຮຽກຮ້ອງໃຫ້ເປີດໃຊ້ການຕັ້ງຄ່ານີ້ສໍາລັບນະໂຍບາຍການນໍາໃຊ້ PreDNAT ແລະ untracked, ເບິ່ງພາກຕໍ່ໄປນີ້. ນອກຈາກນັ້ນ, ApplyOnForward ສາມາດຖືກນໍາໃຊ້ເພື່ອຕິດຕາມກວດກາການຈະລາຈອນຂອງເຈົ້າພາບໃນກໍລະນີທີ່ມີ router virtual ຫຼືຊອບແວ NAT ຖືກນໍາໃຊ້.

ໃຫ້ສັງເກດວ່າຖ້າທ່ານຕ້ອງການໃຊ້ນະໂຍບາຍເຄືອຂ່າຍດຽວກັນກັບທັງສອງຂະບວນການໂຮດແລະພອດ, ຫຼັງຈາກນັ້ນທ່ານບໍ່ຈໍາເປັນຕ້ອງໃຊ້ທາງເລືອກ ApplyOnForward. ສິ່ງທີ່ທ່ານຕ້ອງເຮັດແມ່ນສ້າງປ້າຍສໍາລັບ hostendpoint ແລະ workload endpoint (pod). Calico ແມ່ນສະຫລາດພໍທີ່ຈະບັງຄັບໃຊ້ນະໂຍບາຍໂດຍອີງໃສ່ປ້າຍຊື່, ໂດຍບໍ່ຄໍານຶງເຖິງປະເພດຂອງຈຸດສິ້ນສຸດ (hostendpoint ຫຼື workload).

ນະໂຍບາຍ PreDNAT (4)

ໃນ Kubernetes, ຜອດຫນ່ວຍບໍລິການສາມາດຖືກເປີດເຜີຍພາຍນອກໂດຍໃຊ້ຕົວເລືອກ NodePorts ຫຼື, ທາງເລືອກ (ເມື່ອໃຊ້ Calico), ໂດຍການໂຄສະນາໃຫ້ເຂົາເຈົ້ານໍາໃຊ້ Cluster IPs ຫຼືທາງເລືອກ IPs ພາຍນອກ. Kube-proxy ດຸ່ນດ່ຽງການຈາລະຈອນຂາເຂົ້າທີ່ຜູກມັດກັບການບໍລິການກັບ pods ຂອງການບໍລິການທີ່ສອດຄ້ອງກັນໂດຍໃຊ້ DNAT. ດ້ວຍເຫດຜົນນີ້, ທ່ານຈະບັງຄັບໃຊ້ນະໂຍບາຍສໍາລັບການຈະລາຈອນທີ່ເຂົ້າມາຜ່ານ NodePorts ແນວໃດ? ເພື່ອຮັບປະກັນວ່ານະໂຍບາຍເຫຼົ່ານີ້ຖືກນຳໃຊ້ກ່ອນທີ່ການຈະລາຈອນຈະຖືກປະມວນຜົນໂດຍ DNAT (ເຊິ່ງເປັນການສ້າງແຜນທີ່ລະຫວ່າງໂຮດ:ພອດ ແລະບໍລິການທີ່ສອດຄ້ອງກັນ), Calico ໃຫ້ພາລາມິເຕີສຳລັບ globalNetworkPolicy ເອີ້ນວ່າ "preDNAT: true".

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

ເມື່ອສ້າງນະໂຍບາຍກັບ DNAT ກ່ອນ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະລະມັດລະວັງກ່ຽວກັບການຈະລາຈອນທີ່ທ່ານຕ້ອງການທີ່ຈະດໍາເນີນການແລະອະນຸຍາດໃຫ້ຄົນສ່ວນໃຫຍ່ຖືກປະຕິເສດ. ການຈະລາຈອນທີ່ຖືກໝາຍເປັນ 'ອະນຸຍາດ' ໃນນະໂຍບາຍທາງສ່ວນຫນ້າຂອງ DNAT ຈະບໍ່ຖືກກວດສອບໂດຍນະໂຍບາຍ hostendpoint ອີກຕໍ່ໄປ, ໃນຂະນະທີ່ການຈະລາຈອນທີ່ລົ້ມເຫລວໃນນະໂຍບາຍກ່ອນ DNAT ຈະສືບຕໍ່ຜ່ານຕ່ອງໂສ້ທີ່ຍັງເຫຼືອ.
Calico ໄດ້ເຮັດໃຫ້ມັນບັງຄັບໃຫ້ເປີດໃຊ້ທາງເລືອກ applyOnForward ໃນເວລາທີ່ໃຊ້ preDNAT, ເນື່ອງຈາກວ່າໂດຍຄໍານິຍາມຈຸດຫມາຍປາຍທາງຂອງການຈະລາຈອນຍັງບໍ່ທັນໄດ້ເລືອກ. ການຈະລາຈອນສາມາດຖືກນໍາໄປຫາຂະບວນການໂຮດ, ຫຼືມັນສາມາດຖືກສົ່ງຕໍ່ໄປຫາ pod ຫຼື node ອື່ນ.

ນະໂຍບາຍທີ່ບໍ່ມີການຕິດຕາມ (5)

ເຄືອຂ່າຍແລະຄໍາຮ້ອງສະຫມັກສາມາດມີຄວາມແຕກຕ່າງຂະຫນາດໃຫຍ່ໃນພຶດຕິກໍາ. ໃນບາງກໍລະນີທີ່ຮຸນແຮງ, ແອັບພລິເຄຊັນອາດຈະສ້າງການເຊື່ອມຕໍ່ທີ່ມີຊີວິດສັ້ນຫຼາຍ. ອັນນີ້ສາມາດເຮັດໃຫ້ conntrack (ອົງປະກອບຫຼັກຂອງ Linux networking stack) ໝົດຄວາມຈຳ. ຕາມປະເພນີ, ເພື່ອດໍາເນີນການປະເພດຂອງຄໍາຮ້ອງສະຫມັກເຫຼົ່ານີ້ຢູ່ໃນ Linux, ທ່ານຈະຕ້ອງຕັ້ງຄ່າດ້ວຍຕົນເອງຫຼືປິດການໃຊ້ງານ conntrack, ຫຼືຂຽນກົດລະບຽບ iptables ເພື່ອຂ້າມ conntrack. ນະໂຍບາຍທີ່ບໍ່ມີການຕິດຕາມໃນ Calico ແມ່ນທາງເລືອກທີ່ງ່າຍກວ່າ ແລະມີປະສິດທິພາບກວ່າ ຖ້າທ່ານຕ້ອງການປະມວນຜົນການເຊື່ອມຕໍ່ໄວເທົ່າທີ່ຈະໄວໄດ້. ຕົວຢ່າງ, ຖ້າທ່ານໃຊ້ຂະຫນາດໃຫຍ່ memcache ຫຼືເປັນມາດຕະການເພີ່ມເຕີມຂອງການປົກປ້ອງຕໍ່ຕ້ານ DDOS.

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

ເມື່ອທ່ານຕັ້ງຕົວເລືອກ "doNotTrack: true" ໃນ Calico globalNetworkPolicy, ມັນຈະກາຍເປັນນະໂຍບາຍ **untracked** ແລະຖືກນຳໃຊ້ຫຼາຍໃນຂັ້ນຕອນການປະມວນຜົນແພັກເກັດຂອງ Linux. ຊອກຫາຢູ່ໃນແຜນວາດຂ້າງເທິງ, ນະໂຍບາຍທີ່ບໍ່ມີການຕິດຕາມແມ່ນຖືກນໍາໃຊ້ໃນລະບົບຕ່ອງໂສ້ PREROUTING ແລະ OUTPUT ໃນຕາຕະລາງດິບກ່ອນທີ່ຈະເລີ່ມຕົ້ນການຕິດຕາມການເຊື່ອມຕໍ່ (conntrack). ເມື່ອແພັກເກັດຖືກອະນຸຍາດໂດຍນະໂຍບາຍທີ່ບໍ່ໄດ້ຕິດຕາມ, ມັນຈະຖືກໝາຍໃຫ້ປິດການຕິດຕາມການເຊື່ອມຕໍ່ສຳລັບແພັກເກັດນັ້ນ. ຫມາຍ​ຄວາມ​ວ່າ:

• ນະ​ໂຍ​ບາຍ​ທີ່​ບໍ່​ໄດ້​ຕິດ​ຕາມ​ແມ່ນ​ໄດ້​ຮັບ​ການ​ນໍາ​ໃຊ້​ບົນ​ພື້ນ​ຖານ​ຕໍ່​ຊຸດ. ບໍ່ມີແນວຄວາມຄິດຂອງການເຊື່ອມຕໍ່ (ຫຼືການໄຫຼ). ການຂາດການເຊື່ອມຕໍ່ມີຜົນສະທ້ອນທີ່ສໍາຄັນຫຼາຍ:
• ຖ້າທ່ານຕ້ອງການອະນຸຍາດໃຫ້ທັງການຮ້ອງຂໍແລະການຕອບໂຕ້, ທ່ານຕ້ອງການກົດລະບຽບສໍາລັບທັງຂາເຂົ້າແລະຂາອອກ (ນັບຕັ້ງແຕ່ Calico ປົກກະຕິແລ້ວໃຊ້ conntrack ເພື່ອຫມາຍການຈະລາຈອນຕອບຮັບເປັນອະນຸຍາດ).
• ນະໂຍບາຍ untracked ບໍ່ເຮັດວຽກສໍາລັບ Kubernetes workloads (pods), ເນື່ອງຈາກວ່າໃນກໍລະນີນີ້ບໍ່ມີວິທີທີ່ຈະຕິດຕາມການເຊື່ອມຕໍ່ຂາອອກຈາກ pods ໄດ້.
• NAT ເຮັດວຽກບໍ່ຖືກຕ້ອງກັບແພັກເກັດທີ່ບໍ່ໄດ້ຕິດຕາມ (ນັບຕັ້ງແຕ່ kernel ເກັບຮັກສາແຜນທີ່ NAT ໃນ conntrack).
• ເມື່ອຜ່ານກົດລະບຽບ "ອະນຸຍາດໃຫ້ທັງຫມົດ" ໃນນະໂຍບາຍທີ່ບໍ່ໄດ້ຕິດຕາມ, ທຸກແພັກເກັດຈະຖືກຫມາຍເປັນ untracked. ນີ້ແມ່ນເກືອບສະເຫມີບໍ່ແມ່ນສິ່ງທີ່ທ່ານຕ້ອງການ, ດັ່ງນັ້ນມັນຈໍາເປັນຕ້ອງເລືອກຫຼາຍກ່ຽວກັບແພັກເກັດທີ່ໄດ້ຮັບອະນຸຍາດໂດຍນະໂຍບາຍທີ່ບໍ່ມີການຕິດຕາມ (ແລະອະນຸຍາດໃຫ້ການຈະລາຈອນສ່ວນໃຫຍ່ຜ່ານນະໂຍບາຍຕິດຕາມປົກກະຕິ).
• ນະ​ໂຍ​ບາຍ​ທີ່​ບໍ່​ມີ​ການ​ຕິດ​ຕາມ​ແມ່ນ​ໄດ້​ຖືກ​ນໍາ​ໃຊ້​ໃນ​ຕອນ​ຕົ້ນ​ຂອງ​ທໍ່​ການ​ປຸງ​ແຕ່ງ​ຊອງ. ນີ້ແມ່ນສິ່ງສໍາຄັນຫຼາຍທີ່ຈະເຂົ້າໃຈໃນເວລາທີ່ສ້າງນະໂຍບາຍ Calico. ທ່ານສາມາດມີນະໂຍບາຍຝັກທີ່ມີຄໍາສັ່ງ: 1 ແລະນະໂຍບາຍທີ່ບໍ່ມີການຕິດຕາມທີ່ມີຄໍາສັ່ງ: 1000. ມັນຈະບໍ່ສໍາຄັນ. ນະໂຍບາຍ Untracked ຈະຖືກນໍາໃຊ້ກ່ອນນະໂຍບາຍສໍາລັບ pod ໄດ້. ນະ​ໂຍ​ບາຍ​ທີ່​ບໍ່​ມີ​ການ​ຕິດ​ຕາມ​ແມ່ນ​ນັບ​ຖື​ຄໍາ​ສັ່ງ​ປະ​ຕິ​ບັດ​ພຽງ​ແຕ່​ໃນ​ບັນ​ດາ​ຕົນ​ເອງ​.

ເນື່ອງຈາກວ່າຫນຶ່ງໃນຈຸດປະສົງຂອງນະໂຍບາຍ doNotTrack ແມ່ນເພື່ອບັງຄັບໃຊ້ນະໂຍບາຍໃນຕົ້ນໆຂອງທໍ່ການປຸງແຕ່ງແພັກເກັດ Linux, Calico ເຮັດໃຫ້ມັນບັງຄັບໃຫ້ລະບຸທາງເລືອກ applyOnForward ເມື່ອໃຊ້ doNotTrack. ໂດຍອ້າງອີງໃສ່ແຜນວາດການປະມວນຜົນແພັກເກັດ, ຈົ່ງຈື່ໄວ້ວ່ານະໂຍບາຍທີ່ບໍ່ມີການຕິດຕາມ (5) ຖືກນຳໃຊ້ກ່ອນທີ່ຈະມີການຕັດສິນໃຈກຳນົດເສັ້ນທາງ. ການຈະລາຈອນສາມາດຖືກນໍາໄປຫາຂະບວນການໂຮດ, ຫຼືມັນສາມາດຖືກສົ່ງຕໍ່ໄປຫາ pod ຫຼື node ອື່ນ.

ຜົນໄດ້ຮັບ

ພວກເຮົາໄດ້ເບິ່ງຕົວເລືອກນະໂຍບາຍຕ່າງໆ (Host endpoint, ApplyOnForward, preDNAT, ແລະ Untracked) ໃນ Calico ແລະວິທີການທີ່ພວກມັນຖືກນໍາໃຊ້ຕາມເສັ້ນທາງການປຸງແຕ່ງແພັກເກັດ. ຄວາມເຂົ້າໃຈວິທີການເຮັດວຽກຊ່ວຍໃນການພັດທະນານະໂຍບາຍທີ່ມີປະສິດທິພາບແລະປອດໄພ. ດ້ວຍ Calico ທ່ານສາມາດນໍາໃຊ້ນະໂຍບາຍເຄືອຂ່າຍທົ່ວໂລກທີ່ໃຊ້ກັບປ້າຍຊື່ (ກຸ່ມຂອງ nodes ແລະ pods) ແລະນໍາໃຊ້ນະໂຍບາຍທີ່ມີຕົວກໍານົດການຕ່າງໆ. ນີ້ອະນຸຍາດໃຫ້ຜູ້ຊ່ຽວຊານດ້ານຄວາມປອດໄພແລະການອອກແບບເຄືອຂ່າຍສາມາດປົກປ້ອງ "ທຸກສິ່ງທຸກຢ່າງ" ໄດ້ສະດວກສະບາຍ (ປະເພດຈຸດສິ້ນສຸດ) ໃນເວລາດຽວໂດຍໃຊ້ພາສານະໂຍບາຍດຽວກັບນະໂຍບາຍ Calico.

ການຮັບຮູ້: ຂ້າພະເຈົ້າຢາກຂໍຂອບໃຈ Sean Crampton и Alexa Pollitta ສໍາລັບການທົບທວນຄືນແລະຂໍ້ມູນທີ່ມີຄຸນຄ່າຂອງພວກເຂົາ.

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