Taking eBPF 🐝 for a ride on the Solo.io rocketship 🚀🚀🚀

I recently attended our brand new eBPF workshop, which was announced and delivered at SoloCon 2022. Let me give you a walk-through on taking eBPF for a ride on the Solo.io rocketship … 

First, there’s A LOT (I mean A LOT) of buzz around eBPF. In fact, plenty of implementations and interpretations exist. eBPF can be used for anything in the Linux kernel and several tools have been created for debugging and introspection. What we at Solo.io care most about is solving for challenges around:

• Networking
• Security
• Observability

But, before we get started, what is eBPF?

eBPF stands for extended-Berkley Packet Filter. The two words, Packet Filter, just get me all warm and fuzzy because already, it has something to do with networking technology. eBPF provides a unique approach to creating Just-In-Time sandboxed applications inside of the operating system, which allows you to extend kernel capabilities without having to recompile to modify the kernel itself.

If we build with eBPF, we have the ability to revolutionize how we create and deploy networks, observe and monitor different parts of our application, or even push strict security policies. 

Here’s the official definition from eBPF.io, an open source initiative for eBPF:

eBPF is a revolutionary technology with origins in the Linux kernel that can run sandboxed programs in an operating system kernel. It is used to safely and efficiently extend the capabilities of the kernel without requiring to change kernel source code or load kernel modules.

Historically, the operating system has always been an ideal place to implement observability, security, and networking functionality due to the kernel’s privileged ability to oversee and control the entire system. At the same time, an operating system kernel is hard to evolve due to its central role and high requirement towards stability and security. The rate of innovation at the operating system level has thus traditionally been lower compared to functionality implemented outside of the operating system.

Image source: eBPF.io

Who is this workshop for?

1. Practitioners who are interested in gaining an introduction to eBPF
2. Technical leaders looking to gain an understanding the value eBPF brings
3. Builders/developers who want to learn how to create eBPF programs
4. Those who want to skill up on eBPF and add a credential to their portfolio

What does this workshop cover?

1. The fundamentals of eBPF
2. The different ways to create eBPF programs using BCC and Libbpf
3. How to deploy BumbleBee, created by Solo.io
4. How to leverage BumbleBee to visualize traffic flows on applications deployed to Kubernetes
5. An optional certification exam which allows you to earn the Fundamentals for eBPF Badge!

With that, let’s dive in…

Creating and playing with eBPF

The lab begins with you running a Python application which contains:

• The kernel-space BPF program which is written in C and contained within a string in the Python code
• User space application

The Python application itself containing the C code, when run, proceeds to output all Source to Destination address information in a tabular format. This is a simple network program for tracing traffic in our system where eBPF is running which should have you thinking for a second…I can create some really interesting networking tools…

The approach taken here using the BPF Compiler Collections, to run an eBPF-based program, works very well and it compiles easily, except it is quite resource intensive.

After we’ve reviewed this process, our next step is to use Libbpf to write the user-space and eBPF programs in C and compile them ahead of time. The resulting binary can run basically anywhere.

Build and deploy with BumbleBee

This next module exposes us to running BumbleBee, an open-source tool to help build eBPF programs.

BumbleBee helps to build, run and distribute eBPF programs using OCI images. It allows you to focus on writing eBPF code, while taking care of the user space components – automatically exposing your data as metrics or logs.

The module has you install the “Bee” CLI tool that allows you to run four key commands:

• Bee init, which helps create the initial structure of the eBPF based code in C-lang
• Bee build, which helps build and compile the eBPF program
• Bee push, which pushes the compiled binary as an OCI-image to a Docker-like image repository
• Bee run, which simply executes the eBPF program locally

The result ends up being another variant of the network source and destination tool, but with a BumbleBee touch to it.

Leveraging BumbleBee for observability in Kubernetes

In the final module we go off to deploy the famous  “book info” application for our testing. We’ll use this application to serve as our example to observe and visualize the flow of traffic. We have to deploy a few additional pieces:

• Prometheus;
• A container running BumbleBee deployed as a daemonset to Kubernetes;
• A PodMonitor resource to capture metrics; 
• And kebpf, an application to visualize traffic flow. 

We can even see how all the components interact with one another

Once everything is deployed, we can see a visualization of how all pods speak with each other. Looks a bit like Kiali, right? 

Our community

We also received a 🤩 GLOWING 🤩 recommendation from one of our industry experts, Walter Lee.

Connect with Walter here on LinkedIn!!                      

Final thoughts  on taking eBPF for a ride on the Solo.io rocketship 

We’ve witnessed that eBPF can provide varying observability through the usage of BumbleBee in Kubernetes. That leads to endless possibilities of what we can do for the Kubernetes Data Plane, and applications that live inside a cluster!

eBPF for networking has shown us we can create interesting applications that allow us to extract networking specific information. We can potentially manipulate our flows of traffic and use a differentiated approach to traffic engineering. What if eBPF allowed us to create just-in-time network policy based on these observability metrics?

When taking into consideration, eBPF for Layer 3/4 is covered by the Container Networking Interfaces but, imagine for a second if I could create a routing termination point outside of the CNI layer? What if I allowed for the creation of an eBGP speaker that interfaces with other WAN networks? Could I turn a Service Mesh into a multi-layer network service?

I’m excited to see where Solo.io takes eBPF and the many ways it’ll super-charge the Gloo Application Network Framework.

If you’re interested to learn more about eBPF head over to bumblebee.io and visit our GitHub Repo and take eBPF for spin!

We also run workshops weekly, check out our events schedule to find out when the next eBPF workshop is!

Thanks for reading 😃