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.
Warning: We've decided that we're going to rewrite the control-plane in Rust (as it was earlier on in this project's life), so please note that if you contribute to the Go control-plane in the interim before we take this warning down, things might get "lost" when we switch to the new version. See the relevant milestone and check in with us in the issues (or via discussions) if you're interested in working on something control-plane related!
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
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
.
Note: Currently our container images are under migration from a private repository. At this moment, you should build and load images yourself.
- Deploy Gateway API CRDs:
kubectl apply -k https://github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v0.8.1
- Build Blixt 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
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 withmake 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
#blixt
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.