Enfoque en la Gestión de Dispositivos WG

La creciente popularidad de la IA, Edge y las cargas de trabajo de telecomunicaciones en Kubernetes ha llevado a nuevos requisitos para la gestión de hardware. Ahora necesitamos especificaciones de hardware más allá del tiempo de CPU y las asignaciones de memoria. Esto incluye la asignación de GPUs, TPUs, interfaces de red y otro hardware, a veces después de iniciar el pod y ocasionalmente a través de la compartición de tiempo. Gestionar de manera eficiente este hardware especializado es la misión del Grupo de Trabajo de Gestión de Dispositivos. Su proyecto fundamental, Asignación Dinámica de Recursos (DRA), ha pasado recientemente a GA, marcando un cambio fundamental en cómo el proyecto maneja cargas de trabajo intensivas en hardware a gran escala. En este foco, nos sentamos con los presidentes del grupo de trabajo Kevin Klues, Patrick Ohly y John Belamaric para discutir las limitaciones del modelo de dispositivo heredado, los desafíos NP-hard de la programación y cómo están construyendo un futuro más programable y consciente del hardware para Kubernetes.

Introducción a la Gestión de Dispositivos Natalie Fisher: ¿Puedes presentarte, tu rol y cómo te involucraste en el Grupo de Trabajo de Gestión de Dispositivos? Kevin Klues: Mi nombre es Kevin Klues. Soy Ingeniero Distinguido en NVIDIA. He sido copresidente del grupo de trabajo de gestión de dispositivos desde su creación en Kubecon EU 2024. También he estado involucrado en DRA (el entregable principal del grupo de trabajo) desde su inicio en 2019/2020. También he sido mantenedor de kubelet desde 2019, con un enfoque en su gestor de dispositivos, gestor de CPU y subcomponentes de gestor de topología. Los desafíos que vimos al utilizar estos componentes para cargas de trabajo que dependían de aceleradores externos (por ejemplo, GPUs) fueron lo que nos llevó a comenzar a trabajar en DRA en primer lugar. Patrick Ohly: Soy Ingeniero Principal en Intel. En Kubernetes, soy Líder Técnico de SIG Testing y SIG Instrumentation y copresidente del WG de Gestión de Dispositivos. Fui copresidente del WG de Registro Estructurado y miembro del Comité de Direccionamiento. Algunas de mis primeras contribuciones a Kubernetes incluyen volúmenes CSI efímeros y seguimiento de capacidad de almacenamiento, así que tuve alguna experiencia con el diseño de API, implementación y programación. Sabíamos que introducir una nueva API importante para aceleradores sería difícil. Algo imprudentemente, acepté ese desafío en 2020, escribí el KEP inicial de DRA (ahora conocido como "DRA clásico") e implementé la mayor parte, luego comencé de nuevo con un segundo KEP para el "DRA de parámetros estructurados". Al principio, fue una batalla cuesta arriba convencer a los mantenedores de que este trabajo era necesario. Solo alrededor de 2023 el interés por DRA aumentó, lo que condujo a la formación del grupo de trabajo. John Belamaric: Soy Ingeniero de Personal Senior en Google y el tercer copresidente del WG de Gestión de Dispositivos, también desde su inicio. También soy copresidente de SIG Architecture desde 2019. Como mencionó Patrick, a finales de 2023, el interés por DRA realmente aumentó. La implementación inicial hizo que la escalabilidad automática fuera muy desafiante, y había cierta preocupación en la comunidad sobre avanzar a beta. Me involucré para ayudar a abordar algunas de esas preocupaciones, y los tres, junto con Tim Hockin, trabajamos arduamente durante los siguientes meses para construir un consenso en torno a un nuevo diseño. Para facilitar esta colaboración, formamos el grupo de trabajo después de la discusión en KubeCon en París en 2024.

