Warning: Experimental. There is no intention to ever make this viable for production. Do not use in production.

An experimental layer 4 load-balancer for Kubernetes.

The control-plane is built using Gateway API and written in Golang with Operator SDK/Controller Runtime. The data-plane is built using eBPF and is written in Rust using Aya.

This project's main purposes are to help facilitate the development of the Gateway API project and to be a fun and safe place for contributors to contribute and try out newer technologies.

Note: The word "blixt" means "lightning" in Swedish.

Current project goals are the following:

• support Gateway/GatewayClass (partially complete)
• support UDPRoute (partially complete)
• support TCPRoute (partially complete)
• use this as a basis for adding/improving Gateway API Conformance Tests
• plug this into Gateway API CI to run conformance tests on PRs
• use as a reference implementation for Gateway API (don't use it this way yet!)

After these goals are achieved, further goals may be decided.

Given the goals and nature of this project, and the fact that everyone who works on it is a volunteer, we try to optimize for time with a highly iterative development approach. This project follows a "Work -> Right -> Fast" development mentality, which is to say for any functionality or feature we focus on making sure it works at a basic level first, then we'll focus on making it work right, and then once we're happy with the code quality we'll move on to making it faster and more efficient. This project is currently still very much in the early parts of the work stage and so the code may be a little rough and/or incomplete. We would love to have you join us in iterating on it and helping us build it together!

Note: TLSRoute support may be on the table, but we're looking for someone from the community to champion this.

Note: HTTPRoute support may be on the table, but we're looking for someone from the community to champion this.

Note: The initial proof of concept was written as an XDP program, but with more features (including access to ip conntrack in newer kernels) available in TC, we made a switch to TC.

Note: Currently usage is only possible on Kubernetes In Docker (KIND) clusters. You can generate a new development cluster for testing with make build.cluster.

Deploy Gateway API CRDs:

kubectl apply -k https://github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v0.8.1

Deploy:

kubectl apply -k config/default

At this point you should see the controlplane and dataplane pods running in the blixt-system namespace:

$ kubectl -n blixt-system get pods
NAME                                 READY   STATUS    RESTARTS   AGE
blixt-controlplane-cdccc685b-9dxj2   2/2     Running   0          83s
blixt-dataplane-brsl9                1/1     Running   0          83s

Check the config/samples directory for Gateway and *Route examples you can now deploy.

Note: When developing the dataplane you can make changes in your local dataplane/ directory, and within there quickly build an image and load it into the cluster created in the above steps with make load.image. This will build the eBPF loader and eBPF bytecode in a container image, load that image into the cluster, and then restart the dataplane pods to use the new build.

You can reach out to the community by creating issue or discussions. You can also reach out on Kubernetes Slack on the #sig-network-gateway-api channel. There is also a #ebpf channel on Kubernetes Slack for general eBPF related help.

The Blixt control-plane components are licensed under Apache License, Version 2.0, which is everything outside of the dataplane/ directory. The data-plane components are dual-licensed under the General Public License, Version 2.0 (only) and the 2-Clause BSD License (at your option) including everything inside the dataplane/ directory.