Kubernetes on Oxide: How Customer Needs Shaped Our Integrations | Oxide Computer Company

13 Aug 2026

Kubernetes on Oxide: How Customer Needs Shaped Our Integrations

Matthew Sanabria<br>Solutions Software Engineer

In late 2024, customers and prospects were eager to run Kubernetes on Oxide, but<br>we had no supported integrations to help them do it.

Kubernetes and Oxide are a natural fit. Kubernetes defines the infrastructure<br>behavior it expects through standard extension points, while Oxide exposes the<br>primitives needed to implement that behavior through APIs. The foundation for<br>integration was there. What was missing was the software and an understanding of<br>which integrations customers actually needed.

That was the situation when I joined Oxide as its first Solutions Software<br>Engineer,[1]<br>focused on building software to solve customer problems. My first assignment was<br>to make it easier to deploy and operate Kubernetes on Oxide.

In my first week, I was handed two resources to help me get started:

A customer-submitted pull request for a Rancher node driver

An early draft of RFD 493 Initial Kubernetes Integrations

What began with those two resources grew into a team effort shaped by a feedback<br>loop. Rather than design integrations in the abstract, we followed the problems<br>customers encountered as they moved from provisioning clusters to operating<br>workloads.

This post follows those problems across the Kubernetes lifecycle rather than in<br>strict chronological order. Different provisioning workflows led us to Rancher,<br>Omni, and Cluster API. Running clusters required infrastructure reconciliation,<br>exposing applications revealed networking gaps, and stateful workloads exposed<br>storage constraints. At each stage, customer workflows exposed the next gap,<br>shaping both the integrations we built and the platform work still ahead.

How do I provision a Kubernetes cluster on Oxide?<br>The first gap we tackled was provisioning. Our immediate goal was to unblock the<br>customer who had submitted the Rancher node driver pull request. Working through<br>their use case would also give us firsthand experience creating Kubernetes<br>clusters on Oxide and help us uncover the next problems to solve.

No single provisioning approach fit all customers' workflows, so we ended up<br>publishing three integrations.

Rancher Node Driver<br>Before we could maintain the customer-submitted integration, we needed to<br>understand the workflow it supported. I had never used Rancher or worked with a<br>node driver, so reviewing the contribution meant learning both.

A Rancher node driver is an executable plugin that teaches Rancher how to<br>create and manage virtual machines on a particular infrastructure platform.<br>The Oxide<br>Rancher node driver translates those operations into Oxide API requests. Once<br>installed in Rancher, it lets customers provision Oxide instances as nodes in<br>Rancher-managed Kubernetes clusters.

Testing confirmed that the customer’s implementation worked. I merged the pull<br>request, added CI/CD and documentation improvements, and published the initial<br>release. Oxide officially had its first Kubernetes integration—​and a customer<br>was already using it successfully in production!

If you’re a Rancher shop looking to run Kubernetes on Oxide, see our<br>Rancher guide to<br>get started.

Omni Infrastructure Provider<br>Customers expressed interest in using Sidero Labs' Omni to provision Kubernetes<br>clusters running Talos Linux. Omni connects to infrastructure platforms through<br>infrastructure providers, programs that create Talos Linux instances and<br>register them with Omni.

With KubeCon North America 2025 a few months away, we saw an opportunity to<br>partner with Sidero Labs to build and showcase an Oxide infrastructure provider<br>for Omni. We had seven weeks to complete it before our Oxide+Sidero<br>event.[2]<br>Building against a second provisioning platform would also test Oxide’s APIs<br>across distinct customer workflows.

The integration work uncovered several issues across Omni and Talos Linux. I<br>brought those issues to Sidero Labs in<br>siderolabs/omni#1633,<br>where their team was eager to work with us—​a lovely reminder of<br>RFD 68 Partnership as Shared Values.

The most memorable issue was<br>siderolabs/talos#11948.<br>Oxide uses a FAT12 filesystem for cloud-init user-data, not ISO 9660, but<br>Talos’s filesystem probe only attempted to read an ISO 9660 superblock from the<br>NoCloud configuration disk. When that read failed, the probe stopped instead of<br>trying other formats such as VFAT or MS-DOS. As a result, Talos never read the<br>Oxide user-data containing the configuration needed to join Omni. The fix would<br>not be released in time for KubeCon, leaving us with a rather funny workaround.

The workaround right now is to pad the user-data with comments to increase its<br>size enough that it uses an ISO 9660 superblock.

KubeCon arrived and we hosted an<br>Oxide+Sidero<br>event to showcase the<br>Oxide infrastructure provider for Omni.<br>Customers could now use this infrastructure provider to...