El problema y la solución El grupo de trabajo surgió de una reconsideración fundamental de cómo Kubernetes interactúa con hardware especializado. En el corazón de esta evolución está la Asignación Dinámica de Recursos (DRA). En lugar de tratar a los dispositivos como simples enteros, DRA proporciona un marco estructurado que divide la gestión de dispositivos en cuatro etapas distintas: Modelado: Los vendedores utilizan la API ResourceSlice para publicitar las capacidades y la capacidad granular de su hardware. Solicitud: Los usuarios definen sus necesidades específicas de hardware, como memoria de GPU o requisitos de interconexión, a través de la API ResourceClaim. Programación: El programador de Kubernetes utiliza estas APIs para igualar los requisitos de carga de trabajo con el hardware disponible de manera inteligente. Actuación: Una vez que se realiza una coincidencia, el sistema maneja el "apretón de manos" que prepara y asegura el dispositivo para el uso del Pod. NF: Para los lectores que pueden no estar familiarizados, ¿qué es el Grupo de Trabajo de Gestión de Dispositivos y qué problemas intenta resolver? KK: El Grupo de Trabajo de Gestión de Dispositivos fue encargado de habilitar una configuración, compartición y asignación simples y eficientes de aceleradores y otro hardware especializado a través de las cargas de trabajo de Kubernetes. Pensemos en GPUs, TPUs, FPGAs y dispositivos similares que no encajan bien en el modelo de recursos tradicional de Kubernetes. El problema que nos propusimos resolver es que la API de Plugin de Dispositivo heredada (que ha sido el mecanismo principal para exponer aceleradores de hardware en Kubernetes) es fundamentalmente limitada. Trata los dispositivos como enteros opacos: puedes solicitar "2 GPUs", pero no puedes decir nada significativo sobre qué GPUs necesitas, cómo deberían estar conectadas entre sí, si pueden ser compartidas o cómo deberían ser particionadas. Eso era suficiente para casos simples, pero las cargas de trabajo modernas de IA/ML son todo menos simples. Se extienden por múltiples nodos, requieren topologías de interconexión específicas y cada vez más necesitan compartir o particionar hardware de manera dinámica. El entregable principal del grupo de trabajo es la Asignación Dinámica de Recursos (DRA), un nuevo marco que reemplaza el rígido modelo de plugin de dispositivo con una API flexible y declarativa. Con DRA, las cargas de trabajo pueden describir sus requisitos de hardware (por ejemplo, tipo de GPU, capacidad de memoria, topología de interconexión, particionamiento deseado) y los controladores pueden publicar atributos de dispositivo de grano fino en los que el programador puede actuar. DRA pasó a GA en Kubernetes 1.34, y el ecosistema a su alrededor (por ejemplo, controladores, herramientas y nuevas extensiones de API) está creciendo rápidamente. PO: Como dijo Kevin, el grupo de trabajo se formó en torno al esfuerzo existente para desarrollar DRA. El trabajo inicial se realizó con solo un puñado de personas activamente involucradas, y quizás solo se pudo hacer con éxito en dicha configuración. Pero como toca muchas áreas diferentes de Kubernetes, también necesitábamos un lugar para discutir eso y obtener la participación de la comunidad más amplia de mantenedores de Kubernetes, proveedores de dispositivos y, en menor medida, también de usuarios finales. El grupo de trabajo proporciona ese lugar, con reuniones regulares en línea (un espacio para las Américas/EMEA, uno para EMEA/Asia) y en KubeCon. JB: DRA es el primer problema que ha abordado el WG. Se centra en la selección, asignación y configuración de los dispositivos. Dividimos el problema en cuatro partes: cómo el vendedor modela el dispositivo y publicita la capacidad, cómo el usuario lo solicita, cómo programamos esa solicitud sobre la capacidad publicitada y cómo actuamos ese resultado (es decir, cómo hacemos que el dispositivo esté listo y disponible para el Pod). Una cosa que es fundamental para el enfoque que tomamos es la conciencia de la increíble diversidad del hardware y la rápida tasa de cambio en la industria del hardware. Sabíamos que no podíamos mantenernos al día con el cambio si las APIs de Kubernetes tenían que cambiar para cada tipo de hardware. En su lugar, creamos un enfoque general donde abordamos los aspectos del hardware que son importantes para Kubernetes. Lo que hemos hecho hasta ahora se centra en los aspectos de programación y configuración de dispositivos. Crearemos una API de modelado de dispositivos (la API ResourceSlice) que los vendedores utilizarán para modelar las características de programación de sus dispositivos y permitir que los usuarios transmitan configuraciones arbitrarias a esos dispositivos. Al hacerlo, Kubernetes puede ser "programado" para entender estos aspectos de los dispositivos, sin necesidad de ser modificado. Pero DRA, tal como está ahora, se centra mucho en la programación. Hay otros aspectos de la Gestión de Dispositivos que están en el alcance del WG. En particular, estamos investigando la detección y mitigación de fallos en dispositivos, y si hay un mejor soporte que podemos integrar en Kubernetes para ayudar. Además, como mencionó Kevin, los dispositivos a menudo se asignan y utilizan en grupos, en lugar de individualmente. Elegir los dispositivos correctos para trabajar juntos en un grupo depende de cómo están interconectados; por ejemplo, las GPUs de NVIDIA pueden estar en una disposición de tejido de cualquier tipo en un dominio NVLINK, mientras que las TPUs pueden tener una interconexión de toro 3D. Esto afecta la "selección, asignación y configuración" de los dispositivos, y tenemos mucho más trabajo por hacer para abordar estos casos de uso.

