Tinkerbell gets pixie dust for managing K8s on bare metal as Equinix looks to grow governance roles

Tinkerbell was born at Packet (now Equinix Metal) as a general-purpose bare metal provisioning engine and management tool. Developers 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

Kubernetes inspired Tinkerbell’s new declarative, API-centric characteristics.

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.

With the introduction of Cluster API Tinkerbell, developers 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 a cloud-native experience for provisioning Kubernetes clusters.

Instead of taking a generic bare metal provisioning engine and bolting Cluster API support onto it, the Cluster API was integrated 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. 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.

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, developers 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. (Equinix Metal is continuing to support the Tinkerbell API and Postgres backend for now, but those are slated to be deprecated in the future.)

Equinix Metal and the Developer Community

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 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

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.

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.

About the author

Jason DeTiberus is a senior staff software engineer at Equinix Metal.

DISCLAIMER: Guest posts are submitted content. The views expressed in this post are that of the author, and don’t necessarily reflect the views of Edge Industry Review (EdgeIR.com).

Article Topics

bare metal  |  edge cloud  |  edge orchestration  |  Equinix Metal  |  infrastructure management  |  Kubernetes  |  open source  |  Tinkerbell