I’ve been keeping an eye on eBPF for a little while. In fact, the first time I properly paid attention was when listening to one of my favourite Cloud podcasts:
eBPF also caught my eye because the leading eBPF company out there (Isovalent) was cofounded by leaders in the cloud networking space and because they keep hiring industry leaders and folks I respect. I was particularly impressed that Isovalent’s project Cilium is used as the default networking and security option for AWS EKS Anywhere.
Isovalent’s Chief Open Source Officer – Liz Rice – presented a recent session that I took the time to attend. I will admit that there are still many concepts I need to wrap my head around so please forgive my inaccuracies. After all, what I will be doing is learning in public.
Why eBPF (in my own words)
Linux is extremely popular and is used literally everywhere. As a consequence though, the Linux kernel (and its 53,600 files and 20-million lines of code) is not something you mess about with. Any changes to the upstream Linux kernel can be a daunting process.
So if you want to add some features to the Linux kernel, it might literally take years to be not only accepted but also implemented and rolled out. That’s especially applicable to networking and security features. For example: Open vSwitch.
OVS is like the Open Source and Linux version of the Cisco Nexus 1000V or the VMware Distributed Virtual Switch if you come from the Cisco or VMware worlds.
Adding OVS to the Linux kernel would have been a no-brainer from a functionality & feature aspect but it was a strenuous process regardless (again – because of the wider ramifications involved in updating the kernel). I imagine that every single enhancement to OVS (and therefore to the Kernel) would have to be ratified and approved.
One way to bypass this lengthy process is to use eBPF. eBPF allows users to run functions in kernel. In practical terms, the most common use case appears to be for networking and security use cases, like service mesh. eBPF runs in a sandbox and is verified, which means that, even though it might run in kernel, it is still secure.
eBPF essentially made the Linux Kernel extensible and will enable users to insert networking and security capabilities that are not possible today. And by users, I mean:
- networking/security vendors adding some eBPF-based features to their existing products
- service providers or very large enterprise customers (Netflix/Facebook for example) writing eBPF codes and implementing eBPF to achieve better performances or more security/observability
- end-users who will use eBPF-based projects for their own needs but might not write eBPF code themselves (as it can be very complex).
One of the challenges with writing eBPF programs is that it typically requires writing ‘user-space’ (usually in Python) code and ‘kernel’ based code (usually in C). Solo.io, a start-up in the service-mesh and micro-services connectivity space, was updating their service mesh products with eBPF capabilities and ran into challenges with writing eBPF programs. They decided to build their own tool to provide a docker-like experience to build eBPF functions (essentially, removing the need to write the specific ‘user-space’ code and making it easy to port the code to various platforms). The tool is called BumbleBee.
Lin Sun explains it far better than I could in this blog post:
Getting Started with eBPF & BumbleBee
The blog post above also explains how to go and run Bumbleebee with Vagrant which is obviously a great choice. Alternatively, you can use a Linux VM like me (using an EC2 instance).
I followed Christian’s video at the end of the blog post here.
First, I downloaded and installed Bumbleee:
[ec2-user@ip-172-31-92-171 ~]$ curl -sL https://run.solo.io/bee/install | sh Attempting to download bee version v0.0.10 Downloading bee-linux-amd64... Download complete!, validating checksum... Checksum valid. bee was successfully installed 🎉 Add the bumblebee CLI to your path with: export PATH=$HOME/.bumblebee/bin:$PATH Now run: bee init # Initialize simple eBPF program to run with bee Please see visit the bumblebee website for more info: https://github.com/solo-io/bumblebee
Next, I add bumblebee to my environment variables path.
[ec2-user@ip-172-31-92-171 ~]$ export PATH=$HOME/.bumblebee/bin:$PATH
Finally, I run bumblebee. Note it needs to run in “sudo” because we are running eBPF programs in kernel (it requires elevated privileges). The path environmental variables are not preserved when using sudo so we need to specify the bee path. Finally, we are running the tcpconnect eBPF program (directly pulled from GitHub).
Bee run will render the output of the commands into a basic UI.
[ec2-user@ip-172-31-92-171 ~]$ sudo env "PATH=$PATH" bee run ghcr.io/solo-io/bumblebee/tcpconnect:$(bee version) SUCCESS Fetching program from registry: ghcr.io/solo-io/bumblebee/tcpconnect:0.0.10 SUCCESS Loading BPF program and maps into Kernel SUCCESS Linking BPF functions to associated probe/tracepoint INFO Rendering TUI...
The tcpconnect eBPF program is essentially a good helloWorld eBPF example. It will track every TCP connections. So when I run “curl” or “wget”, it can see the IP addresses of the TCP request.
Clearly this is a very basic use case of eBPF for networking but a good example nonetheless.
- eBPF will give us flexibility around the networking stack of the Linux kernel. The primary use cases are around observability, tracing, security and advanced networking in micro-services environments.
- I had been interested in eBPF for the past couple of years but I admit I hadn’t taken the time to go and test it. Using bumblebee made it very easy for me to run some eBPF code.
Video & Mini Demo
In the next post, I check out Cilium, an eBPF-based Container Network Interface (CNI) for Kubernetes.
2 thoughts on “Exploring eBPF – Part 1”