In this post, I will show how I provisioned a Raspberry Pi 4 with an attached USB SSD via Tinkerbell. This is part 4 of my Tinkerbell series. The main goal of this post is to get this little guy to boot into Tinkerbell’s HookOS and install an Ubuntu 24.04 Raspberry Pi image onto the SSD: My experimental setup. ...
In this post, I will describe how I deployed Tinkerbell into my k3s cluster and provisioned the first Ubuntu VM with it. This is part 3 of my Tinkerbell series. Deploying Tinkerbell The first step is to deploy Tinkerbell into the k3s cluster I set up in the previous post. For this, I used the official Helm chart, which can be found here. My values.yaml file looks like this: publicIP: "203.0.113.200" trustedProxies: - "10.42.0.0/24" artifactsFileServer: "http://203.0.113.200:7173" deployment: envs: tinkController: enableLeaderElection: false smee: dhcpMode: "proxy" globals: enableRufioController: false enableSecondstar: false logLevel: 3 init: enabled: true service: lbClass: "" optional: hookos: service: lbClass: "" kernelVersion: "both" persistence: existingClaim: "hookos-volume" kubevip: enabled: false The first setting, publicIP, is the public IP under which Tinkerbell’s services will be available to other machines. It will be used in DHCP responses for the next server, download URLs for iPXE scripting and so forth. It will also be set as the loadBalancerIP in the Service manifest created by the chart. In my case, this is a VIP controlled by a kube-vip deployment I will go into more detail on later. The trustedProxies entry is just the CIDR for Pods in my k3s cluster. The artifactsFileServer is the address for the HookOS artifacts, in this case the kernel and initrd. The Tinkerbell chart sets up a small Nginx deployment for this and automatically downloads the newest HookOS artifacts to it. This is configured under optional.hookos. I’m also disabling a few things because I don’t intend to use them. One of those is leader elections for Tinkerbell - as I will only have one deployment, those seem unnecessary. I disable Rufio and SecondStar as well. Rufio is a component to talk to baseboard management controllers usually found on enterprise equipment. As I don’t have any such gear, it’s unnecessary. Finally, SecondStar is a serial over SSH service I also don’t need. ...
A description of my lab setup for tinkering with Tinkerbell. This is part 2 of my Tinkerbell series. For my Tinkerbell tinkering lab Actually, no. Let’s start with: How did I not come up with “tinkering with Tinkerbell” until the second post of this series? You may tsk tsk tsk disapprovingly at your screen now. For my Tinkerbell tinkering lab, I decided to run it on my desktop machine. This is because previous work on network booting has shown that I definitely want direct access to the netbooting machine’s TTY. And that’s easiest when it runs on my desktop. Also makes stuff like packet capturing easier. So I needed the following things in my lab setup: ...
Wherein I describe how I organize Helm charts and other k8s manifests. I’ve had this post laying around in my draft folder for a long long time. Mostly because I started writing it before I realized how useful it is to write posts very close to when something happens. The “something happens” in this case is the answer to the question “How to organize my Helm charts and other k8s manifests?”. I liked Helm fine enough when I looked at it. It’s pretty nice to get all necessary manifests to run an app, instead of having to write all of them myself. But the question then was: How to store which exact Helm charts I have installed, and in which version? And how/where to store the values.yaml files? And then, what about random manifests, like additional PriorityClasses? ...
A rough overview of my plan for trialing tinkerbell in my Homelab. This is part 1 of my tinkerbell series. I’m planning to trial tinkerbell in my Homelab to improve my baremetal provisioning setup. This first post will be the plan and the reason why I’m doing this. Tinkerbell is a system for provisioning baremetal machines. It is deployed into a Kubernetes cluster and consists of a controller, a DHCP/netboot server, a metadata provider e.g. for cloud-init data, and an in-memory OS for running workflows. The basic idea is that new machines netboot into that in-memory OS and execute workflows configured in tinkerbell to install the actual OS. ...