Skip to main content

Leda cluster

Setting up a bare-metal cluster - part 2

The story so far

In the first part (part1) we set up and provisioned three servers to serve as nodes in the cluster. We have a virtual ip managed by Keepalived and a HA etcd cluster that we will be using as external datastore for the k3s cluster. Some other stuff was installed and configured using ansible as well; we have docker installed, though in principle we could have simply let k3s use the default containerd.

Setting up a bare-metal cluster - part 1


We are going to setup a Kubernetes cluster on bare-metal. Specifically a HA instance of Rancher's k3s using etcd and a virtual ip on three small form factor Thinkcentre machines. The main purpose is to create a simple home lab to explore Kubernetes, do local development and also to host several in-house workloads. The underlying OS is Debian Buster. We'll also look at Ansible to do the initial provisioning of the servers. 

Versions used:

Jupyterhub on Kubernetes


Deploying Jupyterhub to a kubernetes cluster allows multiple users an easy way to develop, run and test their notebooks. The hub takes care of spawning Jupyter instances for each user and pruning their pods when not in use anymore. Each new user gets their own volume (through a persistent volume claim), containing all their notebooks, files and working environment. More information on

Buildkit-cli for kubectl

Building images on the cluster

Developing and testing on a kubernetes cluster usually means building a new image, pushing it to your registry, then pulling and redeploying your containers. Especially for local clusters, like on premises or even on your own workstation in a vm, it would be nice to be able to build your images directly on the nodes, making turn around much faster. Buildkit already exists, but now a new github project makes this even easier by giving you a kubectl extension to build directly on your cluster using regular kubectl commands. 

Subscribe to Leda cluster