Oxide Computer Company ha desarrollado un conjunto de integraciones de Kubernetes adaptadas a las necesidades reales de sus clientes, en lugar de diseñarlas de forma teórica. El proceso comenzó a finales de 2024, cuando una pull request de un cliente para un Rancher node driver y un borrador de la RFD 493 sobre integraciones iniciales de Kubernetes marcaron el punto de partida. La primera integración oficial fue ese Rancher node driver, que traduce las operaciones de Rancher en llamadas a la API de Oxide para aprovisionar instancias como nodos de clústeres Kubernetes gestionados.
Ante la diversidad de flujos de aprovisionamiento de los clientes, Oxide lanzó tres integraciones. Junto a Rancher, publicó un infrastructure provider para Sidero Omni, creado en siete semanas para presentarse en KubeCon North America 2025 en colaboración con Sidero Labs; el desarrollo sacó a la luz un problema en Talos Linux, cuya sonda de sistema de archivos solo intentaba leer un superbloque ISO 9660 en lugar de formatos como VFAT, lo que impedía leer los datos de usuario de Oxide (el workaround consistió en rellenar el user-data con comentarios para forzar el uso de un superbloque ISO 9660). La tercera integración es Cluster API Provider Oxide (CAPOx), que permite gestionar clústeres de forma declarativa mediante recursos personalizados de Kubernetes. El conjunto se completa con un Packer plugin, un Kubernetes Image Builder y un Oxide Cloud Controller Manager para la reconciliación entre instancias de Oxide y objetos Node de Kubernetes. El artículo describe cómo cada problema operativo —aprovisionamiento, reconciliación, redes, almacenamiento— fue detectado a partir del uso real de los clientes, guiando tanto las integraciones publicadas como el trabajo de plataforma aún pendiente.