katran 为什么使用 IPIP？ 而且封装后还丢回原网卡。 好像是在物理网卡上以这种思路做了 “loopback” 一样
The Katran Architecture: In-Kernel, XDP-Powered Load Balancing Katran's design is brilliant in its simplicity and efficiency. It is deployed as a software-based load balancer on commodity Linux servers and operates as follows:
- XDP Ingress: An eBPF program is attached to the network interface using XDP. This program is the first piece of software to see an incoming packet, acting before the kernel's networking stack.
- Consistent Hashing with Maglev: When a new connection's packet arrives, the eBPF program uses a hash of the packet's 5-tuple (source IP, source port, destination IP, destination port, protocol) to select a backend server. Katran uses a modified version of Google's Maglev consistent hashing algorithm, which ensures that packets from the same connection always go to the same backend, even if a load balancer node fails. This also allows multiple Katran instances to make the same routing decision without communicating with each other.
- Encapsulation and Forwarding: Instead of copying the packet to user space, the eBPF program encapsulates it in an IP-in-IP tunnel destined for the selected backend server. It then uses the XDP_TX action to send the encapsulated packet directly back out the same NIC. This is a crucial step that avoids all the traditional networking stack overhead.
- No Context Switching: Because all the packet processing, hashing, and forwarding logic happens within the eBPF program at the XDP layer, there is no need to switch to user space, eliminating a major source of latency and CPU overhead.
参考
Sousa , Benjamin E. . Linux Networking with eBPF: From Packet Processing to Cloud-Native Security (Mastering eBPF : The Professional’s Guide to Linux Performance and Cloud-Native Security) (pp. 217-218). (Function). Kindle Edition.
