Tinkerbell’s Pixie Dust Makes Kubernetes Fly

Kubernetes inspired Tinkerbell’s declarative, API-centric characteristics. Originally, however, the open source Tinkerbell project focused solely on provisioning and interacting with bare metal servers. It’s now been extended with new features and integrations that make it easier than ever to provision and manage Kubernetes clusters on bare metal.

Tinkerbell was born at Equinix Metal (formerly Packet) as a general-purpose bare metal provisioning engine and management tool. You can use it to install operating systems, update firmware, manage applications, and perform other tasks on bare metal servers in remote data centers, even if the servers have no OS already provisioned.

Provision Kubernetes on Bare Metal Declaratively

It was always possible to use Tinkerbell to provision bare metal infrastructure for hosting Kubernetes clusters—it could automate the OS provisioning and so on—but you couldn’t provision Kubernetes clusters directly using a one-step declarative process.

Now you can. Thanks to the introduction of Cluster API Tinkerbell, you can set up Kubernetes clusters on bare metal servers using Tinkerbell as the provisioning engine and the Kubernetes Cluster API as the declarative provisioning framework.

This gives you a cloud-native experience for provisioning Kubernetes clusters. Instead of taking a generic bare metal provisioning engine and bolting Cluster API support onto it, we integrated the Cluster API elegantly into Tinkerbell. For example, Tinkerbell uses cloud-init to automate instance initialization and lets you pull images for provisioning Kubernetes nodes from any OCI-compliant container registry, so you can manage OS images for cluster provisioning just as you manage your container application images.

The current version of Cluster API Tinkerbell supports Cluster API v1 and all Kubernetes releases that are compatible with it. Cluster API Tinkerbell also has high availability support via Kube-Vip.

Support for Kubernetes Types and Controllers

Another big new addition to Tinkerbell, contributed by Micah Hausler and his team, is support for Kubernetes types and controllers. 

You can read the details of what this means in the feature’s proposal, but in a nutshell, it lets you use Tinkerbell to interact with a Kubernetes cluster using the Kubernetes Resource Model. Thus, you can do things like listing Kubernetes resources, monitoring for resource changes, or managing RBAC settings directly–and in true real time–from Tinkerbell. 

Previously, you would have to work with the Tinkerbell API and its Postgres backend to do these things, which created more overhead and made it hard to achieve real-time interaction. (We’re continuing to support the Tinkerbell API and Postgres backend for now, but those are slated to be deprecated in the future.)

We’re excited about this enhancement not just because of the technical functionality it adds, but also because it was proposed, designed, and built completely by Tinkerbell’s external developer community. It’s a sign, we hope, that developers in the world at large, not just here at Equinix Metal, see real promise in Tinkerbell and its role in a cloud native world.

Tinkerbell Meets Hook

Alongside the work done to make Tinkerbell gel better with Kubernetes, we overhauled the worker environment Tinkerbell uses when provisioning servers.

Previously, that environment was OSIE. OSIE’s great, and we love it, but it has one major drawback: it weighs in at 2.4 gigabytes, which means it can take some time to transfer over a network.

Hook, OSIE’s LinuxKit-based replacement, is considerably smaller: just a few hundred megabytes. This smaller footprint makes working with Tinkerbell that much more convenient.

Tinkerbell’s Journey Continues

And more good things are in the works for the Tinkerbell project, both by our internal developers and by the outside developer community.

One key initiative right now is establishing firm project governance. As Tinkerbell continues to gain more features and components, we need to make sure that we have maintainers and reviewers for its various pieces. (Looking at you, dear reader ?. Come join us in a governance role!)

Meanwhile, Micah Hausler is working on a proposal to integrate PBnJ into Tinkerbell, which would provide even more ways to interact with infrastructure. Expect to be able to do things like connect to an IPMI interface to influence the power state of a system—for example, to turn machines on and off remotely. Ultimately, we hope that PBNJ will help us extend Tinkerbell into a tool for full lifecycle management of bare metal hardware.

Last but not least, we’re replacing the versioning scheme for Tinkerbell components. Instead of boring version numbers, we’re switching to semantic versioning. That will make it easier for our collaborators and users to learn which component versions are compatible with each other and build sandbox environments based on them.

Join Us in Neverland

If you think Tinkerbell sounds cool, you can learn more by visiting our community page, reading our documentation, or joining the CNCF Slack #tinkerbell channel.

Even better, go ahead and set up a sandbox environment to kick Tinkerbell’s tires, find issues, contribute code, or suggest ideas for optimizing it for your use case.

Tinkerbell is hardly the only provisioning tool out there, but one of the greatest things about building it has been that it’s a young project, and we have the luxury of being able to design it to be the best tool possible for the cloud native age. Come join us and be a part of this story.