Planteamiento y contexto
Eres el responsable de un clúster de Kubernetes para tareas de entrenamiento e inferencia. Los nodos contienen H100, A100 y aceleradores más pequeños. Una carga de trabajo prefiere primero H100, luego A100 y, después, otro dispositivo compatible cuando no haya capacidad disponible. Diseña la solicitud y el flujo de programación de Dynamic Resource Allocation (DRA), cubriendo determinismo, equidad, fallos, observabilidad, migración y reversión (rollback). Responde como un ingeniero senior capaz de tomar decisiones arquitectónicas fundamentadas.
Qué evalúa el entrevistador
- Si la preferencia es una política verificable en lugar de un sondeo (polling) del lado del cliente o una asignación directa codificada de forma fija.
- Comprensión de los ciclos de vida de ResourceClaim, ResourceSlice, el driver y el scheduler.
- Desempate determinista, cambios de estado de salud, reintentos y tiempos de espera (timeouts).
- Asignación justa de capacidad, aislamiento de inquilinos (tenants), métricas y auditabilidad.
- Una ruta de migración reversible desde device plugins hacia DRA.
Preguntas para clarificar
- ¿Es aceptable cualquier alternativa disponible o la memoria, la arquitectura y las capacidades del driver deben seguir siendo restricciones duras?
- ¿Puede un Pod aceptar diferentes modelos de dispositivos? ¿Son la topología, NUMA y el ancho de banda de red restricciones duras?
- ¿El negocio requiere una garantía estricta de modelo o puede intercambiar la preferencia de modelo por tasa de éxito y costo?
- ¿Tienen los inquilinos cuotas, prioridades y reglas de desalojo (preemption)? ¿Cuándo se elimina un dispositivo no saludable de la lista de candidatos?
- ¿Pueden las cargas de trabajo existentes adoptar ResourceClaims y deben coexistir los antiguos device plugins durante la migración?
Respuesta en 30 segundos
Codificaría la preferencia de dispositivos como candidatos ordenados junto con restricciones duras en una solicitud de DRA, permitiendo que el scheduler asigne recursos durante el ciclo de vida de la reclamación en lugar de que los clientes sondeen los nodos. El scheduler filtra primero las restricciones de driver, arquitectura, topología y cuota del inquilino, y luego evalúa H100, A100 y otros dispositivos compatibles en orden. Cada nivel utiliza un criterio de desempate estable, y los eventos y métricas registran los candidatos, los motivos de rechazo y la elección final. Los cambios de estado de salud o los fallos de vinculación activan una reevaluación solo mientras la reclamación sea reintentable. Las cuotas de cola y los pesos de inquilino garantizan la equidad. La migración utiliza despliegues canary de doble vía, plantillas de ResourceClaim versionadas y un mecanismo de cambio hacia el plugin anterior.
Análisis paso a paso en profundidad
1. Definir el modelo de preferencias
Trata el orden del modelo como una preferencia blanda. Trata la versión del driver, la arquitectura, el piso de memoria, la topología y el aislamiento como restricciones duras. La solicitud puede indicar “H100 primero, A100 segundo”, pero la alternativa no debe eludir la memoria ni la cuota del inquilino. Incluye un identificador de política versionado para auditoría y reversión.
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
spec:
spec:
devices:
requests:
- name: accelerator
exactly:
deviceClassName: gpu
selectors:
- cel: "device.attributes['model'] == 'H100'"
- cel: "device.attributes['model'] == 'A100'"Los candidatos ordenados expresan la preferencia de negocio; el despliegue aún debe coincidir con la versión de la API de DRA y las capacidades del driver admitidas por el clúster.
2. Flujo de reclamación de recursos y programación
El Pod utiliza un ResourceClaimTemplate para crear una reclamación. Un driver de DRA publica ResourceSlices que contienen los atributos, la capacidad y el estado de salud de los dispositivos. Durante el prefiltrado, el scheduler lee las reclamaciones y los slices, verifica las restricciones duras y busca candidatos en orden. Tras la vinculación, el driver expone la asignación al contenedor. Las reclamaciones deben ser idempotentes para que los reintentos no creen una segunda asignación que no pueda recuperarse.
3. Elección determinista y explicación
Cuando un nivel tiene múltiples dispositivos, utiliza un orden estable basado en el pool de recursos, el nombre de ResourceSlice y el identificador de dispositivo, o una clasificación explícita de capacidad y topología. Haz que la regla forme parte del contrato de la interfaz. Registra los candidatos, los filtros, los motivos de rechazo, el dispositivo final y la versión de la política. Reproducir las mismas entradas debe producir el mismo resultado, y un operador debe poder explicar por qué se omitió un H100.
4. Comportamiento ante fallos, salud y reintentos
Las nuevas reclamaciones deben omitir los dispositivos marcados como no saludables; las cargas de trabajo ya vinculadas siguen la política del runtime y del controlador para terminación, migración o recreación. Distingue los conflictos de vinculación, los slices obsoletos y la pérdida de nodos como reintentables o terminales. Los reintentos necesitan retroceso exponencial (backoff) y una clave de idempotencia para evitar que los escaneos repetidos amplifiquen la carga del scheduler. Recurrir a un A100 solo es válido cuando las restricciones duras aún se cumplen, y el modelo real debe ser visible en el estado del Pod.
5. Equidad, capacidad y observabilidad
La preferencia no debe convertirse en un pase que reserve H100s indefinidamente. El arbitraje a nivel de cola utiliza la cuota del inquilino, el peso y el tiempo de espera; la elección a nivel de dispositivo sigue el orden de los candidatos. Monitorea el volumen de solicitudes por modelo, la tasa de uso de alternativas, el tiempo de espera, los fallos de vinculación, los cambios de salud, el uso por inquilino y la tasa de acierto de la política. Mantén una cadena de decisiones legible en los eventos evitando datos sensibles del inquilino en los registros.
6. Migración y reversión
Comienza con clases de DRA y plantillas de ResourceClaim para una pequeña porción de la carga de trabajo mientras los antiguos device plugins atienden el resto. Compara la tasa de éxito, la tasa de uso de alternativas, la latencia de programación y la utilización de GPUs antes de expandir. Versiona las plantillas y las políticas. Si surge un problema con el driver o la programación, detén la publicación de la nueva plantilla y cambia las cargas de trabajo de vuelta al plugin anterior; maneja las tareas ya vinculadas bajo la política de terminación establecida en lugar de cambiar reclamaciones y asignaciones de dispositivos simultáneamente.
Respuesta modelo
Separaría la preferencia, las restricciones y la prueba de asignación. La preferencia es una lista ordenada de candidatos. Las restricciones cubren la capacidad del modelo, la memoria, el driver, la topología, la cuota del inquilino y el aislamiento. Después de que el Pod crea un ResourceClaim, el driver de DRA publica ResourceSlices y el scheduler filtra las restricciones duras antes de seleccionar los candidatos en orden. Un orden estable de pool de recursos e identificador de dispositivo resuelve empates, haciendo que la reproducción sea determinista. Los eventos incluyen candidatos, motivos de rechazo, versión de la política y el modelo real.
Las rutas de fallo distinguen entre dispositivos no saludables, conflictos de vinculación, reclamaciones obsoletas y pérdida de nodos. Solo los errores reintentables utilizan backoff; la alternativa nunca infringe una restricción dura y el modelo final se escribe en el status. La cuota de inquilino, el peso en cola y el tiempo de espera protegen la equidad para que la preferencia por H100 no desabastezca a otros inquilinos. La migración ejecuta los plugins antiguos y DRA en modalidad canary, con plantillas versionadas y un interruptor de reversión probado.
Errores comunes
- Decir únicamente “ordenar por modelo” sin restricciones duras o sin un criterio de desempate dentro del nivel.
- Permitir que los clientes escaneen nodos o reclamen dispositivos directamente, eludiendo las reclamaciones y el scheduler.
- Tratar los cambios de salud, los conflictos de vinculación y las restricciones insatisfactorias como reintentos infinitos.
- Optimizar únicamente la tasa de acierto de H100 ignorando la equidad de inquilinos, la cuota y el tiempo de espera.
- Eliminar los antiguos device plugins en un solo paso, sin dejar una vía de reversión rápida.
- Registrar únicamente el dispositivo final y perder la evidencia de los candidatos y los rechazos.
Preguntas de seguimiento y respuestas
Si tanto H100 como A100 satisfacen las restricciones, ¿por qué no elegir aleatoriamente?
La elección aleatoria debilita la capacidad de reproducción y el diagnóstico. El balanceo de capacidad puede seguir un orden estable, pero la regla debe seguir siendo explicable y observable; una semilla aleatoria no debe convertirse en un contrato oculto.
¿Qué sucede si un dispositivo pasa a no saludable después del prefiltrado pero antes de la vinculación?
Vuelve a verificar la versión y la salud en el momento de la vinculación. Devuelve un error clasificado y reintenta con backoff solo cuando la reclamación siga siendo válida y existan candidatos; de lo contrario, expón un motivo claro de insatisfacción en el Pod.
¿Cómo demuestras que el uso de alternativas no perjudicó la equidad?
Mide el tiempo de espera, el uso, la tasa de uso de alternativas y la participación en la cola por inquilino y modelo, luego compara cohortes de reproducción y de canary. Si un inquilino rara vez obtiene su primera opción, ajusta la cuota o el peso en lugar de aumentar continuamente la prioridad de la solicitud.