Un esfuerzo inter-SIG Dado que la gestión de dispositivos toca la programación, operaciones de nodo, escalabilidad automática, redes y diseño de API, el trabajo abarca naturalmente múltiples SIG a través del proyecto Kubernetes. NF: ¿Cómo funciona la colaboración entre estos SIG en la práctica y por qué es necesaria? KK: La gestión de dispositivos toca casi cada capa de la pila de Kubernetes, por lo que el grupo de trabajo fue encargado como un esfuerzo inter-SIG desde el principio. Tenemos cinco SIG de interesados: sig-node, sig-scheduling, sig-autoscaling, sig-network y sig-architecture. En la práctica, el grupo de trabajo actúa como una capa de coordinación. No poseemos el código directamente; en su lugar, nuestros entregables toman la forma de KEPs e implementaciones que viven en los respectivos SIG. Lo que proporcionamos es un foro unificado donde las personas que están construyendo el programador, el kubelet, el escalador automático y el plano de red pueden diseñar juntas en lugar de aisladamente. ¿Por qué es esto necesario? Considera un ejemplo simple: un usuario solicita un conjunto de GPUs que necesitan comunicarse a través de NVLink. Ese requisito involucra al programador (ubicar los pods en los nodos adecuados), al kubelet (configurar los dispositivos y exponerlos al contenedor) y, potencialmente, a la escalabilidad automática (proporcionar el tipo de nodo adecuado si no existe). Si esos tres grupos diseñan de manera independiente, terminas con abstracciones inconsistentes, lógica duplicada y errores de integración que solo aparecen en producción. El grupo de trabajo asegura que una sola API coherente y un modelo de datos fluyan a través de todos estos componentes. El modelo inter-SIG también significa que las decisiones de diseño son revisadas desde múltiples ángulos. Alguien de sig-scheduling captará complejidades del programador que un contribuyente de sig-node podría pasar por alto y viceversa. Esto ralentiza ligeramente las decisiones individuales, pero produce resultados mucho más robustos.

