Oxide integra Kubernetes: cómo clientes moldearon 3 soluciones en 2026

Kubernetes on Oxide: cómo las necesidades de clientes dieron forma a las integraciones de 2026

Oxide Computer Company, la startup de infraestructura cloud on-premises que recaudó US$100 millones en su Serie B de 2025, acaba de revelar cómo las demandas reales de clientes han moldeado su ecosistema de integraciones con Kubernetes. Según Matthew Sanabria, Solutions Software Engineer de Oxide, lo que comenzó como un simple pull request de un cliente en 2024 se ha convertido en un conjunto completo de herramientas que abordan cada etapa del ciclo de vida de Kubernetes.

El mercado de Kubernetes está en plena expansión, con un tamaño estimado de US$3.130 millones para 2026 según Mordor Intelligence, y se espera que alcance los US$8.410 millones para 2031. En este contexto, la capacidad de ejecutar Kubernetes de manera eficiente en infraestructura on-premises se ha convertido en una necesidad crítica para empresas que buscan control, seguridad y reducción de costos frente a las soluciones cloud públicas.

Tres enfoques de aprovisionamiento para diferentes flujos de trabajo

Cuando los clientes comenzaron a solicitar Kubernetes en Oxide a finales de 2024, el equipo no tenía integraciones soportadas. La solución fue desarrollar tres enfoques distintos que cubrieran los diferentes workflows de los clientes.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Rancher Node Driver: la primera integración

La integración comenzó con un pull request enviado por un cliente que necesitaba un driver de nodos para Rancher. Un Rancher node driver es un plugin ejecutable que enseña a Rancher cómo crear y gestionar máquinas virtuales en una plataforma de infraestructura específica. El Oxide Rancher node driver traduce esas operaciones en solicitudes a la API de Oxide.

Una vez instalado en Rancher, permite a los clientes aprovisionar instancias de Oxide como nodos en clusters de Kubernetes gestionados por Rancher. Esta fue la primera integración oficial de Oxide con Kubernetes, y un cliente ya la estaba usando exitosamente en producción desde el lanzamiento inicial.

Omni Infrastructure Provider: asociación estratégica

Con KubeCon North America 2025 a pocos meses de distancia, Oxide vio la oportunidad de asociarse con Sidero Labs para construir y mostrar un proveedor de infraestructura de Oxide para Omni. El equipo tenía siete semanas para completarlo antes del evento conjunto Oxide+Sidero.

El trabajo de integración descubrió varios problemas en Omni y Talos Linux, incluyendo un problema memorable con el sistema de archivos FAT12 de Oxide para cloud-init user-data. La solución temporal fue aumentar el tamaño de los datos de usuario con comentarios para que utilizaran un superbloque ISO 9660.

El resultado fue el Oxide infrastructure provider for Omni, que permite a los clientes usar Omni para aprovisionar instancias de Oxide ejecutando Talos Linux como nodos en clusters de Kubernetes gestionados por Omni.

Cluster API Provider: el enfoque nativo de Kubernetes

El equipo sabía desde el principio que quería construir un proveedor de infraestructura para Kubernetes Cluster API (CAPI), que ofrece una API upstream y extensible por proveedores para gestionar clusters sin requerir una plataforma de terceros como Rancher u Omni.

Eventualmente, tanto la demanda de clientes como la capacidad de ingeniería justificaron la inversión. Los compañeros de equipo Josh y Brandon tomaron posesión del trabajo y lanzaron Cluster API Provider Oxide (CAPOx), dando a los clientes una forma nativa de Kubernetes para aprovisionar clusters en Oxide.

El workflow de Cluster API también ejercita varias de las otras integraciones de Oxide, permitiendo probar el flujo de trabajo de extremo a extremo. El Kubernetes Image Builder usa el plugin de Packer de Oxide para crear imágenes de VM listas para CAPI, que CAPOx utiliza al aprovisionar instancias.

Cloud Controller Manager: reconciliación en tiempo real

Las integraciones de aprovisionamiento crean y gestionan instancias de Oxide, pero no reconcilian esas instancias con objetos Node de Kubernetes. Sin esa reconciliación, un cluster no podría determinar de manera confiable si un nodo de Kubernetes inalcanzable estaba temporalmente no disponible o si su instancia de Oxide subyacente había sido eliminada.

La solución fue construir el Oxide cloud controller manager (CCM), que conecta Kubernetes con Oxide. Su controlador de nodos mantiene los objetos Node de Kubernetes sincronizados con sus instancias de Oxide subyacentes, registrando detalles como IDs de instancia y direcciones de red, e informando si cada instancia está ejecutándose, apagada o ya no existe.

Importante: el CCM no crea instancias ni aprovisiona clusters. Eso sigue siendo trabajo de las integraciones de aprovisionamiento. En cambio, proporciona una integración en tiempo de ejecución compartida entre esos workflows de aprovisionamiento.

LoadBalancer Services: una solución temporal ingeniosa

Uno de los problemas que enfrentaron los clientes era la falta de un balanceador de carga nativo en Oxide. Sin embargo, Oxide sí tenía floating IPs - direcciones de pools IP externos del rack que pueden adjuntarse y desadjuntarse de instancias.

