Project Lightning Talk: Bare Metal Provisioning With Tinkerbell - Jacob Weinstock, Maintainer
About this talk
This talk introduces Tinkerbell, a Kubernetes-native bare metal provisioning engine designed for managing on-prem physical hardware. The speaker explains how Tinkerbell employs Custom Resource Definitions (CRDs) for hardware and installation templates, allowing users to create and manage workflows for operating system installations. Tinkerbell offers features such as a read-only web UI, the lightweight Hook OS operating system, and the ability to autodiscover machines for easier provisioning without prior setup. He highlights the project's flexibility, including support for static layer three provisioning and integration with custom resources. The session also notes upcoming features like enhanced data source support and the potential for external Kubernetes installations.
Full transcript
My name is Jacob Weinstock. I'm the core maintainer of the Tinkerbell project. Um we are a Kubernetes native bare metal provisioning engine. How many folks out here have on-prem physical hardware? They Nice. How many How many home labbers? Ooh, nice. Well, maybe even more. I like it. Hopefully, Tinkerbell can be a part of your uh your systems there. What is Tinkerbell? So, uh Tinkerbell's a a little
bit of a different way in which we can provision physical hardware. Um if you're familiar with some of the older technologies, Kickstart, um or Pixie booting, things of that nature. Tinkerbell goes about it in a little different way. We're Kubernetes native, so we have uh CRDs for all the things. Uh we have hardware CRD, which allows you to just define your disks, your network, all the things
about your hardware. And then we have what's called a template. Inside of there, you define how you install your operating system. And when you dive in, you'll see the template looks very similar to what you might have with um any kind of CI system, so GitHub Actions or uh Buildkite, etc., right? This is a manifest that allows you to lay out disk images, do partitioning, update files
on disk, do things of that nature. And then when you combine those two, a hardware and a template object, uh we get what we call a workflow, and that allows you to do power operations. You can reboot, you can uh Pixie boot, you can do uh ISO mounting, so you can do full layer three static provisioning, um run your installation, reboot, kexec, do whatever next steps you
need to do. Um and all of this comes in, like I said, in a very Kubernetes native way. Um some of the features that we've recently landed in our projects um include a read-only web UI. Um we have a new lightweight in-memory operating system called Hook OS, which is the successor to Excuse me. We have Captain OS, which is the successor to Hook OS. all things Peter
Pan related as you can see with our naming schemas here. Uh we have a serial over SSH that allows you to SSH through Tinkerbell into the console of your BMC using public keys. No more needing to play with IPMI tool and make sure you have all that set up properly. Uh we also have some discovery modes. So, you can plug tink You can set up Tinkerbell, install
it, and without actually having to define any of the previous CRDs we talked about, you could turn your machines on. Tinkerbell will auto discover all those machines, create CRDs for you, and even run workflows uh based on attributes of different of your machines in different ways. So, pretty extremely flexible in that way. We also have solved um a potential problem with uh how do you provision hardware
without provisioning your provisioning stack, right? Tinkerbell has a single binary, zero external dependencies that you can use and deploy uh to set up your kind of initial run. And then transfer all of those CRDs over to a permanent cluster, and you're off and running. We have a lot of DHCP modes. Um we can integrate with your own stack. We can do fully static layer three provisioning if
you don't have uh control of your DHCP or don't want it as well. And we have this interesting idea of hardware references. So, hardware is an object in the Tinkerbell stack, but we can take other CRDs and incorporate them, your own custom ones, um and incorporate them into the Tinkerbell ecosystem by referencing them. And some exciting features coming up uh we're going to have additional support for
the no cloud data source. We already have EC2 metadata. Um we have a new spec coming out soon. Um and we're going to extend uh template and workflow references just the way we have hardware. And then the CAPT side, so not only can Tinkerbell do um arbitrary operating system installs, but we can do full Kubernetes installations to our uh CAPT provider. And we'll be a new feature
we'll be able to run Tinkerbell externally to our to an existing CAPT structure, which allows a lot more flexibility. So, uh getting involved, we have meetings every Tuesday. Come and find us on the CNCF Slack. Um we have a website here, our GitHub. We do have a couple sessions tomorrow. We'll have a ContribFest. Um come find us. Look it up in the schedule. And then on on
Wednesday, we'll have a project booth where you can come and we can talk and we can give demos and you can see all about it. So, excited to work with you and hope hopefully your bare metal needs can be satisfied through Tinkerbell. Thank you.
More from this event
See all 436 talks →
Best of KubeCon + CloudNativeCon Amsterdam 2026
2:17
The Quiet Work of Forever: Sustaining Open Source Communities - O. Hope Amaechi-Okorie, JSON Schema
26:24
Evolving KServe: The Unified Model Inference Platform for Both Predictive and... F. Spolti & J. Lee
32:40
Preventing S3 Cost Storms: Applying Cortex’s Efficiency Lessons to I/O-Heav... A. Fishman-Lichterman
5:32