Oxide detalla tres vías para Kubernetes, con el almacenamiento nativo aún inconcluso

Why it matters

Kubernetes is testing Oxide's central thesis: owning the full rack lets it fix customer problems across APIs, networking, storage and the hypervisor, while making Oxide responsible for every missing capability.

Oxide, el fabricante de hardware de nube local (on‑prem) fundado por Steve Tuck y Bryan Cantrill, el jueves detalló cómo las solicitudes de clientes lo empujaron desde no tener integraciones de Kubernetes compatibles a finales de 2024 hasta mantener tres vías de aprovisionamiento y un controlador de runtime compartido.

La nota técnica del 13 de agosto también ofrece un inventario inusualmente directo del trabajo que queda por hacer. Oxide todavía carece de un servicio de balanceo de carga nativo, y un controlador de almacenamiento nativo para Kubernetes está bloqueado por la incapacidad del Cloud Computer para adjuntar o desadjuntar discos mientras una instancia está en funcionamiento.

Esas limitaciones convierten el esfuerzo con Kubernetes en una prueba de la apuesta original de los fundadores. Tuck y Cantrill construyeron Oxide alrededor de la idea de que la infraestructura on‑premises debería llegar como un Cloud Computer integrado, con hardware, almacenamiento, redes y software de control diseñados conjuntamente. Kubernetes está obligando a esa pila integrada a cumplir los mismos contratos de infraestructura que los desarrolladores esperan de los proveedores de nube pública.

Matthew Sanabria, quien se incorporó a Oxide como su primer Ingeniero de Software de Soluciones, ha estado llevando ese trabajo a través del límite entre los clientes y el producto. Su primera asignación comenzó con un pull request enviado por un cliente y una hoja de ruta interna, RFD 493. Eventualmente produjo integraciones para Rancher, Omni de Sidero Labs y Kubernetes Cluster API, además de un cloud controller manager compartido entre esos sistemas de aprovisionamiento.

El código del cliente se volvió la hoja de ruta

La primera integración vino desde fuera de Oxide. Un cliente había enviado un Rancher node driver pull request que traducía las operaciones de aprovisionamiento de Rancher a llamadas a la API de Oxide. Sanabria probó la implementación, la fusionó, añadió CI/CD y documentación, y publicó la versión inicial.

Sanabria dice que ese cliente ya estaba ejecutando el driver en producción. Oxide no ha publicado la identidad del cliente, el tamaño del clúster ni el perfil de cargas de trabajo, por lo que la afirmación de producción sigue siendo un relato del proveedor en lugar de un despliegue medido de forma independiente. La contribución, aun así, le dio a Oxide un punto de partida concreto: software escrito alrededor del flujo de trabajo de un operador real en lugar de un plan de integración especulativo.

Ese patrón continuó con la integración Omni de Sidero Labs. Los clientes querían aprovisionar máquinas Talos Linux en Oxide y registrarlas con Omni. Oxide comenzó el trabajo el 24 de septiembre de 2025, dando al equipo de Sanabria siete semanas antes de un evento de Oxide y Sidero el 12 de noviembre.

La fecha límite sacó a la luz un error de compatibilidad a bajo nivel. Oxide presenta los datos de usuario de cloud-init usando un sistema de archivos FAT12, mientras que Talos inicialmente buscaba un superbloque ISO 9660 y dejó de sondear después de que ese intento falló. Por lo tanto, Talos no pudo leer la configuración necesaria para unirse a Omni.

La solución temporal capturó la naturaleza práctica del proyecto: rellenar el archivo user-data con comentarios hasta que fuera lo bastante grande como para usar ISO 9660. Sidero trabajó en la corrección subyacente, mientras Oxide usó la solución provisional para mantener la integración en movimiento de cara a la demostración de noviembre.

Más tarde, Oxide lanzó Cluster API Provider Oxide, o CAPOx, después de que la demanda de clientes y el tamaño del equipo de Ingeniería de Software de Soluciones alcanzaran el costo de ingeniería. CAPOx permite a los operadores usar recursos personalizados de Kubernetes para crear, escalar, actualizar y eliminar clústeres en un rack Oxide. Proporciona una vía nativa de Kubernetes que no requiere Rancher u Omni como capa de gestión.

