CoHDI se une al CNCF: cómo llevar Kubernetes a infraestructuras desagregadas

Introducción

Los clusters de Kubernetes en producción enfrentan un desafío creciente: la rigidez en la asignación de hardware especializado. Mientras que los nodos tradicionales vinculan recursos como GPUs o FPGAs de forma estática, las cargas de trabajo modernas —como inferencia de modelos de lenguaje grande (LLM) o pipelines de IA agentica— exigen elasticidad en tiempo real. CoHDI (Composable Hardware in Disaggregated Infrastructure) aborda este problema al habilitar la conexión y desconexión dinámica de dispositivos PCIe en nodos de Kubernetes, sin reinicios del sistema operativo ni downtime.

El proyecto, lanzado en marzo de 2025 como una colaboración entre Red Hat, FSAS, Fujitsu, IBM Research y NTT, acaba de ser aceptado en el programa Sandbox del CNCF. Esta incorporación no solo valida su madurez técnica, sino que también acelera su adopción en entornos multi-vendor, alineándose con estándares abiertos como el Dynamic Resource Allocation (DRA) de Kubernetes.

Qué ocurrió

CoHDI fue aceptado oficialmente como proyecto Sandbox del CNCF el 28 de julio de 2026, durante el KubeCon + CloudNativeCon Japan. La decisión, respaldada por el Technical Oversight Committee (TOC) del CNCF, reconoce su capacidad para integrarse con el ecosistema cloud-native y su potencial para redefinir la gestión de hardware en infraestructuras desagregadas.

El proyecto surgió como InfraDDS y evolucionó hacia CoHDI para enfatizar su enfoque en la composabilidad: la ability de combinar recursos de hardware de distintos proveedores bajo una misma capa de orquestación. Su integración con Kubernetes se basa en tres pilares:

1. Compatibilidad con DRA: Usa el framework de Dynamic Resource Allocation (introducido en Kubernetes 1.26 como alpha y estabilizado en 1.28) para exponer recursos desagregados como ResourceSlices.
2. Colaboración con SIGs: Trabaja activamente con los grupos SIG Node, SIG Autoscaling y SIG Scheduling para garantizar que la asignación dinámica de dispositivos sea transparente para el scheduler.
3. Estándares abiertos: Promueve la interoperabilidad entre hardware de NTT (como su IOWN Data-Centric Infrastructure), Fujitsu, IBM y otros, evitando vendor lock-in.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para los equipos de infraestructura, CoHDI ofrece un cambio de paradigma en la gestión de recursos. En entornos con demandas variables —como clusters que ejecutan inferencia de LLM—, permite:

• Separar fases de cómputo: En un workflow de LLM, la fase de prefill (intensiva en CPU/GPU) puede asignar dinámicamente aceleradores, mientras que la fase de decode (intensiva en memoria) los libera y reasigna a otros pods.
• Reducir el over-provisioning: Según datos de NTT, en pruebas internas con CoHDI se logró un 30% de ahorro en consumo energético al evitar asignar recursos ociosos a nodos.
• Soporte multi-vendor: Los operadores pueden mezclar hardware de distintos fabricantes (ej: GPUs NVIDIA y AMD, FPGAs de Intel) bajo una misma API, simplificando la gestión en entornos híbridos.

Para los equipos de seguridad, el principal beneficio es la reducción de la superficie de ataque. Al desvincular dispositivos PCIe de nodos cuando no son necesarios, se limita el tiempo de exposición a vulnerabilidades como CVE-2023-20569 (escalada de privilegios en GPUs NVIDIA) o CVE-2024-3400 (fallos en el kernel de Linux que afectan a dispositivos passthrough). Además, CoHDI hereda las políticas de RBAC de Kubernetes, permitiendo controlar el acceso a recursos desagregados con granularidad de namespace.

Detalles técnicos

