En su primera semana como ingeniero de soluciones en Oxide Computer, a fines de 2024, Matthew Sanabria recibió dos documentos para arrancar: un pull request enviado por un cliente con un driver de nodos de Rancher hecho a mano, y el borrador de la RFD 493, "Initial Kubernetes Integrations". De ahí salieron, en menos de dos años, las tres integraciones oficiales que hoy permiten correr Kubernetes en Oxide: un driver para Rancher, un proveedor de infraestructura para Omni y un provider de Cluster API.
Oxide fabrica racks completos de cómputo, red y almacenamiento con una API propia en lugar de los BMC tradicionales de los servidores comerciales. Ese diseño encaja de forma natural con Kubernetes, que define el comportamiento de infraestructura que espera a través de puntos de extensión estándar. Faltaba el software que conectara ambos mundos, y ese es el trabajo que Oxide documentó en su blog.
TL;DR
- Oxide Computer publicó cómo construyó sus tres integraciones de Kubernetes: Rancher, Omni y Cluster API.- Matthew Sanabria, primer Solutions Software Engineer de Oxide, arrancó el proyecto a fines de 2024.- El driver de nodos de Rancher fue la primera integración: traduce acciones de Rancher a la API de Oxide.- El proveedor de infraestructura para Omni se construyó en siete semanas, a tiempo para KubeCon NA 2025.- Un bug en Talos Linux (siderolabs/talos#11948) impedía leer el user-data de Oxide por un problema de filesystem.- La solución temporal: inflar el archivo user-data con comentarios para forzar el superbloque ISO 9660.- La tercera integración es un provider de Cluster API (CAPI), declarativo y sin depender de terceros.- Las tres integraciones ya cuentan con guías oficiales publicadas por Oxide.
Introducción: qué significa correr Kubernetes en Oxide
Kubernetes fue diseñado desde el inicio para no depender de un proveedor de nube en particular. Define puntos de extensión estándar (interfaces de proveedor de nube, drivers de almacenamiento, infrastructure providers) para que cualquier plataforma pueda implementarlos. Oxide, por su parte, expone cada operación de su hardware (crear una instancia, adjuntar un disco, configurar red) a través de una API HTTP documentada. Cuando esas dos piezas encajan, correr Kubernetes en Oxide se vuelve un problema de integración, no de reinvención.
El problema, hasta fines de 2024, era que esa integración no existía todavía de forma oficial. Los clientes que querían Kubernetes sobre racks de Oxide tenían que resolverlo por su cuenta, como el que terminó enviando el pull request del driver de Rancher.
Qué pasó
Sanabria fue contratado como el primer Solutions Software Engineer de Oxide, un rol enfocado en construir software para resolver problemas concretos de clientes, no investigación abstracta. Su primera tarea fue simplificar el despliegue y la operación de Kubernetes en Oxide.
En lugar de diseñar integraciones en el vacío, el equipo siguió los problemas que los clientes encontraban a medida que avanzaban del aprovisionamiento de clusters a la operación de cargas de trabajo reales. Distintos flujos de aprovisionamiento llevaron a Rancher, Omni y Cluster API. Operar clusters expuso necesidades de reconciliación de infraestructura. Exponer aplicaciones reveló huecos de redes. Y las cargas de trabajo con estado expusieron límites de almacenamiento.
Ese orden (aprovisionar, operar, exponer, persistir) es el que Oxide usa para explicar en qué trabajó primero y qué le falta todavía.
Oxide expone cada operación del rack via API HTTP, sin BMC tradicional.
Contexto e historia
El driver de nodos de Rancher
Un node driver de Rancher es un plugin ejecutable que le enseña a Rancher cómo crear y administrar máquinas virtuales en una plataforma de infraestructura particular. El driver de Oxide traduce esas operaciones (crear, listar, borrar una instancia) en llamadas a la API de Oxide.
Sanabria nunca había usado Rancher ni trabajado con un node driver, así que revisar la contribución del cliente significó aprender ambas cosas a la vez. Después de confirmar que la implementación funcionaba, el equipo fusionó el pull request, agregó integración continua y documentación, y publicó la primera versión oficial. Fue la primera integración de Kubernetes de Oxide, y ya tenía un cliente corriéndola en producción antes de que se publicara.
El proveedor de infraestructura para Omni
Omni, de Sidero Labs, es un control plane que aprovisiona y administra clusters de Kubernetes sobre Talos Linux, una distribución de Linux inmutable pensada específicamente para correr Kubernetes. Omni se conecta a distintas plataformas a través de infrastructure providers: programas que crean instancias de Talos Linux y las registran en Omni.
Con KubeCon North America 2025 a pocas semanas de distancia, Oxide vio la oportunidad de construir ese provider junto con Sidero Labs y mostrarlo en un evento conjunto. El equipo tuvo siete semanas para completarlo antes del evento Oxide+Sidero en KubeCon.
El provider de Cluster API
Cluster API (CAPI) es la API de Kubernetes mantenida por SIG Cluster Lifecycle para crear, escalar, actualizar y borrar clusters de forma declarativa usando recursos custom de Kubernetes. A diferencia de Rancher u Omni, no depende de una plataforma de terceros: cada infrastructure provider implementa los recursos que le indican a CAPI cómo crear y borrar máquinas virtuales en una plataforma específica.
Oxide ya tenía intención de construir este provider desde el primer borrador de la RFD 493, pero al principio la demanda de clientes y la capacidad de ingeniería no justificaban la inversión. Terminó siendo la tercera integración publicada, después de confirmar que ningún enfoque único cubría todos los flujos de trabajo de los clientes.
Detalles técnicos y rendimiento
El detalle técnico más citado del proyecto es un problema de compatibilidad entre el cloud-init de Oxide y el probe de sistemas de archivos de Talos Linux. Oxide usa un filesystem FAT12 para el disco de user-data de cloud-init, no ISO 9660. Pero el probe de Talos solo intentaba leer un superbloque ISO 9660 en el disco de configuración NoCloud, y si esa lectura fallaba, se detenía en lugar de probar otros formatos como VFAT o MS-DOS. El resultado: Talos nunca leía el user-data de Oxide con la configuración necesaria para unirse a Omni.
⚠️ Ojo: el fix de este bug no llegó a tiempo para KubeCon. La solución temporal que Oxide publicó fue rellenar el archivo de user-data con comentarios hasta que el disco alcanzara el tamaño suficiente para que el probe usara el superbloque ISO 9660.
El bug quedó documentado públicamente en siderolabs/talos#11948, dentro de una serie más amplia de reportes que Oxide abrió en siderolabs/omni#1633. Sidero Labs respondió rápido a los reportes, algo que Oxide atribuye a su propio proceso de RFD (Request for Discussion), el mecanismo interno que usa la empresa para documentar decisiones de diseño antes de escribir código.
El provider de Cluster API sigue un modelo distinto: en vez de un binario que traduce comandos puntuales, define recursos de Kubernetes que describen el estado deseado del cluster. Un manifiesto típico luce así:
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: prod-oxide-01
namespace: default
spec:
clusterNetwork:
pods:
cidrBlocks: ["10.244.0.0/16"]
infrastructureRef:
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha1
kind: OxideCluster
name: prod-oxide-01
El nombre exacto del recurso (OxideCluster) es ilustrativo del patrón que siguen todos los infrastructure providers de CAPI (AWSCluster, VSphereCluster, etc.); conviene confirmar el nombre real en la documentación que publica Oxide junto al provider. CAPI reconcilia ese manifiesto de forma continua: si alguien borra una máquina a mano, el controlador la vuelve a crear para que el estado real coincida con el declarado. Esa es la diferencia central frente a un node driver, que solo actúa cuando Rancher se lo pide explícitamente.
Un manifiesto CAPI describe el estado deseado; el controlador lo reconcilia solo.
flowchart TD
A["Kubernetes"] --> B["Rancher node driver"]
A --> C["Omni infrastructure provider"]
A --> D["Cluster API provider"]
B --> E["API de Oxide"]
C --> E
D --> E
E --> F[("Racks Oxide")]
Cómo elegir entre las tres
IntegraciónCuándo usarlaVentajaLimitaciónRancher node driverYa administrás clusters con Rancher ManagerSe instala como plugin desde la UI, sin escribir YAMLDepende de tener Rancher Manager corriendo y actualizadoOmni infrastructure providerCorrés Talos Linux y querés gestión centralizadaAprovecha el modelo inmutable de Talos y el control plane de OmniRequiere aplicar la solución temporal al user-data hasta que se libere el fix de TalosCluster API providerYa usás CAPI en otras nubes y querés el mismo flujo en OxideAPI declarativa estándar, sin plataforma de terceros de por medioExige definir y mantener más recursos custom por cluster
💡 Tip: si ya administrás clusters en otras nubes con Cluster API, el provider de Oxide te deja mantener el mismo flujo de trabajo (mismo clusterctl, mismos manifiestos) en vez de aprender una herramienta nueva solo para tu hardware on-premise.
Cómo empezar
La forma más directa de probar el provider de Cluster API es instalar clusterctl, el CLI oficial del proyecto, y apuntarlo al provider de Oxide.
Linux
curl -L https://github.com/kubernetes-sigs/cluster-api/releases/latest/download/clusterctl-linux-amd64 -o clusterctl
chmod +x clusterctl
sudo mv clusterctl /usr/local/bin/clusterctl
clusterctl version
macOS
curl -L https://github.com/kubernetes-sigs/cluster-api/releases/latest/download/clusterctl-darwin-amd64 -o clusterctl
chmod +x clusterctl
sudo mv clusterctl /usr/local/bin/clusterctl
clusterctl version
Windows (PowerShell)
curl.exe -L https://github.com/kubernetes-sigs/cluster-api/releases/latest/download/clusterctl-windows-amd64.exe -o clusterctl.exe
.\clusterctl.exe version
Con el binario instalado, inicializás el provider de infraestructura correspondiente y validás que aparezca en la lista de providers activos:
clusterctl init --infrastructure oxide
clusterctl config repositories | grep oxide
Si preferís Rancher, el driver se agrega desde Cluster Management > Drivers > Node Drivers en la UI, apuntando a la URL del binario que publica Oxide. Para Omni, hay que registrar el infrastructure provider siguiendo la guía específica que Oxide enlaza desde su post original; ahí mismo está el detalle de cómo aplicar la solución temporal al user-data mientras el fix de Talos no esté disponible.
Impacto y análisis
Lo relevante de este caso no es una sola integración, sino el método: Oxide no diseñó tres formas de correr Kubernetes porque sí, sino porque cada cliente llegaba con un flujo de trabajo distinto (Rancher, Omni o CAPI) y ninguno de los tres cubría a todos. Para equipos de infraestructura en LATAM que evalúan hardware on-premise o soberano por costo, regulación o latencia, esto importa porque reduce el riesgo de quedar atado a una sola herramienta de orquestación al elegir un proveedor de hardware.
También es un caso de estudio sobre cómo una empresa de hardware compite en el ecosistema de Kubernetes sin construir su propia distribución: en vez de eso, Oxide invirtió en integrarse con las herramientas que sus clientes ya usaban (Rancher, Sidero Labs, SIG Cluster Lifecycle), incluyendo colaborar en reportar y corregir bugs en proyectos de terceros como Talos Linux.
Qué sigue
El propio post de Oxide deja abiertos los siguientes frentes: operar clusters expuso necesidades de reconciliación de infraestructura que todavía se están resolviendo, exponer aplicaciones reveló huecos en el modelo de redes de Oxide (relevante para quien necesite un CNI o balanceo de carga nativo), y las cargas de trabajo con estado expusieron límites de almacenamiento persistente, un área donde se esperaría trabajo futuro en drivers CSI. Oxide no da fechas concretas para esas piezas, pero las señala como la continuación natural del mismo proceso guiado por clientes que produjo las tres integraciones de aprovisionamiento.
📖 Resumen en Telegram: Ver resumen
Probalo vos: instalá clusterctl, corré clusterctl init --infrastructure oxide y confirmá con clusterctl config repositories | grep oxide que el provider de Oxide aparece activo antes de levantar un cluster real.
Preguntas frecuentes
¿Qué es Oxide Computer?
Es una empresa que fabrica racks completos de cómputo, red y almacenamiento con una API propia integrada al hardware, en lugar de depender de BMCs tradicionales de terceros.
¿Qué es un node driver de Rancher?
Un plugin ejecutable que le enseña a Rancher cómo crear, listar y borrar máquinas virtuales en una plataforma de infraestructura específica, en este caso Oxide.
¿Qué relación tiene Omni con Talos Linux?
Omni es el control plane de Sidero Labs que aprovisiona y administra clusters de Kubernetes corriendo sobre Talos Linux, una distribución de Linux inmutable diseñada para Kubernetes.
¿Qué es Cluster API y en qué se diferencia de Rancher u Omni?
Es una API declarativa de Kubernetes para gestionar clusters con recursos custom, sin depender de una plataforma de terceros como Rancher u Omni.
¿Por qué Talos Linux no podía leer el user-data de Oxide?
Porque Oxide usa un filesystem FAT12 para ese disco y el probe de Talos solo intentaba leer un superbloque ISO 9660, sin probar otros formatos si esa lectura fallaba.
¿Las integraciones de Kubernetes en Oxide son de uso libre?
Oxide las publica como parte de sus guías oficiales de producto para clientes que operan hardware Oxide; el desarrollo se coordinó públicamente con Sidero Labs en GitHub.
Referencias
- Oxide Computer: post original, "Kubernetes on Oxide: How Customer Needs Shaped Our Integrations".- siderolabs/talos#11948: issue donde Sidero Labs documentó el bug de detección de filesystem en el user-data.- siderolabs/omni#1633: reportes de integración entre Oxide y Omni.- Cluster API (SIG Cluster Lifecycle): documentación oficial del proyecto CAPI.- Rancher Manager Docs: documentación oficial de Rancher y sus node drivers.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)