La integración de Kubernetes en una plataforma de infraestructura bare-metal como Oxide no es un ejercicio puramente técnico, sino una iteración continua guiada por las necesidades operacionales de los clientes. El problema fundamental de la computación que se aborda es cómo mapear las abstracciones de infraestructura de Kubernetes (nodos, servicios de balanceo de carga, almacenamiento persistente) a las primitivas de una plataforma de hardware subyacente, minimizando la fricción y optimizando el rendimiento.
Este proceso implica identificar los puntos de extensión estándar de Kubernetes (Node Drivers, Infrastructure Providers, Cloud Controller Managers, CSI Drivers) y desarrollar componentes que traduzcan las operaciones de Kubernetes a las APIs nativas de Oxide. La relevancia actual radica en la creciente demanda de ejecutar cargas de trabajo en contenedores en infraestructuras más cercanas al hardware, buscando mayor eficiencia y control, lo que requiere una integración profunda y bien diseñada entre el orquestador y la infraestructura.
Arquitectura del Sistema
La arquitectura de integración se compone de varios módulos, cada uno abordando una fase del ciclo de vida de Kubernetes. Para el provisionamiento de clusters, se desarrollaron tres enfoques: un Rancher Node Driver, que traduce las operaciones de Rancher a las APIs de Oxide para la gestión de VMs; un Omni Infrastructure Provider, que permite a Omni provisionar instancias de Talos Linux en Oxide; y un Cluster API Provider (CAPOx), que ofrece una forma Kubernetes-nativa de gestionar clusters mediante Custom Resources. Este último utiliza un Kubernetes Image Builder con un plugin de Packer para crear imágenes de VM de Oxide.
Para la reconciliación en tiempo de ejecución, el Oxide Cloud Controller Manager (CCM) es un componente crítico. Este CCM, que se ejecuta dentro de cada cluster de Kubernetes, se comunica con la API de Oxide para sincronizar los objetos Node de Kubernetes con las instancias de Oxide subyacentes, gestionando su estado y direcciones de red. También incluye un Service Controller que, en ausencia de un balanceador de carga nativo de Oxide, utiliza Floating IPs para implementar servicios LoadBalancer. Este controlador publica tanto la Floating IP (modo Proxy) como la IP interna del nodo (modo VIP) en el estado del servicio. Finalmente, para el almacenamiento persistente, se está desarrollando un CSI Driver de Oxide. Este driver gestionará el ciclo de vida de los discos distribuidos de Oxide, creando, adjuntando y montando volúmenes en respuesta a PersistentVolumeClaims de Kubernetes. Un desafío clave es la necesidad de soporte de hot-plug de discos en la pila de Oxide, ya que la API actual requiere detener la instancia para adjuntar/desadjuntar discos.
Flujo de Provisionamiento de Cluster con Cluster API
- 1 Usuario Crea Custom Resources de Kubernetes para definir el cluster
- 2 Cluster API Interpreta CRs, invoca a CAPOx
- 3 CAPOx Llama a la API de Oxide para provisionar instancias
- 4 Kubernetes Image Builder Usa Packer para crear imágenes de VM de Oxide
- 5 Oxide API Provisiona VMs con imágenes específicas
- 6 Oxide CCM Reconcilia estado de nodos y servicios en el cluster provisionado
Flujo de Tráfico para Servicio LoadBalancer (Floating IP)
- 1 Cliente Envía solicitud a Floating IP (ej. 45.154.216.233:80)
- 2 Red de Oxide Traduce destino a IP interna de instancia (ej. 172.30.0.5:80)
- 3 Nodo Kubernetes Recibe paquete en IP interna
- 4 Dataplane de Servicio K8s Selecciona un endpoint de servicio (pod)
- 5 Pod Recibe tráfico en su puerto de destino
| Capa | Tecnología | Justificación |
|---|---|---|
| orchestration | Kubernetes | Orquestador de contenedores, define la interfaz de infraestructura deseada. |
| orchestration | Rancher | Plataforma de gestión de clusters de Kubernetes, utiliza Node Drivers para aprovisionamiento. vs Omni, Cluster API |
| orchestration | Omni (Sidero Labs) | Herramienta para aprovisionar clusters de Talos Linux, se integra vía Infrastructure Providers. vs Rancher, Cluster API |
| orchestration | Cluster API (CAPI) | Framework para gestionar declarativamente clusters de Kubernetes, utiliza Infrastructure Providers. vs Rancher, Omni |
| compute | Oxide API | Expone las primitivas de infraestructura de Oxide para la gestión de VMs, redes y almacenamiento. |
| networking | Oxide Floating IPs | Mecanismo para exponer servicios externamente en ausencia de un balanceador de carga nativo, con traducción de direcciones. vs Balanceador de carga nativo (futuro) ipMode: Proxy (para Floating IP), ipMode: VIP (para IP interna del nodo) |
| storage | Oxide Distributed Disks | Almacenamiento persistente con replicación integrada, objetivo del CSI Driver nativo. vs Oxide Local Disks + Longhorn |
| storage | Oxide Local Disks | Discos sin replicación, adecuados para sistemas de almacenamiento que manejan su propia replicación (ej. Longhorn). vs Oxide Distributed Disks |
| storage | Longhorn | Sistema de almacenamiento distribuido para Kubernetes, usado como alternativa al CSI Driver nativo de Oxide. vs Oxide CSI Driver (en desarrollo) |
Trade-offs
Ganancias
- ▲ Soporte para LoadBalancer Services
- ▲ Flexibilidad en el provisionamiento de clusters
- ▲ Reducción de write amplification para almacenamiento persistente
Costes
- △ Abstracción imperfecta de LoadBalancer Services (doble IP)
- ▲ Dependencia de hot-plug de discos para CSI nativo
- △ Complejidad inicial de integración con múltiples herramientas de provisionamiento
status:
loadBalancer:
ingress:
- ip: 45.154.216.233
ipMode: Proxy
- ip: 172.30.0.5
ipMode: VIPFundamentos Teóricos
El problema de mapear abstracciones de alto nivel a primitivas de bajo nivel es un tema recurrente en la informática, con raíces en los sistemas operativos y la virtualización. La noción de un 'Cloud Controller Manager' en Kubernetes es análoga al concepto de un 'hypervisor' en la virtualización, o al 'kernel' en un sistema operativo, donde un componente central se encarga de abstraer y gestionar los recursos de hardware subyacentes para las aplicaciones o máquinas virtuales. La gestión de recursos distribuidos y la consistencia de estado entre un plano de control (Kubernetes) y un plano de datos (Oxide) se relaciona con principios de sistemas distribuidos como el teorema CAP y la necesidad de mecanismos de consenso o reconciliación eventual. La implementación de un CSI Driver y los desafíos con el hot-plug de discos tocan directamente los principios de gestión de E/S y dispositivos en sistemas operativos, donde la capacidad de añadir o quitar hardware sin interrupción es un objetivo de diseño clave, a menudo abordado con técnicas de interrupción y reconfiguración dinámica de recursos, como se describe en trabajos sobre sistemas operativos tolerantes a fallos y sistemas en tiempo real.