Planteamiento y alcance
Una plataforma de aprendizaje automático multiinquilino utiliza GPU, FPGA y tarjetas de red (NIC) de alta velocidad. Su diseño actual asigna dispositivos completos mediante etiquetas de nodo, recursos extendidos y complementos de dispositivos, lo que dificulta expresar los atributos de los dispositivos, el uso compartido y el aislamiento entre inquilinos. El equipo desea adoptar Dynamic Resource Allocation (DRA), cuyas API principales de resource.k8s.io/v1 alcanzaron la estabilidad en Kubernetes 1.34.
Diseñe la migración y explique las responsabilidades de ResourceClaim, DeviceClass, ResourceClaimTemplate, ResourceSlice, el controlador y el programador (scheduler). El clúster debe migrar gradualmente sin reiniciar todas las cargas de trabajo a la vez.
Qué evalúa el entrevistador
El entrevistador busca ver una separación clara entre la declaración de una necesidad de dispositivo y la asignación de un dispositivo concreto. Explique el flujo de datos entre las API del plano de control, el programador, el controlador del nodo y el kubelet, y distinga las API estables de DRA de las capacidades que siguen siendo experimentales o específicas del controlador.
Las respuestas sólidas cubren el uso compartido de capacidad, referencias entre espacios de nombres, fallas del controlador, reemplazo de Pods, coexistencia con cargas de trabajo antiguas, principio de privilegio mínimo y señales de rollback en lugar de limitarse a listar tipos de recursos.
Preguntas clarificadoras antes de responder
- ¿La solicitud es para un dispositivo completo, una capacidad divisible o cualquier dispositivo que coincida con ciertos atributos?
- ¿El controlador admite DRA y puede el complemento de dispositivo antiguo ejecutarse durante la migración?
- ¿Las cargas de trabajo deben crear Claims directamente o deben crearlas las plantillas de la plataforma?
- ¿Pueden los inquilinos reutilizar Claims entre espacios de nombres y qué objetos puede escribir el controlador de la plataforma?
- Durante la migración, ¿la prioridad es la continuidad de los trabajos, el rendimiento de la programación (throughput) o la utilización?
Marco de respuesta en 30 segundos
“Modelaría las necesidades de los dispositivos como Claims, dejaría que el controlador descubra, asigne y configure los dispositivos, y permitiría que el programador tome decisiones de viabilidad a partir de Claims y ResourceSlices. Realizaría una prueba canary con una clase de dispositivo pequeña en un espacio de nombres aislado. El complemento antiguo y DRA pueden coexistir por grupo de nodos (pool), pero nunca deben ser propietarios del mismo dispositivo. Cada fase mide el estado del Claim, la vinculación del Pod, la visibilidad del nodo, los errores del controlador, la latencia de asignación y los límites de los inquilinos. Si la asignación falla, detengo los nuevos Claims, preservo los trabajos en ejecución y redirijo las nuevas cargas de trabajo a la ruta antigua”.
Respuesta detallada paso a paso
Dibuje primero el flujo de datos de DRA
Una carga de trabajo hace referencia a un Claim mediante el campo resourceClaims del Pod. Un Claim se puede crear directamente o puede generarse para un Job mediante un ResourceClaimTemplate. Un DeviceClass describe una clase seleccionable de dispositivos, mientras que un controlador publica los dispositivos y atributos del nodo a través de ResourceSlice. El programador combina el Pod, Claim, DeviceClass y ResourceSlice para seleccionar un nodo; luego, el controlador del nodo realiza la asignación y configuración concretas.
Esto separa la selección del dispositivo del YAML de la aplicación y evita codificar la topología de hardware en convenciones de etiquetas.
Diseñe plantillas de Claim y límites de inquilinos
Exponga únicamente parámetros orientados al inquilino, como el nivel de memoria, el tipo de interconexión o el ancho de banda de red. No exponga identificadores internos del controlador. Un controlador de plataforma aplica la política de admisión de espacios de nombres, la cuota y la limpieza del ciclo de vida. El uso de Claims entre espacios de nombres requiere permisos de referencia explícitos y eventos de auditoría. Durante la eliminación de inquilinos, detenga nuevos Claims, espere a que los Pods liberen los dispositivos y luego reclame el estado del dispositivo.
Gestione dispositivos completos y capacidad compartible
La asignación de dispositivos completos puede mapear una DeviceRequest a un dispositivo. Compartir memoria, ancho de banda o intervalos de tiempo requiere que el controlador publique la capacidad y admita el comportamiento de capacidad consumible de DRA correspondiente. No simule el uso compartido con etiquetas del programador; la programación puede tener éxito mientras el nodo sobrevende la capacidad real. Defina unidades, límites de concurrencia, tiempos de liberación y políticas de fragmentación.
Coexista con los complementos de dispositivos
Particione la migración por clase de dispositivo o grupo de nodos para que el complemento antiguo y DRA nunca anuncien la propiedad sobre el mismo hardware. Las cargas de trabajo existentes conservan los recursos extendidos; las nuevas cargas de trabajo hacen referencia a Claims de DRA. Las etiquetas de grupo son un límite de migración, no la fuente final de los atributos del dispositivo. Cada grupo necesita una propiedad explícita y un interruptor de desactivación para evitar la inicialización duplicada de controladores.
Gestione la programación, la apropiación y las fallas
Cuando un Claim espera o falla, el Pod debe exponer un motivo de Pending explicable. Seleccionar un nodo no significa que el dispositivo esté configurado; el controlador puede fallar durante la configuración en el nodo. Un controlador debe clasificar las fallas como reintentables, no reintentables o que requieren limpieza, y enviar cada clase a la alerta correcta. La apropiación (preemption) debe considerar la prioridad del Pod, la capacidad ocupada del Claim y la latencia de liberación, no solo la CPU o la memoria.
Observe y planifique la capacidad
Mida la creación del Claim hasta la vinculación, la vinculación hasta la asignación en el nodo y la asignación hasta el estado Pod Ready como etapas separadas. Rastree la capacidad inactiva, asignada, no disponible y fragmentada, así como los errores del controlador. Concilie la capacidad anunciada por ResourceSlices con lo que los nodos realmente exponen; detenga la expansión del canary si divergen. Las plataformas de entrenamiento también deben registrar reintentos, recuperación de puntos de control (checkpoints) y eventos de salud del dispositivo.
Canary, rollback y consistencia
Comience con un controlador y un grupo de nodos utilizando trabajos reintentables. Expanda luego a múltiples inquilinos y plantillas; migre los trabajos de larga duración y no interrumpibles al final. Un rollback no significa eliminar Claims vinculados. Detenga la creación de nuevos Claims, deje que los Pods en ejecución finalicen o migren, congele los cambios en el controlador y redirija los nuevos trabajos al complemento antiguo. Conserve los eventos de Claim, Pod y controlador para que el incidente siga siendo diagnosticable.
Valide las API y los límites de seguridad
Antes del despliegue, ejecute pruebas de contrato contra las API de resource.k8s.io/v1 para versiones de Claim, Template, DeviceClass y ResourceSlice, transiciones de estado y orden de eliminación. Inyecte reinicios del controlador, pérdida de nodos, asignaciones duplicadas, Claims filtrados y accesos entre espacios de nombres. Verifique la admisión, RBAC, auditoría y los permisos del agente de nodo. Expanda el grupo de dispositivos únicamente después de que las métricas de funcionalidad, aislamiento y recuperación se superen con éxito.
Respuesta modelo de alta calidad
“Dividiría la migración en capas de modelo de recursos, controlador, programación y tiempo de ejecución. Las cargas de trabajo declaran Claims; las Templates los generan; DeviceClass expresa la selección; el controlador publica ResourceSlices y asigna en el nodo; el programador maneja la viabilidad y la elección del nodo. Los complementos antiguos y DRA coexisten por grupo o clase de dispositivo, nunca con doble propiedad. Para compartir recursos, requiero un modelo de capacidad del controlador y semánticas de liberación en lugar de sobreventa basada en etiquetas. Comienzo con trabajos reintentables, mido la latencia de Claim a Ready, fallas de asignación, fragmentación, salud del controlador y violaciones de inquilinos, luego detengo nuevos Claims y preservo el estado antes de redirigir los nuevos trabajos durante el rollback”.
Errores comunes
- Tratar DRA como nuevas etiquetas de dispositivo → la programación tiene éxito sin cumplimiento a nivel de nodo → haga que el controlador publique dispositivos estructurados y capacidad.
- Permitir que el complemento y DRA sean propietarios del mismo dispositivo → inicialización o asignación duplicada → particione la propiedad por grupo o clase de dispositivo.
- Diseñar Claims sin reclamación → se acumulan fugas de dispositivos y cuotas → defina liberación, tiempos de espera, eliminación y reconciliación.
- Simular el uso compartido con etiquetas → el programador no puede ver la capacidad restante real → haga que el controlador publique capacidad y concurrencia.
- Equiparar la selección de nodo con el éxito de la asignación → los errores del controlador dejan los Pods en Pending indefinidamente → separe las métricas de programación, asignación de nodo y Ready.
- Eliminar todos los Claims durante un rollback → los trabajos en ejecución y la evidencia desaparecen → congele nuevas asignaciones y preserve el estado.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Por qué no seguir registrando las GPU como recursos extendidos?
Los recursos extendidos se adaptan bien a solicitudes simples de cantidad, pero no expresan adecuadamente atributos de dispositivos, alternativas, capacidad compartida o configuraciones complejas. Si el requisito es solo el conteo de dispositivos completos y el controlador es maduro, la ruta antigua puede mantenerse. DRA debe introducirse cuando la selección de dispositivos y la complejidad del ciclo de vida lo justifiquen.
Pregunta de seguimiento 2: ¿Cómo previene la sobreventa cuando varios Pods hacen referencia a un mismo Claim?
Las semánticas de reutilización deben ser explícitas en el controlador y la política de la plataforma, no asumidas desde el YAML. Para la capacidad compartida, el controlador registra la capacidad asignada, los límites de concurrencia y el estado de liberación; la admisión limita las referencias que violen la política del inquilino.
Pregunta de seguimiento 3: ¿Debe el programador reintentar una falla del controlador durante la configuración del nodo?
Clasifique primero las fallas transitorias de nodo, las fallas de salud del dispositivo y los parámetros de Claim no válidos. Reintente las fallas transitorias con retroceso exponencial (backoff); marque los parámetros no válidos como no reintentables; aísle los nodos en mal estado para que el programador no envíe trabajo repetidamente al mismo dominio de falla.
Pregunta de seguimiento 4: ¿Cómo demuestra que la migración no redujo la utilización?
Compare el éxito de asignación, el tiempo de espera, la fragmentación, el tiempo de cómputo útil y la tasa de reintentos de trabajos para cargas de trabajo similares en el mismo grupo de dispositivos. Divida DRA y el complemento antiguo por clase de dispositivo; un promedio general de utilización de GPU en todo el clúster es insuficiente.