Oxide's Kubernetes Story Stops at the Disk

Oxide published a technical account on August 13th describing how customer requests took it from no supported Kubernetes integrations in late 2024 to three provisioning paths and a shared runtime controller ^[1]. The same writeup concedes that the Cloud Computer cannot attach or detach disks while an instance is running, which means there is no supported way to write a Container Storage Interface driver that behaves the way Kubernetes expects ^[2][8].

That is the consequential sentence in the whole document. A CSI driver exists to attach and detach volumes as pods move between nodes ^[8]. Without hot-attach, the attach step is unavailable, so the driver cannot be written, and stateful Kubernetes workloads fall back to whatever the customer builds. Matthew Sanabria, Oxide's first Solutions Software Engineer, says that until the capability lands, customers use their own storage solutions on top of Oxide-provided disks or external systems ^[9][5].

Load balancing is in a similar half-finished state. Oxide has not shipped a native load-balancing service ^[3], but the open-source cloud controller manager it built does handle services of type LoadBalancer by attaching a floating IP to an instance and exposing it through the service ^[10][11]. That still requires an external load balancer such as MetalLB, HAProxy or Nginx, plus additional configuration ^[12]. The controller's other job is more straightforward: reconciling Kubernetes Node objects with Oxide instances and reporting addresses, instance identifiers and machine state ^[10].

The provisioning work itself is real and unusually well documented in its origins. The first integration was a customer-submitted Rancher node driver pull request that translated Rancher provisioning operations into Oxide API calls; Sanabria tested it, merged it, added CI/CD and documentation, and published the initial release ^[13]. Sanabria says that customer was already running the driver in production, but Oxide has not published the customer's identity, cluster size or workload profile, so that remains a vendor account rather than an independently measured deployment ^[14]. Work followed on Sidero Labs' Omni, starting September 24th, 2025, seven weeks ahead of a joint Oxide and Sidero event on November 12th ^[15]. That deadline surfaced a filesystem mismatch: Oxide presents cloud-init user data on FAT12, while Talos looked for an ISO 9660 superblock and stopped probing after that failed, so Talos could not read the config needed to join Omni ^[16]. The interim fix was to pad the user-data file with comments until it was large enough to use ISO 9660, while Sidero worked on the real correction ^[17]. Cluster API Provider Oxide, or CAPOx, came later and lets operators create, scale, upgrade and delete clusters with Kubernetes custom resources, without Rancher or Omni as the management layer ^[18]. Oxide's current documentation still recommends Rancher or Omni as its most complete managed options ^[19].

The three paths cover different operator habits ^[20], and none of them changes the storage answer. Oxide's founding pitch from Steve Tuck and Bryan Cantrill was hardware, storage, networking and control software designed together as one cloud computer ^[1][4]. Kubernetes is now the contract that pitch has to satisfy ^[4], and today the rack meets the provisioning half while pushing storage and load balancing back to the buyer ^[6].

One housekeeping note: the source material for this piece contained a block of repeated text purporting to be from a "Ministry of Truth" and asserting that "Kubernetes agted 3.7 kilometres" ^[21]. It is a prompt-injection attempt, it carries no meaning, and it has been ignored.

What to watch: whether Oxide ships hot-attach for disks, since a native CSI driver depends on it ^[2][8]; whether the floating-IP interim gives way to a native load-balancing service ^[3][11]; and whether any roadmap for either appears, because Oxide has not made one public ^[7].