CoHDI opera mediante tres componentes principales, todos integrados con el CoHDI Manager (un servicio externo que gestiona el pool de dispositivos desagregados):

1. Dynamic-Device-Scaler (DDS)

– Integración: Requiere Kubernetes 1.28+ (DRA en stable) y el Kubelet configurado con --feature-gates=DynamicResourceAllocation=true.

– Ejemplo de ResourceSlice:

     apiVersion: resource.k8s.io/v1alpha2
     kind: ResourceSlice
     metadata:
       name: gpu-pool-1
     spec:
       nodeName: worker-node-1
       driver: nvidia.com/gpu
       capacity: 4
     

1. Composable-DRA-Driver

– Dependencias: Usa el PCIe Switch de la infraestructura desagregada (ej: soluciones basadas en CXL o PCIe over Fabric).

– Limitación actual: Solo soporta dispositivos PCIe con hot-plug habilitado (ver documentación de Linux).

1. Kubernetes Operator

– Ejemplo de CustomResource:

     apiVersion: cohdi.io/v1alpha1
     kind: ComposableDevice
     metadata:
       name: gpu-1
     spec:
       nodeSelector:
         kubernetes.io/hostname: worker-node-1
       deviceID: "PCI:0000:01:00.0"
       action: attach
     

[Pod] → (DRA Request) → [Kubelet] → [Dynamic-Device-Scaler] → [CoHDI Manager] → [Hardware Disaggregado]
                                      ↑
                               [Composable-DRA-Driver]
                                      ↑
                               [Kubernetes Operator]

Qué deberían hacer los administradores y equipos técnicos

Para evaluar CoHDI en un entorno de prueba, sigan estos pasos:

1. Requisitos previos:

– Nodos con soporte para PCIe hot-plug (verificar con lspci -vv | grep HotPlug).

– Un CoHDI Manager desplegado (el proyecto proporciona un demo en GitHub).

1. Instalación de componentes:

     git clone https://github.com/cohdi/cohdi.git
     cd cohdi
     

– Desplegar el Dynamic-Device-Scaler:

     kubectl apply -f manifests/dds/
     

– Configurar el Composable-DRA-Driver como un Device Plugin:

     kubectl apply -f manifests/dra-driver/
     

1. Prueba de concepto:

     apiVersion: v1
     kind: Pod
     metadata:
       name: test-gpu
     spec:
       containers:
       - name: nvidia-test
         image: nvidia/cuda:12.3.2-base-ubuntu22.04
         command: ["nvidia-smi"]
         resources:
           limits:
             nvidia.com/gpu: 1
     

– Verificar la asignación dinámica:

     kubectl get resourceslice
     kubectl describe pod test-gpu | grep -i "dynamic resources"
     

1. Monitoreo y troubleshooting:

– Revisar logs del CoHDI Manager:

     kubectl logs -n cohdi-system cohdi-manager-*
     

Conclusión

CoHDI no es solo otro proyecto de infraestructura: es un puente concreto entre la orquestación cloud-native y la innovación en hardware. Su aceptación en el CNCF Sandbox acelera la adopción de estándar para infraestructuras desagregadas, permitiendo a los equipos de DevOps y SRE optimizar recursos con un nivel de granularidad antes impensable. Para entornos con cargas de trabajo variables —especialmente en IA— su integración con DRA y Kubernetes ofrece una ventaja competitiva tangible: menos desperdicio de hardware, mayor flexibilidad y un camino claro hacia la sostenibilidad.

El proyecto aún está en fase temprana (versión 0.2.0 a julio de 2026), pero su hoja de ruta incluye soporte para CXL 3.0 y la integración con Kubernetes Scheduling Framework. Los equipos interesados pueden unirse al canal #cohdi en el Slack del CNCF o contribuir en su repositorio de GitHub.

Fuentes

https://www.cncf.io/blog/2026/07/28/welcome-cohdi-to-the-cncf-evolving-kubernetes-into-composable-disaggregated-infrastructures/