Simulación de uso compartido de GPU multi-tenant con Kamaji y HAMi

Los ingenieros de plataforma a menudo se enfrentan a un difícil equilibrio entre la eficiencia de los recursos y el aislamiento del inquilino al gestionar cargas de trabajo de GPU. Una demostración reciente de Anish Bista muestra cómo la combinación de Kamaji y HAMi permite a los equipos compartir GPUs físicas de forma segura mientras mantienen planos de control distintos. Este enfoque utiliza hardware simulado para validar la arquitectura antes de comprometerse con infraestructuras costosas.

Qué ocurrió

El artículo detalla un entorno de laboratorio reproducible construido sobre un único host Linux utilizando contenedores Docker. El objetivo era demostrar que dos proyectos de código abierto, Kamaji y HAMi, pueden trabajar juntos para resolver el problema de la subutilización de GPU en clústeres de Kubernetes multi-tenant. Tradicionalmente, asignar una tarjeta GPU completa a un pod que solo necesita una fracción de su memoria conduce a un desperdicio significativo. Por el contrario, compartir un clúster entre múltiples equipos a menudo resulta en un aislamiento débil y riesgos de seguridad.

Bista construyó un clúster de gestión usando kind (Kubernetes in Docker) para alojar Kamaji. Dentro de esta capa de gestión, se crearon dos planos de control de inquilinos separados como pods. A cada inquilino se le asignó su propio nodo de trabajo, también ejecutándose como un contenedor, que se unió a la red y ejecutó componentes HAMi. La configuración incluía dos inquilinos simulados: tenant-a con una NVIDIA A100 simulada y tenant-b con dos tarjetas NVIDIA L4 simuladas. El laboratorio superó con éxito ocho pruebas, confirmando que cada inquilino podía programar cargas de trabajo de GPU fraccionadas sin ver recursos o pods pertenecientes al otro.

Cómo funciona

Kamaji aborda la sobrecarga del plano de control ejecutando el servidor API de Kubernetes y el almacén de datos etcd de cada inquilino como pods dentro de un clúster de gestión central. Esto elimina la necesidad de máquinas dedicadas al plano de control para cada equipo. HAMi, por otro lado, opera a nivel de programación y dispositivo. Permite a los pods solicitar segmentos específicos de una GPU, definidos por memoria en megabytes y porcentaje de cómputo, en lugar de reclamar una tarjeta entera. Esto permite que múltiples pods de diferentes aplicaciones coexistan en una única GPU física.

El punto crítico de integración implica la ruta de comunicación entre el servidor API del inquilino y el webhook de HAMi. Dado que el servidor API se ejecuta en el clúster de gestión pero el webhook reside en los nodos de trabajo del inquilino, la conexión debe atravesar un túnel Konnectivity. El laboratorio confirmó que este mecanismo de proxy inverso funciona correctamente, permitiendo que el servidor API llame de vuelta al entorno del inquilino para las decisiones de programación. Para probar esto sin hardware físico, el autor utilizó el plugin de dispositivo simulado de HAMi, que omite la interacción con el controlador y registra capacidad de GPU falsa mediante anotaciones de nodo.

Detalles clave

• El laboratorio se ejecutó en un único host con 4 núcleos de CPU, 8 GB de RAM y 20 GB de espacio en disco.
• Tenant-a estaba configurado con una NVIDIA A100 simulada de 80 GB, mientras que tenant-b tenía dos tarjetas NVIDIA L4 simuladas de 24 GB.
• La red IPv6 en kind causó fallos en los pools de MetalLB, lo que requirió inspección manual de la subred IPv4 para corregir la configuración de la puerta de enlace.
• Los pods de GPU simulados inicialmente fallaron debido a la contención de bloqueo de nodo porque el plugin simulado no libera automáticamente los bloqueos después de la asignación.
• Se requirió anotación manual de pods y nodos para simular el paso de finalización del plugin de dispositivo en el entorno simulado.
• La configuración demuestra la lógica de cableado y programación, pero no valida los límites de memoria reales ni el rendimiento de CUDA.

Por qué importa

Para desarrolladores de software e ingenieros de plataforma, esta arquitectura ofrece un camino para reducir significativamente los costos en la nube asociados con instancias de GPU. Al habilitar la asignación fraccionada, las organizaciones pueden empaquetar más cargas de trabajo en menos tarjetas, mejorando las tasas de utilización sin sacrificar los beneficios de seguridad de los planos de control aislados. La capacidad de probar toda esta pila utilizando hardware simulado significa que los equipos pueden validar su diseño de plataforma y pipelines de CI/CD antes de comprar nodos de GPU costosos.

Además, la integración exitosa de Kamaji y HAMi demuestra que los requisitos complejos multi-tenant no necesariamente requieren código de pegamento personalizado o soluciones propietarias. El uso de túneles estándar como Konnectivity asegura que el plano de control pueda gestionar de forma segura nodos de trabajo distribuidos. Esta modularidad permite a los equipos adoptar estas herramientas incrementalmente, comenzando con la simulación y pasando a hardware de producción con confianza en los mecanismos de programación subyacentes.

Qué puedes hacer

• Replicar el entorno de laboratorio usando kind y Kamaji para probar el aislamiento del plano de control multi-tenant en hardware local.
• Utilizar el plugin de dispositivo simulado de HAMi para validar políticas de programación y lógica de cuotas sin necesitar GPUs NVIDIA físicas.
• Inspeccionar manualmente las subredes de red de Docker si encuentras problemas relacionados con IPv6 con MetalLB en clústeres kind.
• Implementar pasos manuales de liberación de bloqueo en entornos de prueba para evitar las limitaciones del plugin simulado durante el desarrollo.
• Verificar la conectividad del túnel Konnectivity entre los servidores API de tu clúster de gestión y los webhooks de los nodos de trabajo del inquilino.
• Planificar la integración del plugin de dispositivo real desde el principio, ya que las configuraciones simuladas no imponen límites reales de memoria o cómputo.