Áreas de enfoque actuales Con DRA ahora generalmente disponible, el enfoque del grupo de trabajo se ha expandido para habilitar modelos de programación más avanzados, semánticas compartidas, visibilidad operativa y soporte para topologías de hardware cada vez más complejas. NF: ¿Cuáles son algunas de las iniciativas o entregables clave en los que el grupo de trabajo se está enfocando actualmente? KK: Mantenemos un tablero de proyectos en Kubernetes Project Board con seguimiento en tiempo real de nuestras iniciativas y su progreso. PO: El alcance y el conjunto de características del DRA central se limitaron intencionadamente para habilitar su graduación a GA en un tiempo razonable. KEPs adicionales agregan más características, en su propio calendario. Esas caen aproximadamente en tres categorías: Extender la expresividad de DRA para soportar dispositivos más complejos y escenarios de programación. Soportar operaciones del día dos, como monitoreo de salud. Mejorar el soporte multinodal, principalmente integrando con la programación consciente de la carga de trabajo. Además del tablero del proyecto, también mantenemos una tabla que resume todos los KEPs que están actualmente en desarrollo. Este es el estado para 1.36; es probable que se agreguen más para 1.37: KEP Descripción Lanzamiento 1.32 1.33 1.34 1.35 1.36 4381 DRA: Parámetros Estructurados Beta Beta Estable 5004 DRA: Solicitudes de Recursos Extendidas a través de DRA Alpha Alpha Beta 4817 DRA: Estado de Reclamo de Recursos Alpha Beta Beta Beta Beta 5018 DRA: Acceso Administrador Controlado por Namespace Alpha Beta Beta Estable 5055 DRA: Taints y Tolerancias de Dispositivos Alpha Alpha Alpha Beta 4816 DRA: Alternativas Prioritarias en Solicitudes de Dispositivos Alpha Beta Beta Estable 5075 DRA: Capacidad Consumible Alpha Alpha Beta 4815 DRA: Dispositivos Particionables Alpha Alpha Alpha Beta 5304 DRA: API Descendente de Atributos Alpha 5729 DRA: Soporte de ResourceClaim para Cargas de Trabajo Alpha 4680 Estado de Salud de Recursos en el Estado del Pod Alpha Alpha Alpha Alpha Beta 5517 DRA: Solicitudes de Recursos Nativas Alpha 5677 DRA: Visibilidad de Disponibilidad de Recursos Alpha 5007 DRA: Condiciones de Vínculo de Dispositivos Alpha Alpha Beta 5491 DRA: Tipos de Lista para Atributos Alpha

NF: Uno de los principales desafíos es la utilización y compartición eficiente de dispositivos. ¿Qué progresos se están realizando en esta área? JB: Buena pregunta. Una forma de pensar al respecto es en lo que estamos haciendo en las dos APIs principales: ResourceClaim y ResourceSlice. La API ResourceClaim es cómo el usuario solicita dispositivos. Hemos construido algunas características que permiten al usuario ser más flexible en sus solicitudes. Por ejemplo, en lugar de pedir un modelo específico de GPU, pueden pedir una GPU con al menos cierta cantidad de memoria. O pueden pedir una lista de alternativas: "Me gustaría una GPU A100 (80GB), pero si no la tienes, aceptaré 2 GPUs A100 (40 GB)". Esto le da al programador algunas opciones para satisfacer la solicitud, lo que puede llevar a una mejor disponibilidad y utilización de hardware que de otra manera no sería seleccionado. La API ResourceClaim permite a los usuarios compartir dispositivos explícitamente. Puedes conectar múltiples contenedores (en el mismo pod o en diferentes pods) a un ResourceClaim; esto permite que los dispositivos asignados por esa reclamación se utilicen en todos esos contenedores, si el dispositivo lo admite. La API ResourceSlice es cómo los vendedores modelan y publicitan sus dispositivos. Aquí es donde implementamos soporte para otros modelos de compartición. Por ejemplo, tenemos una forma de representar "particiones superpuestas", permitiendo que el programador seleccione dinámicamente una partición MIG y haga que cualquier partición MIG superpuesta no esté disponible automáticamente. Esto funciona bien en combinación con una solicitud como “dame cualquier GPU con 20GB o más de memoria”: el programador puede satisfacer esto con una MIG o una GPU real. Algunas características requieren cambios en ambas. Tenemos otro método de compartición que llamamos "capacidad consumible". En el caso de la compartición explícita descrita anteriormente, un usuario necesita conectar contenedores al mismo ResourceClaim; hay un ResourceClaim compartido entre varios contenedores y Pods. Con la capacidad consumible, la compartición de dispositivos funciona más como los Pods comparten un Nodo. El usuario crea un ResourceClaim que solicita una cierta cantidad de recursos, por ejemplo, “necesito un NIC con 2Gbps de ancho de banda”. El programador sabe que hay un NIC con 40Gbps de ancho de banda disponible, por lo que asigna 2Gbps de ese 40Gbps y se lo da a ese ResourceClaim. En este caso, cada Pod tiene su propio ResourceClaim, pero el dispositivo subyacente se comparte entre esas reclamaciones. Depende del controlador DRA en el nodo configurar correctamente el dispositivo para este tipo de compartición (en el caso del NIC, probablemente creando una subinterfaz). Llamamos a esto "compartición mediada por la plataforma" para diferenciarlo de la "compartición mediada por el usuario".

