Recently, I saw a video talking about why they replaced iptables with eBPF in Kuberentes. As a pre-CKA person 😂(Damn, I need to get certified quickly, all this procrastinating is messed up), I need to know about this new stuff. So this is actually a beginner’s guide of eBPF for myself.
# It turns out that eBPF started to appear in Linux Kernel in 2014. Not that new after all. 🤘
What is BPF?
Berkeley Packet Filter (BPF) is a Linux kernel bytecode interpreter originally introduced to filter network packets, e.g. for tcpdump and socket filters.
I think we can say that BPF handles network packets filtering and eBPF is an improved version of BPF. 💡
What is eBPF? 🐝
eBPF(extended BPF) is a revolutionary technology that can run sandboxed programs in the Linux kernel without changing kernel source code or loading kernel modules.
Why do we even care to run custom code in the Linux Kernel? Well, Linux Kernel is the main core of our software, so it is an ideal place to implement monitoring/observability, networking, and security solution. If we can reuse the existing layers in Kernel space, we can improve the efficiency of our applications. However, we need to make sure our code didn’t screw up the entire Linux Kernel.
This is where eBPF come in handy. By leveraging eBPF, developers can easily and safely run their code in the Linux Kernel.
How does eBPF work?
I found this awesome video that clearly explain the process of how a user-defined eBPF application work. We can see how user defined a eBPF application in the user space.
- User writes a few lines of code in C, which is managed by a eBPF agent like Cilium. Cilium provides a friendly abstraction for eBPF.
- These code are then compiled by the compiler tools into eBPF bytecode, e.g. LLVM.
- If a certain event is triggered, which is called a hook, an event packet in this case, this compiled file will be handed over to the BPF loader to load it into the Kernel.
- Before loading the eBPF bytecode to the Kernel, it needs to be verified. The BPF verifier will check if the code cannot crash, harm the system or run forever.
- After verification, BPF verifier will hand over to JIT(Just-in-time compilation) to translate bytecode into machine instructions to optimize its running speed to match the native Kernel code.
- User can collect useful information in the Kernel by Cilium through BPF maps.
In this code example, we want to redirect packets that are sent to port 80 to lxc0, and drop the rest of other packets.
How can Kubernetes benefits from eBPF?
The above image shows the packet flow for kube-proxy. The orange sections are the iptables chain for processing a packet. If the packet is being sent to a remote service endpoint or lxc0, it has to go through all these processes.
After applying Cilium for packet forwarding, it seems that the overhead of iptables disappear, making the whole packet flow more efficient. The below is the performance comparison between kube-proxy and XDP + eBPF. I believe you! 🤟 The benchmark seems nice, but I want to double check this myself. 🤠
Conclusion
I cannot wait to try applying Cilium to my Kubernetes clusters! 🤗 I’ll share some development and operation notes with Cilium + eBPF in the next post.
Reference
[1] Replacing iptables with eBPF in Kubernetes with Cilium
[2] eBPF and Kubernetes: Little Helper Minions for Scaling Microservices — Daniel Borkmann, Cilium
