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 thearchive/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 forGateway
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 thepanic
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.