Warning: The main branch is under heavy development, and is not fully functional yet as we are rewriting our control-plane. if you're interested in using or testing Blixt, use the archive/golang-control-plane branch temporarily.

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 written in Rust and employing Gateway API for the control-plane and eBPF/Aya for the data-plane.

This project is a sandbox for experimentation and learning. This repo is mainly meant for those interested in experimenting. This project intentionally does not have end-users and is a safe place to learn, break stuff and have fun!

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

Current project goals are the following:

• support the Kubernetes Service API (upcoming)
• support Gateway/GatewayClass + UDPRoute / TCPRoute (in progress, partially complete)

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

Warning: Currently our container images are under migration from a private repository. At this moment, you must build and load images yourself locally.

Warning: 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 the Gateway API CRDs:

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

Build container images:

make build.all.images TAG=latest

Load images into your Kind cluster:

make load.all.images TAG=latest

Deploy Blixt:

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

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

Development is generally done by making your changes locally, building images with those changes locally and then deploying those images to a local kind cluster (see the usage section above to get an environment set up).

You can build the data-plane:

make build.image.dataplane

Then load it into the cluster and perform a rollout on the Daemonset:

make load.image.dataplane

The same can be done for the control-plane:

make build.image.controlplane
make load.image.controlplane

Warning: The integration tests are currently written in Golang, which is a little awkward, but it is a temporary situation as we rewrite them in Rust. Run make test.integration.deprecated after deploying your custom images to the cluster.

Note: We use Cargo workspaces to manage the various crates spread across the Rust parts of the repo. However, there is one exception. The dataplane/eBPF crate must be kept as a standalone because it needs to re-implement the panic handler. All new crates should be added to the workspace, if possible.

You can reach out to the community by creating issues or discussions. You can also reach out on Kubernetes Slack on the #blixt channel. There is also an #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.