Impacto en el mundo real Aunque gran parte del trabajo es profundamente técnico, el objetivo subyacente es práctico: permitir que Kubernetes soporte mejor cargas de trabajo de IA/ML y de alto consumo de hardware a gran escala. NF: ¿Cuáles son los mayores desafíos que enfrentan los usuarios hoy en día al ejecutar cargas de trabajo intensivas en hardware (como IA/ML) en Kubernetes? PO: Tales cargas de trabajo se alejan de las cargas de trabajo de contenedor tradicionales de varias maneras: pueden consistir en múltiples pods que se comunican y que deben ejecutarse al mismo tiempo (“programación en grupo”). A menudo son de larga duración y costosas de inicializar, y su rendimiento es sensible a dónde se ejecutan (topología dentro de un nodo e interconexiones entre nodos para múltiples pods). El programador de Kubernetes tradicionalmente no ha apoyado bien ninguna de estas características porque programa un pod a la vez y no es consciente de la topología dentro de un nodo. Varios programadores externos intentan llenar este vacío, lo que a menudo no es ideal, en particular cuando el programador de Kubernetes programa otros pods en el mismo clúster. NF: ¿Cómo deberían pensar los ingenieros de plataforma sobre la gestión de dispositivos al diseñar sus plataformas Kubernetes? JB: Aún estamos aprendiendo aquí, pero una idea de DRA es permitir un cambio hacia especificaciones más “impulsadas por requisitos”. Esto puede permitir menos acoplamiento entre los usuarios finales que escriben la especificación de carga de trabajo y los administradores del clúster que configuran los clústers. En lugar de acordar convenciones de etiquetado y requerir que los usuarios entiendan la topología del clúster, los usuarios pueden especificar lo que sus cargas de trabajo necesitan y el programador puede averiguar cómo satisfacerlo. Si podemos hacer que esto funcione, puede hacer que incluso cargas de trabajo complejas sean más portátiles entre clústers.

Desafíos y compensaciones Como en muchas áreas de Kubernetes, aumentar la flexibilidad y la expresividad también introduce nuevas capas de complejidad, particularmente en torno a la programación y la optimización. NF: ¿Cuáles son algunos de los desafíos técnicos más difíciles que el grupo de trabajo está abordando hoy? PO: Existe un conflicto inherente entre flexibilidad y complejidad de programación. La implementación actual se centra en encontrar alguna solución que satisfaga los recursos solicitados, pero no necesariamente es la mejor, lo que sea que “mejor” signifique, lo cual tampoco siempre está claro. El otro gran desafío es exponer los recursos asignables por nodo (RAM, CPU) como dispositivos con metadatos adicionales; esto es necesario para afinar la programación de cargas de trabajo que necesitan una alineación perfecta en un nodo para un rendimiento óptimo. JB: La lista de Patrick es buena. Modelar dispositivos complejos es difícil, y asegurarse de que construyamos la semántica correcta de modo que se aplique a muchos tipos diferentes de hardware siempre es complicado. Además, la programación en general es muy compleja y es un problema NP-hard. Todos los metadatos y flexibilidad que DRA agrega le dan al programador más opciones, lo que tiene pros y contras. Más opciones son útiles si estás limitado en tus elecciones, ya que significa que puedes programar algo que de otro modo no podrías. Pero también significa que es aún más difícil encontrar una solución óptima cuando hay muchas posibilidades en un clúster dado. DRA ha funcionado bien en nuestros casos de uso comunes hasta ahora, pero tenemos mucho trabajo por hacer para mejorar la optimalidad de la solución de programación elegida y asegurar el rendimiento de esa elección.