El equipo implementó una solución creativa: usar floating IPs para entregar tráfico a un solo nodo de Kubernetes, y dejar que el dataplane de Service de Kubernetes distribuya ese tráfico a los pods apropiados. Esta implementación actualmente soporta externalTrafficPolicy: Cluster, que permite al nodo seleccionado reenviar tráfico a un endpoint de Service en cualquier parte del cluster.

Cuando Oxide introduzca un servicio de balanceo de carga nativo, el equipo podrá actualizar el controlador de servicios para usarlo sin cambiar la interfaz de Kubernetes.

Almacenamiento persistente: el próximo desafío

Con clusters aprovisionados, reconciliados con Oxide y accesibles desde fuera de sus VPCs, el almacenamiento para workloads con estado se convirtió en la siguiente capa a abordar. Sin un driver CSI nativo de Oxide, los clientes podían desplegar sistemas de almacenamiento de terceros como Longhorn.

Sin embargo, usar Longhorn significaba respaldar sus réplicas con discos distribuidos de Oxide, que ya almacenan tres réplicas en sleds distintos. Esto podía crear una amplificación de escritura sustancial - una escritura de aplicación podía amplificarse hasta nueve escrituras de disco.

La introducción de discos locales de Oxide proporcionó una forma de eliminar la segunda capa de replicación. Los discos locales no tienen replicación incorporada y permanecen ligados a su sled, haciéndolos adecuados para sistemas como Longhorn que replican datos entre nodos de Kubernetes.

Para una integración nativa, el equipo está desarrollando un plugin CSI de Oxide, pero el desarrollo expuso un bloqueador crítico: Oxide requiere que una instancia se detenga antes de adjuntar o desadjuntar un disco, mientras que Kubernetes espera que un driver CSI adjunte almacenamiento a un worker en ejecución después de programar un pod.

¿Qué significa esto para tu startup en 2026?

La estrategia de integración de Oxide con Kubernetes ofrece varias lecciones valiosas para founders que construyen productos técnicos complejos:

1. Construye basándote en necesidades reales de clientes, no en especulaciones

Oxide no diseñó sus integraciones en abstracto. Comenzaron con un pull request real de un cliente y siguieron los problemas que los clientes encontraban al pasar del aprovisionamiento de clusters a la operación de workloads. Este enfoque de feedback loop continuo asegura que cada funcionalidad resuelva un problema concreto que los usuarios están enfrentando.

Acción concreta: Antes de desarrollar una nueva característica, identifica al menos tres clientes que estén experimentando el problema que intentas resolver. Documenta sus workflows actuales y las soluciones alternativas que están usando.

2. Ofrece múltiples puntos de entrada para diferentes workflows

Al ofrecer integraciones con Rancher, Omni y Cluster API, Oxide cubre los diferentes enfoques que tienen los equipos de DevOps. Algunos prefieren plataformas de gestión como Rancher, otros buscan soluciones más nativas como Cluster API, y otros están comprometidos con distribuciones específicas como Talos Linux.

Acción concreta: Mapea los diferentes perfiles de usuario en tu mercado y desarrolla puntos de entrada específicos para cada uno. No intentes forzar a todos los usuarios en un único workflow.

3. Aprovecha las arquitecturas complementarias

Kubernetes y Oxide tienen arquitecturas que se complementan naturalmente: Kubernetes da puntos de extensión estándar a los proveedores de infraestructura, mientras que Oxide expone primitivas de infraestructura a través de APIs. Esta complementariedad permite construir integraciones más robustas y mantenibles.

Acción concreta: Identifica cómo la arquitectura de tu producto se complementa con las plataformas existentes en tu ecosistema. Busca puntos de extensión estándar que puedas aprovechar en lugar de crear interfaces propietarias.

4. Prioriza la portabilidad y evita el vendor lock-in

El enfoque de Oxide permite a los clientes ejecutar Kubernetes en su infraestructura on-premises sin quedar atrapados en soluciones cloud públicas. En un mercado donde 96% de las empresas reportan usar o evaluar Kubernetes para workloads de producción, la capacidad de ejecutarlo donde sea más conveniente es un diferenciador clave.

Acción concreta: Diseña tu producto para funcionar en múltiples entornos (cloud público, híbrido, on-premises) desde el principio. La portabilidad se está convirtiendo en un requisito, no en una característica opcional.

El futuro de las integraciones Kubernetes en Oxide

El equipo de Oxide planea expandir su uso interno del proveedor de Cluster API recién lanzado para aprovisionar y operar más de sus clusters. El trabajo a corto plazo incluye completar el hot-plug de discos y enviar el plugin CSI, agregar soporte de autoscaling, y extender el controlador de servicios del CCM para soportar subredes externas.

A más largo plazo, a medida que Oxide envíe tagging de recursos, soporte OIDC y balanceo de carga nativo, extenderán sus integraciones de Kubernetes para aprovechar estas capacidades.

Lo más importante es que este trabajo permite a Oxide ejercitar sus SDKs y APIs desde la perspectiva de sus clientes y convertir la fricción del cliente en mejoras de producto. Ese ciclo de feedback es cómo continuarán creciendo este ecosistema.