Project Reveal: KRaft

It's a bit funny to me to finally properly reveal this project. It has taken up several names in the past and has been remade over and over and over again. And with it, I have several drafts in varying stages of decay on the Ghost dashboard. The last public post about what is the distanced ancestor of Kraft was here. Given how much it has changed, let me start from the beginning.

The page you first see when opening Kraft

The Start

(you can skip all this and miss on nothing super important)

Back in 2024, I wanted to run a workshop on Kubernetes. It was right after I had attended KubeCon in Paris, and I had a ton of inspiration. In particular, I was impressed by Hobby Farm, which is a platform created by Rancher/SUSE and used for all sorts of training. Notably, I got hands-on with the platform during Rancher day where I played around with Kubernetes and deploying Rancher Prime to the cluster, and, just doing Kubernetes things.

So, back in Mauritius, I hit up some of the people from Rancher who I had met, asking them if it's feasible to host an instance of Hobby Farm myself, with it being open source and all. Aaaand, well, I got pointed to the docs. And those docs killed my idea from the get-go. Not that Hobby Farm is a bad platform, or that the docs are bad. But the two main complications were the complexity and the fact it relied on a CSP to deploy VMs for attendees to work on.

Therefore, I decided to instead try virtual clusters so that attendees to my workshop could create clusters and work on them, without one person risking rm -rf'ing someone else's deployments. The solution back then was to run a Python API with Flask, using VCluster under the hood for virtual cluster management.
In my defense, it did technically work, but it was held together by duct tape and glue. And because of limitations on the host cluster, my program failed silently and it was absolute chaos. And it didn't help that I had so many attendees.

And Now

Now that I am older and supposedly more experienced, I decided to finally address the shortcomings of my previous attempt at this project. The goal was to make it a proper platform, with a "nice" UI, make it more polished, and add a couple extra features. Unrelated to the project itself, I wanted to use K3k, which is also a Rancher project, for Kubernetes in Kubernetes. It's not that I dislike VCluster, but I wanted to try something new.

What is KRaft?

I am glad you asked that! The bottom line is that KRaft is a very opinionated but fully-contained platform which runs on top of a host Kubernetes cluster and spins up virtual clusters for each person who wants one. You can use this for workshops and training sessions. Or you can even try it out as a Kubernetes-centric "cloud service provider" where you can split up resources of a host cluster.

From my perspective, KRaft is a Cloud in a Box though people who love "-aas-ing" everything will undoubtedly call this Kubernetes as a Service. And, well, it's sort of like a "cloud platform from wish dot com".

What is KRaft not?

If you're looking for something ultra-polished and ultra-corporate, then this is not for you. There are more thorough implementations out there, and, if you're daring, you can always run a Hobby Farm instance. I would also not recommend using KRaft if you demand that the developers (cough me cough) be serious and professional.

At the end of the day, I wanted to write some Rust. And I wanted to host workshops without AWS free credits.

Features

There's quite a few features already there, to the point where it's actually functional. My only limitation now is hardware as my Proliant will not be running anytime soon with its ancient v1 Xeons.

Current Features

  • Cluster management - you can create and list and delete your clusters.
  • Authentication - you cannot touch someone else's clusters.
  • Pleasant frontend - a good looking UI for you to manage clusters through.
  • Resource monitoring - get metrics on host and virtual cluster resource usage.
  • Kubeconfig - because you need to get the file to use the cluster after all.

Future Features

  • DNS entries w/ ingress - you can then access the clusters through custom URLs, such as cluster1.kraft.alexbissessur.dev.
  • Resource management - so you can put custom limits to your own cluster.
  • Payments? - I'd probably do this on another branch, so I could theoretically make my friends refund the power bill for how much they used.
  • Distribution Method - I need to make this easier to install on other clusters. Initially I would've thought a helm chart but those are cursed. What about a whole Kubernetes distribution, such as K3s, which I strip down, install some parts by default - Nginx ingress + Longhorn storage and others. Then deploy KRaft right on top.
    So for anyone who wants to run an instance, it's just a single command + bash script.

Misc

So now I'm running out of things to talk about. If you want to try KRaft out, ping me on Fedi or Signal or GitHub. This is the repository for KRaft https://github.com/xelab04/KRaft so you can check it out, criticise it, and even contribute. And if you truly like it, leave a star :) There's a shorter version of this blogpost as the readme. Technically, Kraft is running on https://kraft.alexbissessurd.dev though uptime is not great, and I am constantly deploying to prod.

There's also two pages on the website which add a bit more detail to anyone curious: https://kraft.alexbissessur.dev/sub/about/1.html (WIP). Again, would love suggestions and contributions.

So yeah, small project. I'm looking forward to running an instance under Cloud Native Mauritius and giving people who want to learn Kubernetes access, so that they can create clusters and experiment with Cloud Native technologies without being like me and setting up a homelab in the living room.