Building Momentum with Tinkerbell

The journey of building an open-source platform

Tinkerbell’s recent traction — especially since joining the CNCF as a sandbox project — has provided our team the chance to celebrate some of the milestones we’ve hit along the way. From getting stable releases out with solid documentation to creating new components that dramatically improve stability and performance, it’s been awesome to see the project find its sea legs.

In the beginning, Tinkerbell was a bit jumbled and heavily tied into Equinix Metal’s infrastructure. Our goal since last March has been to simplify things, remove anything that might be superfluous, make it non-server specific, and work on the user experience.

To help with the last point we introduced the Tinkerbell sandbox, which is an easy way for people to have everything quickly up and running to begin work. With the latest Tinkerbell 0.5 release and inline with a growing community, we have doubled down on our efforts to be exhaustive with documentation, including on docs.tinkerbell and artifact hub.

End users now have a lot more to work with and can think more outside the box with what they can achieve with Tinkerbell.

What’s new?

The main goal for this release was to simplify, automate, and capitalize on what Tinkerbell has already done.

A new component named “Hook” allows us to provision on x86 machines, but also smaller things like Raspberry Pi’s or edge devices. Hook creates a small operating system making use of LinuxKit, which allows Tinkerbell to provision from start-up in about 47 seconds. With Hook we now have a much smaller footprint and can provision on smaller devices. So not only can Tinkerbell provision reliably in the data center, but in constrained edge environments as well.

Another aspect of Hook is the kernel build area. Since Tinkerbell is open source, people with different hardware needs may want to make use of it. The the kernel build area makes it easy to add in drivers to Hook and follow a few steps to generate a custom kernel to run on specific hardware. End users can now use these components and build on top of them and customize them, but still use Tinkerbell in its intended form.

Another exciting project that sits on top of Tinkerbell is called CAPT (Cluster API Tinkerbell). Cluster API is a standardized way to get Kubernetes deployed, no matter the environment. While provisioning Kubernetes in cloud environments like AWS, GCP and Azure is well established, people are asking for the same implementation for bare metal servers. CAPT is able to stand up bare metal servers running Kubernetes the same way other clusters work on cloud services.

To help make common or complex tasks repeatable, we’ve introduced actions, which are hosted on the CNCF Artifact Hub. One new action is called Imag2Disk, which allows us to provision operating system images very efficiently. We can get an entire copy of a block device, from the first byte 0 to the end of the actual disk, as a lump of block data that can be streamed in a compressed format directly to a physical machine's storage. Pretty slick, isn’t it?

In another example of community involvement, we recently created an additional project named crocodile that eases the process of generating a disk image of an Operating System. With one or two commands an end-user will have a newly created image that they can then immediately deploy to a bare metal server with Tinkerbell.

Building what users want

Tinkerbell is a modern system that is still at times limited by dated technologies. Such is the way of the world! DHCP, TFTP, and PXE are all around 20 years old, and we’ve had to do a lot of work to ensure those limitations never impact the end user.

Before reaching a critical mass of users, we were not always sure what to implement for the community. While there have a few things we had to roll back because they didn’t make sense, as the community has grown we’ve seen the feedback loop improve and can build more directly what the community wants and needs. Proven community hacks like timezone friendly contributor meetings and staying responsive in our Slack channel have gone a long way.

With any open source project, we have to learn as we go. But we have put structures in place for end users to submit ideas that we can implement if we feel it makes sense for Tinkerbell and the direction we are going.

Growing as part of the CNCF community

Being a part of the CNCF (Cloud Native Computing Foundation) incubator scheme has been fantastic. CNCF recently accepted Tinkerbell as a Sandbox project, and now Tinkerbell sits within the CNCF funded provisioning space in their landscape. This also sets us up to be in their community and field questions from users and improve our projects based on a wider range of feedback.

One of our new features affects the capability of using raw images to deploy operating systems. From a cloud native perspective, that has dramatically reduced deployment times. The key reason we wrote this raw image support is because CNCF has its own image builder project that provides an operating system with the Kubernetes components on it. We can now make use of those same images and stay in lockstep with the Kubernetes project as it runs in cloud providers.

What’s very exciting about CAPT on bare metal is that we don’t differ in any way from the clusters on cloud servers. While bare metal has been known to be quite difficult, users will be very close to having that cloud-like experience on hybrid, private or edge infrastructure.

We want to support you and build features that matter to you and your projects. Ultimately, we want to keep Tinkerbell as malleable as possible so that people can shape it to their needs for each project.

If you want to find out more about working with Tinkerbell, visit our website and join our community Slack channel!