Mirando hacia adelante A pesar de los desafíos, los colaboradores en el grupo de trabajo están emocionados por el ritmo de la innovación y la creciente comunidad que se forma en torno a la gestión de dispositivos en Kubernetes. NF: Mirando hacia adelante, ¿qué es lo que más te emociona sobre el futuro de la gestión de dispositivos en Kubernetes? KK: NVIDIA donó recientemente su controlador DRA para GPUs al proyecto Kubernetes. Personalmente, estoy emocionado por que más miembros de la comunidad comiencen a contribuir al proyecto y definan su dirección futura. PO: Para mí, es principalmente el número de nuevos colaboradores y personas que se presentan para ayudar. Esto plantea nuevos desafíos en torno a la revisión de propuestas y ayudar a los desarrolladores a implementarlas y fusionarlas. Es bueno y gratificante ver a otros tener éxito, y es una buena señal para el futuro porque más personas están familiarizadas con el tema. JB: Estoy emocionado por muchas cosas. La comunidad realmente ha crecido y tiene tantas características interesantes en desarrollo para habilitar el modelado de dispositivos más complejos y modelar mejor dispositivos multinodales. Estoy realmente emocionado de ver las formas creativas en que la gente usará estas APIs. Fueron diseñadas principalmente para abordar "dispositivos", pero así como en Unix/Linux "todo es un archivo", las APIs en sí son bastante flexibles en cuanto a lo que modelan. Realmente construyen un programador más programable, lo que puede tener aplicaciones interesantes. Por ejemplo, recientemente prototipé el uso de DRA para programar pods en nodos donde un gran modelo de IA ya está almacenado en caché localmente. Es realmente bastante flexible, y tengo gran confianza en la creatividad de nuestra comunidad, así que creo que veremos algunas soluciones inesperadas en el ecosistema.

Involucrándose NF: ¿Cómo pueden los colaboradores involucrarse con el Grupo de Trabajo de Gestión de Dispositivos? KK: El primer paso más fácil es unirse a nuestra lista de correo en wg-device-management@kubernetes.io. Suscribirse añadirá automáticamente invitaciones de calendario para nuestras reuniones quincenales a tu calendario. Tenemos dos espacios de reunión para acomodar diferentes zonas horarias: Europa/Américas: martes a las 8:30 AM PT (quincenal) Asia/Europa: miércoles a las 9:00 AM CET (quincenal) Las notas de las reuniones, agendas y grabaciones son accesibles públicamente (enlaces disponibles desde la página de Gestión de Dispositivos). Puedes tener una idea del trabajo en progreso antes de asistir a tu primera reunión. En Slack, encuéntranos en #wg-device-management en el espacio de trabajo de Kubernetes Slack. Ese es el mejor lugar para preguntas rápidas o para presentarte. Para contribuciones más prácticas, el Controlador DRA para GPUs de NVIDIA es ahora un proyecto comunitario y un gran lugar para comenzar. Es una implementación real, de grado de producción que la comunidad más amplia está formando juntos. Damos la bienvenida a colaboradores de todos los niveles, ya sea que estés interesado en el diseño de API, la programación interna del programador, el desarrollo de controladores o la documentación. Ven y di hola.

Resumen A medida que Kubernetes evoluciona para apoyar la revolución de IA/ML y la computación de alto rendimiento, el trabajo que se realiza dentro del WG de Gestión de Dispositivos se está convirtiendo en la base de cómo se programan y operan las cargas de trabajo modernas a gran escala. Desde la graduación de la Asignación Dinámica de Recursos (DRA) hasta las próximas fronteras de monitoreo de salud y programación consciente de topología, este grupo está reescribiendo efectivamente el "apretón de manos" entre software y hardware. Si estás interesado en dar forma al futuro de la orquestación consciente del hardware, ahora es el momento perfecto para involucrarte. Ya sea que desees ayudar a refinar la API, construir controladores o mejorar la documentación, el grupo de trabajo da la bienvenida a todos los niveles de experiencia y perspectivas de toda la comunidad.