La integración de Kubernetes con una plataforma de infraestructura subyacente, como Oxide, es un problema fundamental de la computación distribuida que requiere la alineación de dos modelos de control distintos: el declarativo de Kubernetes y el imperativo de las APIs de infraestructura. Este desafío se ha vuelto crítico con la ubicuidad de Kubernetes como estándar de facto para la orquestación de contenedores, impulsando la necesidad de que cada proveedor de infraestructura ofrezca una experiencia nativa y eficiente.
Históricamente, la abstracción de la infraestructura para plataformas de orquestación ha evolucionado desde scripts manuales hasta sistemas de gestión de máquinas virtuales (VMware, OpenStack) y, más recientemente, a la computación en la nube (AWS, Azure, GCP). Kubernetes, con su modelo de control basado en controladores y Custom Resources, formaliza esta abstracción a través de puntos de extensión como los Cloud Controller Managers y los Container Storage Interface (CSI) drivers. La tesis central es que una integración exitosa no solo mapea las operaciones, sino que también optimiza el rendimiento y la resiliencia, a menudo requiriendo cambios en la plataforma de infraestructura misma para soportar los patrones esperados por Kubernetes.
Arquitectura del Sistema
La arquitectura de integración de Kubernetes en Oxide se basa en un enfoque multifacético que aborda el ciclo de vida completo del cluster. Para el aprovisionamiento, se han desarrollado tres integraciones clave: un Rancher Node Driver, que traduce las operaciones de Rancher a la API de Oxide para la gestión de VMs; un Omni Infrastructure Provider, que permite a Omni aprovisionar instancias de Talos Linux en Oxide; y un Cluster API Provider (CAPOx), que ofrece una forma nativa de Kubernetes para gestionar clusters mediante Custom Resources. Este último utiliza un Packer plugin para construir imágenes de VM de Oxide.
La reconciliación en tiempo de ejecución se maneja mediante el Oxide Cloud Controller Manager (CCM). Este componente, que se ejecuta dentro de cada cluster de Kubernetes, utiliza la API de Oxide para sincronizar los objetos Node de Kubernetes con las instancias de Oxide subyacentes, reportando su estado y direcciones de red. El CCM también incluye un Service Controller que gestiona los servicios de tipo LoadBalancer. Dada la ausencia inicial de un balanceador de carga nativo en Oxide, el CCM utiliza Floating IPs de Oxide, traduciendo el tráfico entrante a la IP interna de la instancia y delegando la distribución a la Service dataplane de Kubernetes. Esto implica publicar tanto la Floating IP (modo Proxy) como la IP interna del nodo (modo VIP) en el estado del servicio.
Para el almacenamiento persistente, la estrategia inicial implicó el uso de sistemas de almacenamiento de terceros como Longhorn con discos locales de Oxide para evitar la replicación redundante. La solución nativa en desarrollo es un Oxide CSI driver. Este driver, al recibir una PersistentVolumeClaim, crearía un disco distribuido de Oxide y lo adjuntaría a la instancia seleccionada. Un desafío clave es que Oxide requiere detener una instancia para adjuntar/desadjuntar discos, lo que contrasta con la expectativa de Kubernetes de "hot-plugging". Esto ha impulsado un proyecto de ingeniería de pila completa en Oxide para implementar el hot-plug de discos desde el hipervisor hasta la API.
Flujo de Servicio LoadBalancer con Floating IP
- 1 Cliente Envía solicitud a Floating IP (ej. 45.154.216.233:80)
- 2 Red de Oxide Traduce la IP de destino a la IP interna de la instancia (ej. 172.30.0.5:80)
- 3 Nodo de Kubernetes Recibe el paquete en su IP interna
- 4 Kubernetes Service Dataplane Selecciona un endpoint de servicio (Pod)
- 5 Pod Recibe el tráfico en su puerto de destino
| Capa | Tecnología | Justificación |
|---|---|---|
| orchestration | Kubernetes | Plataforma de orquestación de contenedores, define los puntos de extensión para la integración de infraestructura. |
| orchestration | Rancher | Plataforma de gestión de Kubernetes utilizada para el aprovisionamiento de clusters a través de un Node Driver de Oxide. |
| orchestration | Omni (Sidero Labs) | Herramienta para aprovisionar clusters de Talos Linux, integrada con Oxide mediante un Infrastructure Provider. |
| orchestration | Cluster API (CAPI) | API upstream y extensible para la gestión declarativa del ciclo de vida de clusters de Kubernetes, implementada con CAPOx. vs Rancher Node Driver, Omni Infrastructure Provider |
| compute | Oxide Cloud Controller Manager (CCM) | Componente que reconcilia el estado de los nodos de Kubernetes con las instancias de Oxide y gestiona los servicios LoadBalancer. |
| networking | Oxide Floating IPs | Mecanismo para exponer servicios LoadBalancer de Kubernetes externamente, mapeando IPs públicas a IPs internas de instancias. vs Balanceador de carga nativo de Oxide (futuro) ipMode: Proxy (Floating IP), ipMode: VIP (Internal IP) |
| storage | Longhorn | Sistema de almacenamiento de terceros para Kubernetes, utilizado con discos locales de Oxide para evitar doble replicación. vs Oxide CSI driver (en desarrollo) |
| storage | Oxide Local Disks | Discos sin replicación integrada, adecuados para sistemas de almacenamiento que gestionan su propia replicación (ej. Longhorn). vs Oxide Distributed Disks (con replicación integrada) |
| storage | Oxide Distributed Disks | Discos con replicación integrada (tres réplicas en sleds distintos), objetivo del futuro CSI driver nativo. vs Oxide Local Disks |
| storage | Container Storage Interface (CSI) | Estándar de Kubernetes para la integración de sistemas de almacenamiento, con un driver de Oxide en desarrollo. |
Trade-offs
Ganancias
- ▲ Soporte de LoadBalancer con Floating IPs
- ▲ Reducción de write amplification con Longhorn + discos locales
- ▲ Flexibilidad de aprovisionamiento con múltiples opciones (Rancher, Omni, CAPI)
Costes
- △ Abstracción imperfecta de LoadBalancer (doble IP en EXTERNAL-IP)
- ▲ Dependencia de hot-plug de discos para CSI nativo
- △ Gestión de almacenamiento por terceros (Longhorn) en lugar de nativo
status:
loadBalancer:
ingress:
- ip: 45.154.216.233
ipMode: Proxy
- ip: 172.30.0.5
ipMode: VIPFundamentos Teóricos
El problema de la integración de sistemas distribuidos y la gestión de recursos subyacentes se remonta a los fundamentos de los sistemas operativos y la virtualización. Conceptos como la abstracción de hardware y la gestión de recursos son centrales en papers clásicos como 'The Design and Implementation of the 4.3BSD Unix Operating System' (Leffler et al., 1989), que describe cómo el kernel abstrae los dispositivos de hardware para los procesos de usuario. En el contexto de la nube, la idea de un 'Cloud Controller Manager' se alinea con el patrón de 'control loop' o 'reconciliation loop' que es fundamental en los sistemas de control distribuidos, donde un estado deseado se compara continuamente con un estado actual y se toman acciones para converger. Este patrón es una aplicación práctica de los principios de control realimentado, comunes en la ingeniería de sistemas.
La gestión de almacenamiento persistente y los desafíos del hot-plug de discos se relacionan con la evolución de los sistemas de archivos distribuidos y la virtualización de E/S. El concepto de un Container Storage Interface (CSI) driver es una formalización moderna de la abstracción de almacenamiento, similar a cómo los drivers de dispositivos han funcionado en sistemas operativos tradicionales. La problemática de la doble replicación (Longhorn sobre discos distribuidos de Oxide) resalta el 'write amplification' y la importancia de comprender las propiedades de durabilidad y rendimiento de cada capa de almacenamiento, un tema recurrente en la investigación de bases de datos distribuidas y sistemas de archivos tolerantes a fallos.