Blixt - A load-balancer written in Rust, using eBPF, born from Gateway API
In SIG Network we now have a layer 4 (“L4”) load balancer named Blixt. This project started as a fun experiment using emerging technologies and is intended to become a utility for CI and testing to help facilitate the continued development of Gateway API. Are you interested in developing networking tools in Rust and eBPF? Or perhaps you’re specifically interested in Gateway API? We’ll tell you a bit about the project and how it might benefit you.
Blixt originated at Kong as an experiment to test load-balancing ingress traffic for Kubernetes clusters using eBPF for the dataplane. Around the time of Kubecon Detroit (2022) we (the Gateway API maintainers) realized it had significant potential to help us move our TCPRoute and UDPRoute support forward, which had been sort of “stuck in alpha” at the time due to a lack of conformance tests being developed for them. At the same time, various others in the SIG Network community developed an interest in the project due to the rapid growth of eBPFs use on Kubernetes. Given the potential for benefit to the Kubernetes ecosystem and the growing interest, Kong decided it would be helpful to donate the project to Kubernetes SIGs to benefit upstream Kubernetes.
Over several months we rewrote the project in Rust (from C), due to a strong contingency of Rust knowledge (and interest) between us developing the project and an active interest in the burgeoning Aya project (a Rust framework for developing eBPF programs). We did eventually move the control plane (specifically) to Golang however, so that we could take advantage of the Kubebuilder and controller-runtime ecosystems. Additionally, we augmented our custom program loader (in eBPF, you generally write loaders that load your BPF byte code into the kernel) with bpfman: a project adjacent to us in the Rust + eBPF ecosystem, which helps solve several security and ergonomic problems with managing BPF programs on Linux systems.
After the recently completed license review process, which provided a blanket exception for the use of dual licensed eBPF in CNCF code, the project became officially part of Kubernetes and interest has been growing. We have several goals for the project which revolve around the continued development of Gateway API, with a specific focus on helping mature Layer 4 support (e.g. the UDPRoute and TCPRoute API kinds).
Currently the high level goal of the project is to provide a Gateway API driven load-balancer for non-production use cases. Those non-production use cases include:
- Driving conformance tests and adoption for L4 use cases.
- Using this implementation as part of the Gateway API CI testing strategy.
- Having the Blixt control-plane be a reference implementation.
- Exploring issues associated with the generic use of eBPF in Kubernetes.
In support of those goals we have some more specific sub-goals we’re actively working towards:
- Support GatewayClass and Gateway, meeting conformance requirements
- Support UDPRoute and TCPRoute, meanwhile helping to develop the conformance requirements for these APIs.
We have some significant progress on the above in that we have a basic level of support for creating a GatewayClass and at least one Gateway, and then attaching UDPRoute and TCPRoute resources to that Gateway. Doing that drives a process of the underlying data plane receiving corresponding configuration and traffic then flowing as expected. We emphasize the basic: as the project is still quite early on, and being developed in a highly iterative fashion. That said the fundamentals are there and you can try them out yourself on a local system using our usage documentation and sample configurations. You can see more about the project’s current status on the README.md including the milestones and current progress.
One thing that can’t be overstated about this project is that it has been at the center of a lot of learning, community building and fun. We have maintained a policy with this project that it shall never be intended for production use cases which means development of the project is more of a sandbox and a safe space for people to learn and experiment. If any of this sounds interesting to you, now is a great time to get involved!
If you’re interested in networking, Rust, Linux, eBPF (or all of the above)
there’s a lot of opportunity here to learn and have fun. We invite you to jump
right in on the repository if that’s your style, or reach out to us in
the community: You can reach us on Kubernetes Slack on the
#sig-network-gateway-api channel as well as the
#ebpf channel. Blixt is a
topic of discussion at the Gateway API community meetings, and the
monthly SIG Network Code Jam as well.