Warning: The main branch is under heavy development as we are rewriting our control-plane. if you're interested in using or testing Blixt, consider using the archive/golang-control-plane branch temporarily. If you have any questions or issues, check in with us in the #blixt channel on Kubernetes Slack!

Warning: Experimental. We currently intend this project to be a sandbox for experimenting with networking functionality, and a safe place to learn. For the moment there is no intention to ever make this viable for production use cases. DO NOT USE IN PRODUCTION.

Blixt

An experimental layer 4 load-balancer for Kubernetes written in Rust using Kube-RS for the control-plane and eBPF with Aya for the data-plane.

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

Current Status

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.

Usage

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 intended 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=v1.2.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

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 to run them.

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.

Community

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 as well.

License

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.