Las tres integraciones atienden diferentes preferencias de los operadores. Rancher encaja en entornos Rancher existentes. Omni combina Talos Linux con las herramientas de ciclo de vida de Sidero. CAPOx permite a los operadores gestionar la infraestructura de clústeres mediante el modelo upstream de Cluster API. La actual documentación de Kubernetes de Oxide recomienda Rancher u Omni como sus opciones de aprovisionamiento gestionado más completas, mientras que CAPOx le da al equipo de ingeniería otro sistema de extremo a extremo contra el cual probar su propia infraestructura.

Kubernetes expuso las brechas de la plataforma

Aprovisionar máquinas virtuales solo resuelve la primera parte de ejecutar Kubernetes. Una vez que un clúster está activo, Kubernetes necesita una vista fiable de la infraestructura que está debajo. Oxide construyó un cloud controller manager de código abierto para reconciliar los objetos Node de Kubernetes con las instancias de Oxide y reportar detalles como direcciones, identificadores de instancia y estado de la máquina.

El controlador también maneja los servicios de Kubernetes de tipo LoadBalancer, aunque Oxide no ha entregado un servicio de balanceo de carga nativo. Oxide usa direcciones IP flotantes como un mecanismo provisional. El controlador adjunta una IP flotante a un nodo de Kubernetes elegible y luego confía en el dataplane de servicios del clúster para enrutar el tráfico hacia los pods objetivo.

Ese enfoque soporta una API de Kubernetes familiar mientras expone una implementación imperfecta debajo. Los usuarios ven tanto la IP flotante accesible externamente como la dirección interna del nodo en la salida de Kubernetes. Según la documentación del cloud controller manager de Oxide, el controlador de servicios asigna y adjunta la IP flotante al primer nodo ordenado por nombre. El controlador actualmente soporta externalTrafficPolicy: Cluster, lo que permite que ese nodo reenvíe tráfico a endpoints en otras partes del clúster.

El almacenamiento presenta la restricción más difícil. Kubernetes espera que un controlador de Container Storage Interface cree y adjunte un volumen después de que un pod haya sido programado. Oxide actualmente requiere que una instancia se detenga antes de que se pueda adjuntar o desadjuntar un disco. Detener un worker de Kubernetes por una operación de volumen interrumpiría sus otras cargas de trabajo y podría provocar cambios adicionales de programación y de almacenamiento.

Un plugin CSI nativo de Oxide, por lo tanto, depende del soporte de conexión en caliente de discos a través del hipervisor, el plano de control y la API. Kubernetes ha convertido una integración faltante en un requisito de plataforma que atraviesa toda la pila hardware‑software.

La apuesta de integración de los fundadores se pone a prueba en producción

El enfoque de Oxide le da a Tuck y Cantrill control sobre las capas necesarias para resolver estos problemas. También hace responsable a Oxide cuando un flujo de trabajo estándar de nube alcanza una capacidad que el rack aún no puede ofrecer. El trabajo con Kubernetes ya ha generado proyectos en redes, almacenamiento, creación de imágenes y reconciliación de infraestructura, en lugar de permanecer como un paquete delgado de compatibilidad alrededor de una API.

Esa responsabilidad es costosa. Oxide levántó una Serie C de $200M el 5 de febrero de 2026, tras una Serie B de $100M en julio de 2025. Oxide dijo que la Serie C provino íntegramente de inversores existentes; Intel Capital dijo que US Innovative Technology Fund lideró la ronda. El financiamiento le da a Oxide margen para seguir extendiendo un producto físico intensivo en capital después de la entrega, incluido trabajo de plataforma que comienza con la solicitud de Kubernetes de un cliente y termina dentro del hipervisor.

El relato de Sanabria muestra el modelo operativo detrás de ese gasto. Un cliente suministró el primer código para Rancher. Los clientes de Omni obligaron a Oxide y Sidero a depurar una suposición sobre el sistema de archivos. La demanda de Cluster API justificó una implementación mayor. Las cargas de trabajo con estado expusieron la necesidad de conexión en caliente de discos.

Oxide ahora tiene integraciones de aprovisionamiento y de runtime para Kubernetes, incluyendo software que, según Sanabria, al menos un cliente ya estaba usando en producción. El almacenamiento CSI nativo y el balanceo de carga nativo siguen sin terminar. Cada pieza sin terminar marca otra prueba de la promesa de los fundadores de que poseer todo el cloud computer puede hacer que la infraestructura on‑premises se comporte como un servicio en la nube.