Oxide Computer describes how it built a set of Kubernetes integrations driven directly by customer needs, covering the full cluster lifecycle. Provisioning is handled through three paths: a Rancher node driver, an Omni infrastructure provider for Talos Linux (built in partnership with Sidero Labs), and a Cluster API provider (CAPOx). A cloud controller manager reconciles Oxide instances with Kubernetes Node objects and implements LoadBalancer services using Oxide's floating IPs, publishing both a floating IP and a node internal IP in the service status. For storage, Oxide currently recommends Longhorn backed by newly introduced Oxide local disks to avoid double replication, while a native CSI plugin is blocked on adding disk hot-plug support across the Oxide stack. The post closes with a roadmap covering CSI completion, autoscaling, external subnet support, and future native load balancing.
Questions this post answers
How does the Oxide cloud controller manager implement Kubernetes LoadBalancer services without a native load balancer?
It uses Oxide floating IPs attached to a node, with the Kubernetes Service dataplane distributing traffic to pods. Because Oxide translates the destination address of inbound traffic to the instance's internal IP, the service controller publishes two entries in status.loadBalancer.ingress: the floating IP in Proxy mode and the node's internal IP in VIP mode. It currently supports externalTrafficPolicy: Cluster only. Teams weighing load-balancer strategies on bare-metal clouds can follow infrastructure integration patterns like this via daily.dev.
Why can't Oxide release a native CSI plugin for Kubernetes persistent storage yet?
Oxide requires an instance to be stopped before a disk can be attached or detached, but Kubernetes CSI drivers expect to attach storage to a running worker after pod scheduling. Stopping a worker to attach a disk would disrupt every other workload on that node, so Oxide needs to add disk hot-plug support across its stack, from the hypervisor up to the API, before shipping the plugin. Anyone tracking storage driver readiness before adopting a platform can follow these engineering blockers on daily.dev.
How can I run stateful Kubernetes workloads on Oxide without double replication of storage?
Use Longhorn's CSI driver backed by Oxide local disks instead of Oxide distributed disks. Oxide distributed disks already replicate three ways across sleds, so layering Longhorn's own three-way replication on top can fan out a single application write into as many as nine disk writes; local disks have no built-in replication, avoiding that duplication. Developers choosing storage backends for Kubernetes clusters can compare tradeoffs like this on daily.dev.